Jump to content

Migration from ISY994i ZWave node naming issues


gduprey
Go to solution Solved by MrBill,

Recommended Posts

Howdy,

After migrating from my ISY994i to eISY, all my ZWave identifiers have changed from ZWxxx to ZYxxx.  

This is breaking every 3rd party connector I use.  Not because they can't handle different letters, but because they have buttons, controls, scripts, macros, etc that are all developed to use the original ZWave Node IDs

Is there anyway to fix this?  Is this documented anywhere?

I would like to migrate all my clients to eISY, but this will break so many existing integrations I would be buried in this for over a year (best case, as many of these things were adapted over a long period of time)

 

Edited by gduprey
Link to comment
3 hours ago, gduprey said:

Howdy,

After migrating from my ISY994i to eISY, all my ZWave identifiers have changed from ZWxxx to ZYxxx.  

This is breaking every 3rd party connector I use.  Not because they can't handle different letters, but because they have buttons, controls, scripts, macros, etc that are all developed to use the original ZWave Node IDs

Is there anyway to fix this?  Is this documented anywhere?

I would like to migrate all my clients to eISY, but this will break so many existing integrations I would be buried in this for over a year (best case, as many of these things were adapted over a long period of time)

 

Are you voluntarily upgrading your clients to eisy? If they're not asking for upgrades, it seems like a money losing proposition for something that's already in place and that they're happy with. 

Have you tried, updating what each device is called to their original name and then re-saving the programs? I haven't upgraded to eisy yet so I don't know (it's had too many issues for me)?

Link to comment

I'm just starting this trying to get ahead of things.  UDI has said support for the ISYs is coming to an end, including hardware/repair support.  While the ISY994i have been absolute rocks in my experience, nothing lasts forever and if something breaks down for a client, I have to have a "fallback" plan.  

So been trying this weekend to take my personal/home ISY994i and migrate to the eISY.

I have a number of additionally integrations that all take the ISY and extend it to control other devices, often custom devices, alternate user interfaces, etc.  Every client I have has at least a few "add-ons" and so it's critical that:
1) Migration is flawless - all devices come over and work as before
2) All exposed REST-based add-on integrations continue to work with the same identifiers

So far, neither has worked out.  About 50% of the ZWave devices refuse to complete a Synchronize and Interview process (all worked before the update).  All Insteon worked fine and it appears all programs seem OK to me.  

And the device IDs changed for ZWave devices, breaking all the add-on integrations that had mapped out node IDs to control.

Link to comment
5 hours ago, gduprey said:

Howdy,

After migrating from my ISY994i to eISY, all my ZWave identifiers have changed from ZWxxx to ZYxxx.  

This is breaking every 3rd party connector I use.  Not because they can't handle different letters, but because they have buttons, controls, scripts, macros, etc that are all developed to use the original ZWave Node IDs

Is there anyway to fix this?  Is this documented anywhere?

I would like to migrate all my clients to eISY, but this will break so many existing integrations I would be buried in this for over a year (best case, as many of these things were adapted over a long period of time)

 

Yes it has been well documented in the firmware upgrade notices and the migration documentation. 

It also states what you need to do, resaving programs and network resources for instance.

Link to comment

Saving programs and network resource was not a problem.  

Some devices simply will not come back.  And I would appreciate pointers to migration documentation discussing the device identifiers were to change for all zwave devices to ZYxxx format

Regardless, these changes break many 3rd party integrations.  If 3rd party support is not a priority, then this is an understandable decision.  But it also means there are people who have investments high enough that this forces the issue of considering alternative paths forward outside of UDI.  

Which would be a shame as it's a great product, but if everything outside of the controller has to be re-implemented, the level of effort pushes the bar high enough that such reconsideration is necessary.

  • Thanks 1
Link to comment
1 hour ago, gduprey said:

Some devices simply will not come back.  And I would appreciate pointers to migration documentation discussing the device identifiers were to change for all zwave devices to ZYxxx format

In the eisy user guide, it states:

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.
1 hour ago, gduprey said:

Regardless, these changes break many 3rd party integrations.  If 3rd party support is not a priority, then this is an understandable decision.  But it also means there are people who have investments high enough that this forces the issue of considering alternative paths forward outside of UDI.  

Pretty much all of us here are heavily invested in the isy994 and have upgraded without issue. It's been years since ive installed a 994 in clients home so im not as concerned about upgrading those customers should they ever call. The way I see it, if they want something newer, then it would be a new installation anyway that they're paying for. Support is for like systems not brand new ones. All of mine are beyond warranty swap out and I have enough ISY's to get through my 5 year guarantee so Im good. The point im making is that this may not be as big of an issue that you're thinking it is for the long term outlook. 

With that said, it would be helpful if you would state exactly what 3rd party integrations you are having problems with (or thats breaking). How can anyone fix anything or make something better if they dont know? Continuously posting on multiple pages without specific information means things wont get fixed. Afterall, UDI is beholden to ensuring devices work within their ecosystem. They may work with partner systems or developers to ensure compatibility but if they dont know exactly whats broken, they cant fix it.

1 hour ago, gduprey said:

Which would be a shame as it's a great product, but if everything outside of the controller has to be re-implemented, the level of effort pushes the bar high enough that such reconsideration is necessary.

This goes back to what I said before- what exactly gets broken...Its such a broad term when other nodeservers dont have this problem or to the level that you state.

  • Like 2
Link to comment

@gduprey 

(1)  All tech products have a eol  and not surprising that it now happens to isy994i

(2)  Polisy is still being serviced for time being and upgrade to eisy or ZMatter on Polisy is not (yet) required .

(3) Is it not commendable that UD gives us the option of a product with Matter compatibility as well as more power ?

If change from ZW to ZY is that big of an issue, then simply stay with Polisy without ZMatter.

  • Like 2
Link to comment

Hey - I love the ISY/IOX platform!  I've championed it for years and run it everywhere.

Yes, it's totally reasonable that they are EOL a device and I never had a problem with that.  In fact, it was the trigger for me to consider what seemed like their "next gen" that I wanted to get on board with - the eISY.  

Right now, all clients are on ISY994i - none on anything later as it did/does all that is needed.  If there was ongoing/eternal support for the ISY994i (unrealistic), I'd just be a happy clam keeping everything working the way it has been for years.

So I can either just stay with what I have (ISY994i), hope they don't break and/or I can find used ones to stock pile or try to migrate and if I am, I would prefer to "jump" to the most current/future-proof offering.

Link to comment
10 hours ago, lilyoyo1 said:

In the eisy user guide, it states:

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.

Pretty much all of us here are heavily invested in the isy994 and have upgraded without issue. It's been years since ive installed a 994 in clients home so im not as concerned about upgrading those customers should they ever call. The way I see it, if they want something newer, then it would be a new installation anyway that they're paying for. Support is for like systems not brand new ones. All of mine are beyond warranty swap out and I have enough ISY's to get through my 5 year guarantee so Im good. The point im making is that this may not be as big of an issue that you're thinking it is for the long term outlook. 

With that said, it would be helpful if you would state exactly what 3rd party integrations you are having problems with (or thats breaking). How can anyone fix anything or make something better if they dont know? Continuously posting on multiple pages without specific information means things wont get fixed. Afterall, UDI is beholden to ensuring devices work within their ecosystem. They may work with partner systems or developers to ensure compatibility but if they dont know exactly whats broken, they cant fix it.

This goes back to what I said before- what exactly gets broken...Its such a broad term when other nodeservers dont have this problem or to the level that you state.

So yes, ZWave node ident change - we saw that when going from 4.x to 5.x and again in later 5.x multi-channel support for Zwave.  That said, I didn't see anything about the ZW -> ZY thing other than the "may change" (a heads up, but not a statement of entire namespace).  Previous changes tended to affect a few devices vs all.

I'm heavily invested in the ISY994i and loved it.  My clients love it (even if they don't know what that black box is) because everything "just works".

As for 3rd party, I'm not asking UDI to fix them all.  I was suggesting (in another topic) that this and other name changes (not just from this, but from device re-inclusion, replacements, etc) makes integration with distributed device identifiers challenging. This particular case just pushes an existing issue to the forefront - at least for me. Understanding that it's unlikely UDI can make device idents "eternal", my suggestion of an user manageable ident used for REST connections (aka 3rd party integration) provides a simple way to have a single point management of identifiers (i.e. in the admin console).

This entire experience is just trying to find a way to migrate all my clients (eventually, I clearly have plenty of time) each of which has a variety of additional 3rd party integrations, in the most time efficient way and most stable/least-error prone way possible.

Several here have asked for specific 3rd party integrations, and I really don't have a lot of help for that.  They are all pretty custom integrations built with a variety of tech to suite each clients need.  There are simple ones like a MQTT proxy/gateway, one using HomeAssistant most to help knit in some HomeKit things, but most are custom built for each clients needs.  The consistent thing is they all use device identifiers, often stored/reference in the integration, for talking to the ISY and if a substantial number of device idents change, it's a lot of work in multiple integrations for each client spread all over the country.

I suppose one example I have in several installs is an REST based integration for in-wall touch panels that allow all devices in the house to be controlled.  Each panel has a button or buttons for each device, so they are all tied to each device via the device identifier.  In one house, there are well over 100 controls, all hand positioned to match the end users need and several in-wall panels throughout the house, each one tailored to the needs of that area of the house.  Changing all the device idents means each one of those touch screens 100 or so buttons need to be manually touched/updated multiple times.  And that is just one house.

All boiled down, I'm seeing a need, in my case using a LOT of 3rd party integrations in a lot of places, for stable (at least from the perspective of the REST interface) device identifiers.  

I'm not suggesting UDI cannot or should not change ident when they have to.  Just a way to provide a stable presentation to add-ons/integrations.

Link to comment
7 hours ago, gduprey said:

Hey - I love the ISY/IOX platform!  I've championed it for years and run it everywhere.

Yes, it's totally reasonable that they are EOL a device and I never had a problem with that.  In fact, it was the trigger for me to consider what seemed like their "next gen" that I wanted to get on board with - the eISY.  

Right now, all clients are on ISY994i - none on anything later as it did/does all that is needed.  If there was ongoing/eternal support for the ISY994i (unrealistic), I'd just be a happy clam keeping everything working the way it has been for years.

So I can either just stay with what I have (ISY994i), hope they don't break and/or I can find used ones to stock pile or try to migrate and if I am, I would prefer to "jump" to the most current/future-proof offering.

or you can go to Polisy without Zmatter board and just the Zooz 7 series dongle.

Link to comment
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Forum Statistics

    • Total Topics
      36.5k
    • Total Posts
      367.6k
×
×
  • Create New...