UZB/RaZberry Firmwares - Update

[parkerc]

Ok, clicking on UZB all and then 5.7, it gives me the following..

The second one relates to the bootloader upgrade option that’s presented.. is it suggesting I update the bootloader first ?

{"data":[{"id":"252","baseid":"","enabled":"enabled","type":"bootloader","file":"bin","vendorID":"277","bootloaderCRC":null,"appVersionMajor":"5","appVersionMinor":"7","targetBootloaderCRC":"40196","targetAppVersionMajor":null,"targetAppVersionMinor":null,"fileURL":"UPD_BOOTLOADER_UZB_ZME_05_07_04000001_9d04.bin","released":"2018-01-12","comment":"Update bootloader to 9d04","position":"70","version":"5.7"},

{"id":"98","baseid":"","enabled":"disabled","type":"bootloader","file":"bin","vendorID":"277","bootloaderCRC":null,"appVersionMajor":"5","appVersionMinor":"7","targetBootloaderCRC":"29304","targetAppVersionMajor":null,"targetAppVersionMinor":null,"fileURL":"bootloader_UZB_from_05_07_to_7278_2MB.bin","released":"2017-05-12","comment":"Update bootloader to 7278","position":"72","version":"5.7"},

{"id":"88","baseid":"","enabled":"disabled","type":"firmware","file":"bin","vendorID":"277","bootloaderCRC":null,"appVersionMajor":"5","appVersionMinor":"7","targetBootloaderCRC":null,"targetAppVersionMajor":"5","targetAppVersionMinor":"7","fileURL":"UPD_FIRMWARE_UZB500_X_from05_07_to_UZB500_3CH_05_07.bin","released":"2017-04-18","comment":"Update firmware to 3 channels (JP/TW/KR/SG) on 5.07","position":"57","version":"5.7"},

{"id":"89","baseid":"","enabled":"disabled","type":"firmware","file":"bin","vendorID":"277","bootloaderCRC":null,"appVersionMajor":"5","appVersionMinor":"7","targetBootloaderCRC":null,"targetAppVersionMajor":"5","targetAppVersionMinor":"7","fileURL":"UPD_FIRMWARE_UZB500_3CH_X_from05_07_to_UZB500_05_07.bin","released":"2017-04-18","comment":"Update firmware to 2 channels (EU/RU/US/ANZ/MY/IL/..) on 05.07","position":"58","version":"5.7"}]}

[rafale77]

I went to read the map myself and here are the steps I would take:
5.7 -> 5.7 40196 BL -> 5.27 ->5.36 ->5.39

So yes Bootloader first in general but need to read the version.

Also there is a hex to dec you need to do to understand the numbering. 7278 is 29304 and is likely a bootloader downgrade. You need to know what version of bootloader you are on right now.

[parkerc]

Using the control ‘Show Controller Data’ option, it looks like my bootloader is 40196

So based on your recommendation I would do the following..

Update bootloader to 7278
Update firmware to 5.25
Update firmware to 5.36
Update firmware to 5.39

[parkerc]

Just to confused matters,

I’ve upgraded the bootloader to 7278, and the information in the system has changed to 29304

And I’m now presented with another bootloader option..

This time.. 9d04 , which hex to Dec = 40196 - which means I downgraded the bootloader ?

This is turning out to be far more complicated than I thought - I had hoped the expert UI would guide me through the required sequence so I have the latest version .

So now we have 5.22 and 5.23 added In to the mix ?

Sorry for all the questions

[rafale77]

So indeed as I said 7278 seems to be a downgrade. I wouldn’t have run the boot loader update knowing that my boot loader number was already higher. Sorry for not being clear. You indeed need to be on 40196 and then move on from there as I described from my previous post.

[parkerc]

Thanks for all the guidance @rafale77

I’ve reapplied the bootloader update, and have started to go through the incremental firmware updates..

Update : What’s interesting is after going to 5.25, it gives me two sideways options of ‘normal’ and ‘bridge’ version ?

Assuming it’s knows what it’s doing - and to try to keep moving on, after going to 5.26, (which admittedly was not in our earlier list), I now have the following options .

Trying to work out the correct path to take (factoring what ‘active; and what not) is a puzzle in itself_

All..
Active ..

Looking at the published firmware releases, is that the path I ultimate want to take ?

So, that would suggest 5.27 firmware (not bridge) next - rather than 5.33 ? (Any idea why there are all duplicates ?)

[rafale77]

You didn't need to go to 5.26. As you can see from the graph, 5.27 is kind of a central version from which they build many upgrades from so it is the pivotal version. I only use the static versions of the firmware.
5.33 is a dead end. Don't go there.

[parkerc]

@rafale77 said in UZB/RaZberry Firmwares - Update:

You didn't need to go to 5.26.

I didn’t seem to have any other option, (based on the earlier screenshot) all I could do was upgrade from 5.25 to 5.26. But now I’m on 5.26, I do have the 5.27 option..

[rafale77]

ha... such a complicated scheme... it really didn't need to do so. But anyway, once you get to 5.27 you can practically go anywhere you need.

[parkerc]

Hi @rafale77, seems I’ve reached another block, trying to move from 5.26 to 5.27

And now over 3,600 items appeared in the queue..

I’ve tried a couple of times , same result..

[rafale77]

Yeah there where I switched to the command line tool. Do you already have devices on that stick? @poltoS says it is because the upgrade process is interrupted by RF signals. I thought it was due to some EEPROM start location issues but I did find it painful in recent versions to upgrade and had to retry dozens of times to get it through. It looks like the upload of the firmware started but gets interrupted by something.

[parkerc]

@rafale77 said in UZB/RaZberry Firmwares - Update:

Do you already have devices on that stick?

No, currently it’s blank, I reset it before I started down the whole upgrade path. What it is near is loads of other HA devices, 2 x Veras (a 3 and a Plus) and there’s also a hue hub and numerous other things .

Could that have an effect ?

[rafale77]

Hmm possibly. But I don't know for sure. The recommendation was even to temporarily change region so as to prevent any noise from interrupting the upgrade process. I don't know why they don't have a better way to not be impacted by the RF signals during the upgrade on these newer firmwares.

[hunnypuppy]

A kinda basic question, I'm currently on UZB1 firmware 5.34
What is the advantage of going through this process to get to 5.39

The only I notice is that it seems to have something called Zniffer feature to trap packets. What exactly does this enable? I can see packets in Zniffer using Z-Way (when using as a secondary controller but only between the secondary controller and device, not between devices and primary controller) and Zniffer ART seems to indicate that it needs different hardware. So where can this Zniffer additional 5.39 feature be used or is there any other advantage to upgrading the firmware?

[hunnypuppy]

I'll answer my own question for others benefit. I was able to successfully upgrade UZB from firmware 5.34 to 5.39 using Z-Way server and the all token to first downgrade and then upgrade following this path.

5.34 → 5.33 → 5.27 → 5.36 → 5.39

My bootloader version is 40196 and I did not upgrade the bootloader along the way, I started and ended with the same bootloader.

I did a ResetAPI followed by a ControllerReset after each firmware downgrade/upgrade to ensure that I had a clean start. I also disabled all zwave device (unplugged/removed batteries) to ensure that any stray packets didn't interfere with the process. Be sure to backup your configuration/network before updating the firmware.

After upgrading to 5.39 I'm now able to use the promiscuous mode in Z-Way zniffer to capture packets on the network (although it misses some packets)

I did get a note from support, so those with firmware under 5.24 may want to pay heed to this.

there is a batch of sticks with "dead-end" firmware and a slightly modified board topology. But given the fact that such sticks are usually impossible to upgrade above version 5.24, then you most likely have a good stick for which this operation will be possible.