Geddy

Probably get more accurate information asking Insteon directly. If they've received the recent shipment they can at least tell you what version they're calling the current production runs. But @lilyoyo1 is right (and basically confirmed by @Techman in edited OP), that using the same part numbers basically implies that it's the same build as before. But just for reference: Serial PLM (2413s) received in January 2021 is Revision 2.6 and date code was 4520. I think others got some around that same time and might have been the last time they were available from prior Insteon.

@HHarris Welcome to the forums. We split your post out to a new post as you had it posted in a Win11 issue, but say you're on Win10. What has changed that your ISY994 is not found on the network? Did you replace your router or did you update the ISY994 firmware? What firmware are you running? If you changed your router please review this section of the wiki: https://wiki.universal-devices.com/index.php?title=Main_Page#Changed_ISP/Router_-_Can_no_longer_access_ISY Also, please review this section and observe the lights on the front of the ISY994 and report what you see: https://wiki.universal-devices.com/index.php?title=Main_Page#Front_Panel_LEDs/Lights

Nothing known here beyond the email everybody received. To guess would just be speculation until somebody confirmed directly with Insteon. Probably best to email/contact Insteon directly: https://www.insteon.com/contact-us

Check if you have another power supply available to test on the Echo if you move it back and they return again. It could be that the brick of the power supply for the Echo is flaky and where you're using it is causing the noise. I recall there being other posts that cell wall warts started causing noise randomly. So it might not be the Echo itself, but it's power supply. Depending on how old the Echo is you might get Amazon to replace the cord, but they don't usually offer that kind of option. I've seen elsewhere that some have been able to get Amazon to issue a credit for the amount of a new cord, but it's also difficult to get. Good luck.

Correct. If you get the serial version. Since the USB is also available for pre-order just go with the USB version and not have to worry about additional cables. That is if you're going to use it with the Polisy or eisy. As @nowandthen stated they got the serial version to use with the existing ISY994. The extra cable just adds unnecessary clutter to the cable management system (or lack there of for some) and another possible component failure to have to troubleshoot should there be an issue. (IMO)

@asbril Since UD Mobile can call on the program directly it is possible that you just make the geofence trigger the "THEN" of your program. Since a Geofence can have multiple commands just add another command, select "My Programs" -> "Run Then" Otherwise, you could still use the variables and have it set a variable and then trigger any number of programs off that variable. I still wonder where your "Occupied is true" portion came from.

@vbPhil as answered above i3 aren’t fully supported yet. Great news from UDI in a recent news post though has many hoping for full support as UDI land Insteon are working together! UDI release: https://www.universal-devices.com/i3-support/

@KConover you're certainly correct in the information is "outdated", but it was written for the ISY99i and ISY26 (both long since EOL), but the "basics" do still apply to IoX programming. The amount of edits and changes that would need to be made are too numerous to try to update all old pages. Most would look at the list and see that "My Devices" is in the same sort order as "Insteon/A10" and select that as the option. Plus, the page you linked to hasn't been updated since 2011. Yeah...have to take some blind faith jumps in relating 12 year old documentation to what you're looking at today. The principal still works...the naming is different. Wait until you try to read the 692 page ISY Cookbook. That's more current ("published" in 2018), but still uses the same image from the page you link to. UDI would almost have to start over with the wiki to bring things "current". Even then they would be evolving. There's so much valuable information available in the wiki that still applies, it's just not verbatim.

@asbril are the "home" and "home/ seno iphone" state variables? I don't think the Geofence setup in UD Mobile adds any variables. You would need to trigger a variable in the app. Did you ever run Geofence when you ran Mobilinc? That required the app to set the state variable then you have a program trigger when the state variable changes. Where do you have anything for "Home Occupied is True"?

@mmb Thanks for posting, but this has been posted (different article) and discussed in this thread:

@GJ Software Products for specific help with an issue please submit a support ticket. Forums are typically not where UDI will watch for issues such as this. It's best to get individual help for this issue so UDI can troubleshoot and see what your system is doing privately. https://www.universal-devices.com/my-tickets/ Also note for easier reading, and searchability, in the forums please use "Copy to Clipboard" by right clicking on the program then paste as text (rather than a screen shot). It helps others by becoming searchable should they ever have a similar issue.

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.