[deconz] Sensors may appear Offline after been Unreachable and becoming Reachable again. Comes Online after disable/enable

[olemr]

Expected Behavior

I would expect the sensor Item to appear Online after "reachable": true & "lastupdated": "2022-09-09T18:52:36.769" becomes current.

Current Behavior

After my Fyrtur battery sensor was unreachable and became reachable again, OH 3.3.0 release still shows it as Offline: (browser refresh does not help.)
Note that everything is working Ok, it's just that the Thing is flagged as Offline in the Things view:

{
  "config": {
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "f9968364c4ecac629519e0b7b1a1ad98",
  "lastannounced": "2022-09-09T18:54:28Z",
  "lastseen": "2022-09-09T18:54Z",
  "manufacturername": "IKEA of Sweden",
  "modelid": "FYRTUR block-out roller blind",
  "name": "FYRTUR block-out roller blind ",
  "state": {
    "battery": 50,
    "lastupdated": "2022-09-09T18:52:36.769"
  },
  "swversion": "2.3.088",
  "type": "ZHABattery",
  "uniqueid": "08:6b:d7:ff:fe:57:c4:64-01-0001"
}

Just pressing

then

makes the item become Online:

This behaviour is also seen on Switches and other Aqara/Lumi sensors so it is probably a common cause.

Steps to Reproduce (for Bugs)

I am not sure how to reproduce, but it seems to happen more often when restarting deconz while OH is still running.
The above example happened sometimes during a 32 day uptime of the whole system.

Context

Your Environment

• Version used: (e.g., openHAB and add-on versions)
• OH 3.3.0 Release, deconz 2.16.1
• Environment name and version (e.g. Chrome 76, Java 8, Node.js 12.9, ...):

omr@shs2:~$ java --version
openjdk 11.0.16 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu118.04)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu118.04, mixed mode, sharing)
omr@shs2:~$

• Operating System and version (desktop or mobile, Windows 10, Raspbian Buster, ...):

omr@shs2:~$ uname -a
Linux shs2 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
omr@shs2:~$

[jlaur]

@olemr - is the bridge also OFFLINE when this happens, or only the sensor thing? Can you provide TRACE logs?

[olemr]

Only the sensor/switch thing is listed as Offline, but the device/channels works just fine, so this is just cosmetic ...

[lhurt]

@olemr - is the bridge also OFFLINE when this happens, or only the sensor thing? Can you provide TRACE logs?

In my case the bridge is mostly also offline.

[Redsandro]

This appears similar to issue #13740 but not identical because of these differences:

1. 13740 doesn't show anything as offline
2. 13740 happens in the opposite case of what you describe.

To elaborate on that second point, you describe this happens often when deconz is restarting. Could you double-check to see if it's not the other way around as described in #13740? E.g.: restart OpenHAB while deconz is offline, and then start deconz after OpenHAB is up?

[lhurt]

Hi, sorry to reply late. I double checked and you’re right. The deconz binding gets back online after restart of deconz docker container on remote server, but not the other way around. One thing I noticed is that some temperature sensors did not come online unless I disabled and reenabled them. This only applies to sensors. When checking in Phoscon Web App or VNC conbee Monitor, it’s clearly visible that the sensor provides new values. The openHAB thing stays offline. So there may be more than one issues. Hope it gets fixed soon. Thanks a lot Von: Redsandro ***@***.***> Gesendet: Freitag, 18. November 2022 01:39 An: openhab/openhab-addons ***@***.***> Cc: dolittle ***@***.***>; Comment ***@***.***> Betreff: Re: [openhab/openhab-addons] [deconz] Sensors may appear Offline after been Unreachable and becoming Reachable again. Comes Online after disable/enable (Issue #13368) This appears similar to issue <#13740> #13740 but not identical because of these differences: 1. #13740 <#13740> doesn't show anything as offline 2. <#13740> #13740 happens in the opposite case of what you describe. To elaborate on that second point, you describe this happens often when deconz is restarting. Could you double-check to see if it's not the other way around as described in <#13740> #13740? E.g.: restart OpenHAB while deconz is offline, and then start deconz? — Reply to this email directly, <#13368 (comment)> view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/AAC4RQHV7RR3HKEXROGBYBDWI3F3RANCNFSM6AAAAAAQI563WM> unsubscribe. You are receiving this because you commented. <https://github.com/notifications/beacon/AAC4RQHJFXQN54FKZQMGNVLWI3F3RA5CNFSM6AAAAAAQI563WOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOURZDS.gif> Message ID: < ***@***.***> ***@***.***>

[Redsandro]

@jlaur it seems like multiple issues boil down to the same problem: The bridge loses the connection and OpenHAB never reconnects properly. If DeCONZ goes down temporarily, the bridge will not work until OpenHAB is restarted.

These issues can be fixed with a docker-compose restart in the OpenHAB directory, but until you manage to login and do that, all the OH+DeConz dependent domotics in the house will be unavailable.

[jlaur]

@jlaur it seems like multiple issues boil down to the same problem: The bridge loses the connection and OpenHAB never reconnects properly. If DeCONZ goes down temporarily, the bridge will not work until OpenHAB is restarted.

I still have a hope that @MHerbst will backport fixes provided in the smarthomej repository since this would probably fix multiple issues - and we have many. See #12223 (comment)