Following this thread for a while as I am experiencing this issue as well. I wanted to inform that I upgraded from OH3.3 to 3.4 last week and encountered the problem again today. A simple “save” on the UI openHAB cloud page got me back online. There were no messages in the openhab.log after the last successful connect to openhabcloud. I have log level set to TRACE now and will send info as soon as I have the issue again. If anything else is helpfull for troubleshooting, please let me know.
I have also been having this issue intermittantly, it’s been worse since October 2022. I was running 2.5.10 so upgraded to 3.4, but the issue remained. I changed the connection to the Pi from wifi to ethernet in case it was dropping, but that didn’t help.
Today it failed at 09:30 UK time (12-01-2023), apparently due to ping timeout. I’m not sure that it worked correctly after that, it was 14:30 that I noticed it failed as Alex said ‘the hub is not responding’. There is nothing else in the log apart from ping/pong even when I ask Alexa to turn on a light, I would have expected to see something.
Probably I’ll implement one of these scrpts that restarts the connector if it fails, clearly this is a hard bug to fix as has been around for a while.
Did yours also fail at 09:30 today? I would guess it did for everyone, unless it is my internet provider.
Maybe someone could increase the ping timeout threshold to make it less sensitive?
I’m also having the same issue. Just like momo90 my connection stopped twice in a very short period. I have two instances running on different locations and both stopped communicating with the Cloud at the same time.
@digitaldan First, thank you for all your great work around openHAB.
I don’t want to play the party pooper, but I fear changes due to myopenHAB maintenance broke my openHAB installation that now it does not reconnect any more since January 30th.
By the way - no changes of my openHAB installation by my own since weeks.
I checked all my logs and this are the results of my research:
Every night shortly past 3am openHAB Cloud service is disconnected because my router performs an internet reconnect to prevent a provider forced disconnect.
After internet reconnect a few seconds later openHAB Cloud service connection was performed automatically – until January 29th.
Since January 30th no openHAB Cloud service reconnection was established automatically, so every morning I must restart openHAB manually to get openHAB Cloud service connection working.
See also my logs for details:
2023-01-29 03:24:20.174 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 2a3780fd-69ad-4e96-b5b8-69ed849xxxxx, base URL = http://localhost:8080)
2023-01-29 03:24:22.075 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 2a3780fd-69ad-4e96-b5b8-69ed849xxxxx, base URL = http://localhost:8080)
2023-01-30 03:23:09.889 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 2a3780fd-69ad-4e96-b5b8-69ed849xxxxx, base URL = http://localhost:8080)
=> No automated openHAB Cloud service reconnect since January 30th!
So, there is an issue in the cloud connector bundle that would not reconnect to the service when the server specifically disconnects the client (which is now more common) . I suspect this is the issue. This is fixed in the next 3.4 release and also in the upcoming 4.0 release. As you are on 2.5, we don’t have a way of back porting this fix. I agree with @rpwong that manually restarting the binding shortly after your router restart is the best bet until you can upgrade to a supported OH version.
Off topic too - In fact I started playing around with OH 3.2 in January 2022 to set up my openHAB installation from scratch as recommended by some experienced OH users. But after 4 month I lost all my developed content when my USB disk crashed totally due to my fault, only to backup openHAB content with its backup script storing my configuration in a zip file locally, not on a separated device. After that incident I was searching for a new backup environment (my old one is an outdated NAS). Due to other private activities I did not complete this search until now, but after closing that subject I will definitely start with OH 3.4.
So there is still a race conditional on the server that happens under load that can cause a zombie connection to happen. Unfortunately our cloud provider Linode just had “Emergency” network maintenance and caused such an event to happen . I have a fix in mind for this, which will involve upgrading our DB software and expose some helpful functionality for this. I’m planning on doing that before the month end, so hopefully that will alleviate the last of these issues.
We should have a discord server for when these maintenance tasks are happening for us to join you and share some of the effort hope to see this issue fixed once and all soon, thank you for all of the hard work you guys have been putting onto this.