Geddy

@JRC welcome to the forums! Have you watched this video from UDI for setting up in wired format? https://youtu.be/GdKfAVfz2Fk Also, just good to make sure you read and check the eisy User Guide in the wiki as you get things running. https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide What do you mean by this statement? It's fine to keep both ISY and eisy running at the same time. Just for setting up it's fine. Once you move the PLM and/or any ZWave devices to the new eisy please turn off the ISY994. (Especially if you have zwave devices!) I can't help with the android device as I'm an iOS user. Also, macOS users seem to have success or heartache with IoX Launcher. If you've used the IoX Launcher successfully on the mac in the past to work on the ISY994 then you should be okay once you have the eisy connected to your network. I would do as @tazman suggests of pressing the button 4 times to reset networking then I would do as @Techman says of pulling the power and trying a different network cable. Oddly enough it could be THAT simple. I know I didn't attempt to use an old cable and just use brand new cables when new devices are being added to the network. Just like to keep things "new" that way.

This is very possible with DHCP reservations. Depending on the router you might have to connect everything first then assign IP reservations. Some routers will allow you to reserve IP with the MAC address before connecting, but depends on the brand and firmware.

Yes. It's normal "now". Seems to be changed from a previous update. I noticed same thing in recent PG3x update process. What are you trying to update? Looks like you are current for IoX and PG3. You can always check what the current versions are in the Current Release Announcements area of the forums: https://forum.universal-devices.com/forum/339-current-release-announcements/ As of today: 3.6.0 IoX (released April 20, 2023) 3.1.21 PG3 (Polisy) (released May 22, 2023)

Does this mean you've resolved your issue or are you still having problems? When you click install it should pop up a window to Purchase. After you purchase you might have to click "install" again. At this point it should pop up another window. At the bottom it has an option for what slot to install it into: Select the slot number you want to install it to and click "install". It should then process correctly. Purchasing and installing node servers is documented here: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#NodeServer_Store_Menu

@mapeter This is something UDI would need to answer directly. Best to open a support ticket to ask the question directly to UDI. https://www.universal-devices.com/my-tickets/ Doubtful any user-to-user support would give a valid answer since only UDI knows the dependencies of the systems they've developed.

@TriLife first thing you will need to do is update the ISY994 to 5.3.4. That's the only path to migrate to IoX. Before you migrate get the eisy connected and updated to the current version. Links to all current version firmware and how to update can be found in the "Current Release Announcements" area of the forums. My suggested path would be to migrate directly from ISY994 to eisy. I don't know what "whole bunch of Tasmota/MQTT devices" implies, but Insteon and Zwave migration should be straight forward at this point. You are on your own for the other devices. Make sure you read through the eisy user guide and pay special attention to the migration instructions: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide There are some specific posts for Z-Wave migration pinned in the IoX Support part of the forum. Be sure to review those for your situation. (Note: unsure where it's mentioned, but all Zwave nodes will change their node nomenclature from ZW to ZY) You CANNOT migrate PG2 node servers to PG3/PG3x. You will need to start fresh with node servers if you are not running any PG3 node servers on the Polisy. There is no migration path from PG2 to PG3/PG3x. You can only migrate PG3 to PG3x. If you've never entered the PG3 side of you Polisy you can see the current list of PG3/PG3x node servers here - https://polyglot.universal-devices.com/ (There is a production store and non-production [beta/test] store. You will probably want to stick with the production store.) Simple suggestion is to stay focused and target the update/upgrade and migration steps in order. Read the whole process so you know what to expect and steps to do. If/when you run into issue fix only THAT issue. Don't move on to something else thinking that you can fix more later. It's usually easier to fix a system when only ONE thing is not functioning properly. If you go off and have multiple things trying to fix all at once it gets confusing for you and those helping you. Note that this is a holiday weekend in the US so not sure how much support there would be through UDI support tickets or activity on the forums. But you know the community is here to help if needed! Good luck and keep us posted on your progress.

@hart2hart Sorry you're having the issues. Hopefully @Michel Kohanimor @bmercier can get to the bottom of this. I checked again after my last reply and thought I had an issue, but it looks like I had a false alarm that it didn't trigger. If you've got the new node server and authenticated it again I'm surprised it isn't working. I went through it and restarted the node server, hit authenticate and motions and rings trigger fine. For my testing I set the log into debug, restarted the node server, hit authenticate allowed a few minutes for things to settle. Went and made motion. I saw the motion result in the log for the node server. Then opened admin console and the program had "last run time" of my motion and the light I trigger had come on (I could see that while I was outside). What I saw in the node server log is: 🤞 they get you squared away. Keep us posted in case others have this issue.

Actually it's better than perfect (for 99% of the users). There has been multiple threads about this since IoP (now IoX) was released. Very few people might have a true use case for something like that, but 99%+ of the users are better served by using the solution @lilyoyo1 posts. Many moons ago it became the suggested method of using a DHCP reservation on the router to keep the ISY994/Polisy/eisy at a known IP address. The reason has been repeated many times that so many support tickets were created due to users replacing the router. The issue always centered around somebody setting a static IP on the (old) ISY994 then changing their router and ultimately the underlying DHCP IP table. The ISY994 couldn't connect to the new DHCP table if it was a static point with a different LAN IP table. Typically most involved and (I dare say) responsible users will make note of settings and remember that things are set statically at the device level rather than at the router. Sadly, many that don't remember those things, or didn't set it up originally panicked when they replaced the router and the ISY994 didn't magically reconnect to their network. Thus resulting in a support ticket. When UDI introduced IoX they removed the ability to set IP at the device level. Meaning the only way to keep the device at a "static" IP is to use the DHCP Reservation from the router level. 👍

@hart2hart what happens if you select "run then" of the programs above? Do you see it triggering the program you're calling? I'm using the Ring node server with a Pro doorbell and a wired Floodlight Camera. What's strange is since the devices are linked in the Ring app it seems if there's motion at my doorbell the floodlight doesn't trigger motion (at least from my limited use/testing). However if the motion of the floodlight triggers first if fires my motion program all the time. On the motion program why do you have the "And $Front_Porch_Motion_Running is 0"? Even if you're saying it's set correctly you've got 3 and statements that all must be true. I'd test it with just the motion first then add one and clause then another if it's needed. Seems too complicated just for a motion trigger. My test program was: ~Flood-Motion-test - If '~NodeServers / ~Ring / Driveway (Motion)' is switched Motion Then Set 'Lamp' On 100% Wait 2 minutes Set 'Lamp' Off Else - No Actions - (To add one, press 'Action') Do you have devices linked in the Ring app? Perhaps motion is being triggered by another device and the porch camera is linked and therefore not the one triggering the motion. Last effort is...have you created the programs as NEW? Using the new nodes? You mentioned they're what you ran when using the PGC version of this from ages ago. I'd try a new program rather than trying to modify an existing one. Doubtful it would have any difference, but something might be goofy.

What resulted from your ticket? Were the old ZW nodes able to be removed somehow? I'm confused as to why/how some remain ZW. Perhaps it's an issue that hasn't been encountered (i.e. reported to UDI) enough for them to consider it being an issue worth making a note/comment in the migration process. If you got resolution through the support ticket share what happened with that so it would help others that might suffer the problem. Additionally in the support ticket suggest that it be documented somewhere that this might happen and possible way to resolve it.

If Honeywell's site doesn't see their own products then that's probably where I would start. Once it shows up on their servers the node server should probably find it by connecting somehow. To me I'd say this is probably an "unsupported" node server. You could open an issue on the github, but appears that @bpwwer is the one updating a few files there now. https://github.com/UniversalDevicesInc-PG3/udi-honeywellhome-poly/issues

Thanks @bpwwer. Was able to upgrade without issue. Just allowed time while I did other work and came back, opened Admin Console and it said it was updated, needing the reboot. Allowed it to reboot and got notification from UD Mobile that eisy went offline and online and a little later tried web access and all was as expected. Well done!

I'm not sure. Perhaps some on here can, but might be better to ask Insteon directly or check their forums. https://www.insteon.com/support Looks like owner's manual is here: https://www.insteon.com/support-knowledgebase/2014/9/26/range-extender-owners-manual

@JSylvia007 if still having issues with such widespread z-wave issues it might be best to open a support ticket with UDI to make sure you're going about the fix correctly. Also, if there are "bugs" or other issues happening that's the only way to report them directly to UDI so maybe they can fix anything that might need fixing moving forward. https://www.universal-devices.com/my-tickets/

This is from the wiki: Hopefully that's what you went back and read again. It's from this section: https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#What_to_Expect_During_Migration

@MSpangler moved your post out to a new topic to hopefully get additional attention. You posted to a thread that was over 4 months old and your issue might be different so better to start a new thread. Link to old issue by other user: Have you replaced the batteries lately?

If the program you posted is the only one triggering based on motion then it shouldn't be doing it during the day, but now you've said you've adjusted the motion sensor to only trigger at night. Did that help? What kind of motion sensor are you using? It sounds like there might be another program triggering the light. You can use the "Find/Replace" feature in the program tree. Click on the root folder (probably "My Programs"). Right click to get a menu. Select "Find/Replace". You'll get the window to search for finding "Your Devices". Select the "Parking Pad..." and then only hit "Find" (note, you don't want to replace so be sure you only click "FIND" If you want it to run all night then you should remove the "11:45pm (Same Day)" from the program and make it something like "Sunrise (Next Day)". The example @MrBill gave above was from his own system and it was for a light he wants to turn off before midnight. The example I gave above turns my lights on and off around the sunset/sunrise time. You would want something similar to allow the motion to trigger during the middle of the night. What you posted in a screen shot above could be your issue. Unless you modified THAT program. The way you had it in the screen shot was that anytime there was motion they light would come on. You also ran the "THEN" of the Sunset path meaning whatever that program does happened following the program you posted. When you call on a "THEN" there's no evaluation of that program and it just runs "THEN". So even though the sunset program probably has a time to happen you're avoiding that schedule when you run "THEN" of that program. Since you've been modifying several programs please post all CURRENT programs that trigger the light (Sunset, Sunrise (if still 2 programs), and motion trigger). This way we can accurately review what is currently being used.

@captainc might have not used proper programming, but mine work fine for motions to trigger lights. Check this from @Bumbershoot for possible help:

Are the ones that are still ZW battery devices? I forget where it was documents (can't find it in the wiki), but in a release for ZMatter Z-wave support it was said that all nodes would rename from ZW to ZY. Reason I ask about them being battery is this portion of the wiki might shed some light on why you have some ZW nodes. https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Post_Migration @Techman yeah, I am not sure how yours also stayed ZW. Everybody else that runs ZMatter had reported the change. I did not migrate any Zwave and don't run many devices, but they're all showing ZY connected to the ZMatter dongle.

You can always look in this area for all the current releases for UDI products and services: https://forum.universal-devices.com/forum/339-current-release-announcements/

The "else" that @MrBill was suggesting was for your Sunset program. You have a "Sunset" and a "Sunrise" program showing in your screenshot. I think he's assuming that your "Sunrise" program might be turning the outside lights off. You can use his suggestion to only have 1 program. For instance I have this for my front door light: Front Light - Night - [Run At Startup] If From Sunset - 1 hour To Sunrise + 1 hour (next day) Then Set 'Front' On Else Set 'Front' Off This does both the turning on, and turning off. Be sure that it's triggered to run at startup incase you have a power outage that happens before your time and returns after your time it will turn on the outside lights. As you have it now your parking pad light will only trigger from Sunset to 11:45pm. You would set it back to the 35%, but you need to edit the sunset program to turn the lights on to 35%. Right now your program just has them coming "ON" at Sunset. Their on% is either handled by another program or scene or device setting. It's unclear how you're turning those on at 35%. What is "Outdoor Lights On"? Probably a scene? Final comment...wouldn't you want the outside lights to go to 100% if there is motion all night long? It would potentially pause anybody approaching your house with the change in brightness. And if you have outdoor cameras might help with the details of the motion overnight.

@macjeff is Easter the ONLY date you want to figure? Why not just program with specific dates? Dates through 2033... Year Holiday Weekday Date 2023 Easter Sunday Apr 9 2024 Easter Sunday Mar 31 2025 Easter Sunday Apr 20 2026 Easter Sunday Apr 5 2027 Easter Sunday Mar 28 2028 Easter Sunday Apr 16 2029 Easter Sunday Apr 1 2030 Easter Sunday Apr 21 2031 Easter Sunday Apr 13 2032 Easter Sunday Mar 28 2033 Easter Sunday Apr 17 uncheck "daily" and you get the yyyy/mm/dd option. Just plug those into your program(s) for Easter.

@737simguy Do you happen to have any "old" backups from the ISY994 prior to your eisy? Perhaps you migrated from ISY994 to eisy and still have the backup used from the ISY994 for the migration. You should be able to restore that backup. Or if you didn't wipe your previous ISY994 it should be possible to just plug back in and go through the replace PLM process to get things working again. If you added devices or changed programs after going to eisy all those changes would be lost, but using an old backup or if you didn't wipe out the old device you should be at least able to use that and not have to re-link or re-program everything.

This would be up to the developer of each node server to make a post when new releases are available. Several do, but many do not. Additionally, if people follow the root of the node server forum area they would get notifications of new topics created. Many developers seem to be editing or replying to prior posts and that does not trigger any notification to anybody following a topic area. However, following also notifies of other new topics, so not always an easy/clean option. Hopefully @bpwwer and @Michel Kohanim can move the update alert up the importance list soon as it does seem to be a missing link in keeping node servers updated. However, it should be one of the first steps in troubleshooting issues is to simply check if there is a node server update available if/when something isn't working as expected. I think the method @macjeff mentions of sorting by modified column is great. But can't see doing that "daily". Maybe once a week for casual review. If I wasn't as active on the forums I could see going weeks (or maybe months) between the time I log in to my Polyglot dashboard. That's the joy of the reliability of what's running on my system.

@smarthome_newbie If it gives you the options @Javi mentions above, but then there's no other window that pops up you might need to try this: https://wiki.universal-devices.com/index.php?title=Main_Page#Admin_Console_Minimized/Invisible_and_Cannot_be_Restored I get that the directions are Windows based, but perhaps macOS also stores *.state files somewhere. Use finder to locate any ud*.state files. delete all ud*.state files clear java cache run start.jnlp again