Premise Premise vs Home Assistant and openHAB

[123]

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 

 

[Shinyshoes]

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 

 
I certainly am.  I have been tinkering with other systems but I am in much of the same situation as you, where many of my components that work with premise don't with others.  (Elk M1, UPB, Weeder Digital I/O, Nuvo Grand Concerto, etc.)  Now that Home Assistant got an interface for the Elk, I'm starting to weigh my options.  Your MQTT bridge is certainly a good way to ease the transition.  I'm going to see where the Elk Driver takes me and go from there, but any other comments you have about HomeAssistant, I have always valued your opinion.  Half of the gear I own is because I was copying you........

 

[roussell]

123 have you tried loading AppDaemon on your HA instance yet? My understanding is that it allows one to write logic using Python instead of trudging through YAML. I haven’t yet tried it as I’m in a “just playing with it” stage of Home Assistant, but it does seem to have the capabilities to get closer to your Premise example.

Terry


Sent from my iPhone using Tapatalk

 

[123]

123 have you tried loading AppDaemon on your HA instance yet?

Not yet but I have read its documentation. Basically, it's like Premise's Modules. It provides an API so you can create 'apps', in python, to do pretty much anything (without the limitations of YAML or Jinja2 and with full access to python libraries). However, whereas Modules let you easily do a few common things, like create global variables or a timer, without scripting, AppDaemon is 100% python programming (i.e. no free lunch).
 

I certainly am.  I have been tinkering with other systems but I am in much of the same situation as you, where many of my components that work with premise don't with others.  (Elk M1, UPB, Weeder Digital I/O, Nuvo Grand Concerto, etc.)  Now that Home Assistant got an interface for the Elk, I'm starting to weigh my options.  Your MQTT bridge is certainly a good way to ease the transition.  I'm going to see where the Elk Driver takes me and go from there, but any other comments you have about HomeAssistant, I have always valued your opinion.  Half of the gear I own is because I was copying you........

I'll organize my thoughts about what I've learned so far and post them. It may take awhile!
 
I think you'll find Premise's version of the ELK M1 driver is easier to configure and use than the one recently created for Home Assistant (by virtue of Premise Builder's visual presentation). I continue to run both Premise and Home Assistant and use Premise's ELK M1 driver via SyseventBroker ("MQTT bridge"). However, if your goal is to completely switch to Home Assistant then yes, you'll need to become comfortable with its ELK M1 component.
 
BTW, I'm far from being a programming whiz but it took me about three months to write Premise's ELK M1 driver. It was one of the first drivers I created so it was a tall order for me. Nevertheless, I credit the highly productive development environment provided by Modules (and copious examples and good documentation) for my ability to quickly produce the driver (and by myself). In contrast, Home Assistant's ELK M1 driver took well over a year to create and one look at its code confirms it wasn't written by python newbies (like me). All this to say that it's more challenging to develop for Home Assistant than for Premise. So far, all I've been able to do is tweak a few existing components, to suit my needs, but writing a new one from scratch remains beyond my grasp.