Then I’m all out of ideas. There’s only 2 possible options left:
if it’s always the same devices showing these symptoms, check the firmware version on these against the working ones. If they’re identical, it could be an actual hardware issue, in which case I’d get in touch with Vimar for a possible replacement.
if the issue jumps from one device to another, then I’d start looking into getting a better coordinator (ideally a network one with an external antenna). I know it sucks because you invested in the yellow, but it might be your only way out.
There is one final option, but it’s a bit more involved. What happens if you swap the wiring between a working switch and a non working one? Does the problem move with the switch, or does it stay in the same place?
I just turned off power of every switch (not the HA yellow) waited half a minute and turned it on again. The device offline came back online (this was surprising), but three other switches are now offline with same errors as above.
Another coordinator won’t do any harm. Worst case scenario if it doesn’t fix your issue is that you flash it with router firmware and use it to strengthen your mesh.
However, I found the instructions for the switch you linked and spotted this:
Are your switches all 2-way switches (the 14592.0 model you linked to)? Because from what I can tell from the instructions, you should only have one smart switch per 2 way circuit, right before the bulb - all other switches should be dumb switches.
PS - did some more digging around, and it seems like these switches go into pairing mode if you cut off their power at the breaker?!? Maybe this is what you’re seeing:
If the 2-way switch is not in pairing mode, cut off the
power supply and restore it after a few seconds.
EDIT: There’s a similar issue reported on the Z2M github. I think what you and the other guy are seeing is the default pairing mode behaviour for these switches when they lose power.
I don’t think that’s the pairing mode because when the switch is in pairing mode it flashes the white led (and that’s not happening). It enters in pairing mode only if it is not already paired.
The issue in Z2M is very interesting, I didn’t find it and I can assure I read every single issue I could find
Very interesting the fact that the user says it wasn’t a problem with deCONZ, maybe it’s a Z2M issue then?
Still power outages happen if I want it or not, and I don’t want to repair every switch every time it happens. Those issues weren’t present in zwave or wifi devices.
It could very well be a Z2M-specific issue with these switches. Best to turn on debug logging for Z2M and add them to the github issue so the dev has more details to go on rather than “me too”.
In the meantime, I’d suggest trying a different coordinator with a proper antenna. Something like the SLZB-06 / SLZB-06M has decent feedback here and is relatively cheap. I personally have been running one of Tube’s zigbee coordinators (again with an external antenna) and it’s been rock solid for me, but it’s slightly more expensive.
It might, or it probably won’t if your devices are changing their address. Having an extra coordinator with a better antenna surely won’t hurt though. Like I said - worst case scenario is you flash it with router firmware and use it as a dedicated router.
In the meantime, make sure to post your debug logs in the Z2M github issue. It might be the only way to help yourself (and others) troubleshoot this.
Yes that’s one possibility, I’ll wait if Z2M devs want to do some troubleshooting or have some hotfix to try… Otherwise yes that’s definitely something I’ll try.
I think I can confirm what’s the issue with Z2M and Vimar devices.
That’s my theory:
When you power off the devices, a lot of Zigbee routers go offline
When you power on the devices again, for some reason I asked Vimar (waiting reply), some devices decide to change their network address
When devices change their network address, they emit a “Device announcement” frame, which is normally captured by the coordinator and Z2M updates the network address of the device with the new one.
Since a lot of routers are offline or are starting up, that device announcement isn’t correctly captured by Z2M.
A fix without need of repairing the device is updating the device network address manually in Z2M. This, in my case, restored the connectivity of the devices.
After powering on the devices, wait to see which one are offline in the “devices” page of Z2M. It takes 10 minutes with the default availability settings
If there is some devices offline, enable debug logs (Logs → logging level debug)
go on the logs’ directory, i.e.: /root/homeassistant/zigbee2mqtt/log/2024-09-03.12-27-45 (replace with most current directory)
tail and grep for unknown devices: tail -f log.log |grep "Data is from unknown device with address"
go on every device offline and manually turn on/off the switches. You will see in the logs something like: Data is from unknown device with address '11746', skipping...
do this for every device and take note of the number seen (i.e. 11746)
go on the device page of the devices offline in Z2M and take note of the old network addresses in decimal, i.e. Network address 0x872F / 34607
after you took notes of every device offline, turn off Z2M
go to Z2M config directory, i.e. /root/homeassistant/zigbee2mqtt/
backup the database cp database.db database.db.backup.20240905
for each device, replace the old network address with the new one. You can do it manually or via a command like sed --in-place 's/\"nwkAddr\":34607/\"nwkAddr\":11746/' database.db where 34607 is the old network address and 11746 is the new one
When you replaced everything, restart Z2M
I know it seems complicate but in reality is less tedious than repairing Vimar devices, because you can reset them only powering them off (and this aggravates the situation; you fix one and break another device) or reflashing them with bluetooth and then zigbee firmware (tedious as this also is unreliable).
I am investigating if there is a mode to avoid changing addresses so frequently (waiting for a Vimar support reply) and also if there is a solution to do a fix via Z2M (though I think this is more of a Vimar -and zigbee- issue rather than Z2M)
Ok so we know what’s going on at least. (weird funky slightly off spec vendor specific behavior. Huh. Gotcha… Interesting)
That said really good info. Not a good solution. You theoretically have enough information to be able to write or have a zigpy ZHA device driver written to handle the specific vendor behavior. (note I am not skilled in that particular par so I can’t assist) but that.s what quirks are for…
It should be able to handle the behavior of the device so you don’t have to do that mess of a workaround
