Deconz not changing states anymore in HA

[pergolafabio]

hi

i am running Hassio on HassOS 97.2 , running deconz as ha addon fw: 0x26330500 version V2_05_66

i have a verry easy setup: some xiaomi motion sensors, then runs an automation when motion is detected some osram smart plus, just act as router and some ikea remote switches

the problem is with the states, after a few hours/days the state of my osrams and xiaomi in Hassio are not changing anymore

in phoscon , i still see motion detections, but the state in Hassio is not changed, so my automation doesnt run if i turn off/on an power switch in Hassio, it actually turns off/on, i also see the state changing in phoscon, but in hassio, the state doesnt change, it stays on/off like it was

so, mesh is still good, all is working, seems only the state from deconz to hassio is an issue

any idea what can be the problem?

[pergolafabio]

if i restart Hassio, all is back to normal, for again a few hours/days i now enabled debugging, and waiting for next time the connection is gone

[Cybersmurfen]

You have not, by any chance, added an IKEA motion detection sensor?

[pergolafabio]

No, same devices for a while now... Why?

[Cybersmurfen]

I had the same issue when added one of those. And all other kinds too. That was solved in another thread tough.

[pergolafabio]

The same state update issue as me? Can you point me to that thread?

[pergolafabio]

Ok, Found some threads, but that's indeed not related to my issue

[pergolafabio]

ok, it happened again there is no info in debug anymore

last debug log was from around 20:07 :

2019-08-28 19:59:09 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"17","r":"sensors","state":{"lastupdated":"2019-08-28T17:59:09","presence":false},"t":"event","uniqueid":"00:15:8d:00:03:05:8f:d4-01-0406"}
2019-08-28 20:03:04 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"config":{"alert":"none","battery":47,"group":"14613","on":true,"reachable":true},"e":"changed","id":"4","r":"sensors","t":"event","uniqueid":"00:0d:6f:ff:fe:25:c1:d9-01-1000"}
2019-08-28 20:07:23 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"2","r":"sensors","state":{"dark":false,"daylight":false,"lastupdated":"2019-08-28T18:07:23","status":180},"t":"event","uniqueid":"00:21:2e:ff:ff:02:a4:80-01"}

above looks normal, so i arrived home now at around 23:20

nothing is working anymore from deconz so when i walk before a xiaomi motion, sensor, it detects motion, i see that in phoscon, but nothing happens in Hassio, also no debug

when i turn on/off a switch from phoscon, also no debug in hassio when i turn on/off a switch from hassio, it works, it actually turn on/off the switch, then in debug i see this:

2019-08-28 23:15:18 DEBUG (MainThread) [pydeconz.utils] Sending {'data': '{"on": true}'} to http://172.30.32.1:40850/api/7E45CBF224/lights/6/state
2019-08-28 23:15:18 DEBUG (MainThread) [pydeconz.utils] HTTP request response: [{'success': {'/lights/6/state/on': True}}]

so above looks good so its just the state direction from deconz to hassio thats seems to be an issue

when i press the hardware button on my osram, deconz sees it, also when i walk before a motion sensor, so below is a copy paste from log from dezconz addon

23:26:59:254 ZCL attribute report 0x7CB03EAA0A0284DC for cluster 0x0006, ep 0x03
23:27:03:449 Current channel 25
23:27:03:481 Device TTL 6300 s flags: 0x7
23:27:32:414 no button map for: lumi.sensor_motion.aq2 ep: 0x01 cl: 0x0400 cmd: 0x0A pl[0]: 000
23:27:32:415 ZCL attribute report 0x00158D00036678FA for cluster 0x0400, ep 0x01
23:27:32:462 no button map for: lumi.sensor_motion.aq2 ep: 0x01 cl: 0x0406 cmd: 0x0A pl[0]: 000
23:27:32:464 ZCL attribute report 0x00158D00036678FA for cluster 0x0406, ep 0x01
23:27:32:882 Set sensor check interval to 100 milliseconds
23:28:03:445 Current channel 25
23:28:03:477 Device TTL 6240 s flags: 0x7
23:28:03:643 Announced to internet
23:28:13:949 0x7CB03EAA0A028FCB onOff 1 --> 0
23:28:13:950 ZCL attribute report 0x7CB03EAA0A028FCB for cluster 0x0006, ep 0x03
23:28:23:604 0x7CB03EAA0A028FCB onOff 0 --> 1
23:28:23:605 ZCL attribute report 0x7CB03EAA0A028FCB for cluster 0x0006, ep 0x03
23:28:29:896 no button map for: lumi.sensor_motion.aq2 ep: 0x01 cl: 0x0400 cmd: 0x0A pl[0]: 000
23:28:29:897 ZCL attribute report 0x00158D0002EDA792 for cluster 0x0400, ep 0x01
23:28:29:928 no button map for: lumi.sensor_motion.aq2 ep: 0x01 cl: 0x0406 cmd: 0x0A pl[0]: 000
23:28:29:929 ZCL attribute report 0x00158D0002EDA792 for cluster 0x0406, ep 0x01

no idea whats wrong, any1 can help me? i always needs to restart hassio again

[HackThatNow]

I have exactly the same issue; it is working in Phoscon App and I can see that the state changes in Phoscon, but it is not forwarded to HASSIO

This is related https://github.com/home-assistant/hassio-addons/issues/672

[pergolafabio]

Ah ok, interesting... After how many hours you notice the issue? Maybe since 97.x ?

Cause nothing changed lately in deconz addon

[pergolafabio]

seems resolved after some HA updates and deconz not happening anymore, so closed for now

[HackThatNow]

Since updating to 0.99.2 and updating the plugin to the latest version (3.6) this is back for me and even worse. Couple of restarts of HASSIO and the plugin but still it stays working in Phoscon, not in hassio. Hassio shows the sensor as unavailable while in phoscon I can see the latest PIR movements (so it is working correctly in phoscon, but not in hassio)

[pergolafabio]

I don't have the issues anymore, not sure why, did deconz and ha updates, and it's gone.. Mine issue was different I didn't see it as unavailable, my states were just not updating

[pergolafabio]

Upgraded today to 100.1 , and my problem is back... Can someone help me to investigate?

[pergolafabio]

@Smanar do you have any idea

i had this issue in 98.x and, it was gone i think in 99.1 or something now upgraded to 100.1 , and i see issue again states are changing in phoscon, but seems websocket is dead to HA, ha doesnt see any changes anymore so lighs/switches/sensors , all down, until i restat HA only

i have enabled logging again, allthough i dont see anything strange in log can i turn more loggin on then below? maybe some websocket log?

logger:
  default: warning
  logs:  
    pydeconz: debug
    homeassistant.components.deconz: debug  

[Cybersmurfen]

Isn't this a Homeassistant issue? What happens if you revert to 0.99.3 (I use it and it is working)

[pergolafabio]

well, not sure, if its only related to HA, maybe some kind of incompatibility in websocket.... 99.3 rollback will probably work, it was stable for those 2 weeks

just wondering how i can investigate it :( for now i need to make an automation to restart HA every 12 hours or something, thats quite annoying :(

[Cybersmurfen]

Probably it is HA - because I´ve experienced other small problems related to the connectivity. Scrape sensor is one issue and I guess it uses the websocket as well.

[pergolafabio]

whats your issue then ?

[Cybersmurfen]

No biggies. But the scrape sensor timeouts sometimes. I don't remember which version it started with but I did not have any issues before. As it happens maybe every 10th check or so I don't really bother as the scrapes I use are pretty static. As I said, I think it's a matter for the HA community.

[pergolafabio]

Yes, already opened an issue there

[pergolafabio]

Upgraded to 100.2, and now seems stable again, normally issue occurs after about 12 hours, now running almost 24 hours

[murales76]

Ciao Fabio, I'm experiencing the same issue :( Running HA 0.101.2 (updated yesterday, hoping it could solve) and DeConz 3.6 I have a couple of Xiaomi Mijia door/window sensors and two temp/humidity (round type).

I tried checking DeConz log, but it's not so clear to me...I don't quite understand all those messages. Did you manage to solve the issue, at last?

Thanks

[pergolafabio]

for now, my issue is resolved, dont know how, just updated to a newer version of HA, and its running stable now maybe there was something corrupt with my update

[collinsimon]

I have similar issue after installing duckdns. I am trying to figure out why. One Xiaomi motion sensor permanently detects motionm the other one never. I lost availibility of another sensor. All other connection to deconz works properly . it is really strange. I am trying to update Hassio to 0.104.3 to see if it fixes otherwise I will just revert a snapshot I guess

[pergolafabio]

has nothing todo with duckdns :) but anyway, it doesnt happen anymore on my side since last HA/deconz updates your issue is different

[collinsimon]

can you share the versions you are currently using? Thanks

[pergolafabio]

deconz 5.1 , hassio 104.3

[audiocrush]

Hi I'm not using hassio but OpenHAB 3, but it appears to be the same problem. After openhab initialized and fetched the sensor data for the first time, deconz api is supposed to push sensor updates via websocket, but after 12-24h this randomly stops for various sensors. So deconz only sends sensor updates for SOME of the sensors, but not ALL of them. In phoscon, the new values can be seen correctly though. Also if I do a API request the correct data is replied. But somehow the websocket falls asleep or gets confused maybe? There is no conclusive information in the logs however...

[Smanar]

On deconz logs you can see at wich one websocket client deconz send notification with "info_l2"

18:53:32:642 Websocket 127.0.0.1:37364 send message: {"e":"changed","id":"5","r":"sensors","state":{"lastupdated":"2022-12-01T17:53:32.641","power":738},"t":"event","uniqueid":"00:04:74:00:00:74:06:51-01-0b04"} (ret = 2128048120)

But for me a websocket connexion, work or not, can't work at 50%

[audiocrush]

where might I find these logs you mentioned? I only know of this command: deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 but there I could not find any mentions of a websocket.

On the receiving side in the openhab logs I can see tons of websocket messages, I receive tonnes of data all the time but one sensor is always missing, it is the kitchen humidity and temperature. It is also exactly the same as 3 others that work just fine.

I have also no clue why deCONZ sends data upon initializing but not via websocket later on.

[audiocrush]

Ah! I found a difference when I was checking the api data: All the sensors have a value for etag, most have a value for lastannounced, however the sensor that does not send any data via deconz to openhab has no value for etag and no value for lastannounced.

Might that have to do something with my problem?

[Smanar]

I m using the GUI on my side but "--dbg-info=2" have the same result And you need to see the same line than me

DBG_Printf(DBG_INFO_L2, "Websocket %s:%u send message: %s (ret = %d)\n", qPrintable(sock->peerAddress().toString()), sock->peerPort(), qPrintable(msg), ret);

I have also no clue why deCONZ sends data upon initializing but not via websocket later on.

The device can disconnect, can be a report/bind issue (the configuration have failed).

The device have temperature and humidity, and only 1 is working ? or none ? what is the brand (Xiaomi/Aqara don't use classic report/bind, and use the same method for both so can't be the problem) ?

But if the device don't appear disconnected in phoscon, no reason for it don't work on openHAB as it use the API.

"etag" is not used by third app, and not send by websocket. "lastannounced" can be "null", it's not a good thing but can happen after a restart, (the announce can happen only 1 time) The important thing is the "lastupdated" you have one in all "state" part.

[audiocrush]

Hi,

both channels on the sensor have the same behavior. it is a generic tuya OEM rebranded one, I got all four of them from german online store pearl. It should not be a faulty sensor because phoscon just updates the data regularly.

[Smanar]

It should not be a faulty sensor because phoscon just updates the data regularly.

Can you show the device json ? Visible in phoscon/help/API Information/sensor

[audiocrush]

Hi,

so device ID 12 and 13 are the misbehaving sensor, and 14 and 15 are working fine for reference.

"12": { "config": { "battery": 15, "offset": 0, "on": true, "reachable": true }, "etag": null, "lastannounced": null, "lastseen": "2022-12-03T13:09Z", "manufacturername": "_TZ3000_ena8vgqb", "modelid": "TS0201", "name": "Kitchen-TempHum", "state": { "lastupdated": "2022-12-03T13:01:27.879", "temperature": 1854 }, "type": "ZHATemperature", "uniqueid": "a4:c1:38:42:31:f2:3e:ea-01-0402" }, "13": { "config": { "battery": 15, "offset": 0, "on": true, "reachable": true }, "etag": null, "lastannounced": null, "lastseen": "2022-12-03T13:09Z", "manufacturername": "_TZ3000_ena8vgqb", "modelid": "TS0201", "name": "Kitchen-TempHum", "state": { "humidity": 6273, "lastupdated": "2022-12-03T13:09:43.657" }, "type": "ZHAHumidity", "uniqueid": "a4:c1:38:42:31:f2:3e:ea-01-0405" }, "14": { "config": { "battery": 11, "offset": 0, "on": true, "reachable": true }, "etag": "4b478216315e8e401b47c67886d88f11", "lastannounced": "2022-12-03T12:39:49Z", "lastseen": "2022-12-03T13:09Z", "manufacturername": "_TZ3000_ena8vgqb", "modelid": "TS0201", "name": "Outside-TempHum", "state": { "lastupdated": "2022-12-03T13:09:49.995", "temperature": 5 }, "type": "ZHATemperature", "uniqueid": "a4:c1:38:97:51:f5:d8:91-01-0402" }, "15": { "config": { "battery": 11, "offset": 0, "on": true, "reachable": true }, "etag": "29ab8ec3c84e61babf1d165a1748b214", "lastannounced": "2022-12-03T12:39:49Z", "lastseen": "2022-12-03T13:09Z", "manufacturername": "_TZ3000_ena8vgqb", "modelid": "TS0201", "name": "Outside-TempHum", "state": { "humidity": 7866, "lastupdated": "2022-12-03T13:09:50.073" }, "type": "ZHAHumidity", "uniqueid": "a4:c1:38:97:51:f5:d8:91-01-0405" }

[Smanar]

"state": {
"lastupdated": "2022-12-03T13:01:27.879",
"temperature": 1854
},

"state": {
"humidity": 6273,
"lastupdated": "2022-12-03T13:09:43.657"
},

So both have made recent notification, you don't have them in openHAB ? The application haven't something to display a "lastseen" by sensor ?

BTW

"battery": 15,

It's something normal ?

[audiocrush]

Hi, yes this is correct. Yea unfortunately these sensors are total garbage at estimating the battery remaining capacity. I just ignore it, expecting the AAA nimh batterys to last about a year or so before they need recharging.

[Smanar]

Hi, yes this is correct.

Mean the update is visible in phoscon (the "lastseen" is visible on the sensor description, the last line) But you haven't the same value on openHAB and no way to see the lastseen or the last updated in the application ? On my domoticz plugin if the value don't move, I don't make update (to don't trigger event in the application), so the application see the change but don't memorise it.

Yea unfortunately these sensors are total garbage at estimating the battery remaining capacity. I just ignore it, expecting the AAA nimh batterys to last about a year or so before they need recharging.

Can come from deconz too, the maximum displayed is 100 or 30 ?

[audiocrush]

The only value that openhab can request from phoscon is "lastseen" which it does successfully and reliably. I can set a refresh value for the interval this is supposed to happen. Why does the deconz plugin not provide a poll refresh mode for all the values like the lastseen? This would solve my problem, because for whichever reason phoscon does not seem to reliably send this information on its own. There is no way for me to find out why. Is there really no log in phoscon that say when it did send what to whom?

[Smanar]

Deconz send a notification at every change, a state, or a "lastseen". Third app, like phoscon or openhab never poll deconz, no need poll interval, it's a websocket connexion. And all receive the same notification in same time.

You have logs in deconz/help/debug view, you can see the ip and the port used to send the websocket.

18:53:32:642 Websocket 127.0.0.1:37364 send message: {"e":"changed","id":"5","r":"sensors","state":{"lastupdated":"2022-12-01T17:53:32.641","power":738},"t":"event","uniqueid":"00:04:74:00:00:74:06:51-01-0b04"} (ret = 2128048120)

But easier you can see all websocket notifications in phoscon/help/api information/event (Openhab need to receive the same)

[audiocrush]

well funny enough, it is working since almost a week now still trying to find out why though :D