OpenHAB or HAAS

Setup, Configuration and Use Beginners
1

Hi
I am trying to migrate from SmartThings to an open source solution, which does not require cloud.
I am looking into HAAS and OpenHAB. I am still navigating around and I would like to ask the community for with some recommendations

Currently I have Smartthings automation with few Zwave dimmers, switches, door contacts, integration with Alexa, zwave thermostat, few motion sensors, siren, smoke alarm. Most of the devices are ZWave, but i have few ZigBEE IRIS motion sensors and ZigBee SmartThings presence sensor.

I need to have an Alarm System (integrate motion sensors with door contacts) , Presence Detection, Text To Voice announcements on my tablet, plus control terminal

Which platform would be easier to integrate and supports above?

thanks

2

It all sounds very OpenHAB-able.

Zigbee support might be weak at the moment, I think depends on your controller

Don’t know what HAAS is - this?

I think that is more of a consultancy solution delivered

See also this older enquiry

3

“HAAS” : https://home-assistant.io/

4

You are asking the butcher where to buy your meat. :slight_smile:

openHAB is versatile, has a steep learning curve.
HASS looks simpler from the surface but eventually you will need to dive in deep, too.
Both basically use a text based configuration.
If you like to develop yourself you have the choice of Java vs Python.

Perhaps it’s better to ask if your setup will work with OH.

1 Like
5

That’s right … :slight_smile:

Sort of described my setup. I understand the ZigBee support is not very strong in both platforms.

What still keeps to jump right in is for me trying to understand how the things are structured and work from the documentation and asking silly questions :slight_smile: .

I also have to figure out what’s involved in creating a custom “Thing” which support events and other parameters. With Smarthings I have used a tablet (custom Windows app controlled with http through SmartThings) to display SmartTiles through IE for house control, display keypad to disable alarm in AWAY mode, also as media player to play sounds and speak. I would like to reuse the setup and just create a Thing with OpenHub to control it (with http/json)

  • Any pointer on what’s involved in creating a Thing? Is it a scripts based or i need to recompile to binaries? (in SmartThings the Thing was a plug in script I can attach at any point while system running). This thing will have multiple items for alarm control, media player, etc

  • I hope iris motion sensor (ZigBee) is supported (https://www.lowes.com/pd/Iris-Motion-Sensor-Works-with-Iris/999925310 ). I have few of those… Anybody have experience integrating those

  • Also is there any additional scripting approach (in addition to the Rules Script) to automate

thank you all for your replies.

I will go through the other blog provided by rossko57

6

First of all, I would point you misunderstand what a Thing is in OH. I recommend reviewing the Concepts and the Beginner’s Tutorial.

Things are completely and wholly unlike Things in SmartThings. A Thing represents a Device. Each piece of information that device reports and/or each way that device can be controlled is exposed as a Channel. Channels are linked to Items. One writes Rules and displays in their UIs based on Items.

To create a “custom Thing” in OH one would have to write a new binding. But that doesn’t really sound like what you are after.

I don’t know any details but believe you might be able to modify your tablet UI to interact with OH’s REST API. I don’t know of any way (without a lot more details) how one could make changes to only openHAB configurations to make it work, but I don’t know details. Perhaps something could be set up in Rules using the HTTP Actions.

I doubt there are many if any users using and Zigbee devices directly with OH yet. The Zigbee binding is still under development and not yet released so there are very few people who are actively using it as far as I’m aware. There are people who are working with these types of devices through a Wink, Hue, or Vera Hub though as OH does have the ability to interact with those hubs. That is one approach to access and control Zigbee devices in the mean time until the Zigbee binding matures and is released for general use.

If using OH 1 one can use the JSR233 binding which lets you code in Jython, JavaScript or Groovy. Support for OH 2 is in work.

There is the Experimental Rules Engine, though it is experimental and comes with very little support or documentation.

Some people interface OH with NodeRed through MQTT and code some or all of their logic in NodeRed.

OH has the ability to call programs and shells directly.

7

To add to what Rich said, I think you need to take a step back and take a higher level view. You will need to ask yourself “what am I trying to accomplish and how do I get there.” All three platforms probably have a lot of similar functionality, but the implementation is going to be very different between them.

I’ve been using OH/2 for a while now, and have recently been looking into HASS. Not necessarily because I have a problem with OH, but because HASS seems to be pretty popular and I thought I would investigate to see if I was missing something.

Some observations from my experience.

HASS seems to have a reputation for being “easier” and I can see where that comes from. I didn’t get too deep into it (added some of my MQTT switches), but even from browsing their documentation it seemed that many things might be less complicated to accomplish than OH. I would almost liken it to assembling an Ikea desk vs building a desk from raw materials. I think a lot of this comes from the next point.

I do have to say that laying out your GUI seems to be less flexible with HASS.

HASS seems to have a higher level of abstraction. OH is limited to the few built in Item types. Switch, Dimmer, Number, etc. I’m sure HASS is too to an extent, but a good example is the Media Player component. There are more than a dozen different kinds of specific media players, but since they all conform to the Media Player class, they all share common and consistent controls.

One thing that was a pretty big turn off for HASS was the configuration structure. The YAML configuration itself didn’t bother me. Like I said, each platform is going to have different ways of doing things. My problem was that everything is dumped into a single config file. Pretty easy to see how this will quickly become unwieldy. I found that you can break it out somewhat into separate files, but you can only have one file for each type of component. i.e. one file for automations, one file for switches, one file for sensors.

OH on the other hand seems very logically structured. You have a folder for all of your items files, a folder for all of your rules, etc.

I can’t say that I’ve found any killer feature that would push me towards one or the other, so I’ve stuck with OH so far. There are things I like about each, and things I don’t. I don’t think I would let my comments about HASS possibly being “easier” sway you either. Both are going to require you to get down and dirty with config files, and once you get past simple things like adding a switch or sensor, I have a feeling there’s not going to be a lot of differences.

8

Thanks for the explanation. Correct… probably I need a binding then… this will have Channels such as “Arm (i.e. lock the screen, show keypad)”, “Disarm (i.e. hide keypad, show home control through a browser”, "Play mp3 (i.e. Say “Home Disarmed”. All these channels I can hook up to items within OpenHub and control through automation (I.e. if present then disarm, Play ) . Currently all these commands are communicated through http/get/ call (http://xx.xx.xx:8080/request.json?play=Hello.mp3).

Potentially I can setup the different Items to communicate through the same http channel (with different JSON transformation), but then all items will be pinging independently to get an update of the status (i.e. will have 10 independent pings to update 10 items, rather than one ping to update all 10 channels if this is a binding)

Of course I can change the whole setup as you suggested, but then it would be double the work :slight_smile: . But might be the right approach to update to REST API.

thanks guys for the discussion

9

Old thread sorry (over 1 year), but I am in the same situation. Have a pretty good working OpenHAB system…some of my rules etc I feel are a little too complex and very java based, and also I like coding in python to that has lent to to start looking at Home Assistant.

Now if you’re installing on Rasp Pi, HASSio seems quite straight forward, and their documentation is fairly well set up for it. But if you’re running in a straight linux system the documentation seems out the window, as it doesn’t seem to cover it, and there’s no concept on addons in the linux system.

That aside, I was able to get a system up and running, and I think for store bought components it has the edge on OpenHAB, it seems to find my plex server, chromecasts and a few other things out of the box (incidentally as I don’t actually wnt them in a HA system it was annoying to get rid of them, I prefer the OH install what I want, as opposed to disable what I dont model).

And regarding the mammoth configuraion.yaml file…OMG this did my head in. But you can separate it. There’s one post that discusses it, and doesn’t do a very good job, but I did manage to get my sensors in one file, switches in another. Better, but nowhere near like my OH setup where I consolidate by technology (DHT sensors in dht.items, zwave.items etc). And groups, don’t get me started on that, seems very complicated, I really like the openhab items config, mostly a single line config that lists it’s name, label, icon and group definitions. HA goes the otherway around in that you define your items…split by type, then you have a separate file to specifying the groups and entities (items) in that group, there’s no real link.

MQTT setups in Home Assistant (of which my setup is very dependant on), felt unwieldy, especially if you’re defining switches and sensors. But the common interfaces of items (media player, alarms etc) i did thinks was done quite well.

Also I agree about the UI, specifying groups and how you’d make it look (say for basic ui) seems much easier in the openhab world, especially with the way you specify what items are in a group.

Their equivalent of the openhab rules engine seems more featured, and creates automation files…what OH calls a rules file, these is a feature I think is a good idea, so that you can extend them…but while I said it seems more featured, the amount of time it took me to get one switch to turn on was just ridiculous, no .sendCommand, I had to go find the item (entity), and then write some json to a service call on turning it on…weird concept.

The other reason I’m potentially considering HA, is I think it would be less resource intensive that an java application…that’s anecdotal.

10

Have you reviewed any of the design patterns? They are intended to show good ways to solve common problems in rules in a way that avoids some of the pitfalls that arise when one tries to code in Rules DSL as if it were a “standard” language. I also frequently help people simplify their rules code, is how I’ve come up with half of the DP postings I’ve made.

Are you aware of the JSR223 binding that lets you code Rules in Jython, JavaScript, or Groovey? While the Rules DSL is the default and most documented, it is by no means the only option. There are also several python libraries that make coding rules in these languages even more natural than the raw jsr223 interface.

This is actually one of the focuses for the Experimental Rules Engine. Eventually we will be able to import and export rules as libraries instead of copying then from web pages and forum postings.

And if you use JSR223, you have the full set of features for whatever language you choose including libraries, classes, inheritance, etc.

That may be true but notepad is less resource intensive than notepad++. But since they both user so little resources to begin with, does that really matter? I doubt you would see much of a meaningful difference between the two.

11

Very possible, it’s just with the move from a Windows gigabyte brix (AMD A6) to an odroid c2, is I notice a particular rule (night time + open study door reed switch = turn on lights) is slower to react, from < 1 second to between 0.5 > 5 seconds.

In terms of CPU usage.memory usage I don’t think I’m stressing the platform at all.

12

That’s odd but I can see some potential causes, without actually seeing the rules themselves or logs:

  • do you have Thread::sleeps or other long running commands in your Rules (executeCommandLine, sendHttp*request, indeterminate while loops, etc). What could be happening is that you are at the max number of Rule threads and if that is the case it will introduce latency (best case) in when your Rules run since only 5 can run at a given time. If this is in fact the problem there are usually plenty of alternative approaches to avoid these long running Rules and there is a property in the useradata/etc folder somewhere where you can increase the number of threads available to rules.

  • there is something different with this binding while running on the odroid c2 that is causing it to perform poorly

  • there is something different with the physical devices or the way the devices communicate with the binding on the odroid c2.

13

I should experiment with the rules ui.

I should also look for a method of chaining more complex rules but allowing them to be split into smaller parts.

But what I can’t quite get my head around is somethin glike a set of rules where i say:
If the alarm is disarmed and night time, turn on light (zwave) 1, 2 (outside) and 3 (lamp inside) for 15 mins. This works fine.

But then there’s another rule which is every 5 mins, check if the time is between two values, ie 17:00 and 23:00, if so turn on light 3, otherwise turn it off.

Both these rules work, but the unintended consequence is that the lamp light (number 3) is turned on when the alarm is disarmed, but rather than staying on the 15 mins, it’s turned off when the next timed check occurs as it’s outside the 17:00 to 23:00 period.

So while it would be nice to drive rules on small discrete actions, how they interfere with each other (IMO) drives more complex code.

14
  1. Separate the calculations of states. So don’t check whether it is between 17:00 and 23:00 in your lighting rule, put that into it’s own Rule and set an Item ([Deprecated] Design Pattern: Time Of Day).
  2. Do the same for any other relevant state like your alarm being armed and the like.
  3. Have your lighting Rule triggered based on changes to these states and make the correct calculation for the lighting.

So you one Rule for lighting could look something like

rule "alarm lighting"
when
    Item vAlarm changed
then
    if(triggeringItem.state == "DISARMED" && vTimeOfDay.state == "NIGHT")  {
        Light1.sendCommand(ON)
        Light2.sendCommand(ON)
        Light3.sendCommand(ON) 
        createTimer(now.plusMinutes(15), [ | 
            Light1.sendCommand(OFF) 
            Light2.sendCommand(OFF)
            // the rule below will turn off the light.
        ]
    }
end

rule "Night Light"
when
    Item vTimeOfDay changed
then
    Light3.sendCommand(if(triggeringItem.state == "EVENING" || triggeringItem.state == "NIGHT") ON else OFF)
end

And even the above is pretty sloppy code and could probably be dropped by half. But it does what you need. Small discrete Rules that DON’T interact with each other.

As it is with writing prose, it often takes MORE work and experience and is harder to make code simpler and shorter.

15

hello guy, I’m beginner even latest beginner i have tried a lot and kudos to mksmart house for his tutorials are helpful to me, pls some one should help me with my OPENHAB2 automation project,
At the first entry to my openhab2 i choose STANDARD after a lot of trouble i figure out how to add some things to my BASIC UI, HOME BUILDER, and others but how can add or control GPIO pins with this ITEMS.

16

You need to use the gpio binding. The readme will have all the details for how to set it up and configure items to work with it. Though I’ll caution that gpio is a bit tricky to get working the way you want. I do not recommend it for beginners.