gduprey

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.

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.

Possibly true, but not something I'd ever expect/want UDI to do. The idea is that they have a well developed REST interface and the more "stable" that is, the more they don't have to worry about what is "connected" to the ISY. My whole issue is the use of unique/stable device identifiers is "spread out" over a number of integrations that use the REST interface and that means all of them need to be updated. In the case of some, which present an entire touchscreen UI overlay, such changes involve pretty much every device in the house. Which is manual, tedious, error prone, etc.

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.

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.

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.

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.

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.

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

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)

Howdy, This is for the ISY994i, so limited to the specific ZWave dongles that UDI provide - not USB. Once I get to the eISY, I already have the Matter/ZWave/Zigbee dongle and looking forward to that. VBut before I can, I have to migrate from the older 300 dongle to the 500 dongle in order to be able to migrate that to the eISY and it's dongle. Gerry

Thanks - just needed to scroll down further and all is there. Figured it had to be somewhere Gerry

Howdy, Starting my path from the ISY to the EISY and step 1 is to updating my ISYs (there are like 12 of them around) from the 300 series to 500 series Zwave dongle. I cannot seem to find any instructions on it. Most are already on 5.0.16C, so the "pain" of the 4.x -> 5.x migration has been resolved a while back. Is there a page that covers the process that I'm just not using the right search terms to find? From what I can see, I THINK the process looks like: 1 ) Upgrade to most recent 5.0.16C on ISY (if not already there) 2 ) Zwave -> Backup -> Full Backup 3 ) Backup ISY 4 ) Power down and replace 300 series with 500 series 5 ) Zwave -> Advanced -> Factory Reset (just in case) 6 ) ZWave -> Advanced -> Upgrade Firmware (just in case) 7 ) Disable Battery Updates 8 ) ZWave -> Restore 9) Power cycle/reboot ISY 10) Wake up each battery zwave device and Zwave-> Synchronize 11) Review programs for any "broken"/changed ZWave ID numbers I'd appreciate any pointers on steps missed, best practice type things, etc Thanks! Gerry

My suggestion would be to try a magnetic transformer (i.e. real transformer vs electronic switched power supply). They are linear and don't have that same "fall off" that a switch-mode power supply might at lower levels and seem overall to behave a bit more reliably with dimmer. Downside is they are larger. That said, there are a few things that are likely to come up: 1) LEDs show any disturbance in the power line, so at low levels, even the 60hz line frequency often becomes "visible", even if mostly in peripheral vision (at higher levels, I think there is enough brightness for you're eyes "persistence of vision" to smooth over something as quick as 60hz). Capacitors on the transformer output could help, but I've not seen a LED driver with any, so the output is always pulsed DC. 2) I've had some jankiness with some Insteon and other dimmers with switch-mode or transformer based low voltage at low dim levels. That is, unexplained occasional pulses (vs regular ones) and dips. I think it is just showing any small surges in the power (i.e. fridge starting/stopping) or other brief variations you can see. I have the "impression" (i.e. not tested out) that this is likely related to the dimmer not working as well when the load on it drops below some minimum. I suppose a way to test this would be to parallel as 120V incandescent light across the same high-volt leads the transformer has (incandescent being a purely restive load and presenting a consistent load to the dimmer). Not sure that is a valid permanent solution, but if debugging, worth a try. In general, dimming to low level is a bit problematic. I think a lot of it comes down to presented load to the dimmer, the characteristics of switch-mode power supplies at the lower-end of their operating range and the nature of LEDs themselves, not having any "buffer" in displaying input power like an incandescent. That last one, I think, might be helped out by adding some filter and storage capacitors to the transformer output, but again, starts getting a bit more complicated. But if it's important, it can be done, it's just not always easy or "off the shelve" for dimming down to the last 15% or so (though I'd love to hear if someone has a better buffered and load adjusted power supply that does handle it).

Howdy, Interested and following along with these EISY announcements. I have about a dozen ISY994i installs that eventually would benefit from this sort of migration. All of them use Zwave to one degree or another (as well as Insteon). In the EISY description/product page, it does mention that there may be issues with ZWave migration (which I've read before), but it also suggests that there is a process being worked on, presumably to make that part of the migration simpler. Given the large number of zwave devices and the fact that my installs are all over the place, the idea of having to re-include everything would be a show-stopper. Is there any sense/ideas around what sort of Zwave migration tool may be developed and/or what sort of general time frame (i.e. in Q1, first half 2023, in 2023, etc) it's planned for? I know it's very early days for the EISY, but in case there are some hints on this, I can at least mentally start planning around that for eventual migrations. Thanks, Gerry