full devices reset

[CatmanV2]

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

[kfxo]

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

[rafale77]

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.

[therealdb]

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

[CatmanV2]

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)

1. Buy Pi3B+ and SSD + UZB
2. Set up Raspbian, Open Luup, Z-way with bridge plugin and , AltUI and Reactor
3. 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.
4. Any new Devices and Reactor instances will be added to the Pi / OpenLuup
5. 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

[rafale77]

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:

1. Install openLuup somewhere on any machine (again does not need to be a rPi but it can be) with verabridge.
2. 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,
3. get a uzb plug it to a machine, can be the same one, and install z-way-server.
4. 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
5. Install the z-way bridge on openluup and connect them together. Migrate scenes.

[CatmanV2]

Yeah, I only mentioned Pi because I like them and I don't have anything else that I want to add it to.
Couple of Qs
3) This is the machine running Openluup?
4) Will this change the device IDs? I ask because I intend to have no scenes, and if all the IDs change (again) then it's a chunk of work to fix all the reactors.

Thanks (again)

C

[rafale77]

3. Yes I run z-way-server and openluup along with all my echo and siri bridges on the same machine which is a ubuntu VM but it could be really anything from rPi to a mini PC.
4. Yes it will and it the part which requires the most work as I said. I have about 150 scenes with a vast majority of them being device triggered. I had to changed everything to variable watch and all their IDs along with that. Likewise the actions from the scenes all had to be changed. I would say 90% of my time spent on the migration was on this part. The rest was reasonably straightforward.

[prophead]

If I want to try the zwave device backup to uzb restore on zway method can I “turn off” the zwave radio on zway and leave my vera in “production” while I reprogram openluup with the new zway bridged devices?

[CatmanV2]

@rafale77 said in Why Migrate to Z-way from vera and how?:

Yes it will and it the part which requires the most work as I said. I have about 150 scenes with a vast majority of them being device triggered. I had to changed everything to variable watch and all their IDs along with that. Likewise the actions from the scenes all had to be changed. I would say 90% of my time spent on the migration was on this part. The rest was reasonably straightforward.

Hmm so the device IDs will be different for a reactor on on Openluup, then different again when I move them to the UZB.

Is it possible to move one device at a time without unpairing from Vera / pairing with UZB?

C

[rafale77]

You can make the reactor device IDs the same by manipulating them the same way you would on a vera (it is an attribute). What will be different will be the device IDs of the zwave devices.... When moving to openLuup, the zwave devices will be come bridged and will have an added “prefix” of 10 sending them in the 10000+ range.

You could alternatively try to add z-way as a secondary controller first which would make the same zwave device show up twice on openLuup: one through the vera path and the other through the z-way path.

[CatmanV2]

Yeah sorry, I meant the zwave devices, not the Reactor device ids.

Not possible to move one device at a time?

C

[rafale77]

Not without breaking your network... remember? it's a mesh. So they all talk to one another. The whole point of this migration is so that you don't need to do it one device at a time. Trust me it is much better to move the whole thing all at once but you do need to reserve the time to change all the IDs in the scenes.

[CatmanV2]

That's a lot of time is my point I don't mind a lot of time per se, but a lot of time without HA working (If I'm reading it right every instance of every device in every Reactor / scene will need updating)

Prophead's experience seems that it's even more a lot of time getting Z-way running due to the libcurl 3/4 issue?

Personally I'd probably compile from source, but.....

C

[CatmanV2]

@rafale77 said in Why Migrate to Z-way from vera and how?:

1. Install openLuup somewhere on any machine (again does not need to be a rPi but it can be) with verabridge.
2. 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,
3. get a uzb plug it to a machine, can be the same one, and install z-way-server.
4. 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
5. Install the z-way bridge on openluup and connect them together. Migrate scenes.

OK I think I'm up to step 2.

But I have no plug ins.
I have no scenes either but that's deliberate. All my automation is now done on Reactor (the 4 house scenes are there, of course)

So what do I need to do to further to stabilize the Vera?

Cheers

C

[rafale77]

Move reactors to openLuup along with all the plugins.

[CatmanV2]

Move Reactors =
Install Reactor from AltMarketplace
Backup Reactors on Vera
Restore Reactors on OpenLuup
Edit Reactors on OpenLuup with regard to device numbers
Delete Reactors on Vera
?

Move plugins = Just install them all from Alt Market place?

Cheers!

C

[rafale77]

This all sounds about right for those which are on the alt market place. Technically though the files should have been transferred over from from the download verafiles action so all you have to do is to create the devices to get the plugins appear and then copy over the parameters for these plugins from the vera.

[CatmanV2]

Your point 5 here:

<quote>
Go into the vera UI and go under Settings/Z-wave settings/Options Tab and change the port field to "/dev/ttyACM0" and let the luup engine reload. This will wipe out all the zwave devices from your vera configuration (Another wonderful feature of the luup reload...) and switch you to the uzb as your zwave chip.
</quote>

Can I assume the NVM of the Vera dongle is not impacted? And if you change the port back everything will be restored? Just wondering what my roll back / fix forward options might be.

Cheers

C

[rafale77]

The vera dongle is indeed unimpacted. If is just swaps what dongle the luup engine's communicates with.