Deconz Things suddenly shows as status "unknown" in paperui

Add-ons Bindings
1

The day before yesterday, most of my Deconz Things changed into status “unknown”. Some of them are not updating any more.
I run openhab (2.5.7) on one PI4 running Openhabian. DeConz is running on a separate Pi4 (the phoscon Image from Conbee, i.e. Debian Buster).

I’ve tried clearing the cache on the openhab pi, rebooting, removing and re-adding things - however, it does not change anything.

I re-installed DeConz/Phoscon (2.05.80, Conbee 2 stick of firmware 26580700) on another pi4, and imported a phoscon backup file.
I can see perfect mesh in the DeConz application - both on the first (original) as well as the new install
57 Nodes (14 powered/repeating, the rest battery powered - mostly Aqaras).
I can read all the sensors and control the lights from the Phoscon interface as well as from the Hue Essentials app. So - the phoscon/conbee2/deconz setup seems to work as usual.

It seems like OpenHAB is the culprit.

Does anyone (@David_Graeff ?) have any suggestion on what to check? (the log is filling up, as per below…)

20-Aug-2020 21:50:27.945 [TRACE] [ing.deconz.internal.handler.DeconzBaseThingHandler] - Requesting URL for initial data: http://192.168.1.239:80/api/C80C894FF2/light
s/23
20-Aug-2020 21:50:27.942 [DEBUG] [ing.deconz.internal.handler.DeconzBaseThingHandler] - Get new state failed:
java.util.concurrent.CompletionException: java.lang.IllegalStateException: Unknown status code 404 for full state request
at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273) ~[?:1.8.0_252]
at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280) ~[?:1.8.0_252]
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:618) ~[?:1.8.0_252]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:591) ~[?:1.8.0_252]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:488) [?:1.8.0_252]
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1975) [?:1.8.0_252]
at org.openhab.binding.deconz.internal.netutils.AsyncHttpClient$1.onComplete(AsyncHttpClient.java:112) [bundleFile:?]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:198) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:190) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:444) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:390) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:316) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.http.HttpParser.handleContentMessage(HttpParser.java:574) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1644) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1490) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:172) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:135) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:154) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Caused by: java.lang.IllegalStateException: Unknown status code 404 for full state request
at org.openhab.binding.deconz.internal.handler.SensorBaseThingHandler.parseStateResponse(SensorBaseThingHandler.java:128) ~[?:?]
at org.openhab.binding.deconz.internal.handler.SensorBaseThingHandler.parseStateResponse(SensorBaseThingHandler.java:1) ~[?:?]
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:616) ~[?:1.8.0_252]
… 28 more

2

As far as I understand OH uses the Deconz REST API to access the devices/sensors.
The API is described here
The error 404 is mentioned here and means resource ( e.g. lights with id 23 in your example ) not found.

Could you check which IDs are registered in your Deconz device using the above API ?
This means is ID 23 still listed in the reply of the API ?
This means browse to http://192.168.1.239:80/api/C80C894FF2/lights where C80C894FF2 must be your apikey.
If ID 23 is not listed in the reply then OH is right.

3

Same here, Both OH and Deconz run on docker.
Zigbee devices are shown and update status on deconz app. being found again after deleted from OH, but yet status is Unknown.

4

When checking the REST output for one of the sensors marked as “unknown” - it looks OK?

{“config”:{“battery”:100,“on”:true,“reachable”:true},“ep”:1,“etag”:“d087876f77347ecd0952440b952c2b83”,“lastseen”:“2020-08-21T08:10Z”,“manufacturername”:“LUMI”,“modelid”:“lumi.weather”,“name”:“AqaraMultiSensor_Milla”,“state”:{“lastupdated”:“2020-08-21T08:10:54.294”,“pressure”:1004},“swversion”:“20161129”,“type”:“ZHAPressure”,“uniqueid”:“00:15:8d:00:02:33:fd:22-01-0403”}

I don’t know if Raspbian might have updated anything that affects the parsing of the output, because it seems odd that it stops working from one day to another.

5

Ok.
I realised that the deconz package was upgraded to deconz-2.05.80.
I downgraded to deconz-2.05.78 and now all the thing statuses and updates are working correctly again.
There must be a bug or breaking change in the deconz update regarding the rest api.
I am no programmer, so I cannot dig deeper into this.
For now, I’ve put the deconz-2.05.78 version on “hold” - since my home is very much dependent on my zibee devices working correctly with openhab
I’ll make a report on github regarding this.

.

1 Like
6

In deconz V2_05_80 there was a change in the API: https://github.com/dresden-elektronik/deconz-rest-plugin/releases https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2590
Looks like the deconz binding has to be updated.

I’m using V2_05_79 without any problems.

7

I don‘t think that change is the culprit. If you look at the log above it seems that there is a problem with the URL.

If this is not a copy&paste error in the log, there are at least one whitespace character between light and s/. Can yo verify that?

8

I cannot find the same segment again, because log rotate has already rotated through all 10 files since yesterday. But looking into the current log files - I can conclude that that is a copy&paste mistake. The URLs do look correct, i.e. no space included.

9

Does that same URL work in a browser?

10

What I don’t understand is why a method of SensorBaseThingHandler is called for a light. Can you show the thing definition? Is that auto-discovered? If so, please show the openHAB REST API representation of that thing. Otherwise show the textual configuration.

11

Jan,
It seems that when I entered by report on git hub, I already mixed up things from my memory.
It was not not from same “thing”. First I did paste the last response in the log, which happened to be for a light.
After that I took the rest-response from an arbitrary “unknow state” sensor. They all showed “unknown” and I just picked one and did try the rest response from that specific item.

I cannot re-produce this this evening. My daughters are back from school - and they won’t be happy of I “de-commision” the lamps right now… :wink:

12

I have manually created the coordinator thing in a file.
All the actual light/sensor/switch things/nodes are created from paper-ui.

13

Ok. So if you find the time, please provide from the same sensor (at best disable all other sensors for that, otherwise it’s not so easy to find out which error comes from what request as the processing is asynchronous):

  • the trace log of the request
  • the exception
  • the (deconz) REST API response of the logged URL if used from a browser
  • the (openHAB) REST API representation of that thing

at best with both fw versions from deconz

14

Will do!

15

I just upgraded to 2.05.80 (from 2.05.72) and I don’t see this issue. So it may be related to s special sensor type (I don’t have many sensors, I only have lights and two aqara multi-sensors).

16

@J-N-K It really seems to be limited to certain sensors. My LEDs and rollershutters are all fine but the battery sensors (ZHABattery) are offline.

Maybe it has to do with API changes in this PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3087

17

I have seen that change but I can’t imagine how that shpuld affect us. Do you also see the “404” in your log? Are the battery sensors still reported if you try /api/<key/sensors?

18

I read something in one of the issues about the reachable attribute and changes to lastseen, but I can’t see any real chagnes in the return of the API call. Here is the response to /api//sensors

    "3": {
        "config": {
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "3a3366b9a9f2ad59db1f7e88c29339f7",
        "lastseen": "2020-08-22T11:14Z",
        "manufacturername": "IKEA of Sweden",
        "modelid": "KADRILJ roller blind",
        "name": "KADRILJ roller blind ",
        "state": {
            "battery": 69,
            "lastupdated": "2020-08-22T10:54:58.707"
        },
        "swversion": "2.2.009",
        "type": "ZHABattery",
        "uniqueid": "08:6b:d7:ff:fe:60:29:91-01-0001"
    },

I did not see any special messages in the openHAB log, but maybe because of the log level. Will do some tests in my development environment later.

19

I think I found the issue. It’s indeed the change in the lastseen. The binding fails to parse the shortened version (without seconds). I don’t see this, because I have disabled that.

2 Likes
20

Please try if update org.openhab.binding.deconz https://janessa.me/esh/org.openhab.binding.deconz-2.5.8-SNAPSHOT.jar fixes your problems.

2 Likes