Guy Lavoie

So you're saying that the same original PLM and serial adapter that worked fine with the original eisy isn't seen by the new one? And works fine when put back on the original? That does look like some kind of unusual problem with USB communications. On the v2 unit, you connected the power to the designated USB C power port (next to a hdmi port), right? Have you tried the power supply of your original eisy on it too?

That's the problem with status-only devices. Using a variable allows you to convert it to a control type event by having the status change set a state variable, wait a few seconds, then reset it. Like this: If Status = true Then set s_event_variable = 1 Wait 5 seconds set s_event_variable = 0 Then your other program can look for the variable = 1 AND time = xxx to yyy

Ah yes, I call these "latent triggers", when the time interval test becomes the trigger instead of just a static condition you want to "And" against. I usually use a variable as @DennisC suggests. It would be nice if there was a way to make time intervals optionally work like integer variables, to not trigger.

Have you tried going into the Alexa app on seeing if the device already exists? If yes, try deleting it, then add it back through the portal.

Try powering off your eisy for a few minutes, then turn it back on. Then log back in and see if the PLM now shows as responding ok.

If it's like for a few of us, just rebooting your controller might automatically upgrade it to 6.0.4 (if your current version is 6.0.0 or higher). If you get the eisy-ui login screen and log in with your portal credentials, don't be surprised if the screen is just blank. Just do a browser refresh.

I'm guessing that "That that has stooped on have of the device insteon devices woek" means half of the devices work? If so, are the non working ones battery powered devices, like leak detectors or open close sensors? If that's the case, you might need to relink those manually.

As you might have seen in other threads in this section, I have had difficulty with migrating from a Zooz stick to ZMatter on my eisy, and essentially reinstalled all my Zwave devices manually. One particularly difficult part was adding back Weiser locks. I have 5 of them, plus a spare that I use for testing. Doing the add Zwave device routine and pressing the button on the lock would often only add a single generic device node, or two nodes. This might vary for other locks but a proper add of a Weiser lock will usually give 5 or 6 nodes (depending on if it's a Smartcode 10 or Smartcode 620). In the US, these are often known by the Kwikset name. Each time I needed to do a Zwave exclude and retry the add. Bringing the lock closer to the controller would improve chances of success, but still usually required multiple retries. Taking the lock off the door isn't exactly fun either. In Zwave discussions on the forum, I would often see a suggestion to bring the device closer to the controller, so it wasn't just me either. In observing the add process, it's the "interview" process that seems to be the failure point. In checking out settings under the "Z-Wave" menu, I noticed Network -> Interview Timeout. So I bumped it up to the maximum of 3 minutes, and tried the Nth add of a lock that wasn't adding correctly for over an hour. Poof, added perfectly on the first try! There were short pauses during the interview progress indication, but it carried on to completion. And this lock was sitting on my desk to be closer to the controller. Well I had one last lock to add (of the five, the first two added back in-place, the third by bringing it close, and then the frustrating one I just described). This last lock is the farthest away, on a separate garage behind the house. I used the UD Mobile feature to go out, exclude it, and add it back. Came back in the house to see the 6 nodes added perfectly, on first try! Dumb luck? Twice? When thinking about the notion of bringing the device closer for adding it, the only real justification for that seems to be to reduce the need to go through the mesh network, which can only add delays. It would seem that making the timeout delay more tolerant is a much easier way of doing this. Let me know what you think, and if you do try this yourself, how it works out.

The common denominator seems to be the battery powered devices. Locks are also battery powered. Though there might still be a difference because locks need to be able to receive commands so they're always awake, while sensors usually only send out data. Do the sensors appear at all in your device list? Or are they there but showing only as placeholder nodes with no controls? If they do appear, try right clicking on the device: Z-Wave -> Synchronize -> Update with Interview. You might try waking up the device first, if there is a way to so that. I'll actually be experimenting a bit with migrations once I'm certain that I've manually reconfigured everything correctly to ZMatter on my eisy.. Then I'll be able to reset the Zooz stick and try things with it. I have Polisys as test controllers, and I've just acquired one that has a ZMatter board in it. I'll create a small setup with one lock and a zwave appliance module with the Zooz stick on a Polisy, and try migrating that to the ZMatter Polisy.

Migrating from a ISY994i to a eisy? Is it just Insteon devices or also Zwave? Did you keep the same PLM, using a serial to USB adapter?

With 6.0.3 you should already have eisy-ui installed. Have you tried accessing it? Just browse to your controller's IP address, with no port number (default 80).

I just couldn't get the zwave migration to work. I ended up adding back each device manually (exclude or reset, then add). Thankfully I only have about a dozen zwave devices, none of which are wall switches. But for a few of the locks, I needed to remove them from the door and bring them closer to the ZMatter dongle to properly add them. These are Weiser locks. I'm thinking that their greater number of features and nodes might have been a factor. To make reconfiguring devices easier, I had the restored migration backup running on a test controller (Polisy) and my actual setup with the new dongle on my eisy, and ran two admin console sessions running side by side on two monitors, so I could easily see what the old device names were, and search the programs where they were referenced. I'd then replicate that on the eisy.

So your Zooz to ZMatter migration worked ok? Please confirm. I'm trying to learn from this. Mine didn't, and I needed to add back each device manually (exclude or reset, then add). Thankfully I only have about a dozen zwave devices, none of which are wall switches. But for a few of the locks, I needed to remove them from the door and bring them closer to the ZMatter dongle to properly add them. These are Weiser locks. Do you have any zwave locks? I'm thinking that their greater number of features and nodes might have been a factor. To make reconfiguring devices easier, I had the restored migration backup running on a test controller (Polisy) and my actual setup with the new dongle on my eisy, and ran two admin console sessions running side by side on two monitors, so I could easily see what the old device names were, and search the programs where they were referenced. I'd then replicate that on the eisy. For your Insteon migration, keeping the same PLM makes things a lot easier! I also have a bunch of battery powered devices (leak sensors and open/close sensors) and wouldn't want to redo each one.

The "replace with" feature only works with the same type of device. Dimmer with dimmer, switch with switch, etc. I don’t know if a Togglelinc can be replaced by a non Togglelinc, even bith are switches, or dimmers. The replacement process is done by adding the new device with a temporary name, then right clicking on the old one, selecting "replace with" and picking the newly installed temporary one. If the new one isn't in the list, then it's not deemed equivalent.

Yes, upgrades and migrations are UDI's weak spot. Hard to follow instructions and iffy results. The forum is a good place to discuss particular issues you run across. Patience pays off! It almost always ends up being successful, but often with detours.

Do you have the USB to serial adapter for the PLM? Otherwise it's a pretty straightforward migration, especially if you don't have zwave: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migration

General line noise isn't as specific as looking for noise in the 120 kHz region, but is still good to know if it's strong enough. But I'd start testing with turning off breakers first.

Do you notice if the working or non working groups are on a common breaker? I used to have X10 and one thing I've kept is my Elk ESM-1 signal strength meter. It indicates Insteon signals quite well, as well as background noise. I think you have the right approach by trying to isolate the problem by turning off breakers.

Have you tried doing a device restore on a non responding device? If only some don't work, then the PLM is somewhat functional. Sounds more like memory (link table) corruption. Start with units closest to the PLM to re-establish the network.

I haven't had much luck with my migration.

My latest test: I tried doing the migration to a test Polisy (yup, "upgrade" from a eisy to a Polisy!). Same result. If I factory reset the ZMatter dongle, which deletes all the existing zwave devices, I can then add devices to it. But migrating existing devices just doesn't work. So at least I have a painful plan B: manually add back all the devices, and modify all the programs. That's 5 locks and about 6 to 8 appliance modules. Not fun. Has anyone ever successfully migrated from a Zooz dongle to ZMatter, on a eisy or Polisy?

Well the procedure in the link above does explain what to do, including the migration backup (you get that option when you click on "Migrate to ZMatter" in the Configuration screen. That page needs careful reading because it explains several types of migrations all in one long text. Here is the relevant part: Preparing for Migration from Eisy / PolisyYou can migrate locally on the same Eisy / Polisy or to another Eisy / Polisy. On the Eisy / Polisy your are migrating from Make sure Eisy / Polisy is up to date Go to Admin Console configuration page and select Upgrade Packages If you are not migrating your Z-Wave network Use (Admin Console | File | Backup ISY) to make a backup of your Eisy / Polisy If you are migrating your Z-Wave network Leave your current Z-Wave board / dongle connected Go to configuration tab in Admin Console and select "Migrate to ZMatter Z-Wave" Choose the option that allows you to create a "migration" backup (first option) You will see a series of popup windows providing information and asking simple questions Once you have your "migration" backup you are ready to migrate A migration backup is different than a regular backup. When a migration backup is restored it also migrates your Z-Wave network MigratingOn the Eisy / Polisy you are migrating to Do the appropriate preparation step (see above) Make sure Eisy / Polisy is up to date Go to Admin Console configuration page and select update packages If you don't have a current backup, make a backup of your Eisy / Polisy (Admin Console | File | Backup ISY) If you are using Insteon, plug in the PLM If you are not migrating your Z-Wave network Use (Admin Console | File | Restore IoX) to restore either your Eisy / Polisy backup or your ISY-994 backup If you are migrating your Z-Wave network If you aren't already using it, plug in your ZMatter Z-Wave dongle and unplug any other Z-Wave dongle you may have been using. (Polisy only) If you have a ZMatter Z-Wave board then power down Polisy, add it, then power on again. Reboot Eisy / Polisy Use (Admin Console | File | Restore IoX) to restore your "migration" backup If you are migrating from Eisy / Polisy use the migration backup (e.g. "ISY-BackupWithZWaveMigration.v5.5.4__Sat 2023.01.21 09.07.44 AM") If you are migrating from ISY-994 use your ISY-994 backup When IoX restarts, it automatically does the following: Writes you Z-Wave network into the ZMatter Z-Wave controller Interviews every Z-Wave device in the Z-Wave nework, creating/updating nodes, programs and scenes. This process can take anywhere from a few seconds to a few minutes for each device depending on the complexity of the device. The best way to monitor the progress is to open the Admin Console Event Viewer to level 3 For those who want lots of low-level details, you can also use this from the command line: tail -f /var/isy/FILES/LOG/ZWAY.LOG 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.

Thing is, I'm not migrating from a ISY994i. I'm migrating from the Zooz dongle to ZMatter. On a eisy.

There is no zwave backup option with the Zooz dongle. That menu choice only appears when you have the ZMatter dongle. The migration process also doesn't mention doing a zwave backup. Instead it has you do a IoX migration backup. From here: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migration

To answer your first question, upgrading the Polisy to 6.0.4 isn't a migration if you're just keeping the Zooz stick on it. It's just a straight IoX version upgrade. As you'll see in my own thread I started yesterday about migrating from Zooz to ZMatter, there is no zwave backup option when you have the Zooz dongle. That option only appears with the ZMatter dongle. The migration involves clicking on the button you highlighted in your post above, which will have you create a migration backup. This is similar to how you migrate from a ISY994i to a eisy. Your ultimate migration to ZMatter could either be done on the eisy or the Polisy. I'd probably do it on the eisy. The process is explained here: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Migration It's confusing to read because it covers several different migrations (from ISY994i, Polisy, eisy -> ZMatter).