Geddy

Yes, the eisy has Admin Console that is identical to the ISY994. There are a few changes for support of the eisy and if you run node servers it will add additional devices. And I think you can also setup eisy without the phone app, but the app does make it a lot easier (for most). Remember if you make any changes to your ISY994 to make a new backup before migration so it's current. Don't think today's backup will be the best option if you tinker with things and forget about it before you get the eisy and migrate. Lots of great threads in IoX Support and eisy forums area as well as the UDI Wiki to read through to learn more.

@Lore I didn't have a chance read more about the I/O Links the other day (I don't have any I/O Link devices). Why are the devices setup in reverse? I just checked out the ISY Cookbook and it would appear there's a way to set it up as "Trigger Reverse". Wouldn't that give you the status you want to be correct on a reboot? Sadly, I don't know anything about them other than what's in the Cookbook, but sounds like you might not have set it up as outlined in the cookbook. The cookbook even mentioned the issue of not showing the correct status after query, but that was mentioned to have been fixed in FW 2.7.4 (loooong time ago). Anyway, glad you seem to have it worked out for your need. But it might be worth reviewing the cookbook (link is in the UDI Wiki) and maybe setting up those devices again to display correctly.

So...just like all the Z-Wave issues "we've" been having? I think the biggest issue is while there's a "Z-Wave" standard not all manufacturers adhere to it as some might hope. I feel for UDI in that their support ticket could will probably jump significantly again once the additional devices are supported. 🤞 My hope is users realize that it's not UDI but the device manufacturer devices (UDI is trying to support) that are causing the problems. Most haven't considered this being case with the Z-Wave debacles many faced.

@Lore I think current versions of IoX are not putting the "old" Default Query All program back in the system. It would need to be created. Smart suggestion from @DennisC to have it delay a moment as the Polisy starts up. It starts up much quick than the old ISY994 did, but has a lot of dependencies running on initial boot. To make the Query All program set it up this way: 00-Query All - KEEP - [Run At Startup] If Time is 3:05:10AM Then Wait 2 minutes Set 'ISY' Query Else - No Actions - (To add one, press 'Action') For the "THEN" section you'll find "Your Devices" in the action option. Once created you have to go to the summary, right click on the program and "Enable Run at Startup" (Note: "ISY" is the name (or folder name) for your ISY if you renamed it on the "Main" tab. It might be near the bottom of the device list and should have a terminal looking icon next to it: ) You could also just query the individual devices depending on the size of your install and number of items needed to query.

@ctviggen1 seems that you're plowing into the eisy and not taking the time to read any setup instructions found in the Wiki: eisy User Guide. It would have given you most of this information.

Click the red "x" to the left of the UUID for the ISY in the portal. You could offer it up to others (in the Coffee Shop forum) or list it on ebay. Otherwise, electronic recycling is best option. Perhaps you could see about sending back to UDI if they are doing any sort of referb ISY994 or need parts for OEM ISY that they're still supporting. There was a trade in option, but think it was limited for how old the ISY994 was and had to be purchased directly from UDI. Not sure if that is still available or applies in your case.

If you're not using it then it's probably no worry. The Firmware will work, you might have issues if it was a 300 series board. Since you got your primary concern taken care of and not using z-wave then I wouldn't worry about it at this point. @lilyoyo1 helps determine which board might be installed in this post:

@Joe Casullo Keep us updated on what happens. Would be interesting to see if there's a software/firmware/driver fix or if you have a device issue.

IMO (and purely as a user) with a system as complex as yours I wouldn't even attempt a "dry run" out of worry of what happens in an attempt to go back to an old system. I know that there's been a few bumps along the way, but it's a lot better than the initial release time of the eisy. And going to Polisy had been fairly easy, but the ZMatter board did add some complexity in that regard. Even if you wait until you feel it's a little more safe there's bound to be something that will bite you because it's your system and UDI can't program for everything in everybody's system to migrate without a hiccup. Just got to be ready for anything. Many have probably updated without major issues that they haven't even had to post on the board. While as with everything else in the world when there are issues you hear about them 10-fold. (You know the "saying" that it's easier to complain sitting behind a keyboard than to somebody's face...well...forums give everybody that medium.) The issue becomes - "when is the best time to migrate"? Well, given the number of people actively going through the process now I'd actually say RIGHT NOW would be perfect. You'd have the most support from other users on the forums with issues. You'd also be a great help to UDI for migrating a complex system for finding any additional bugs that need to be ironed out. If you wait the user-to-user support on the forums becomes "well, when I did it (x-months ago), I did x-y-z to fix that issue". That would prove two things...x-y-z didn't get fixed (mostly because UDI didn't know about it by way of support ticket). And that if you thought waiting would be better it still wasn't. I'm kicking myself for not migrating to the Polisy from the ISY994 sooner. I waited until I had the eisy to migrate from ISY994 all the way to eisy. I have about 100 nodes and less than 100 programs. My system was uber simple. (IMO) I had everything migrated within 30 minutes. That was about 2 months ago now. The other side of me is saying...why wait? Just do it! Rip off the band-aid! Make the leap! Come on in, the water's fine! I would say plan for the best, but be prepared for some bumps along the way. There is a very strong user support system here to help you in the process.

It uses the ISY Portal login. You need to setup an account at https://my.isy.io/index.htm then you can get into the ticket system and start a new ticket.

@hetrickb yeah, sorry...edited above post about Auto DR. That's not the issue. At least doubtful anyway. Do you have an OEM ISY994 that was part of a California energy program? It sounds like it based on what @DennisC found. That's beyond experience of most on the forum as I can't recall seeing any/many questions about it through the years. I'd contact support and see if they ever figured out a way to stop that or if something else was needed.

Sounds like @DennisC found your main issue. But the question is: What firmware version did you upgrade to? Where do you see this issue? (Event viewer, Event Log, Error Log) Sounds like it's something that a ticket with UDI might be necessary to figure out how to turn it off, if it's possible to turn off. https://www.universal-devices.com/my-tickets/ This would not be related to the "Auto DR" that's a default scene in the ISY994. It cannot be deleted. It's not creating this issue. You can rename it. I add a simple "~" before it and the ISY puts it at the bottom of the device list - out of the way.

@RKalish and @bob123 There was a change a few versions of PG3 ago that required the Polisy to be applied to an ISY Portal account. As for having an active subscription I do not know/recall that status. But you do need to at least have it showing up in your available devices in your ISY Portal account. You can set it up for a trial license to get it added to your Portal account and add/install node servers. I recall doing the same as you both mention of installing node servers on the Polisy before having it on my Portal account. Then I couldn't, not even free ones. Since I went to the eisy before going to the Polisy (fully) I didn't worry about adding it to my account. If you're just wanting to test/try before migration and haven't had a trial license on the Polisy then signup for the 30 day trial. If during that trial you're ready to migrate then the Portal Migration will move the remaining license time on your ISY994 over to the Polisy. Or you can extend the license time and think you can migrate later and still add the time. Either way if you run into issues with the portal license down the road open a ticket with UDI and they can will help sort it out. Just do it before the free support ends for the ISY994!

@vbPhil Not in ABQ, but have issues this time as well. Time was correct in admin console, but sunrise/sunset were an hour later than expected. Crazy! Didn't notice this until a program didn't trigger that's set for 3 hours after sunset (normally not a problem in ATL), but that made it after midnight (next day) and it didn't trigger. Rebooting seemed to get the time back on track. Very strange indeed. In my case I have a "Custom" location set, but it does pick it to be "America/New_York" for Daylight Saving Rule. So it knew what it should be at least.

Sorry that didn’t help. Post back what you get from support once resolved so we know what happened and what might help others if they experience a similar issue.

If nobody answered the original question then nobody probably knew the correct answer. Best option would be to ask UDI directly by opening a support ticket with the question. https://www.universal-devices.com/my-tickets/ Since UDI wrote the code for the ISY994 method you reference and the eisy code then they would know if this was available/possible. That is, if what @DennisC said above doesn’t get you what you desire.

@Andy P with Admin Console open start Event Viewer and set it to level 3. Operate a light both via admin console and physically (maybe different lights). Is there any activity? Looking for some ACK results. More than likely nothing. It might be best to open a support ticket and get help directly. Since you can control devices and the status does update on query there’s something not getting from the PLM to ISY service somehow. https://www.universal-devices.com/my-tickets/ Is your PLM plugged directly into the wall? What cables are being used from PLM to eisy? You said you tried different PLMs though, did you restore PLM after the migration and restored backup? I don’t usually randomly change PLM so don’t know the process and don’t usually suggest the “restore PLM” process, but know others do it randomly. Perhaps something additional went goofy in those steps.

@Andy P welcome to the forums! Please check the UI and Firmware match when you are logged into Admin Console. Menu “Help” -> About What firmware are you running on the eisy? (Current is 5.5.9) What OS are you using on the computer you are accessing the Admin Console? (Win, Mac, other?) You may need to clear the Java Cache (selecting all three boxes in the process) and downloading a fresh IoX Finder (start.jnlp - NOTE: Don’t use old downloaded copies). Have you preformed a full power cycle during any of your migration steps or subsequent trouble shooting steps? Always make sure the PLM is powered on a few moments before the eisy. If you have not fully power cycled the eisy please try that now also, if above steps don’t help.

Does the Polisy (IoP) have an active portal license or account tied to it? You will need to log into the ISY Portal to be able to buy/install node servers. Even for free node servers. I do not currently run the Polisy, but know I tried to install a free one in the past and the Polisy was not on my ISY Portal account and the store acted as you describe. Which node server are you trying to install? Click on “Log” on the top, change it to “debug” then try to buy a node server. Then go check the log (might need to download the log and view it for information). Be sure you change the log type back to “Info” or “Warn” (might not be exactly those words, but just don’t leave it on “debug” forever.

@RKalish welcome to the forums. I believe there was an issue with Polisy around 3.4.5 that the upgrade package function got stuck in a loop. The best option is to open a support ticket to get the proper upgrade steps to get you current. The Polisy is certainly ready for daily use. It functioned great for me when I had it installed in my house. With the development for Polisy and eisy as well as Polyglot v3 it means users will probably need to keep the system updated more often. This is different than most users that had an ISY994 and just set it and never updated it. I liken it to if you’re running a more robust system things are bound to break/change more often so the core of that system will need to be updated more often to keep things working. If you’re good with SSH commands perhaps look into the support thread for 5.4.5 or the next version. I think there might be help there. Otherwise, support ticket is the best route. https://www.universal-devices.com/my-tickets/

@Jack D Yep...your folder is messing you up... The My Programs folder has a "next scheduled" run time. I assume that's also sunset. So for that moment the folder is true thus allowing the sunset program to run. After such time the folder would be False and not allow anything else to run. That's why no other programs have a "Next Scheduled Run" showing. Even the Sunset program itself doesn't have a next runtime because it's in a false folder. (Notice that your "ON" "Query All" also don't have any last run times and no scheduled run times.) Click on the "My Programs" folder. On the right side there should be a line in the "IF" area. Click on that. Click "Remove Line" (see arrow below) Then "Save Changes" on the bottom left column of the admin console Once you do that the "My Programs" folder shouldn't appear in the summary screen. As noted above when there aren't conditions in the folder it won't show up on the summary tab because it has no reason to run. Your other programs should then populate "Next Scheduled Run". Final comment - notice in my program above that you can achieve both the On and Off setting with one program. You don't need to have two programs for the different times. If you really aren't turnning off both devices that you're turning on at sunset then just put the ones you want to turn off in the ELSE of a single program to run from Sunset to Sunrise (next day) and the light will turn off (if you follow the program I posted earlier. Good luck!

@Jack D For your Sunrise program is there a "Next Scheduled Run" time shown? I just created a test program like your Sunset program. The status matches what you're seeing. The above "Light-test1" is for Sunset, and "light-test2" is for Sunrise. Make sure that you've saved the programs. They shouldn't have a green arrow on the name like this one does: If I run the "IF" of the Sunrise program my light turns off. It also updates the summary for "Last Run Time" so you know something in that program ran when you triggered it manually. The program is: light-test2 - If Time is Sunrise Then Set 'Front Door' Off Else - No Actions - (To add one, press 'Action') OH!!!! I've got it (I think)! While I was typing the above I looked at your screen shot again. You've got a folder condition in the "My Programs" folder that is making the folder false. Anything in that folder won't run. (which makes it odd that your sunset program ran - maybe it ran yesterday, but didn't run tonight if you changed something today). Make sure your "My Programs" folder looks like this: NO conditions! Mine doesn't have any conditions and doesn't show up in the summary tab. I added a condition that would make that folder false and it showed up in the summary tab. Because the "My Programs" is typically the root folder none of the programs in the root would show that as the path. Only programs in subfolders would show something in the "Path". I still don't know how your Sunset program shows "True".

@Jack D yes, check the version to make sure they match. Especially since you said you just updated. Looking at your programs again and the summary something isn’t right…the “Sunset” program should only be “True” at the moment of sunset. All other times it should be false. Something is causing it to always be true. Perhaps UI/FW don’t match. A way to test is: Then turn on the light strip. Right click on the sunrise program and select “Run Then”. Do they turn off? Doing this is a simple way to test that the program actually controls what you expect it to do. Do you have any other programs that might be conflicting with the time and keeping those lights on? Lastly, since you said you transitioned from the Insteon Hub to the ISY did you reset any/all devices before adding them to the ISY? I don’t think that would block a program from even running and it clearly doesn’t have a “last run” time shown. I assume you made the program before today so it should have run at sunrise today. Also since you did just update make sure you save the programs again. Select one, then hit save again. Just as a troubleshooting step following the update.

@Jack D Welcome to the ISY way of life! We're here to get you sorted out. The forums are great for user-to-user support and assitance. First off, the best way to get program help is to post the actual program. If you're on the details tab and click on the program you want to work on. Right click that program and at the bottom of the menu that comes up will be the option "Copy to Clipboard". Then come to the forum post and paste it as text. For your first request, here is a simple program that turns on a light in the evening and off in the morning. Front Light - Night - [ID 0002][Parent 0001][Run At Startup] If From Sunset - 1 hour and 30 minutes To Sunrise + 1 hour and 20 minutes (next day) Then Set 'Front Door' On Else Set 'Front Door' Off The way the ISY programs work is they are ALWAYS running. So you seeing them "enabled" is fine. The "True" and "False" status is what you want to look at. A program that is "TRUE" means everything in the "IF" portion of the program happened. My program above currently shows: The program would be "FALSE" when it doesn't meet the criteria of the "IF" portion. The best thing I would suggest to you is to review the UDI Wiki and download the ISY Cookbook and search for topics you want to learn more about. The cookbook was written a few years ago and hasn't been "updated", but it still reflects the basics of how to program and definitions of each part of a program mean. Post your program to get help with the specific issue. The summary tab doesn't help us be able to help you very much. It's also key for us to know what your ultimate goal is. So just turning some lights on at sunset and off at sunrise can be done with a very simple program. More complicated things will require a lot more information from you for what you actually want to accomplish.

@larryllix overall I agree, but I don't like getting lost in the weeds by nitpicking what is typed out. I'd say even the most casual user could understand the instructions as written. Sure, they could be cleaned up a little and matched EXACTLY, and certainly someone could suggest this directly to UDI (there's a great "contact us" link on their website). How do you jump to the conclusion that the instructions might cause people to "factory reset" their devices? That's quite a huge leap from where the discussion was heading. Are you alright? Either your keyboard/device is having issues or you might need medical attention. What is "5 .inured"? I can figure out "co fusion" is just a space instead of "n", but...? I can recall all the 4.x and 5.x updates for ISY994 that seemed to just copy/paste the method for updating and big differences that were sometimes in those instructions or results. Besides, if the instructions were exactly right what would we then be able to discuss on the forums? I mean it's not like there's NOTHING else that needs the attention to detail. So I'm willing to look past a few minor discrepancies in the instructions because I know what to expect.