Is openhab3 actually stable?

I wanted to discuss in a bit wider approach about openhab3.

Some background…
I have been testing some hone automation solutions like Telldus Tellstick net2, animus heart and Philips hue.

I wanted to combine and not restrict myself to only zwave or ZigBee. I wanter wider, bigger, better.
Therefore I tried animus heart.

The idea and the cost is quite good. But the non existing community and the app is really what made me leave it behind. Not worth it.

Then i heard about openhab. How wide and great it was.
So I got a raspberry pi 4, installed the openhab3 version - like why not? Latest is often better?

Oh how much frustration I have had. The learning curve is somewhat understandable that it’s just nu “plug and play let’s go” rather than the mentality sort of “but how do you want it to look, feel or work?”.

The buggy parts is what really is frustrating.
Each day the zwave stick loses contact and is not able to add new zwave units. Each day! So I have to unplug, and plug it in again and reboot the raspberry pi.

The second part. Philips Hue. It is not possible for me to add a new device. No way.
What I have to do is remove the hue connection (models and items), then in the hue app - add each new bulb or whatever… Then add the hue back again and reconfigure each device! What the actual.

Does anyone else have this experience with the openhab3? Or is the grass greener on openhab2?

1 Like

I used openHAB V2 for some time and never had difficulties.
Currently I’m running for the UI part a openHAB 3 docker container on my server and some openHAB 2 systems on Raspberry Pis and they all work like a charm. It happened two to three times that my server crashed but it restarted properly and all docker containers where up and running after several minutes.

I’m not experienced in the zwave-stuff, but you described “unplug and plug the stick every day” helped. Maybe you could look into Linux chron jobs and “unmount and mount” the zwave stick automatically.

I have thought about adding a cronjob that does this. But it seems for me like an hack rather than a permanent fix in some sense. I mean, during the cronjob hack - that would mean for a fraction (don’t know exactly how long it takes) the zwave devices would not be able to be used.

You are right, that would be more a “hack” or “workaround”…

Another idea which could maybe help you. But I would also tag it as a “workaround”:
Create a rule, which triggers when the zwave thing gets offline. start a timer for a fair amount of time to see, if the zwave thing comes back online. If so, stop the timer.
If not, disable the thing by the openHAB rule, run a script (command line execution via openHAB rule) and then try to disable the zwave thing.
The benefit would be, that you have total control about this process in your openHAB

In general most users find openHAB to be very stable. But realize that everyone’s openHAB setup is going to be a unique configuration of bindings, Things, Items, Rules and such. Consequently some people run into problems from time to time. Ideally when this happens a thread is posted and information is gathered and the problem is fixed.

I’ve use zwave with OH since OH 1.6 and have found it to be one of the most stable bindings. The behavior you are describing actually sounds like it might have to do with the buggy USB on the RPi 4. My first suggestion would be to plug the controller into a powered USB hub and see if the behavior continues.

Ultimately the problem here likely lies outside of openHAB and there is something going on at the OS level between the RPi and the USB controller. We have seen reports of that on RPi 4 and the suggestion above is the general solution. But that was several months ago and there might be changes to RPi since then that addresses the problem in other ways.

However, the above assumes I’m interpreting your problem correctly and that it’s openHAB that is losing access to the Zwave controller and all the Zwave stuff appears as offline. If that’s not the case and it is truly just about putting the controller into inclusion mode but you can still control your zwave devices then something else is going on. The first thing I would try is to disable the nightly Heal (there’s a flag on the Zwave Controller Thing). You don’t say which version of OH 3 you are running (3.0.2, 3.1 M5, 3.1 SNAPSHOT, etc.). IIRC there were some problems with the Heal in 3.0.1 and before, perhaps other versions too.

I don’t use Hue at all but what you describe is not my understanding of how it’s supposed to work. Hue is also one of the most used bindings so if your experience were the general experience I would expect to see this forum full of posts about it. So we need to get to the root of what’s different about your configuration. To get the attention from the right people I recommend opening a new thread to discuss just that topic in the addons and bindings category tagged with “hue”.

I use the Hue binding and I think that is how it is supposed to work. When I get a new Hue device, I open the Hue app on the phone and add the device. By the time I set the phone down, the device has already popped up in my inbox in openHAB. I don’t even have to click the button to search for a device, it is already there.

Regarding the version, I was using 3.0.1 of the build.
Just upgraded it to 3.0.2

The zwave issue I was having did not prevent me from using the devices. Just adding new ones. The scan part did not do a thing unless I unplugged the stick, inserted it then rebooted the raspberry pi.

Now it cannot even find the stick anymore. I even removed it and removed the zwave binding and re-added.

So now I guess the upgrade messed it up really bad.

In my case I never get new devices in the inbox unless i exclude and then include the hue bridge again.

So every lamp i get will add even more time for the reconfiguration of the home.

Have you collected logs when it failed?

You’ve not provided enough detail to say for sure but it sounds like you didn’t stop openHAB prior to removing the stick and readding it. On Linux a serial device shows up as a file (e.g. /dev/ttyUSB0). When a piece of software accesses the device, the device get’s locked by the OS so only one program can talk to it at a time. When you unplug the USB device though, the lock doesn’t get cleared. Only when the program that is accessing the device releases it which usually only happens when it’s closed down does the lock get released. So when you plug the device back in it can’t appear as the same file because that one is locked. So it appears as a different file (e.g. /dev/ttyUSB1).

It gets further complicated if you have more than one device as there is no guarantee that they appear as the same file every time. But there are ways to handle that on this forum and on the internet at large.

Again, this is not the way it is supposed to work. But until such time that we can figure out why it’s not working for you this should be manageable if you make sure to use the same Thing ID for the Bridge when you recreate it. By default a random string is inserted into the Thing ID for the bridge. But if you modify that to be the same as it was before, which you should be able to do before accepting it from the inbox (if not I can provide alternative instructions), then it won’t see all the already existing lamps as new and they won’t appear in the Inbox.

Put another way, because the Bridge Thing gets a new Thing ID every time, openHAB has no way of knowing that all the lamps you’ve included with the old Thing are the same as all the lamps it sees with the new Thing. But if you use the same IDs it will be able to determine that and it won’t detect them as new devices.

After alot of tweaking I actually got the zwave stick to work again.
But now the inbox is all the already added zwave devices.

I’ve tried to ignore them. But they seems to keep coming back.
Strange really.

What are the Thing IDs of the newly rediscovered Things?
What is the Thing ID of your ZWave Controller Thing?
You only have the one ZWave Controller Thing, right?
Do your Zwave Things that have already been accepted out of the inbox appear to be ONLINE?
Do they work?

Unfortunately there really wasn’t enough detail to begin with and all we really know about what you’ve done to this point is “a lot of tweaking” so we have no idea what state your OH instance is in nor how it got there. All we can do is make wild guesses as to what might cause the behavior you’ve described.

As the devices are in your z-wave controller’s device table they will continue to show in openhab until you remove them from the controller.

Your zwave USB stick contains a microcontroller and memory that manages the zwave network. OpenHAB is just reading these devices from that microcontroller and memory.

I suggest you do a bit of reading on how zwave works and then I think it will become clear why these devices keep showing. It is only an issue if you have reset the slave devices without first removing them from the zwave network.

Of course I could read into more on how zwave works. It just that It seems odd that the behavior just started after I upgraded to 3.0.2.

I will get back with a larger description on it all later this weekend!

Yes it’s stable I went away in February for a week four months later I haven’t got home and openhab is still running fine and doing everything it should be doing.

openHAB 3.02 Stable is not the latest and is now 6 months old. Since it was the very first release made in the V3 lineup a lot has been improved and changed since then.
3.1 Stable may now be only a week(?) away. If you want the latest changes that are less than a month old, you should run the ‘milestone’ builds which are a good compromise between having the latest and some people have already done testing on it. If you are tinkering with the system weekly then you should be on the Milestones IMHO, as they are not applied automatically and you can choose when to do an upgrade at a time that suits you to deal with any issues that may crop up.

openHAB is three different parts that work together:
ADDONS (bindings and other types)

The core I would say is very stable, the mainUI in V3 is changing a lot as it is new but should not cause a system to become unstable. This leaves the ADDONS which is entirely up to how often people report there is a problem and if someone is active at fixing the issues. If you want to move to openHAB or any opensource project then it is best to look at what is actively being maintained and also what hardware the developers are using so you can stick to the area that is well tested and fixed more quickly.

Since your having issues with multiple addons/bindings, you should open a new thread (after first searching to find the answer first) for each one. A thread lumping multiples into the one is probably not going to assist you.

Look at your log files and then search the forum for any WARN lines or anything you see that may be a clue to your issue, this is a good place to start.

Try opening this on your network if your using openhabian to see if frontail is running.


Logging | openHAB

Then possibly your network/router has an issue/lack support/disabled features like “uPNP” or mDNS. If your using a free modem/router from your ISP then it may not have this setup or supported or disabled.

Hm, I consider uPNP to be dangerous as it enables applications to punch a forward hole thru NAT. That is not a good thing as you have little control over witch application or device doing it.
Be sure to check what these options do. They are named a bit different from router to router.

mDNS/avahi/Zeroconf/bonjour is what you want. :wink:

Edit: Openhab is very stable, there is no problem to leave it running for months.
Even the snapshots can do that for the most of them.

Moving targets like the zigbee binding are a bit different, because, well, it is a moving target.
The zigbee binding have no problem running for months either.
It is new devices and changes in spec that is the moving part.

The Hue binding is one of the more stable ones I belive.
But it is easy to overload the Hue hub. IO bandwith is not its strongest quality.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.