My path to OpenHAB and onward

Tutorials & Examples openHAB Stories
1

Hello all, as there has been a good amount of discussion lately about “what should be next” and “how should openhab work” and “how are users perceiving things” and “how can we fix the docs” etc … I’d like to take a few minutes to put together my thoughts about how I’ve gotten to where I am today and what my plans are next.

First: thank you all for your help. This forum has essentially become my “home page” lately because I enjoy seeing the projects people are working on (new ideas!), I have questions of my own to ask, and occasionally I’m able to chime in and help others figure things out.

TOO LONG, DIDN’T READ:

  • I made my first pull request for OpenHAB documentation this week, I will be trying to find more ways to help there.
  • I don’t trust discovery.
  • I understand OpenHAB 1.x but not OpenHAB 2.x programming.
  • I tried once tried to use Maven to install a modified add-on. It did not go well.
  • I know where the Jenkins server is, I haven’t a clue how to find anything there.
  • I am not personally comfortable using snapshot releases. Sure one binding may be fixed or better in the snapshot 2.5 - but which other bindings and system things are being “worked on” in the snapshot? My setup has more than one thing.

My OpenHAB days started in April or so 2018. Previous to that I was a Home Assistant user. Previous to that all of my home automation was strictly Apple HomeKit. At this point, Insteon switches and HomeKit are the main user interface in my house.

How I found OpenHAB

I was going over my notes yesterday (cleaning out my office at work) and saw all of my past lists and progression from when I dumped the “homekit only” approach for a more powerful open-source system.

My first system, put together summer 2017 was homekit only. I bought Insteon switches for our new house, installed them everywhere, threw in a homekit insteon hub - and was off. I quickly learned the limitations of the Insteon homekit hub, each can only properly handle 10 devices. There is no hope of any upgraded firmware from insteon, they’ve essentially abandoned this hub and are done with it. I found a workaround for my system of about 30 switches: use 3 hubs. What a mess. At this time I also had HomeBridge garage door opening abilities (pi zero w) and a honeywell homekit thermostat.

My second system was home assistant. This was running on a pi 3 b+ with the Insteon USB PLM. I was (and am) stuck on insteon because I’m not about to go out and re-purchase and re-wire my now 40+ light switches. Great - home assistant might be better. I got home assistant up and running and able to control insteon PLM devices within about 2 hours! Wow! It’s pretty easy to set up but I quickly ran into some issues. It’s insteon features were lacking, it didn’t seem to work properly with my onkyo AV system, and it had “system timeout” errors in the log that nobody could explain. I used Home Assistant for 3 or 4 months.

Then I started looking into OpenHAB. I’ve got my notes right here from last April about pros/cons of Home Assistant vs OpenHAB. It came down to one thing: OpenHAB might work better with insteon. I have a list of my 3 “insteon dreams” that would be available with openhab:
1- Fast on/off
2- Insteon “virtual scenes”
3- Set the on level of the dimmer

Begin revision 3 - switch to OpenHAB. I got the basics up and running pretty quickly. I could control my lights. I found the Expire binding pretty quickly. I was still scared of MQTT because I did not understand it. I had seen some people talk about NodeRed at this point - again I had no idea how it worked so I stayed away. I could understand OpenHAB .items files and .rules files.

In my first weeks with OpenHAB I wanted to match the features of my previous Home Assistant install:

  • Lights controlled through homekit
  • Some switches turn off after 30 or 45 minutes
  • Lights respond to Apple TV play state
  • System knows when Onkyo AVR is on/off
  • Lights turn off when we leave the house (dummy switch controlled by homekit)

I got most of that working well. The Apple TV was the only failing point. I was also disappointed with the HomeKit limitations (as you know if you’ve seen me around the forums). My first solution to this was to put Home Assistant back on a second pi and link them up with MQTT. So I spent a week learning how to use MQTT, that was really far more complicated than it should have been because searching the forums anywhere for “MQTT” brings up a huge amount of information - it was difficult to find anything for a beginner MQTT user. Anyway I got things set up and I had things going.

Revision 3.5? I was running OpenHAB and Home Assistant. Devices in the house at this point were:

  • HomeKit only thermostat
  • HomeKit only garage doors
  • Insteon switches/dimmers controlled by OpenHAB
  • Insteon scenes programmed by insteon terminal, working properly in OpenHAB
  • OpenHAB built-in HomeKit bridge for lights and dimmers
  • Insteon + Chinese curtain motor controlled by OpenHAB
  • Smoke detectors connected to OpenHAB GPIO
  • MQTT link between OpenHAB and Home Assistant
  • Home Assistant to HomeKit “curtain” control so my curtain would show as a window in HomeKit instead of a “switch” (didn’t like to say "hey siri turn on the window)
  • Home Assistant to HomeKit “smoke detector” because OpenHAB doesn’t support HomeKit smoke detector
  • Home Assistant to Apple TV “play state”

At this point I was pretty comfortable with open source programs. I was about to switch back to Home Assistant exclusively. There’s a guy over there slowly putting together an insteon-mqtt bridge that should add some very cool features for the insteon system (namely eventually programming scenes through yaml instead of insteon terminal).

My first “contribution” to the OpenHAB world

I was watching the insteon-mqtt development on github and saw that they had recently added the ability to set the “on level” of a switch through rules. I needed it. I knew it was possible to add features to the insteon binding through XML files. I did some research and got it working. I couldn’t find anyone else on OpenHAB who had done this so I wrote up a post on it: Insteon set on level.

Progress beyond "new user"

After adding the on level feature I set out to fix my other problems. Next was HomeKit. It’s no secret that the OpenHAB HomeKit add on is not great. Enter Node-Red. I actually installed it, tried to use it, and deleted it at least twice before sticking with it. Eventually I got so fed up with setting a dimmer level to 25% but instead getting half a second of 25% before 100% brightness that I stuck with node red. It was worth the effort.

In August-September I really got into the node red setup. It “clicked”. It was easy. I didn’t have to use xtend rules (I’m actually not convinced that ANYONE knows all of the things that are possible in xtend - as a new user I was trying to figure out how to get the time of day and had a nice struggle with JODA time). Node red was definitely part of my future.

I have two big things in Node red. The big one is linking my HomeKit to my OpenHAB items. I’ve actually been able to fix all of my OpenHAB HomeKit complaints with this setup. Dimmers turn on to the level I set, there’s no more disco dance party when I slide a dimmer on my phone. Changing an .items file no longer destroys my HomeKit setup. I’m able to put all kinds of items into HomeKit (without Home Assistant!) including dimmer, switch, outlet, light, window, smoke detector, sprinkler, occupancy detector, etc.

By October last year I had my node red system set up and documented for the OpenHAB world Node Red + HomeKit. It is great. It’s still nearly unchanged from what it was when I made that post.

I’m using node red to run a command line version of pyatv.

Next steps and current struggles
My current project is getting ready for the 2.4 update. I’m on my 4th “erase the SD card and try again”.

My first try was to use the embedded mqtt broker with the 2.4 mqtt binding. The embedded broker has what’s been described as “very verbose” and I get a list of “Session does not exist” warnings. That’ll be fixed - use Mosquitto for now. Fine. (NOTE During this round I found an error in the openhab docs and made my first pull request to fix the doc!! More of that to come.)

My second try was to make a “dummy homie switch” on node red and try discovery. This item was discovered, I added a switch, and it didn’t work. I think I was sending 1/0 from openhab and looking for on/off in nodered. I erased before figuring that out.

My third try was mosquitto again - but just with a manual configured switch. I got this working. Then I tried deleting it and re-adding it - no luck. Erase again.

My fourth try (this morning) was to turn on Tasmota Home Assistant discovery on a Sonoff and have it be discovered in OpenHAB. I knew there was an error with this, but I tried it anyway. It now shows as “online” as a switch but I can’t select a profile - there are no profiles. I did add an item though.

What I’m learning through this is that I’m very comfortable with OpenHAB 1.x programming and not at all comfortable with 2.x. Also I do not trust discovery.

My experiences with discovery:

  • OpenHAB discovers my Onkyo as “not supported” and if I add it using discovery it shows 3 zones instead of 2 - and still always shows in the inbox. I’ve manually configured with the IP address in a .things file and it’s been working for months.
  • Home Assistant “discovered” tons of things that never worked
  • The MQTT 2.4 discovery is only like 90% ready for use. Homie is probably good but MY devices don’t support homie. Home Assistant discovery has bugs which have been fixed but are only available on snapshot release.

Conclusion
If you read all (or some) of that - you are a true hero. I want to help. I’ve been watching @Andrew_Rowe with his recent “improve the docs” campaign. I have big dreams of learning to program and eventually contribute to new bindings (insteon 2 anyone?!) but that’s likely a long ways off.

I plan to continue “hanging out” on the forums and trying to help where I can. I plan to go figure out openhab 2.x programming. Thanks again to all!

9 Likes
2

Hey @crxporter thanks for the call out!
campaign is an appropriate term, it’s going to take all of us working together

That the spirit!
I strongly believe in the idea of open source software. I want to contribute because I get to use the software for free and I want to see it gain popularity and get even better.
I enjoyed the story of your ‘journey’ in home automation and getting there is half the fun.

3

Welcome to OH. With Insteon, you might want to consider getting an ISY99. I use that with my 2 OH setups. Insteon networks can be hard to maintain, especially when a device fails. The ISY allows for easy link management and device replacement.

In OH, I mainly use Insteon scenes and do not reference specific devices. By doing this, I don’t have to worry about changing any OH automations when a device needs to be replaced as the code in OH only references the scene and not the device.

Best

4

Michael-

I’ve considered the isy “upgrade” for the last two years since I got my first batch of Insteon switches. You’re one of the first I’ve heard from who uses it with openhab. I have about 30 switches/dimmers and one curtain controller (seen in openhab as a dimmer). If you have a minute I’ve got a few questions-

How long have you used Insteon/isy?
Have you ever had a device fail (need to be replaced)? Device, controller, or both?
I know the serial PLM’s had issues in the past - does the isy work with a usb PLM?
Which binding do you use?

At this point I’m quite happy with the Insteon binding combined with some programming/backup with Insteon terminal. The terminal allows for modem backup and device swapping for scenes, etc - like you do with the isy. I’m sure the isy may be easier to manage but for the $200 or so entry price I don’t mind the extra programming.

Additionally I would need at least equal features with the isy including -

  • fast on/off
  • set on level without turning on a dimmer (lights turn on bright in the day and dim at night)
  • press-hold up/down being sent to openhab (Insteon binding handles this as a 0, 1, 2 number state item)
  • group scenes (I know this is available)

Does isy do all of this? What other “selling points” do you see in the change?

5

Hi Garret,

I have been an Insteon user since the devices first came out in the early 2000’s. Between my home and cabin I have about 170 or devices.

Failure rate is device dependent - I still have some original devices that work (PluginLinc). The newer switches seem to be more robust. That being said, I just did my annual device replacement of about 6 dead switches in my home. Most were 2-3 year old switches. This is where the value of the ISY comes in - otherwise it would take hours to replace the links and restore scenes. At 30 devices, this will be easier but still painful…

The ISY works exactly like the PLM - ie all the same commands are available. Long presses and fast taps can also be detected.

Biggest selling point though is link management. You can also do programming on the ISY, which I use for keeping keypadlinc buttons in sync for various scenes.

6

Im going to bring this chat back over here.

You’re really pushing that ISY thing huh? Must be good! You’ve got me thinking at least. But I don’t see a 2.x ISY binding in the add ones list- are you sure it’s there?

7

Update - just found the new binding discussion in the forums. I’d be quite wary of something who’s developer dropped out before it’s even official.

I’ve also been watching Insteon - mqtt development. It’s right on the edge of looking amazing. If they get the yaml scenes put together and the double-click and click-hold put together it could be really good.

Meanwhile I’ll be seeing what I can learn about the isy setup with OH but like I said - I’d be worried about jumping into something that’s already been abandoned. Don’t want to move from an abandoned project that works to a new abandoned project.

8

I too have been watching the insteon-mqtt. I think this would be a great solution as well. The ISY binding isn’t completely abandoned. The last contributor has a .JAR for download. But yes, its worrisome relying on that piece of work. If you are not using a the ISY I would really like to know how you manage scenes? In my home I have about 120 devices. I find that I am replacing 5% or so of them every year. Manual link management would be a nightmare.

9

That sounds great. So the insteon 1.x binding got be deprecated at some point and only the home-assistant mqtt auto-discovery would need to be 100% reliable for a relatively easy setup.

10

Luckily I haven’t had to replace any yet. I’m using Insteon terminal to set up scenes. It’s a beast but I set them up once last year and haven’t had to adjust yet.

I’m sure I will be reconsidering things if/when I have a device die… this seems pretty simple with the Insteon-mqtt since I would just have to update the replacement device Insteon id in a yaml file… really makes me wonder what could be done with a well written openhab 2 binding for the PLM!

I should have been a java programmer instead of a physicist…

11

@David_Graeff, I have not setup MQTT yet, does the new binding do both Homie and HA MQTT auto discovery?

12

Why don’t you have quick look into the Documentation yourself? (Instead of asking the author)

1 Like
13

Good point, thanks for the reminder,.

14

Are there any benefits to the ISY over an Insteon Hub other than link management?

15

From my experience I think reliability of the ISY994 will be better than the Insteon Hub. I went through 3 Insteon Hubs before purchasing an ISY 994iPro. Each Insteon Hub lasted 18-24 before failing. There is a surface mount capacitor that is the culprit and if you are good with a soldering iron you can replace it, but meanwhile your Insteon devices are down. Time will tell if the ISY is better in this respect, but from what others have posted I fully expect it to be better, and for the price it should be.

The other areas that I think ISY outperforms the Insteon Hub are in programming, and ability to backup the scenes and devices. Every time my hubs failed I had to recreate everything from scratch and have Insteon send me list of my device addresses (ie the hub is essentially cloud based). Now I could have written these down, but I have moved devices over time and didn’t really think about keeping a log. With ISY everything is on a microSD card and I can backup everything to my server over the LAN as well.

As for programming you can obviously use OpenHAB and create rules which works fine, or use ISY to create scenes and programs. I do both. The binding generally works just fine, good discovery and linkage. I had to add few Things manually using Text files, but only a very few. The only issue I have is when I update OpenHAB the bridge goes offline and I have a bear of time to get it to reconnect. I am running OpenHAB in a docker on a linux server, so what I do is uninstall the ISY binding, stop OpenHAB, upgrade, Start OpenHAB, then reinstall the binding. Nothing is lost (all Things and Items are intact), and it only adds an extra 3 minutes to the upgrade process. I’m not sure what the cause of this glitch is, maybe I could just purge the caches, but this works so it is what I do. Might be unique to my system too. Overall my experience with ISY 994i so far has been superior to the Insteon Hub, and I would recommend it as an addition to any serious Insteon installation.

16

I completely agree with John. The ISY is a far superior experience and will make managing your Insteon network much easier.

In addition to link management, I used the ISY to keep keypadbutton states in sync for lighting scenes.

17

With the hub, getting keypads to play nice with OpenHab takes a lot of work; you have to create separate items for each button for the state and the press using insteon-terminal. Is this any easier with the ISY, or do you still have to go through the same rigmarole?

18

I can’t provide any first hand experience regarding keypads as I don’t have any in my installation, only switches, dimmers, relays and sensors. However I would imagine that each key on the pad represents a scene and as such would need to be programmed separately. It will just be much easier to create scenes and programs for the keypad using the ISY vs having to use the terminal/hub.