OpenHAB vs HomeAssistant Rules #2

Another OH vs HA rule

Simple Event Based Rule

Turn on the socket at sunset.

OpenHAB

rule "Sunset lamp on"
when
    Channel 'astro:sun:local:set#event' triggered START
then
    Switch_Socket_Status.sendCommand(ON) 
end

Home Assistant

id: switch_on
alias: Turn switch on
description: Turn switch on at sunset everyday
trigger:
    platform: sun
    event: sunset
 action:
  - entity_id: switch.switch_13
    service: switch.turn_on

 

So simple event rule, easy to read and understand as before. In this case I think the simple ‘event driven’ approach of HA is probably easier to understand rather than OH channel event model.

** Update **

Jython version…. (I think!)

"""
These rules trigger the socket at sunset
"""

from core.rules import rule
from core.triggers import when

@rule("Socket controller - ON", description="This rule turns on the socket at sunset", tags=["Socket", "Lounge"])
@when("Channel astro:sun:local:set#event triggered START")
def socket_control(event):
    socket_control.log.info("Socket ON")
    events.sendCommand("Switch_Socket_Status","ON")

Again, theoretical at this point – until OH is stable, I’m NOT adding Jython!!

OpenHAB Changes

I’ve spent some time trying to fix the stability issues I’ve been having with OH. As part of this, I’ve borrowed a NUC and installed Ubuntu Server 18.04 LTS and OpenHABian. This gives me the same basic system I have been running on the Rpi but with a lot more grunt.

Apart from the base system and OH, I’ve also added some basic Python PIP libraries used to monitor the heating in addition to the EvoHome binding.

(On a side note – the EVoHome binding just suddenly started to work – still no idea why!)

I’ve also installed NodeJS and Zigbee2MQTT to make use of the CC2531 USB stick I got over Christmas. With Zigbee2MQTT (Z2M) running, I’ve also now completely removed the Tradfri binding making the bulb, 2x sockets and ‘control drivers’ (on/off switch & 5 button remote) work solely through Z2M.

The Xiaomi Mi Home has also almost been replaced – so far I’ve migrated 3 buttons and 4 temperature sensors to Z2M. I’ve still got 2 door sensors to move, but I need to figure out how to get the CC stick near to the doors for pairing!

Building the NUC highlighted a flaw in the plan to just use the NUC – it lacks BT capabilities and I rely on that to do presence detection. As I don’t have any BT dongles hanging around, I initially turned off those particular scripts.

So far the system has been quite stable. Lots of thing, item & rule changes have not caused issues during the Z2M migration. Several updates – both openhabian-config and normal apt driven have also occurred without the restart blues I’ve previously encountered.

** UPDATE **
I’ve wondered if the instability of OH over the past few months has been less due to OH and more due to the additional power drain caused by the CC2531 and Z-Wave stick being plugged in (not necessarily being used by OH). Could the extra power drain combined with more resources used by the new OH2.5 version be causing the issue? The RFXCom adapter didn’t cause an issue, so why would swapping it out for the Z2M controller make any difference?

** UPDATE 2 **
So if I’m missing BT & BTLE detection and there’s an issue running the CC2531 on the same Rpi as OH, then maybe the answer is to deploy a Rpi that does nothing but act as a hub – BT/BTLE, Z2M and possibly Z-Wave later. A second Rpi could then just run OH2 and talk to the MQTT broker for the BT & Z2M info.

This hub Pi I’ve dubbed Oracle and it’s been built, but I’ve not yet had a chance to swap the CC2531 stick over and install it where the old Tradfri hub once sat. It is doing the BT/BTLE detection for me, so bits are working OK