forum

ok So I have struggled mightily to upgrade firmware on both my razberry and my uzb. After a number of tries with the razberry, I managed to get it in. It kept erring out with this message on a rPi3b+:

Error 1 Unknown exception:Can't write NVM data! at=XXXXX

The location at which it stops seems completely random. So far I have not been able to update the uzb. The furthest i was able to reach was 70%.
Any insight as to why this is happening?

Depending on versions sometime you need to add offset in the NVM. I would suggest to use Z-Way to upgrade the UZB firmware.

Hi. Just installed 5.39 on one of my UZBs.

A) So far, no dead devices on restart. Will report if they show up.

B) BUG : This no longer works:

5.06: LED can be turned off:
Change it via IP:8083/JS/Run/zway.NVMExtWriteLongBuffer(0x6510,[XX]), where XX is:
0x00 LED used only for memory test when device powers up. Silent mode.
0x01 LED used during memory test and to indicate inclusion/exclusion mode.
0x03 LED used during memory test, to indicate inclusion/exclusion mode and it blinks when data is sending.

C) Possible BUG : On restart I had the NWI packets again. I am unsure if its just once or if it will keep sending them every 5 minutes like before. As soon as I saw them in zniffer I added the following again, and it stopped them:
Previously I had just this, but this is no longer enough:
Maybe its normal to send the NWI explorer packets once on restart? Like I said, I saw it once and added the above code right away so not sure if its doing the 5 minute cycle like previously.

Will post if anything else comes up.

After a lot of pain, I finally was able to upgrade the uzb with the ZME tool and booted the z-way-server. So far no false IsFailed report.

Seems to be some translation problem with the previous post but... I tend to agree. Upon reboot of the server (not of the zwave chip which has remained on with no reboot for the past 6 months), I can still see randomly devices coming up as "dead". Because the devices changes all the time and they are completely random, I think it is a bug in the z-way-server, tagging devices as dead. It is relatively easy to fix, using the JS API command for battery operated devices and just running a poll on AC powered one but still, it is a bug. I also briefly tested on openzwave and it never does this. So it isn't the zwave chip. It is the z-way-server.

Can you check if is failed field is true or false for such device in EUI? Because in smart home UI there is additional logic on top of EUI

PoltoS wrote: ↑

10 Sep 2020 00:18

Can you check if is failed field is true or false for such device in EUI? Because in smart home UI there is additional logic on top of EUI

They show up as isFailed = true and it is actually the command I use through the JS API to make isFailed = false.
I can see from the command queue during the z-way startup that z-way tries to do a check on whether the device is dead. If the dongle does not respond, then it deems the device to be dead. The problem is that upon boot up of the z-way-server the command queue is several hundred commands long and a lot of the commands likely will timeout or run into a collision either through RF or even simply the serial bus. I would suggest not to interrogate the dongle for dead devices upon boot up but to put that functionality elsewhere since the z-way-server seems to have a lot of other things it is trying to do with the dongle when it starts up.

There might be no collision in Serial API. Please show an example of such collision that resulted in isFailed = true.

I believe the chip really believe it is a failed one and answers us that way

I am 100% sure that the chip is not responding that the device is dead. I can plug it into the silabs pc controller and show you that none of the devices ever is tagged as failed. At every single z-way-server start 1 to 3 of my devices show up as failed on z-way and they are never the same one. I can leave it alone and restart z-way and another different set of 1-3 devices will show up as failed. The problem is in the z-way-server process start. I didn't analyze the serial communication, I can only see the command queue and the event where z-way checks if the device is failed and shortly after, it says that it is. It could be worse on a very large network like mine but I think it is due to some communication error between z-way and the dongle or due to some unnecessary check from z-way which is timing out because the zwave dongle is already too busy during the startup.

No need to guess - please check Z-Way log and let's look together in Serial API bytes.