Z Wave roll back

[BONeil]

I decided to roll back from a 994i to Eisy migration (not meeting WAF). I did not change anything on either system. I read in the users guide: 

Quote

• If you don't actually change your Z-Wave network by adding/removing Z-Wave devices after migration, you can back out the migration by connecting whatever Z-Wave dongle you were using before migration and restoring the backup you made prior to migration.

In the migration I followed the procedure where I backed up the Z-Wave network before I did the ISY Backup. Then I used the ISY backup to restore on the EISY. 

Since some Z-Wave operations are one way, I want to make sure I understand this clearly as my action back on the 994i; Can I just use the Z-Wave -> Restore tool, or do I have to restore the entire ISY via File -> Restore ISY, File -> Restore Devices?

Thank you

 

[DennisC]

18 hours ago, BONeil said:

I decided to roll back from a 994i to Eisy migration (not meeting WAF). I did not change anything on either system. I read in the users guide: 

In the migration I followed the procedure where I backed up the Z-Wave network before I did the ISY Backup. Then I used the ISY backup to restore on the EISY. 

Since some Z-Wave operations are one way, I want to make sure I understand this clearly as my action back on the 994i; Can I just use the Z-Wave -> Restore tool, or do I have to restore the entire ISY via File -> Restore ISY, File -> Restore Devices?

Thank you

 

My opinion is if you migrated from ISY994 to eisy, and want to go back to ISY994, you would need to restore your backup on to ISY. 

Note, the instructions indicate using original Zwave dongle and restoring backup before migration. I believe that is a key statement.

One other thing to note, if you migrated your portal license, that is a one way operation and I don't think it can be user reversed.

Not sure about PG3, you might need to reinstall some node servers if you are using them, but a portal license is required.

 

What is not working on eisy withv5.5.9 that you need to back out of the migration?

Have you opened a support ticket with UD?

[asbril]

Others are far more technical than I am, but I wonder why you want to go back to ISY. Most likely any issue that you may have on eisy can be addressed with a ticket to UD support.

[BONeil]

To be honest, I got a bit gun-shy. I have a pretty complicated setup (~100 insteon devices, ~60 zwaves, ~60 Elk sensors and a bunch of Polyglot 3 nodes). Tons of programming that works very well. I've seen a bunch of posts about the reliability and getting door locks working and that has me worried. 

[asbril]

36 minutes ago, BONeil said:

To be honest, I got a bit gun-shy. I have a pretty complicated setup (~100 insteon devices, ~60 zwaves, ~60 Elk sensors and a bunch of Polyglot 3 nodes). Tons of programming that works very well. I've seen a bunch of posts about the reliability and getting door locks working and that has me worried. 

I don't have door locks (prohibited by the fire code in my condo building  ) so I can't take that into account. I have a complicated set-up as well (according to Chris Jahn  ), with more than 80 Zwave,  about 15 Kasa plugs and lights, as well as some 8 nodeservers. I also connect my IoX (eisy) to Home Assistant.

Migration is always more complicated (for me at least) than it seems and I got used to go over the instructions steps several times and sometimes resort to UD support. But I migrated to Polisy when this came out and now I migrated to eisy, and my system is very stable.

[DennisC]

59 minutes ago, BONeil said:

To be honest, I got a bit gun-shy. I have a pretty complicated setup (~100 insteon devices, ~60 zwaves, ~60 Elk sensors and a bunch of Polyglot 3 nodes). Tons of programming that works very well. I've seen a bunch of posts about the reliability and getting door locks working and that has me worried. 

I migrated a Polisy system to eisy with ZMatter dongle previously and if you followed the directions, other then the false pop ups about upgrades available, it wasn't too bad. Only have 3 Zwave devices at that location, along with Insteon & numerous node servers.

Yesterday, at a second location, I migrated another location from Polisy to Polisy with ZMatter. That system has Insteon, several node servers, and 7 ZWave devices. One of which is a Schlage lock.

When migrating, you need to read the directions and understand the intent of the directions and follow them. If you run in to help, UD is right there for assistance.

After the upgrade, my lock still functions. Polisy receives lock/unlock status and can issue the commands. Status of who unlocks/locks also work. Based on my testing, what I lost is if the lock jams, it is not being recognized as a jam, status updates to "unknown". I let UD know about it, so I am sure it will be corrected in a future update.

You obviously have a lot more ZWave then I do, but how will UD know if there are issues if you don't update? UD is extremely responsive and can not test every device out there. They rely on us to upgrade and test, how do you think the ISY became so reliable?

I remember when UD started to support ZWave on the ISY994. There were the same kinds of issues, they were reported and then corrected.

Some support is also available here on the forum, if you have questions about specific devices, maybe some one had tried that one already and can offer input. 

[JTsao]

A few weeks ago, I attempted to migrate from a Polisy/Zooz dongle to the eISY/ZMatter and ended up going back (I have around 30 ZWave devices and 11 PG3 node servers) - I did not have to do a restore to go back to the Polisy

[DennisC]

21 minutes ago, JTsao said:

A few weeks ago, I attempted to migrate from a Polisy/Zooz dongle to the eISY/ZMatter and ended up going back (I have around 30 ZWave devices and 11 PG3 node servers) - I did not have to do a restore to go back to the Polisy

If your Polisy used a Zooz dongle and your eisy used the new Zmatter dongle, that sounds right. Your not changing any infor on the Zooz dongle.

If you move the dongle over, or change the ZWave setup after migrating, that would be different.

[BONeil]

That's reassuring, thank you. I can deal with some temporary pain and can fix most problems, but lingering problems on critical systems (locks, alarm, etc) are a non-starter for the near term. I've had HA for 15ish years and my wife and I have grown to be somewhat uncomfortable without it. 

I am hearing a lot of Polisy to Eisy migrations, but I think those are far less impact from 994i -> Eisy since the architecture changes a bit. In particular, I am still trying to figure out how I will revisit my extensive library of Elk automations (it appears Elk moved to PG3) so I will have to touch each automation. Just time I didn't allocate for this weekend and probably explore a way to incrementally migrate instead of ripping a band-aid off. Possibly using Homeassistant as an abstraction to make the transition seamless. 

[DennisC]

10 minutes ago, BONeil said:

That's reassuring, thank you. I can deal with some temporary pain and can fix most problems, but lingering problems on critical systems (locks, alarm, etc) are a non-starter for the near term. I've had HA for 15ish years and my wife and I have grown to be somewhat uncomfortable without it. 

I am hearing a lot of Polisy to Eisy migrations, but I think those are far less impact from 994i -> Eisy since the architecture changes a bit. In particular, I am still trying to figure out how I will revisit my extensive library of Elk automations (it appears Elk moved to PG3) so I will have to touch each automation. Just time I didn't allocate for this weekend and probably explore a way to incrementally migrate instead of ripping a band-aid off. Possibly using Homeassistant as an abstraction to make the transition seamless. 

Elk support for both eisy & Polisy is now via a node server. While there is a small fee for the node server, it is well worth it. The developer is very support of and actively adds features. While it has most of the features of the Elk Module, there are a few that are missing, however, I was able to mitigate them with work arounds.

When combines with the Notification node server (same developer), you can not beat the combination.  Yes, you will need to update your programs, but if you add the Notification node server, you will need to update them anyway. The combination of the two is much better then anything I had on my ISY's (2 locations, both with Elk). The notifications are reliable, much quicker, and by following the examples, fewer are required.

[gduprey]

Don't feel too bad - having to roll back to the ISY myself.

About 50 Zwave and 80 Insteon devices with a bunch of programs and a lot of 3rd party integrations.  

About half my zwave devices will not work on the eisy (show as disabled/placeholder).  I attempt to synchronize->interview the ones that fail and nothing happens to most.  It does not seem to be specific to type of device (i.e. some door locks work, some don't -- all the same brand, also same for thermostats, etc).  All were working before this upgrade.

Plus the ZWave IDs changed from ZWxxx to ZYxxx which breaks all my 3rd party integrations.

Finally, the ZWave IDs also change from simple ZWxxx_1 to "new" ZW/Yxxx_A_B format stuff, again, breaking all 3rd party integrations and some ISY programs.

I'm pretty disappointed - I have been a huge fan of UDI for a long time, but if this is the amount of things that are going to break (and I have about a dozen other ISY994iZ that I'd have to migrate), it's not going to work.  I feel like, for this much effort, I may as well consider what other alternatives are out there since I'm would have to invest a ton of time to to convert anyway.

In the mean time, I'm rolling all the way back to the 300 ZWave dongle and 5.0.16C after losing the better part of 3 days trying to make this work

[asbril]

4 hours ago, gduprey said:

Plus the ZWave IDs changed from ZWxxx to ZYxxx which breaks all my 3rd party integrations.

The change from ZW to ZY is for everybody. Which 3rd party integrations are impacted ?

[gduprey]

About 15 distinct integrations used in various combinations spread amongst my client base.  Most are custom-coded solutions that have been working for years.

The problem is they all need to "know" what device to control and so have configurations that, for example, send a DON to ZW003_1 that no longer works.  Fixing all those integrations and reconfiguring them - that's is a huge pain and barrier to pushing forward on any migration to the eISY.

Also have problems with a number of Zwave devices that were all confirmed to work just fine before migration that show as disabled and will not "come back" with a Synchronize/Interview at all.  Not sure what that is, honestly that change to device node IDs sucked the wind out of my sails and forced me to retreat to reconsider this.

[DennisC]

4 hours ago, gduprey said:

Don't feel too bad - having to roll back to the ISY myself.

About 50 Zwave and 80 Insteon devices with a bunch of programs and a lot of 3rd party integrations.  

About half my zwave devices will not work on the eisy (show as disabled/placeholder).  I attempt to synchronize->interview the ones that fail and nothing happens to most.  It does not seem to be specific to type of device (i.e. some door locks work, some don't -- all the same brand, also same for thermostats, etc).  All were working before this upgrade.

Plus the ZWave IDs changed from ZWxxx to ZYxxx which breaks all my 3rd party integrations.

Finally, the ZWave IDs also change from simple ZWxxx_1 to "new" ZW/Yxxx_A_B format stuff, again, breaking all 3rd party integrations and some ISY programs.

I'm pretty disappointed - 

In the mean time, I'm rolling all the way back to the 300 ZWave dongle and 5.0.16C after losing the better part of 3 days trying to make this work

 

14 minutes ago, gduprey said:

About 15 distinct integrations used in various combinations spread amongst my client base.  Most are custom-coded solutions that have been working for years.

The problem is they all need to "know" what device to control and so have configurations that, for example, send a DON to ZW003_1 that no longer works.  Fixing all those integrations and reconfiguring them - that's is a huge pain and barrier to pushing forward on any migration to the eISY.

Also have problems with a number of Zwave devices that were all confirmed to work just fine before migration that show as disabled and will not "come back" with a Synchronize/Interview at all.  Not sure what that is, honestly that change to device node IDs sucked the wind out of my sails and forced me to retreat to reconsider this.

None of this should have been a surprise, it has been well documented in the various firmware notices and the migration documentation.

[gduprey]

The term Well documented may be a matter of opinion.  

Regardless, these are high barriers to my ability to migrate myself and all my client installs.  Documented or not, when the barrier is that high, the question about what platform becomes a real one.

[DennisC]

24 minutes ago, gduprey said:

The term Well documented may be a matter of opinion.  

Regardless, these are high barriers to my ability to migrate myself and all my client installs.  Documented or not, when the barrier is that high, the question about what platform becomes a real one.

I added the bold:

From the migration documentation:

https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migration

Post Migration

• If you migrated your Z-Wave Network

  • In most cases they are battery powered devices that were not awake during migration
  • To migrate one of these devices, wake it up (see user manual for the device) and then do the following

  • right+click on a placeholder node for the device, select Z-Wave | Synchronize | Update with Interview

  • When it completes do the same for the next device

  From the eisy user guide:

  https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide

  What to Expect During Migration

  Insteon

  The Insteon network on ISY-994 will be seamlessly transferred to Eisy / Polisy. Your nodes, programs, and scenes using Insteon will remain unchanged.

  Z-Wave

  The Z-Wave network managed by ISY-994 will be migrated to the ZMatter Z-Wave implementation on Eisy / Polisy. The devices in the network will remain the same, but their representation in ISY may change.

  • Nodes

  Z-Wave ISY Nodes will be reused whenever possible, but new nodes may be created as well.

  • Programs

  Z-Wave ISY nodes in programs will be migrated, however, node actions and conditions may no longer be valid if the node's support for them has changed.

  • Scenes

  Z-Wave ISY Nodes in scenes will be migrated, but those using native links (i.e. association) may require updates.

   

   

  • If you have any Z-Wave nodes with a type of (Placeholder) it means the device has not been migrated yet.

From the migration guide:

https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migration

What to Expect During Migration

Insteon

The Insteon network on ISY-994 will be seamlessly transferred to Eisy / Polisy. Your nodes, programs, and scenes using Insteon will remain unchanged.

Z-Wave

The Z-Wave network managed by ISY-994 will be migrated to the ZMatter Z-Wave implementation on Eisy / Polisy. The devices in the network will remain the same, but their representation in ISY may change.

• Nodes

Z-Wave ISY Nodes will be reused whenever possible, but new nodes may be created as well.

• Programs

Z-Wave ISY nodes in programs will be migrated, however, node actions and conditions may no longer be valid if the node's support for them has changed.

• Scenes

Z-Wave ISY Nodes in scenes will be migrated, but those using native links (i.e. association) may require updates.

Programs

Programs and variables will be transferred seamlessly, but some exceptions may occur if ISY Nodes or their commands and/or status have changed.

All of the firmware releases reference the above documentation:

 

Plus, all of the firmware releases have support posts which documents the actions everyone had to do to complete the migration.

My point here is you shouldn't be blaming UD because you missed something. You have been around here long enough to know you need to read up on an upgrade before proceeding.

Network Resources

All Network Resources will be migrated seamlessly, however, you will need to open and save each one individually.

 

[lilyoyo1]

6 hours ago, gduprey said:

About 15 distinct integrations

That says alot. Kind of hard for UDI to fix (or help fix) something when you offer zero insight. 

[TRI0N]

Not sure how that will work. Isn't the ISY ZW 500 Series and the eisy is 700 series and uses S2? So either you're adding items into eisy that don't have S2 enabled when they could be. So not sure how that works going backwards.

TRI0N

[kzboray]

@gduprey I encourage you to try other platforms, but I will warn you they all have the same or similar issues with z-wave. z-wave is the problem, not the controller. Unlike Insteon combined with a ISY994i on which we all got spoiled because UD spent the time to reverse engineer the protocol on each and every Insteon device released; z-wave is a nightmare. Even z-wave manufactures of which there are many don't follow their own standards from device to device, making the word standards an oxymoron.

UD has already sorted out a few of the issues with z-wave on their eisy platform and from experience I can say with 150% confidence that over time the eisy will become a rock soil platform for most z-wave devices. In the mean time like I said, try a few others out and let us know what you find.

Maybe there is a better mouse trap, I personally haven't found it yet and with Matter coming on the scene it's only going to make what is already a crazy space even more convoluted.

[asbril]

33 minutes ago, kzboray said:

@gduprey I encourage you to try other platforms, but I will warn you they all have the same or similar issues with z-wave. z-wave is the problem, not the controller. Unlike Insteon combined with a ISY994i on which we all got spoiled because UD spent the time to reverse engineer the protocol on each and every Insteon device released; z-wave is a nightmare. Even z-wave manufactures of which there are many don't follow their own standards from device to device, making the word standards an oxymoron.

UD has already sorted out a few of the issues with z-wave on their eisy platform and from experience I can say with 150% confidence that over time the eisy will become a rock soil platform for most z-wave devices. In the mean time like I said, try a few others out and let us know what you find.

Maybe there is a better mouse trap, I personally haven't found it yet and with Matter coming on the scene it's only going to make what is already a crazy space even more convoluted.

This is an ongoing debate and the concensus in this forum is that Insteon is better than Zwave. I don't dispute this from a technical view point, but as someone who ditched Insteon 9 years ago to switch to Zwave, I disagree that  "zwave is a nightmare" . It has its issues but there are many more products and my system works well. We have seen what happened to Insteon recently and we still have to see whether the new ownership  will succeed, though I wish it all the success of the world.

[TRI0N]

8 minutes ago, asbril said:

This is an ongoing debate and the concensus in this forum is that Insteon is better than Zwave. I don't dispute this from a technical view point, but as someone who ditched Insteon 9 years ago to switch to Zwave, I disagree that  "zwave is a nightmare" . It has its issues but there are many more products and my system works well. We have seen what happened to Insteon recently and we still have to see whether the new ownership  will succeed, though I wish it all the success of the world.

Insteon was a great product. The devices were very well built and they didn't hide it either with their see through cases with gauge wire more then what was needed for switches. Now I've seen their new products in photos and I can clearly see they have gone to cheaper venues. The back are black plastic and the gauge wire isn't as thick (really don't mean much as long as it 10-12 AWG) but still it looks like they went cheaper on their products, probably to lower their prices to compete against WiFi, Z-Wave, Zigbee, etc... I have not seen their prices yet. We all know they were $10-$20 more per item back when they were thriving but now I can't vouch for their reliability or quality components. 

TRI0N

[kzboray]

3 minutes ago, asbril said:

This is an ongoing debate and the concensus in this forum is that Insteon is better than Zwave. I don't dispute this from a technical view point, but as someone who ditched Insteon 9 years ago to switch to Zwave, I disagree that  "zwave is a nightmare" . It has its issues but there are many more products and my system works well. We have seen what happened to Insteon recently and we still have to see whether the new ownership  will succeed, though I wish it all the success of the world.

@asbril Like all tech, z-wave has it's strengths and weaknesses. I'm glad z-wave is working well for you and I should have been more precise in my comments. Insteon is without a doubt the best solution for DIY lighting control. Outside of that z-wave and other technologies are better suited.

Your comment about the stability of Insteon the company is also another important consideration and one I agree with. But until they either go away for good or another technology becomes available that is better suited to lighting control, I'll have to continue to use and recommend Insteon in combination with a UD controller for rock solid lighting control.

Like you I have personally and in clients homes a combination of technologies. Without a doubt the homes that give me the least amount of support issues are the ones that use primarily Insteon. The homes that I used z-wave in are the most troublesome. From the more mundane issues like the pop-corn effect in lighting groups to the more complex when adding a new switch causes the whole system to need TLC because the manufacturer changed the firmware and now it's a series 700 on a 500 system that has no S2 support and the devices firmware now has a different feature set that causes it to be non-operational with other older switches from the same manufacturer.

For door locks and relays z-wave is awesome, well maybe not awesome, but there are often multiple vendors with solutions for these needs. Insteon has none.

I think there is a place for both Insteon and z-wave, as well as matter, zigbee, and even plain old wi-fi devices(my least favorite) in any automated home.

[asbril]

11 minutes ago, kzboray said:

@asbril Like all tech, z-wave has it's strengths and weaknesses. I'm glad z-wave is working well for you and I should have been more precise in my comments. Insteon is without a doubt the best solution for DIY lighting control. Outside of that z-wave and other technologies are better suited.

Your comment about the stability of Insteon the company is also another important consideration and one I agree with. But until they either go away for good or another technology becomes available that is better suited to lighting control, I'll have to continue to use and recommend Insteon in combination with a UD controller for rock solid lighting control.

Like you I have personally and in clients homes a combination of technologies. Without a doubt the homes that give me the least amount of support issues are the ones that use primarily Insteon. The homes that I used z-wave in are the most troublesome. From the more mundane issues like the pop-corn effect in lighting groups to the more complex when adding a new switch causes the whole system to need TLC because the manufacturer changed the firmware and now it's a series 700 on a 500 system that has no S2 support and the devices firmware now has a different feature set that causes it to be non-operational with other older switches from the same manufacturer.

For door locks and relays z-wave is awesome, well maybe not awesome, but there are often multiple vendors with solutions for these needs. Insteon has none.

I think there is a place for both Insteon and z-wave, as well as matter, zigbee, and even plain old wi-fi devices(my least favorite) in any automated home.

Most of us are partisan to our existing setup. The real question is what would we recommend to someone starting from zero.

[TRI0N]

1 hour ago, asbril said:

Most of us are partisan to our existing setup. The real question is what would we recommend to someone starting from zero.

From zero if you're just doing switches and outlets I would tell people to buy TP-Link Kasa. They work great and eisy uses and identifies them very nicely since PG3. Scene Controllers I would says the ZEN32 is a favorite and has it pros and cons vs Insteon. That is what I would recommend right now...

TRI0N

Edited April 3, 2023 by TRI0N

[gduprey]

Few comments:

First - insteon was dead simple and pretty much rock solid.  Still prefer it for lighting if only for the super insane quick scene activation.  But I've really had no actual problems with Zwave either, once I got the hang of getting a good "mesh" up and running.

Next - yeah, I've been messing with HA for 30+ years now (yikes) and there is no perfect solution, but UDI has been pretty darn close.  It's been the most stable platform I've used and goes years between needing any intervention for anything.  I'm not interested in moving and have built a substantially tailored environment around it that works incredibly well.

My comments about looking at other controllers/systems is just that with the changes that will break a lot of the 3rd party integrations for me, the amount of "work" to get everything working again is pretty intense and high enough it starts to rise to what I'd be be facing if I was just changing technology. Not the same, of course, but high.  And when it's that much, it just makes "taking a look around and considering" a consideration that wouldn't have otherwise occurred.

No control system is going to be perfect.  In fact, to address what really is about my single biggest issue, UDI would need something like what I proposed in the REST forum - one extra attribute that could be maintained independent of the ISY assigned IDs and allow for a nailed-down/continuity-oriented device identifier.  Not saying they have to do that, just that if it were available, the 3rd party stuff would have a chance and a managed and stable world of addressable devices that could always be updated to be stable in the face of any future device ident renaming/adapting.