Tell me zigbee is more reliable than this [Devices offline]

saverio · August 31, 2024, 5:20pm

Hello!
No and in the same switch box there are three switches, two perfectly online right now, heres one of them:

{ "last_seen": "2024-08-31T13:48:33.565Z", "linkquality": 176, "state": "OFF" }

versigo · August 31, 2024, 5:21pm

Do you have steel back boxes in the wall they are fitted to?

zebrahosting · August 31, 2024, 5:38pm

I have the same mixed results with Zigbee and slowly going back to Zwave what has been stable for the last 25 years….
All devices I also use for my alarm need to be rock solid.

saverio · August 31, 2024, 5:47pm

No, here in Italy we don’t use them. All plastic

ShadowFist · August 31, 2024, 5:51pm

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?

Hedda · August 31, 2024, 6:09pm

Zigbee has much shorter range due to worse radio propegation than Z-Wave because Zigbee 2.4GHz and that means that you are going to need to make sure that you add many more ”good” Zigbee Router devices and spread them out yet seento it so they are in range of each other. If you read, understand, and follow all these tips then you should be fine → Zigbee networks: how to guide for avoiding interference + optimize using Zigbee Router devices (repeaters/extenders) to get a stable mesh network with best possible range and coverage

jackjourneyman · August 31, 2024, 6:21pm

I take it your switches do appear in the Z2M list of supported devices?

Edit: There are half a dozen Vimar products mentioned in the Blakadder database, and they all seem to be OK.

ShadowFist · August 31, 2024, 6:26pm

Yes, he already posted a link to the Z2M page further up

jackjourneyman · August 31, 2024, 6:28pm

Sorry, missed that.

saverio · August 31, 2024, 9:03pm

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.

The firmware is the same in every switch.

Do you suggest to try another coordinator then?

ShadowFist · September 1, 2024, 9:02am

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.

aceindy · September 1, 2024, 9:59am

Zigbee devices should never be switched off, especially the routers…

saverio · September 1, 2024, 10:05am

Yes I have only one zigbee switch for bulb.

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?

saverio · September 1, 2024, 10:06am

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.

ShadowFist · September 1, 2024, 10:45am

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.

saverio · September 1, 2024, 12:49pm

interesting logs found when activating debug and manually turning on/off the offline switches:

[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6](ackRx=6 frmTx=6)
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6 frmNum=1](frmRx=1) Added to rxQueue
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=2](ackRx=6)
[2024-09-01 14:46:37] debug:    zh:ember:ezsp: <=== [CBFRAME: ID=98:"undefined" Seq=189 Len=13]
[2024-09-01 14:46:37] debug:    zh:ember:ezsp: <=x= Ignored unused/unknown [CBFRAME: ID=98:"undefined" Seq=189 Len=13]
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6](ackRx=6 frmTx=6)
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6 frmNum=2](frmRx=2) Added to rxQueue
[2024-09-01 14:46:37] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=3](ackRx=6)
[2024-09-01 14:46:37] debug:    zh:ember:ezsp: <=== [CBFRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=189 Len=31]
[2024-09-01 14:46:37] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":10,"destinationEndpoint":1,"options":3392,"groupId":0,"sequence":141}], [packetInfo:{"senderShortId":11746,"senderLongId":"0xFFFFFFFFFFFFFFFF","bindingIndex":255,"addressIndex":255,"lastHopLqi":124,"lastHopRssi":-69,"lastHopTimestamp":0}], [messageContents=08bf0a00001001]
[2024-09-01 14:46:37] debug:    zh:controller: Data is from unknown device with address '11746', skipping...
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6](ackRx=6 frmTx=6)
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6 frmNum=3](frmRx=3) Added to rxQueue
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=4](ackRx=6)
[2024-09-01 14:46:40] debug:    zh:ember:ezsp: <=== [CBFRAME: ID=98:"undefined" Seq=189 Len=13]
[2024-09-01 14:46:40] debug:    zh:ember:ezsp: <=x= Ignored unused/unknown [CBFRAME: ID=98:"undefined" Seq=189 Len=13]
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6](ackRx=6 frmTx=6)
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=6 frmNum=4](frmRx=4) Added to rxQueue
[2024-09-01 14:46:40] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=5](ackRx=6)
[2024-09-01 14:46:40] debug:    zh:ember:ezsp: <=== [CBFRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=189 Len=31]
[2024-09-01 14:46:40] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":6,"sourceEndpoint":10,"destinationEndpoint":1,"options":3392,"groupId":0,"sequence":142}], [packetInfo:{"senderShortId":11746,"senderLongId":"0xFFFFFFFFFFFFFFFF","bindingIndex":255,"addressIndex":255,"lastHopLqi":128,"lastHopRssi":-68,"lastHopTimestamp":0}], [messageContents=08c00a00001000]
[2024-09-01 14:46:40] debug:    zh:controller: Data is from unknown device with address '11746', skipping...

note:

[2024-09-01 14:46:37] debug:    zh:controller: Data is from unknown device with address '11746', skipping...

this device on Z2M dashboard has this address:

Network address
0xECF1 / 60657

any idea why it’s reported with 11746?

Same errors in the other two offline devices.

and is this issue something that could be resolved with another coordinator?

ShadowFist · September 1, 2024, 3:04pm

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.

saverio · September 1, 2024, 3:14pm

Yes of course I posted them!
Also, I found this:

It looks like it’s really something that should be handled by Z2M but for some reason doesn’t.

ShadowFist · September 1, 2024, 3:53pm

Hmm, I wonder if this could be solved simply by enabling advanced availability in Z2M.

Wouldn’t hurt to try I guess:

mamoel · September 1, 2024, 4:11pm

You could try ZHA instead of Zigbee2MQTT.