Vera PushOver notification with image

[rafale77]

wow... so it did recognize the UZB just fine and can read the network ID from it. It is purely about triggering the recovery from your backup to the Uzb dongle then. I am a bit surprised that it didn't work.
So the "/etc/cmh/dongle.restore" file never got replaced?... I wonder if the script has changed. Unfortunately I wiped my vera from anything mios so I can't test with this firmware. The nuclear option would be to edit the user-data.json from a backup and recover from it.... You are sure you have all your dongle files in the etc/cmh folder right?

extract from my own old posting:

Just for documentation purpose, I also found how to restore only the onboard zwave dongle:
-move your desired dongle file (example: “dongle.6.1.dump.0”) to /etc/cmh,
-rename it “dongle.restore”,
-run Stop_cmh.sh
-run Start_cmh.sh
-run Reboot

[rafale77]

I am even wondering if this is worth trying:
https://z-wave.me/zmeserialupdater-manual/

                                    Z-WAVE Serial API Tool
                                         Version:LWE0.9
                                         by Z-WAVE>ME

usage: ZMESerialUpdater [-h]
{version,serialapi_boot,serialapi_firmware,serialapi_info,serialapi_readnvm,serialapi_writenvm,serialapi_cleannvm,serialapi_cap,serialapi_freq,serialapi_setvendor,serialapi_uzbupdate,serialapi_restorenvm,serialapi_ripnvm}
...

ZWave>ME tools for controllers. Welcome

positional arguments:
{version,serialapi_boot,serialapi_firmware,serialapi_info,serialapi_readnvm,serialapi_writenvm,serialapi_cleannvm,serialapi_cap,serialapi_freq,serialapi_setvendor,serialapi_uzbupdate,serialapi_restorenvm,serialapi_ripnvm}
version Just only prints version.
serialapi_boot Adds ability to reflash bootloader of UZB.
serialapi_firmware Adds ability to reflash firmware of UZB.
serialapi_info Shows information packet of controller.
serialapi_readnvm Reads data from UZB NVM.
serialapi_writenvm Writes data to UZB NVM.
serialapi_cleannvm Writes data to UZB NVM.
serialapi_cap Set cap.
serialapi_freq Changes frequency.
serialapi_setvendor Changes vendor of UZB.
serialapi_uzbupdate Updates UZB.
serialapi_restorenvm. Writes hex or bin file directly to NVM.
serialapi_ripnvm Reads content of NVM to hex or bin file.

Just not sure if this would work with a dongle.dump from the vera.

[Trexx]

@rafale77 Yup... dongle.restore never got changed and dongle.dumps's all accounted for (see below)

root@MiOS_50013148:~# ls -al /etc/cmh/dongle*
-rw-r--r--    1 root     root         16383 Aug 22 20:26 /etc/cmh/dongle.6.1.dump.0
-rw-r--r--    1 root     root         16383 Aug 22 20:26 /etc/cmh/dongle.6.1.dump.1
-rw-r--r--    1 root     root         16383 Aug 22 20:25 /etc/cmh/dongle.6.1.dump.2
-rw-r--r--    1 root     root         16383 Aug 22 20:25 /etc/cmh/dongle.6.1.dump.3
-rw-r--r--    1 root     root         16383 Aug 20 14:05 /etc/cmh/dongle.6.1.dump.4
-rw-r--r--    1 root     root         16383 Aug 20 13:57 /etc/cmh/dongle.6.1.dump.5

If you wanted, I could send you a dump file so you could try flashing it via ZMESerialUpdater to see if that even works

As for the onboard restore, I assume I still have to remap the to the internal /dev/ttyS0 first prior to those commands.

[rafale77]

As for the onboard restore, I assume I still have to remap the to the internal /dev/ttyS0 first prior to those commands.

Indeed. You would have to do that before restoring to the onboard zwave controller. I am a bit stunned. This has never happened to me.
Is your dongle.restore file removed though?

I have been looking at a couple of other tools on the vera to try to figure out what the luup engine actually triggers when it restores and found both the zwaveserial tool and the zwave firmware tool but neither seem to generate a 16KB file as a backup.

[Trexx]

I have been having to manually delete the dongle.restore file

[rafale77]

Could you maybe try downgrading the firmware and trying this again? I thought I tested 4955 but maybe not. It doesn't look like a compatibility issue from the dongle itselfl but more likely a change in how the firmware triggers a dongle restore. The other possibility is the translation from one SDK from the other is not working because... you already upgraded your uzb firmware. If that is the case though, you could downgrade the UZB firmware back, do the restore and then re-upgrade it. The restore works better with an SDK the vera knows. In truth I have actually transitioned my vera to an external usb stick a long time back, though it was not an uzb so when I did this, I actually moved from a silabs usb stick to a zwave-me uzb all on the vera. Others have done this though (@DesT for example).

I am baffled because when it is an sdk failure, it still goes and triggers the dongle.restore.go file. Maybe try to do a "touch dongle.restore.go" and run a luup reload instead?

[Trexx]

@rafale77 Which Vera FW version are you thinking and do you have a link to it

Which zwave-me version would I need to be on to to test that portion?

[rafale77]

I think one version back of the UZB should suffice. Probably 5.36 or 5.32 but I was more thinking about downgrading the vera.

[Trexx]

I was able to piece together the URL structure to download the mt621 versions of 7.31 (current), 7.30 & 7.29. Which do you want to target.

[rafale77]

7.29 should work.

[Trexx]

Tried 7.29, reset to factory, restore backup config w/zwave. All came up good, failed on dongle.restore (luup) phase. Tried doing a touch "dongle.restore.go" and reboot even.. no go.

[rafale77]

This is really very strange. And I suppose the file you created is still there? There must be something else going on. It seems like your luup engine is not even trying to do the dongle restore.

[Trexx]

Yup... file still there.

[rafale77]

Last resort is to downgrade the Uzb stick as well but this is rather bizarre. Something must be blocking. I just can't figure out what.

I just realized I have been seeing your posts on the QNAP forum.

[Trexx]

To which version of UZB are you thinking? And yes I have been on the QNAP forums for many years

[rafale77]

just one prior. 5.35 or 5.36 I believe?

[Trexx]

At this point it isn't worth the headache and time to potentially solve this. The "all" access token which used to work on v3.06 to be able to access via the gui the firmware downgrade option doesn't work anymore. I initially thought it was related to upgrading to v3.10 of SmartHome so I rolled back, but still it didn't work. Looks like they shut that one down.

[Trexx]

I think I figured out part of my problem... in looking closer at the controller information in SmartHome app, it looks like I got an EU version instead of a US version of the dongle so it was on the wrong frequencies. I am sending it back to Amazon and re-ordered the chip off of your recommended eBay seller.

[rafale77]

hmm interesting and weird... You know you can recode the dongle to US frequency right? I am just not sure if the embedded antenna was calibrated properly for it. The difference is in the number of channels and how they are optimized for their specific frequencies. The US use only two channels while 3 are used in other regions.

[Trexx]

I was having issues where using OZWD I would try and add a node (inclusion) and it wouldn't register the device even if was almost on top of it.. so that eventually led me there.

I looked on the sticker on the dongle which claims it is the US version (ZMEUUZB1).

In Z-way app, it shows EU and only options that appear to be for the ZMEEUZB version (EU) dongle for changing frequency.

I tried changing frequency via shell script to US, which says it does, but Z-way still showed EU even after that.