openHAB stuck on not connecting to myopenHAB

After a power-outage my OH2.5 system can’t reconnect to the OH-cloud due to message: ‘Error connecting to the openHAB Cloud instance: already connected’

OS: Debian 9

OH-version: 2.5.12-1

Cloudconnector: 497 │ Active │ 80 │ 2.5.12 │ openHAB Add-ons :: Bundles :: IO :: openHAB Cloud Connector

It seems the system at myopenhab.org seems to keep a stale cache and responds with a message that makes the cloud-connector abort connecting. I’ve tried to keep the cloud-connector disabled to see if a session would expire on myopenhab.org, but it seems longer than 4-6 hours.

I’ve tried using invalid uuid and secret or even change these on myopenhab.org to match the new values, this results in ‘Error connecting to the openHAB Cloud instance: not authorized’ when not matching the credentials, or the already connected message.

I’ve also tried to connect from a 3.4 OH(still in process to move over) while disabled on OH2.5 with same result.

Below log when restarting the connector:

2023-02-03 12:09:47.076 [DEBUG] [b.io.openhabcloud.NotificationAction] - sending notification 'System started' to user <username>

2023-02-03 12:09:47.077 [DEBUG] [o.openhabcloud.internal.CloudService] - Sending message 'System started' to user id <username>

2023-02-03 12:09:47.077 [DEBUG] [io.openhabcloud.internal.CloudClient] - No connection, notification is not sent

2023-02-03 12:09:54.590 [DEBUG] [o.openhabcloud.internal.CloudService] - openHAB Cloud connector deactivated

2023-02-03 12:09:54.590 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection

2023-02-03 12:09:54.607 [DEBUG] [o.openhabcloud.internal.CloudService] - openHAB Cloud connector activated

2023-02-03 12:09:54.608 [DEBUG] [o.openhabcloud.internal.CloudService] - Using secret at '/var/lib/openhab2/openhabcloud/secret' with content '<very_secret_key>'

2023-02-03 12:09:54.609 [DEBUG] [o.openhabcloud.internal.CloudService] - UUID = <very_secret_uuid>, secret = <very_secret_key>

2023-02-03 12:09:54.614 [DEBUG] [o.openhabcloud.internal.CloudService] - Using secret at '/var/lib/openhab2/openhabcloud/secret' with content '<very_secret_key>'

2023-02-03 12:09:54.615 [TRACE] [io.openhabcloud.internal.CloudClient] - Manager.EVENT_TRANSPORT

2023-02-03 12:09:54.616 [TRACE] [io.openhabcloud.internal.CloudClient] - Transport.EVENT_REQUEST_HEADERS

2023-02-03 12:09:54.643 [TRACE] [io.openhabcloud.internal.CloudClient] - Manager.EVENT_TRANSPORT

2023-02-03 12:09:54.646 [TRACE] [io.openhabcloud.internal.CloudClient] - Transport.EVENT_REQUEST_HEADERS

2023-02-03 12:09:54.647 [TRACE] [io.openhabcloud.internal.CloudClient] - Transport.EVENT_REQUEST_HEADERS

2023-02-03 12:09:54.731 [ERROR] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: already connected

2023-02-03 12:09:54.731 [TRACE] [io.openhabcloud.internal.CloudClient] - Transport.EVENT_REQUEST_HEADERS

It seems to me there’s some session-stickyness causing this session to hang on being active causing the connector not to reconnect leaving the system in a disconnected state.
Does someone have any idea on how to get this unstuck?

There might be other ways. What I would try is to

  • login to the myopenhab.org interface.
  • goto the account settings ( click onto your email adress /account name )
  • update the content for your OH device that means create a new openHAB UUID and secret on your OH instance which then is to be entered again on the myopenhab.org page

myopenhab.org is only able to handle one device per account. You can’t connect both at the same time.

I tried that by updating the uuid already, didn’t seem to matter as the session on myopenhab.org already states it’s connected(with both old and new credentials).
Currently I don’t see another option but to register a new account, but that seems like a waste of resources(assuming 2 accounts will be live with just 1 functioning).

@digitaldan, could this be an unintended consequence of the recent fix for the disconnect/reconnect issues?

The locks only last for 70 seconds (2 heartbeats plus 10 seconds for good measure), and then only if there is a disconnect we cannot detect (like the TCP connection is still up, but your internet suddenly died). This is directly expired in Redis, and only heartbeats coming from the client extend its TTL, so pretty foolproof. If it continues to give you that message, it means there is another thread or instance of OH connected. I suspect that there might be a bug in the binding that occasional creates more than one connection, hopefully that was fixed last week and will be out in the next 3.4 release. I would turn on TRACE debugging on the cloud connector addon and see what happens (edit i see you did that, so never mind !) .

If you want to PM me your UUID , i can check the logs and see if there are multiple connections coming in.

1 Like

Also when you tried in oh3 , did you have your oh 2.5 instance completely shut down ? Not just the cloud addon, but the OH process itself? My hunch is that a thread gets abandoned somewhere and only a restart of the OH java process will kill it.

Allright,

This can be ruled pebkac :confused:

After the power-outage the server came back up with the VM’s I have on it for openHAB and other tools. What I didn’t realize was that I have a test-VM on there to test migration from OH2 to OH3 via packages(based on backup from the running OH2), which was shutdown prior to the power-outage, had started up as well.
Since it was based on a backup and testing occured with the old system off to also test the cloud-connector, it grabbed the session prior to OH2 could.

Sorry for the noise and thanks for the help pointing me in the right direction(logging in the dashboard and seeing the hostname connected to the session-credential).

1 Like

Hi JoeJos (sorry about that!) , not a problem. Thanks for responding back actually. After putting in the locking mechanism , i was bracing for a chorus of these types of issues, i have been pleasantly surprised this has been the only report. And since you were able to figure out that it was indeed a second system, it helps validate the logic is working, so thanks !!!

5 Likes