NOUS A1Z Network Drop... forever? Bricked?

I do like the NOUS A1Z. I am using the binding-zibee.
Adding them to the network is trivial and rather fast.
They are easy to use and to the job… until they no longer do.

I had the issue already with 3 units. The symptoms are always similar:

  • everything working fine
  • one day, nothing work
  • resetting the device appears to work (they blink…)
  • adding the device again no longer work, ever

I am trying to identify whether the issue is actually on the devices’ side (ie they are now damaged) or if there is an issue on the OH/ZigBee side.

If the issue is on the OH side, I would qualify those devices as great. They are nice for the price. If however OH is fine, then I would conclude (after losing 3 units… not just 1…) that they are really sub quality. So far, the manufacturer has been “cool” and I received replacement units (not many questions asked, which is both nice and a little scary… as if some issues would be known).

Once the devices stop “working”, they appear to actually work all fine. Using the button, the relay switches fine, long press goes to reset and the LED blink. The main issue is that OH will never accept those again. I tried removing them first from OK but that does not help.

Suggestion to id the culpritt are welcome.

1 Like

Have you tried using them with zigbee2mqtt? That would completely eliminate OH from the mix.

Not much I could add: In my case I use them with z2m and they work flawlessly for years now. As they can measure the power and handle up to 3000W they’re great for the dryer and the washing machine.

tldr: I did not try zigbee2mqtt.

The main reason being that I “only” use a RPI4 and I don’t find it amazingly snappy. Maybe moving to a SSD could help.

So far I refrained from using zigbee2mqtt to alos reduce the mqtt traffic. I may eventually give it a spin but I try not installing things I don’t really (really :)) need.

zigbee2mqtt would eliminate OH from the mix but add an intermediary. So it probably will solve some issues and introduce new ones.

I’m on the opposite side: I always used z2m on Pi4 and Pi5 and always with SD-cards. Performance was never an issue and I like the additional control with the UI of z2m. But I have to admit I never tried via direct openhab-binding as it’s not supporting parts of my hardware.

1 Like

My question regarding zigbee2mqtt was in response for testing purposes

based on your question.

Hmmm I guess I could install zigbee2mqtt in a container and test there. That would not affect my OH install. It is a good idea, thanks.

How would adding z2m increase traffic? Makes no sense.

Like others, I also moved from the binding to z2m; no problems since.

My expectation would be that changing to z2mqtt will not help if the devices are leaving the network for some reason (as I understand from the description above). The network connection is maintained through the low level system and not by the likes of the zigbee binding, or z2mqtt.

1 Like

true, but usually z2m runs with TA-based chipsets while the binding supports ember chipsets. So that might have an influence, don’t you think?

z2m uses both TI and Silabs chips. Silabs chips are pretty good - at least as good as the TI chips and probably at least as common these days. While there could be a bug in the firmware of the coordinator, I would be surprised.

In any case, my point remains - changing to z2m is unlikely to resolve this, Even if you are correct and this is caused by a bug in the firmware, if the user keeps the same coordinator and changes to z2m, the bug would still be there don’t you think?

2 Likes

Why would that make no sense ?
I don’t know the intricates of z2m but it seems to be adding a layer in the comm, forwarding everything to mqtt.

Did you have issues before using z2m ? Are you running z2m on a rapsberry pi on the same machine than OH ?

Thanks @Larsen, good to know.
I also now remember one of the reason I never evaluated z2m, I have a single ZigBee stick and I use it for quite some devices with the OH binding.
So installing z2m should be no brainer, but using it would require a new ZigBee stick.
If I would be starting, that could be an easier option but now that my network is built, I am a bit reluctant to “move” unless I know for a fact it will be THE solution.

You’re right; I wasn’t thinking straight. :slight_smile:
Instead of Zigbee comms you now have MQTT traffic.
But given the capability of the protocol, I cannot see a negative impact.
I am running almost 100 RGBCW LEDs plus umpteen of powerplugs, in addition to some 50 controllers all talking MQTT, and the rPI4 with the broker on it has a load of 0.19%

# [2024-11-11 20:22] openhabian@openhabian ~ $ 
top - 20:22:47 up 124 days, 21:15,  3 users,  load average: 0.19, 0.13, 0.15

I used to run the binding, but moved away from it due to having bought unsupported devices. The z2m community is much greater, hence, faster addition of new devices that the binding developer(s) at OH, who certainly support the standard, but the AliExpress sellers often do not.
And yes, running the MQTT broker on the same rPi4 as openHAB.

1 Like

I now tried Z2M after being a Sonoff Zigbee 3.0 USB Dongle Plus -E (that has been a bit of a pain to setup / flash until I realized that all the doc pointed to installing the wrong serial driver… with that figured out, it was fairly straight forward).

First I used a working A1Z. I “deleted” it from the OH binding.
It showed up instantly in Z2M (to m my suprise) and was usable after a short bit.
Now cherry on top with Z2M, I see that OTA are possible. I did update my A1Z:

{"installed_version":78,"latest_version":192,

I removed it from Z2M and added back to OH without any issue (very smooth actually).

I then brought back my defective A1Z one after the other. They were unplugged for quite some time now, so definitely more than 10s :slight_smile:
NONE of them showed up in Z2M. I tried resetting them with a 10s button press until they blink, nothing at all.

So as mentioned above (thanks for the suggestion @justaoldman), we can exclude any issue related to OH and its binding.

What I could imagine is a faulty firmware 78. At least I am now running on 192, if the unit fails, that will invalidate the theory. The more time passes without failure, would validate the issue.

This should be a none issue for Z2M users who can easily update the firmware with OTA. This is however a critical piece of information for OH/ZigBee binding users who may run into the issue. 4/6 items became unsable so far.

I am in touch with “Nous”. They have been compliant (apparently not caring about understanding the issue…) and sent replacements so far. Their last replacement did not last 3 weeks though.

For reference, OH/Zigbee binding users can check the information in OH and see their firmware version. Here is what my update device looks like now:

Nous Support seems to be changing views now and playing “unfriendly”.

Despite my confirmation that I tested using 3 software platforms and 3 different controllers, all leading to the same conclusion that the ZigBee part of the plug is dead/bricked (the relay does work), they mention (without any explanation to the statements):

It is highly unlikely that the issue lies with the devices themselves.

Probably because NOUS devices just cannot go bad right ? …
Not all below is Zigbee but that could help:

Therefore, we believe that the problem is more likely related to Z2M.

The support guy is ignoring that I tested first with OH and the Zigbee binding and it did not work. I then tested with eWelink and the Sonoff controller, same result.
I finally tested with a Sonoff ZigBee 3.0 stick and Z2M, same result.
But the support guy believes …

Unfortunately, without understanding how everything is configured on your end, we are unable to assist further.

They send me this after I sent them 6 messages with an increasing number of information about my tests, the env, the outcome, etc… which obviously, they did not even bother reading.

However, it is clear in this case that the devices are not the source of the issue.

So to recap, enlighten by the lack of information they mention (not) receiving from me, it is clear that the device, that does not work, cannot be the problem. :grimacing:

At that point, I am not sure if I simply ran into a guy that had a bad day or if the attitude is the “NOUS” standard. Time will tell… I hope they find a way to be more useful understanding and resolving issues b/c, ignoring the problem, the products are nice. But a nice product that does not work AND an unhelpful support is a no go afaik… Let’s see.

It looks like I am not the only one: Nous A1Z stopped responding · Issue #22338 · Koenkk/zigbee2mqtt · GitHub