123
Senior Member
There are many things I like about Home Assistant and openHAB. So far, I tend to favor the way things are done in Home Assistant. However, there's one thing I don't like that's common to both and that's the way they handle automation logic.
To be blunt, it's fugly.
Here's a simple example, make one light control another. When you turn on/off Hutch Light, Wall Light should also turn on/off. In Premise, that's done with one line in Hutch Light's OnChangePowerState script:
Home.WallLight.PowerState = this.PowerState
Alternately:
Home.WallLight.PowerState = sysevent.NewVal
In Home Assistant, it looks like this (this is YAML and Jinja2):
alias: 'Hutch Light controls Wall Light'
trigger:
platform: state
entity_id: switch.hutch_light
action:
- service_template: >
{% if is_state('switch.hutch_light', 'on') %}
switch.turn_on
{% else is_state('switch.hutch_light', 'off') %}
switch.turn_off
{% endif %}
entity_id: switch.wall_light
OpenHAB's Rules DSL isn't any simpler (I won't bother with an example). Some users have switched to using Node-Red to handle automation logic, effectively abandoning the native rules engine and using a completely separate product.
This just scratches the surface of how differently automation logic works in these two HA systems (and not necessarily for the better). Home Assistant can easily schedule something to run at a specific minute, hour, or day but has nothing to run it at a specific date (like December 25th). The way it's done involves parsing time out of strings and is a far cry from the ease of using Premise's Schedule.
To be fair, I enjoy using them for the additional functionality they provide (like secure remote-access, modern user-interfaces, recording history of all activities, and integration with HomeKit). However, I don't think I'll be porting my existing automation logic to either Home Assistant or OpenHAB.
If any one is interested in learning more about the strengths and weaknesses of these two systems, and how they compare with Premise, let me know and I'll elaborate
To be blunt, it's fugly.
Here's a simple example, make one light control another. When you turn on/off Hutch Light, Wall Light should also turn on/off. In Premise, that's done with one line in Hutch Light's OnChangePowerState script:
Home.WallLight.PowerState = this.PowerState
Alternately:
Home.WallLight.PowerState = sysevent.NewVal
In Home Assistant, it looks like this (this is YAML and Jinja2):
alias: 'Hutch Light controls Wall Light'
trigger:
platform: state
entity_id: switch.hutch_light
action:
- service_template: >
{% if is_state('switch.hutch_light', 'on') %}
switch.turn_on
{% else is_state('switch.hutch_light', 'off') %}
switch.turn_off
{% endif %}
entity_id: switch.wall_light
OpenHAB's Rules DSL isn't any simpler (I won't bother with an example). Some users have switched to using Node-Red to handle automation logic, effectively abandoning the native rules engine and using a completely separate product.
This just scratches the surface of how differently automation logic works in these two HA systems (and not necessarily for the better). Home Assistant can easily schedule something to run at a specific minute, hour, or day but has nothing to run it at a specific date (like December 25th). The way it's done involves parsing time out of strings and is a far cry from the ease of using Premise's Schedule.
To be fair, I enjoy using them for the additional functionality they provide (like secure remote-access, modern user-interfaces, recording history of all activities, and integration with HomeKit). However, I don't think I'll be porting my existing automation logic to either Home Assistant or OpenHAB.
If any one is interested in learning more about the strengths and weaknesses of these two systems, and how they compare with Premise, let me know and I'll elaborate