Why Migrate to Z-way from vera and how?
-
WAF is exactly what forced my hand... couldn't stand the maintenance and random delays/failures anymore.
It does take time (short heavy investment for long term greater return) and some hardware though. -
I'm not furloughed, and have a couple of new projects on the boil, so don't actually have a great deal more time than before (and my students still want on line classes so even my evenings are used some of the time)
<Touches wood> Currently my set up is stable. Would love a gradual migration. I can buy the kit but it seems a bit big bang.
C
-
So to get this straight in my own mind can I
- Go buy a Pi 3 B+ and SSD
- Install Debian / OpenLuup / Reactor
- Make the Vera Z-wave dongle available to OpenLuup
- 'Migrate' all my reactor instances 'off' Vera onto the Pi
- Use the Pi to create and new Reactors and replace the final couple of scenes I have
- Then think about migrating all my devices to a new Z-wave hardware.
Trying to make this a small steps as possible
Cheers
C
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
- Make the Vera Z-wave dongle available to OpenLuup
If, by this, you mean using openLuup's VeraBridge plugin to access its existing ZWave devices, then, yes, I think you have the sequence correct.
It sounds like a lot of steps, but they're not too difficult... I know almost nothing about Linux / Debian, but seem to have managed thus far.
AK
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
So to get this straight in my own mind can I
- Go buy a Pi 3 B+ and SSD
- Install Debian / OpenLuup / Reactor
- Make the Vera Z-wave dongle available to OpenLuup
- 'Migrate' all my reactor instances 'off' Vera onto the Pi
- Use the Pi to create and new Reactors and replace the final couple of scenes I have
- Then think about migrating all my devices to a new Z-wave hardware.
Trying to make this a small steps as possible
Cheers
C
Pretty much the exact steps I took. Steps 1-3 I had done maybe a year ago. At that time most my logic was in Pleg so I needed to move everything to reactor. Step 4 was the decision maker to completely ditch Vera. Once I did that, no more vera reloads where I was left in the dark because some logic did not execute or a light did not turn on. Step 6 I just did over the past 2 weeks and is well worth the effort. I feel like I have control over my z-wave network now with the "expert ui" of z-way.
-
Thanks. So can I backup Reactors from Vera and restore to OpenLuup?
C
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Thanks. So can I backup Reactors from Vera and restore to OpenLuup?
C
Yes. But you will have to manually change the device numbers of devices used in the Reactors. For example, device 25 on vera will be 10025 on openluup through the VeraBridge. Then again, with z-way, the device numbers will change. Z-way uses node # so If device 25 on vera has a node ID of 12, its z-way device number will probably be 20120.
-
I've not switched yet, but I was thinking about a script that could:
- get the device ID from the Vera (using nodeid and parentid)
- alter the device number in openluup+Zway, in order to reflect the old number
- migrate scene accordingly
I'm running openluup+Zway (as secondary) since a couple of weeks, and this should be doable, from my finding. I just have to figure it out a plan for scenes.
-
To move from vera bridge to zway, I wrote a script that retrieves the backup reactor file, finds all devices that are referenced in the 10000's, determines there node ID#, generates z-way device numbers in the 20000's based on the node id, and provides a new reactor backup file with the 10000's replaced with the new 20000's. It worked pretty well and saved me a lot of time. Some devices were not fully correct as child device numbers do not seem to be standard. I will share if somebody wants it but I am hesitant because it is not full proof and I am not an expert in lua.
-
There is a built-in VeraBridge GetVeraScenes action which migrates scene timers and actions (not triggers) changing the device numbers accordingly.
-
@akbooer the pain for me is in the triggers, since scenes are mainly calling code with an indexed table for devices. I could probably just migrate them to variable watches before. We'll see.
I've been using the new openluup console and I must say I like it a lot!
-
CatmanV2wrote on May 12, 2020, 2:17 PM last edited by CatmanV2 May 12, 2020, 10:22 AM
Well all my temperature sensors dropped out again last night at about 2120 local. I should have worried when I got a 'Device is responding again' notification for the Fibaro Universal when I never got one that it wasn't responding.
It sounds like simpler might be:
- Buy the Pi and the SSD
- Install Raspbian, Openluup, Z-wave bridge
- Restore and edit reactors
- Kill all the remaining scenes (for me this is probably not an issue and in fact would be a good place to make sure Reactor is working on Open luup)
Now at that point, vera is doing really nothing at all other than accepting Z-wave commands from OpenLuup?
C
-
@therealdb said in Why Migrate to Z-way from vera and how?:
the pain for me is in the triggers
Yes, I know. I never implemented the Vera-style triggers because their implementation was so flawed (along with the definition of events, etc.) AltUI Device Variable Watches work fine, but migrating the would require some editing of the WatchedVariables AltUI data structure (and it hardly seems worth it.)
I've been using the new openluup console and I must say I like it a lot!
Thanks for that – glad it works well for you! I have a plan for native openLuup triggers (easily defined from the openLuup console.) Their implementation is the main area where openLuup is deficient (along with the real-time updating of the devices page, and ...)
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Now at that point, vera is doing really nothing at all other than accepting Z-wave commands from OpenLuup?
It's actually still using the Luup layer to translate between HTTP and ZWave commands, but in this mode it seems to stay up for reasonable amounts of time. You'll still suffer from the fundamentally flawed ZWave stack implementation, though, as I'm sure @rafale77 would agree.
-
Hmmm so only a partial solution.
Razberry or USB? Razberry is about half the price and would fit nicely on the Pi?Any other benefit to the dongle?
C
-
@CatmanV2 said in Why Migrate to Z-way from vera and how?:
Hmmm so only a partial solution.
Razberry or USB? Razberry is about half the price and would fit nicely on the Pi?Any other benefit to the dongle?
C
Check out this post with some discussion.
-
Thanks @kfxo! I think that thread was an important piece of the puzzle.
@CatmanV2, I too have pondered between the two. Here is my assessment:
uzb pros and cons:
UZB is more flexible as you are not dependent on a pi to interface. You can use any machine with a usb port. Heck you can even use a vera as I am to send the serial port over IP.
a UZB is needed if you want to "migrate" your entire network since you won't be able to plug the razberry HAT on the vera. I can imagine running socat on the vera to import the port from a rPi but have not tried it.
the UZB has a better RF antenna.
It is more expensive with a z-way license than a razberry
It is a little more prone to "bricking" through firmware upgrades because of the USB intermediary interface requires a bootloader which complicates things. Not a big problem with the zwave.me uzb but more significant on the Sigma Design reference design one.As you probably already know from my history, I don't believe the new owners of the vera have any interest in making the old vera work although I think it could. They are focused on their new platform running on downgraded hardware, spreading the reliability issue from the software to the hardware and extending a long history of poor performance and scalability, problems openLuup has helped to significantly mitigate but couldn't completely eliminate.
I tried everything I could to keep the vera running and extend its life hoping that the new platform could be a breakthrough, peeling it down layer by layer hoping to get rid of the culprit and short of that at least lighten up the load on the vera to prevent it from crashing.
So it is just a matter of time before the vera runs into problems. There are too many ways for them to happen and they all stem from the core luup engine...Anyways... This solution we tried (openLuup+Zway) actually works marvels. It enables migrating your zwave network with minimum pain and configuration, avoiding having to rebuild and eliminate all the surprises, maintenance and other voodoo required to make the vera work and even enables further optimization and control of the network if desired. WAF has increased and I have more time!
The scene migration is the most difficult and work intensive part (both the action device ID and triggers) and I know @therealdb is thinking hard on how to make it easier. -
therealdbreplied to rafale77 on May 12, 2020, 4:50 PM last edited by therealdb May 12, 2020, 12:50 PM
@rafale77 said in Why Migrate to Z-way from vera and how?:
The scene migration is the most difficult are work intensive part (both the action device ID and triggers) and I know @therealdb is thinking hard on how to make it easier.
My plan at the moment is to backup the scene's code, via @rigpapa's LuaView, and then write some code to inspect all the triggers and generate some code around it. Since I have transitioned to watches for new scenes, I have "only" about 60 scenes to migrate to watches. My idea is to place all the code into LUA startup code and then migrate to modules, when I'll have more time. 90% of my scenes are either time based or easily translated (tripped, untripped, light turned on/off, usage above or below a certain threshold) and I already have most of them just calling the main module's code.
So, maintain the very same device ID is quite crucial to accomplish this.
-
Thanks, the UZB is actually cheaper here. Not sure that includes a licence.
So what's the point of plugging it into the Vera?
My plan is looking like this (I'm more than happy to document as much as I can for future noobs)
- Buy Pi3B+ and SSD + UZB
- Set up Raspbian, Open Luup, Z-way with bridge plugin and , AltUI and Reactor
- At a rate that I'm happy with move Reactor instances to Open Luup. Each Reactor will need to be either re-created or restored and the device numbers modified.
- Any new Devices and Reactor instances will be added to the Pi / OpenLuup
- Migrate devices to the UZB stick.
Is this making sense as a softly softly approach.
Additional question, can I migrate one device at a time from Vera to UZB without unpairing / pairing?Cheers!
C
-
Was editing my previous post with additional info...
If the uzb does not mention a license then it probably does not have one.
Plugging it into the vera enables you to transfer all your vera zwave dongle data on it. This means no need to exclude-include or change anything to your devices.My setup is a bit particular where I killed everything "mios" on the vera and made it run essentially like rPi. I then plug the uzb on it and forward its usb port over my network to the z-way-server/openLuup VM. I therefore don't need an additional rPi.
You could run openLuup on anything. It doesn't need to be a pi. I actually considered running my openLuup/z-way-server VM directly on a cheap mini PC which I managed to power through POE.My suggested plan to take these in steps:
- Install openLuup somewhere on any machine (again does not need to be a rPi but it can be) with verabridge.
- Move all your plugins and scenes to openLuup with using the helper features of the bridge. See how you like this. It should stabilize the vera to some degree. (I ran like this for a couple of years)
Then if reliability is still an issue, - get a uzb plug it to a machine, can be the same one, and install z-way-server.
- plug the uzb on the vera to migrate your zwave network on the uzb and then plug it back to where the z-way-server is
- Install the z-way bridge on openluup and connect them together. Migrate scenes.