Sonoff sensors (eWeLink) disconnected and not sending out updates

deCONZ General Support
1

It seems to be the same issue than Sonoff sensors disconnected - #17 by Smanar.

I have the same problem after more than one year without any problem with the Multisensors for temperature and humidity from SONOFF (eWeLink in Phoscon, Version 20211103).

There were two modification in my environment:
I changed from bare metal installation to the docker image ( deconzcommunity/deconz) on the same physical host with unmodified locations of the sensors.
Additionally, the host system (a raspberry pi 4, 64bit, RaspBee II) was upgraded from bullseye to bookworm.

I use the same database as before and all devices are reachable after starting the container. The version I used before is as far as I see the same as before:

2.22.02 / 19.9.2022
Firmware 26720700

I did not have any local device json definition.

The SONOFF sensors disappear after a couple of minutes/ hours. Phoscon shows them at “not reacheable” just after pairing. In the graphical view of deconz I can see the existing connection between the sensor and the configuration tool/ RaspBeeII.

Logs with debug options from the VNC view of deconz (I re-paired one of the sensors starting some seconds after at 20:39:15):

EDIT: I found the last post in Sonoff sensors disconnected - #27 by Smanar, but also that DDF did not fix it for me. I still see the same behaviour (and checked in the graphical view of deconz that I really use the new DDF file)

I see the sensors in Phoscon Webapp in black, but marked as “not reachable” if I click on an entry.

sensors
sensors999Ă—131 12.5 KB

Any help is appreciated as I have several sensors of this type in use.

2

I tried it also with older docker images back to 2.19.01. 2.19.x worked als bare metal installation under bullseye before migrating to bookworm and docker.

3

The sensor is one hour after re-pairing still paired in the vnc overview (“Badezimmer (OG)”), but not sending out updates and “not reachable” in Phoscons Webapp.

Network Overview

4

Ha ? This is strange, because they are marked as “not reachables” after 24h without requests, so strange they are still here in deconz …

5

Moving to deconz > General support.

I’m seeing some 1. 20:39:36:085 ZDP error status 0x8B

No clue what this is.

Asking Manup to check.

6

Interesting case the ZDP error 0x8B means “NOT_PERMITTED” which I think is an invalid status here.
Given that this happens after trying to read the binding table from the device, it looks like it doesn’t support this request.

Looking in the code it does handle errors for the binding table but only for “NO_SUPPORTED” status, so the problem here seems to be that this is tried forever without actually creating the bindings for reporting.

I’ve added the handing of “NOT_PERMITTED” to the state machine now, fingers crossed that solves the issue.

7

Respective PR for the fix: DEV handle Mgmt_Bind_rsp NOT_PERMITTED status by manup · Pull Request #7112 · dresden-elektronik/deconz-rest-plugin · GitHub

1 Like