Are we talking about the same device? My on/off buttons, marketed as wireless dimmers, are on 2.3.079 which was released at the end of October last year.
When I compared the DTH and Edge driver some time back, I thought they were being configured differently between the two and so I was surprised they worked. But work they did. Probably my misunderstanding though.
I’ve had an uptick of Zigbee devices running stock ST edge drivers going offline since .6 and .7 releases. What I’ve noticed for those devices is that the CLI reports the networkId as one number, but the IDE reports it as something else. As soon as that happens my hub’s event logs start to get flooded with messages like this (real example from this morning of a zigbee switch):
raw:9DB0000022A30000251985, dni:9DB0, errorCode:00, ieee:0022A30000251985
IDE networkID is reported as “9db0”, but the CLI says “2BBC”.
The only way to recover is to reset the device (not delete) and then go through the add new device process. As soon as the device is rediscovered, it comes back online and the networkID is back in sync. For the incident this morning, both the CLI and IDE now report the networkID as “2BBC”.
Automations and device control is also crazy slow too.
I just connected that button to Home Assistant so I can see the firmware version (needs to be a feature in the ST app).
Turns out mine was updated to V2.3.079, not V2.3.028.
The number above was from the Ikea changelog
I have to try to fix my abnormal disconnects first, so now I feel useless here, so I decided to quit the beta program. I have a question, will my hub revert to the previous official firmware, or will it stay with this beta until the next official firmware release?
I also have this type of zigbee device messages that perform a zigbee rejoint and change the network id time to time, the last was 3 days ago. It happens to me in 2 very specific devices (one samjin multiporpuse and one smoke sensor, located very close to each other) that, due to their physical location, have worse coverage or change repeaters frequently, the latter I saw during the time I was with DTH groovy metrics.
This has been happening for more than 2 years that I have it in use.
2022-10-03 9:10:07.000 AM CEST
hace 3 días HUB
raw:22E500842E14FFFEF6F0DA, dni:22E5, errorCode:00, ieee:842E14FFFEF6F0DA raw:22E500842E14FFFEF6F0DA, d… raw:22E500842E14FFFEF6F0DA, dni:22E5, errorCode:00, ieee:842E14FFFEF6F0DA
2022-10-03 7:00:11.000 AM CEST
hace 3 días HUB
raw:073E00286D97000108F5BE, dni:073E, errorCode:00, ieee:286D97000108F5BE raw:073E00286D97000108F5BE, d… raw:073E00286D97000108F5BE, dni:073E,
errorCode:0
The difference with your case seems to be that yours devices disconnect and mine never disconnect, they do the rejoint automatically and they continue working.
I have selected the HUB configured with “unsecure rejoint”: True. this should allow zigbee devices that are disconnected to reconnect automatically.
Im set up with unsecured rejoin too. I have over 120 mains powered zigbee devices acting as repeaters, and up until the “migration” i rarely had devices go offline. Now its several times a week and it is always a different device.
My on/off switch has worked for a couple of years without issues, also worked flawlessly with the edge drivers until the 45.6 hub firmware + Zigbee stack.
I have tried numberous attempts of removing and adding them again (I have 4) and the join and register battery ok but not bitton presses.
My hub is the Smartthings V3 (prior to Aeotec).
Another real time example of an offline Zigbee switch where the networkID’s are out of sync.
This is what I came home to just now:
IDE Hub event log: (it’s been doing this for 2 hours)
IDE Device:
CLI Device:
We are going to be releasing 0.45.8 today (Oct 7th) with the following release notes:
Got it, and it’s not been a good morning ever since…
This is happening every minute: (before and after the .8 release by about an hour before I got it this morning)
I have 45.8 now, so hopefully it shows some improvements.
There’s still something not right. I have a few zigbee sensors that report all the time, but haven’t for 2 days and ST says they are online, which is not the behavior these sensors have had for years.
In my post above, I can’t find device 5DDE, but I suspect it’s a Halo smoke detector, so I just tested them, and now there’s even more messages:
I’m going to reset that device and the few other zigbee sensors that show a last update of a couple days ago and then reboot my hub to see if that brings back some stability for a little while.
Even if I came out of the Beta, I received the 45.8 ok, I will continue to use it and see if there is actually an improvement of the zigbee. In Italy, as some of you know, up to firmware 43.4 everything is ok, since 44.09 the problems of chained disconnections began for many users who use Vimar in Italy, and even with this version I continue to encounter these problems. I am slowly wiping all Zigbee devices then resetting the hub and trying again. (I have already tried with the hub reset only but after 24 hours the disconnections are resumed)
Ok, it appears to have been another example of a networkID change but the device still remembering the old one.
The device in question : Media Room Smoke Detector (found to actually be offline but reported in the app and IDE as online)
Old ID : 5DDE
Reassigned ID (how that happens I have no idea) : 120F
New ID after deleting the device from ST and factory resetting it and rejoining it : 77F9
The event log doesn’t seem to be flooded with these messages now.
Even with the new firmware 45.8 the problem of zigbee devices is not solved. They all log off randomly
My hub zigbee shows state: functional, but the devices that were offline never came back online. I tried scanning, but they didn’t come back online. Most are bulbs. Should I try resetting them, or is that not worth the effort (FYI, my bulbs are difficult to reset)?
Just try manually turning them off and back on. That’s what I did and that worked.
Was anyone able to get the IKEA 2 button dimmer working again after the ZigBee update without an IKEA hub?
Out of curiosity I just deleted and re-paired one of the IKEA ‘on/off’ buttons on my beta hub. It works fine. However my motive was to compare my log with one submitted in an issue over on the GitHub repo. The most striking thing to me was that my log included a couple of bind responses and a management bind response that just weren’t there in the log on GitHub.
I genuinely have little understanding of what I just wrote but I figured since the management bind response has a handler it must be kind of important.
I was, but I had to upgrade the firmware on the two dimmer devices that stopped working (I have an Aeotec branded V3 hub).
I had two other dimmer devices that were already on the latest Ikea firmware, and those ones continued to work after the zigbee update.
