Issue of the topic: deconz bridge goes offline. Without any cause, the deCONZ binding stops working. I can still access all the devices from Phoscon, but deCONZ cannot reach them. In Paper UI, in Things, “deCONZ” lists “OFFLINE - COMMUNICATION_ERROR”. If I click on the “deCONZ” Thing, it says “Status: OFFLINE - COMMUNICATION_ERROR org.eclipse.jetty.websocket.api.UpgradeException: 0 null”
Please post configurations (if applicable):
Items configuration related to the issue
Sitemap configuration related to the issue
Rules code related to the issue
Services configuration related to the issue
If logs where generated please post these here using code fences:
I get lines like these repeating every 10 seconds in /var/log/openhab2/events.log:
2023-07-29 14:20:03.629 [hingStatusInfoChangedEvent] - 'deconz:deconz:XXXXXXXX' changed from OFFLINE (COMMUNICATION_ERROR): org.eclipse.jetty.websocket.api.UpgradeException: 0 null to OFFLINE (COMMUNICATION_ERROR): 0 null
2023-07-29 14:20:03.629 [hingStatusInfoChangedEvent] - 'deconz:deconz:XXXXXXXX' changed from OFFLINE (COMMUNICATION_ERROR): 0 null to OFFLINE (COMMUNICATION_ERROR): org.eclipse.jetty.websocket.api.UpgradeException: 0 null```
Just to manage expectations: You are running openHAB 2.5.9 which was released nearly three years ago. You are two major versions behind. So probably you will not get much support.
I assume you didn’t just install that version of openHAB, so either you just started using the deCONZ binding or you just made some changes in your setup when the problems started to appear, which you can probably backtrack (for example upgrading deCONZ or changing configuration in either deCONZ or openHAB).
If you just started using the deCONZ binding, you are probably experiencing a bug. In this case you are out of luck since openHAB 2.0 is long out of support. The good news is that you can upgrade to openHAB 4.0 where the deCONZ binding received a massive overhaul:
I installed OpenHAB a couple of years ago. It has been running OK, though never reliably. I’ve been using it for testing purposes. It was meant to run mission critical aspects of the building, but I have not found it to be reliable enough. However, it never just stopped working like this before. The only configuration change I made was to add some RGBW LEDs. Which work fine in Phoscon. And worked in OpenHAB2 for a while too. But now it all stopped working.
Upgrades always break everything. I don’t have time to upgrade and debug everything that will be broken by the upgrade. I’d just like the system to work as it used to. I’ll consider reinstalling the system at a later date when I have time. But it may be a year or two before I can do that.
By then you might be able to take the leap directly to openHAB 5 or 6.
I also had reliability issues a couple of years ago, but this was mostly caused by the bindings I was using. I started contributing with fixes and enhancements, which for me personally resulted in a more stable system overall.
In general openHAB has received many stability improvements over the last three years, so I would only encourage you to give 4.0 a try.
Thanks. I’m looking to fix my existing installation which has been in testing for about 2 years.
Upgrading essentially means re-installing and re-starting the testing period.
I do not have the time to re-install and debug all the bindings, drivers, things, configuration files that will invariably break. Also, if I changed the installed version of OpenHAB, it would invalidate all the testing I have done on OpenHAB 2. I’d then have to wait another 6 months to a year of testing of OpenHAB 4 before I’d be happy to release it onto running mission critical parts of the building. I know the limitations and bugs of OpenHAB 2, I have learned them over the past 2 years of testing have been finding fixes and workarounds. Or rather, I thought I did, until it broke recently. Hence underscoring even more the need for extensive testing before deployment, since OpenHAB 2 failed in a new (and catastrophic) mode of failure only after 2 years of testing.
I can’t let the system run the building’s mission critical functions, where the building may be unattended for extended periods of time, without testing it for an extended period of time before deploying it. So clearly I will never be deploying the latest version, or even the penultimate version, and I’ll still need to maintain the existing installation, since development cycles seem to be quite short and shorter than a reasonable period of testing before deployment.
