Openhab deCONZ switches permanently between online and offline

General
1

Hello
I am using deConz binding with Openhab 4.0.3. Unfortunately there is a continuous change between online and offline states every 120 seconds.
I already posted it in the Openhab forum, unfortunately without results.

Thing 'deconz:deconz:17838366c2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead.

Openhab and deCONZ are both running in a Docker container.

2

Hello,
So you have 120s online, then 120s offline ?
It seem the message is about the websocket connexion ? But hard to check how long is the offline period ? do you have device state return during it ?

3

This is the timing …

2023-11-02 09:14:00.652 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:deconz:17838366c2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead.
2023-11-02 09:14:10.687 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:deconz:17838366c2' changed from OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead. to ONLINE
2023-11-02 09:17:21.665 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:deconz:17838366c2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead.
2023-11-02 09:17:31.693 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:deconz:17838366c2' changed from OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead. to ONLINE
2023-11-02 09:21:02.692 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:deconz:17838366c2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Watchdog timed out after 120s. Websocket seems to be dead.
4

10s, it’s short, but you can make a test, during a offline period, try to change a device state (better if you have a device you can use manualy), if you have a return, the problem is from your watchdog

5

Many thanks for your help. I have tried the suggested procedure with different devices, but a status change was not possible in any case. If it should be the watchdog, what can I do in this case?

6

You can’t change a state, or haven’t the state change ?

Third app use classic REST request to send requests to change a state (so not a permanent connexion)
Deconz use a permanent Websocket connexion, to send information to third app.

When you send a request to change a state, openHab send a REST request, deconz update the API send the zigbee request, and after the device update, when deconz obtain the zigbee confirmation, it update the API and send info using websocket.

It’s for that I say you need to use manual device, like switch (battery or wired one), because deconz can update the API before the state change, but the info is done using websocket.
If you use a switch deconz is forced to use the websocket connexion to send the information to OpenHAB, so if the state change don’t appear in the third app it mean the websocket connexion is out of order.

It’s a new installation ? You can check too in phoscon/gateway. If you see a firmware number, it’s ok, if you see “unknow” it mean deconz have disconnected (and not only websocket)

If you can’t send command to change a state, it mean the REST is not working, so the complete deconz server is probably out.

If you have problem on the gateway (firmware problem for exemple), deconz is not able to connect, so the deconz server too.

Do you have access to the deconz GUI ?

7

I’m sorry for the inaccurate information. I only have a few sensors in use with Deconz. I have therefore tried to update a sensor again in Openhab during the short offline phase. Unfortunately, I cannot implement the procedure described above (switch …). Everything looks fine in the Phoscon gateway. As everything runs under Raspberry OS light, there is no graphical user interface available on the Pi.
But perhaps I was too vague at the beginning: everything works. Except for the brief interruption every 120 seconds. The Openhab log is filled accordingly quickly … The communication between Openhab and deCONZ must then work in principle, otherwise no data transmission from the sensors would be possible. Or am I seeing this wrong?
Yes, it is a new installation with deCONZ and Openhab 4.0.3 in Docker containers, as I have already written above. With the same hardware and Openhab 3.4 it worked without any problems before.

8

No you are right, but sensors are not realy talkative, if the websocket connexion is out of order for somes seconds, it can be invisible.

Something you can try too is using another websocket client. There is plugin for browser, I m using for exemple “Browser Websocket client” for Firefox. You can see if this client disconnect too, you just need to connect to deconz websocket server, and wait.
The watchdog is not from deconz, so I realy have no idea how it work and what it check.

On my side (I never use docker) the websocket serveur url is ws://deconz_ip:8088

9

I can’t reach the websocket with the browser! Then Openhab certainly can’t do this either . I have tested a few other port combinations for my deCONZ container, unfortunately with the same result. I think I’ll give up and live with these limitations. It only affects a few sensors that are not time-critical.

Thank you very much for your detailed efforts. This is not a matter of course.
Best regards.

10

Never ? it can work, else sensors will never update values.
You can use the same ip you have to acces phoscon (depend of docker config)
The used websocket port is visible on logs I think else on http://IP:PORT/api/KEY/config (IP and PORT are the same than for phoscon, KEY is an API key, use the same than OpenHab)

11

Okay, that works. I had previously tried ws://ip:port and the unformatted output is now:

{"UTC":"2023-11-04T10:03:32","apiversion":"1.16.0","backup":{"errorcode":0,"status":"idle"},"bridgeid":"00212EFFFF042B69","datastoreversion":"93","devicename":"ConBee II","dhcp":true,"disablePermitJoinAutoOff":false,"factorynew":false,"fwversion":"0x26720700","gateway":"172.19.0.1","internetservices":{"internet":"connected","remoteaccess":"disconnected","swupdate":"connected","time":"connected"},"ipaddress":"172.19.0.2","lightlastseeninterval":60,"linkbutton":false,"localtime":"2023-11-04T11:03:32","mac":"02:42:ac:13:00:02","modelid":"deCONZ","name":"Phoscon-Docker","netmask":"255.255.0.0","networkopenduration":180,"panid":13682,"portalconnection":"disconnected","portalservices":false,"portalstate":{"communication":"disconnected","incoming":false,"outgoing":false,"signedon":false},"proxyaddress":"none","proxyport":0,"replacesbridgeid":null,"rfconnected":true,"starterkitid":"","swupdate":{"checkforupdate":false,"devicetypes":{"bridge":false,"lights":[],"sensors":[]},"notify":false,"text":"","updatestate":0,"url":""},"swupdate2":{"autoinstall":{"on":false,"updatetime":""},"bridge":{"lastinstall":"2023-10-01T12:32:06","state":"noupdates"},"checkforupdate":false,"lastchange":"","state":"noupdates"},"swversion":"2.23.2","timeformat":"24h","timezone":"Etc/UTC","uuid":"4f013e4f-ffa5-48a1-bffe-c8b4e7889bfc","websocketnotifyall":true,"websocketport":5443,"whitelist":{"19D1F17BBB":{"create date":"2023-10-12T13:55:17","last use date":"2023-10-12T14:48:43","name":"Phoscon#B1720x1010"},"30690DFF14":{"create date":"2023-10-12T13:59:35","last use date":"2023-11-04T10:03:32","name":"openHAB"},"355B32C12C":{"create date":"2023-10-19T18:32:09","last use date":"2023-10-19T19:19:59","name":"Phoscon#B1293x615"},"6C383B5A80":{"create date":"2023-08-24T15:15:05","last use date":"2023-08-24T15:41:29","name":"Phoscon#B1293x614"},"6E42AB737E":{"create date":"2023-08-24T15:57:29","last use date":"2023-08-24T15:59:42","name":"openHAB"},"79F1DBC2F5":{"create date":"2023-08-24T15:56:41","last use date":"2023-08-24T16:35:47","name":"Phoscon#B1293x614"},"8670D68F2B":{"create date":"2023-10-19T18:33:13","last use date":"2023-11-03T18:48:49","name":"pydeconz"},"A90E5DDC8A":{"create date":"2023-08-24T16:00:53","last use date":"2023-08-24T16:34:56","name":"openHAB"},"A96F96D472":{"create date":"2023-11-01T15:33:37","last use date":"2023-11-01T15:34:25","name":"Phoscon#B1821x918"},"CBC028EADB":{"create date":"2023-10-22T07:58:54","last use date":"2023-10-27T16:10:20","name":"Phoscon#B2003x1010"},"F62243B509":{"create date":"2023-11-01T15:35:26","last use date":"2023-11-04T10:03:32","name":"Phoscon#B1821x918"}},"zigbeechannel":11}

I suspect it simply has to do with the fact that deCONZ runs in a Docker container. The ports used are specified in the config file and also the environment variable for the web port. I’ll attach my dcoker-compose.yml …

version: "3"
services:
  deconz:
    image: deconzcommunity/deconz:stable
    container_name: Deconz
    restart: always
    privileged: true                # This is important! Without it, the deCONZ image won't be able to connect to Conbee II.
    ports: 
      - 85:85
      - 5443:5443
    volumes:
      - /home/pi/docker/apps/deconz:/opt/deCONZ
    devices:
      - /dev/ttyACM0                # This is the USB device that Conbee II is running on.
    environment:
      - TZ=Europe/Berlin
      - DECONZ_WEB_PORT=85
      - DECONZ_WS_PORT=5443
      - DEBUG_INFO=1
      - DEBUG_APS=0
      - DEBUG_ZCL=0
      - DEBUG_ZDP=0
      - DEBUG_OTA=0
      - DEBUG_HTTP=0
      - DECONZ_DEVICE=/dev/ttyACM0   # This is the USB device that Conbee II is running on.
      - DECONZ_START_VERBOSE=0

My local network runs under 192.168.x.x. The internal Docker address is 172.19.0.2, the bridge address of the Docker network is 172.19.0.1. No matter which of the two addresses I enter in Openhab, it works, but in both cases the problem described occurs.

12

From your setting the port is 5443.
So can try ws://172.19.0.2:5443 but need to use a websocket client (a browser plugin can do that)

13

It seems to work - > Status open

14

The postings have overlapped.
What works is ws://192.168.2.85:5443.
What doesn’t is ws://172.19.0.2:5443.

15

One is probably local and the other extern ?
You have disconnection using the websocket client ?

16

Sorry, I don’t know what you mean by “connection error”. I tested the above URLs with a Firefox web client and only the first one (192…) was able to connect.

17

Sure, but it stay connected, you can see event from device ? or it disconnect too regulary ? Can use this method to check if the problem is from the websocket client (Openhap, your plugin, phoscon) or the websocket server (the deconz webserver).

18

Oh, I think I understand now.

The question was whether the ws://. connection stays online while deCONZ goes offline in Openhab, right?

Yes, the connection stays online and status messages from the sensors appear. However, I could not establish a connection in the short time when deCONZ was offline in OH.

I hope this information helps us further.

19

Exactly ^^

However, I could not establish a connection in the short time when deCONZ was offline in OH

You can’t without switch for exemple, all other sensors are lazy, so impossible to make them trigger a notification in less than 10s.

But it mean the problem is perhaps the watchdog ?

20

I’m sorry, but I can’t answer this question