Oh nice. I used this and am happy to report that all my devices are now updated with proper firmware version and date codes. Sometimes it’s the little things that matter 
Just waiting for the new configurations to be exposed through Z2M now!
2 Likes
After waiting several months, my 40 Blue 2-1 switches have finally arrived. I’m sure they’re all going to need updating. If your firmware update bricks the device, you’re not responsible? Please clarify. I don’t want to risk a couple thousand dollars worth of switches, but it seems that this is a necessary update in order fix a number of zigbee issues.
Doesn’t the device check the integrity of the update (CRC, etc.) before flashing the rom? If something goes wrong during the update, doesn’t the device have the capability of using the existing image, or can only one fit into rom at a time?
Or is your disclaimer just the usual “we’re not responsble if you tie the plastic wrapping around your head and suffocate” kind of thing that lawyers make you include? Is there really a significant risk of bricking the device by doing an update?
Are you meaning the “last seen” setting in the advance settings of Z2M? If so, would you star this so it gets some attention?
1 Like
Yes last seen being enabled causes the messages to become garbled when trying to retrieve parameter data from the switch. Dev console is unaffected though. If you try to retrieve any parameters from the expose tab I see the problem exists there too - nothing is received except null.
It seems they’re giving the warning as a fair warning, but if you flash official files by official means (Z2M official repo or Hubitat repo) then you’ll likely have success.
The scariest part of this update is that it also updates the bootloader. I see significant changes between the versions and much of data starting/ending points have changed. Keep in mind that everything is salvageable but if you kill the switch during the bootloader update you’re likely going to have to connect physically to the chipset to flash it via different means.
That all being said, you’ll likely have no problems. There are CRC’s in the firmware, MD5 signatures must match once firmware is delivered to the switch, and if modified (no longer matches) it will JMP to an exception that ends the update process before it begins.
Where was the other thread? I have all sengled devices and this problem. Was hoping this was in here too.
1 Like
Also responded in github - the new converter exposes the new parameters correctly in the Exposes tab, but as you noted the parameters are not visible in the Dev Console. My best guess is that the cluster definition for manuSpecificInovelliVZM31SN comes from a different file, which also needs an update. @EricM_Inovelli @nathanfiscus can you confirm this hypothesis, and if I’m correct point us in the direction of the edits that need implementing?
1 Like
Yes, new parameters have to be updated in the clusters within the zigbee-herdsman repo instead of the converter repo.
4 Likes
I saw some HA updates get pushed today for 2.14. When will the JSON file get updated to point to 2.14 so that HA and ZHA switches are auto updated?
Yes it’s this one. We stand behind the firmware, but can’t control the environment used to flash the firmware.
I’ve seen some weird things in my day where people are flashing the wrong firmware on their device and it completely messes things up (ie: flashing fan/light firmware on a dimmer switch, etc).
But absolutely we stand behind the firmware. Just don’t go throw water at the switch if it’s updating too slow or something lol.
6 Likes
Got my own experience to report here! Have upgraded 36 switches (mostly neutral, some non-neutral) on four floors. Overall: Mixed bag, mostly good.
Positive: Dimming performance on the switches with a neutral is much better. I seem to be getting consistent mesh networking now (including devices with that are more than 1 hop away from the coordinator).
Negative: Some of my Inovelli 2-1 switches running 2.14 seem to drop off the network and not come back. z2m reports them as Offline for a long time and refreshes in the UI result in timeouts. When I reboot the switches, they do come back - all but one, that is. I’ll try replacing it with one of my spares to see if the other switch has a similar issue.
For the ones that get fixed with a reboot - are there any diagnostics that z2m could collect for them?
do these new parameters just need to be added here?
That’s a question for ha discord in the ZigBee channel.
I’m curious too as my switches didn’t update yet but I didn’t manually request the update either yet. Waiting to update to 2023.4.3
Yes, that is the correct definition.
2 Likes
let me know if this looks right
Of course not. But what if I’m really hungry and eat the cardboard packaging while waiting for the update to complete? Could happen.
Seriously, thanks. Can’t wait to start installing these switches this weekend.
Looks correct to me - all param IDs and data types match what @EricM_Inovelli provided.
Mine (attempted to) auto update two days ago, but I just saw Inovelli OTA URL Changes by codyhackw · Pull Request #1159 · zigpy/zigpy · GitHub , which is a change from a few months ago that changed the URL for the Inovelli update JSON. I’m still running HA/ZHA from November 2022, so it’s checking the old URL that has 2.14, rather than the new one that’s only at 2.08.
BTW, I was having trouble getting my switches to update, but got it working by pulling the air gap on about half of my switches and letting it try overnight. I don’t know whether it was reducing the number of switches or just letting it try for several hours (or if both were needed) that ended up working–I still saw failures when only half the switches were on the network, where the switch would show the flashing green progress, then after like 30 minutes, three quick red flashes. It does seem like ZHA should stagger the updates instead of trying to update every switch simultaneously.
In any case, I love the new firmware so far! As I had mentioned in another thread, my main gripe was that even at the lowest dimming level, some of my lights were still fairly bright. Now, those lights are really dim at about 9% and cut off completely at 7 or 8% (so I’ll probably set the minimum dimming parameter now). Thanks to the Inovelli team!
2 Likes
I’ll make sure to add that to the disclaimer next time 
1 Like
Just to keep the community up to date, the PRs required to make this work on Zigbee2MQTT have been posted. We’re now in the hands of the maintainers to get these merged.
7 Likes