The fastest route of flashing seems to be directly to the chip. 
Change to forward slashes: otau_directory: /config/zigpy_ota
1 Like
that did it thanks. Flashing green light now, looks like it’s in progress.
It seems Z2M isn’t properly updating its own database after the update intermittently. This is because the switch is still doing some process and the version value responded from switch is still the old one, then the switch reboots a second time and Z2M never reconfigures or pulls the values again. Performing a reconfigure fails to pull the new version number. This seems to be due to the “last seen” ISO being set. If you turn last seen off and reconfigure the switch manually it will pull the new version number.
Seems a bug is present in Z2M when dealing with Inovelli switches while “last seen” is set to the ISO value.
Seems like it occurs when doing more than 1 update at a time. The first one updates the version in the database correctly, anything after fails and keeps the same version number. When querying the switch, it reports back the new version. The database remains confused. Rebooting Z2M and HA, no change.
1 Like
I’ve been able to get the version update number to go to 2.14 without changing last seen parameter. To get the switch version number to update do the following:
Go to dev console and put the following (Endpoint 1, Cluster genBasic, Attribute swBuildID) and click Read
then go to About and click reconfigure (small green arrow circle) and it should update
after reconfigure:
3 Likes
Also FYI you can do the same for the firmware build date by entering dateCode under dev console and reconfiguring
1 Like
I’ve been reading swBuildID and then just waiting… after about 20-30 seconds the version # is updated in the About tab for the switch and the OTA tab.
Strange - I tried all of those and it still didn’t work.
Seems the ones I updated at the chip (not via Z2M) are still having the issue, but even some I updated via Z2M still won’t state the new firmware version.
Update: No matter what it still states the old version, yet when reading the buildID it responds with 2.14. As soon as I turn off last seen, it updates.
Update again: Re-paired the switch and it’s fixed.
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?