Vera PushOver notification with image

[Trexx]

So ... I am trying to do the following:

Current setup:
Vera Plus (1.7.4955) Zwave only -> HASSIO VM (full control via Vera Integration)

Future Target:
HASSIO VM (leveraging zwave.me UZB1 dongle via USB)

I have done the following so far:

• Updated UZB1 dongle (via RPi SmartHome) to latest 5.39 Firmware

I followed the following steps to try and migrate my existing Z-Wave NW (currently on Vera) onto the UZB1 dongle following the steps listed here:

Migrate from Vera to Z-way

Problem:

• Steps 1-3: went fine (although the dumps are labeled as dongle.6.1.dump.x)

• Step 4: went fine and the UZB1 was recognized as it should be (per dmesg)

• Step 5: updating the port to /dev/ttyACM0 went fine, although I didn't see any indication of luup reload (or a save button for that matter when updating the port mapping)

• Step 6: I did the touch for dongle.restore, but wasn't sure where to trigger a luup reload (I assumed it was Z-Wave Settings > Advanced > Reload Engine). I believe I got an error message when trying to do that step

• Step 7: verify dongle.restore.go I don't recall being in the directions when I was going the test, but I rebooted

• Post Reboot: None of my previous z-wave devices were listed. I also checked dmesg via ssh and noticed the following items:

[ 4.328000] Unsupported Device!
[ 4.328000] Vendor=658 ProdID=200
[ 4.328000] Manufacturer= Product=

I saw that item a couple times which almost seems like Vera is blocking the UZB1 or at least complaining about it.

I ended up switching the Z-Wave back to the embedded controller, and restoring configuration from backup.

Any suggestions what I did wrong??

[rafale77]

Step 5: This is pretty comical as luup reloads itself due to frequent crashes but they almost "hide" it from you when you actually need to do it. I honestly forgot how the vera UI looks like but I vaguely remember doing luup reloads by either going into the z-wave menu where you have a reload engine button or to the apps menu under the serial device something where the button basically runs a luup reload.

Step 6: cf step 5 for the luup reload.

I have never seen that unsupported device thing but I never really looked for it so you maybe right that they broke something.
I don't recognize neither the vendor nor the ProdID as being the uzb so I doubt that's what it is.

It is also very possible that you did not luup reload appropriately and did not go through all the checks.

[Trexx]

In googling, it looks like one way to do a Luup reload is the following in UI7 via Apps > Develop Apps

 luup.reload()

@rafale77 That might be something you want to add to your directions for users who are not as deep into the weeds as you are

Another option is via ALTUI > MISC > Reload Luup Engine

[rafale77]

Yes for those who use ALTUI!
I will go edit to add the reload step later today. Thanks!

[Trexx]

I re-ran the testing today. Step 6 is where things are breaking. I did the touch dongle.restore command, reloaded luup, etc. The dongle.restore.go file never appears.

[rafale77]

So the dongle.restore file is still there?
The process goes like this:
Upon luup reload, the luup engine deletes the "dongle.restore" file and replaces it with a "dongle.restore.go" file while it is preparing the engine to do the restore. Then a vera reboot, gets the zwave serial tool to upload the dongle data to the zwave device.
There are other ways to do this but this is what I thought was the easiest. (The alternative is to edit your user.data.json which is very tricky and error prone). These mimic the steps of a zwave data restore from the UI.

[Trexx]

Yup.. the dongle.restore file was still there.

I tried Luup.reload(), Z-wave engine restart, and via Device > Advanced > New Service > Reload Engine. No go for any of them causing the dongle.restore to delete and create the dongle.restore.go file.

As for user_data.json files... those are now showing as .lzo files btw if under /etc/cmh

[rafale77]

yes the user data file are always compressed with lzo on the vera.
This is strange that the dongle.restore remains there. I have never seen this happen. You did put it in the same folder (/etc/cmh) as the dongle backup files, right?

[Trexx]

Correct... in /etc/cmh

[rafale77]

Could you post a snapshot of the zwave advanced page where it is supposed to show the controller network ID etc... after having switched to the uzb as the controller?

[Trexx]

@rafale77

Here you go.

[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.