Geddy

@Wes Westhaver There should be an option to turn the LED off. I don't have any of these modules so can't confirm. What settings are available when you click on the device? Is there a Backlight, Status, or LED brightness setting at all? What Firmware are you on? (This is posted in the ISY994 area). If you're on ISY994 FW 5.x you might have to press the button labeled for the setting for it to "take". That's a UI issue that was introduced in 5.x updates. On this one I'd have to click on "Backlight" to get that value to set. The above is for an outlet I have so your options for the plugin dimmer might be different. Otherwise, look up Light Dims as an option (for this and other LEDs in the room). There appeared to be a way to dim the light with local programming (Google the user manual for it), but not sure how that's done and it's not advised if being controlled by a controller so makes it seem that a controller would be able to turn the status light off (at least dim it some).

@Fredo Check the actual Geofence Location is still defined in "Location Settings" on Mobilinc. If it is then make sure the variable is still the same as you have indicated above. I recently had a similar issue and either the location or the variable had been deleted from the app. I'm not sure if it was iOS related (I recently updated to 16.4.1) or something else, but I noticed some programs not triggering for a while. I'm running IoX on eisy, but it was clearly app related as something was missing. I think I had to recreate the location and reset my variable. I then had to adjust my programs to reference the new variable. Since I'm on IoX I had some issues with Mobilinc making the variable through the ISY Portal connection, but I made a local connection and it worked right away. I since changed back to ISY Portal connection method and my geofence and programs trigger correctly. While not an issue for this situation you should consider updating the ISY994 to the last release of 5.3.4. There weren't many fixes from 5.3.3 to 5.3.4, but with support ending for the ISY994 you should at least be at the current Firmware so any forum support you get will be on the "most recent" build. I echo @Javi and @DennisC comments of trying UD Mobile. You can use Geofence to call on programs to change the variable as you cross the boundary. There's a learning curve setting up the new app, but it is very customizable to fit the various needs of users. It's also being currently developed and supported by UDI, unlike Mobilinc (that hasn't been updated in several years).

@PB11 split your post out from a solved topic as you're asking about "Unmanaged" node servers. What hardware are you using? My guess would be Polisy. I believe if they are showing unmanaged they were managed by PG2 and you're logging into PG3. You either need to go back to PG2 and remove from there then install in PG3 side. Otherwise, you should be able to remove them from the IoX Admin Console and the Polyglot should update. I think @bpwwer can confirm that's an option. As for the update issue review the release notes for 3.1.19. If you've attempted the normal reboot process then try from the admin console configuration tab to force a Polisy reboot. Last ditch effort would be a full power cycle (pull the power supply). Make sure you're allowing ample time for the updates and with the Polisy getting expected beeps when you reboot it.

@giomania the eisy should auto detect the IoX service since it's on the same machine. It should be using the IP 127.0.0.1. What are the settings for your ISY when you review using the eisy PG3x dashboard? ISYs -> Edit Current ISY Note that with PG3x you should not need to setup the ISY when it is the IoX service running on the same eisy. If you have altered those settings that might be your issue. What device is at 10.10.2.20 and what is using that port? Is that something for the eisy/IoX? What are you setting a static IP on? That option has been removed from eisy because of the number of support tickets networking issues created on the ISY994. Another issue might arise if you have multiple VLAN and don't have cross traffic allowed.

Bummer. Thought it might have worked. I don't know how long it has been since the skill has been updated, but it clearly says it supports LOCKS. I'm not sure if that's the Insteon equipment you're using or z-wave locks that others use. I agree that maybe a support ticket might be best way to get attention to this. But @bmercier does check the forums now and then and might have some insight to this issue.

When you're on the ISY Portal site (my.isy.io) and on the Alexa Echo settings how are the locks added? What category do they show? You might want to select "Device with Open/Close" syntax. My thought is they're just showing as "Light" You could then make a routine to "lock" or "unlock" to control them. After you change the category on the ISY Portal you need to remove the device from Alexa and re-discover. (Sometimes easier from alexa.amazon.com, but that site isn't as helpful as it used to be.)

I don't have a Polisy to try it on, but from the comment above it seemed just put that URL in a browser and apparently there were processes to run and it would just result in having the system updated to PG3x. Nothing has been added to the wiki as far as processes so think it's just use that URL. @bpwwer do you know of anything else needed to upgrade from PG3 to PG3x on the Polisy? Important comment above though: make backups of everything before attempting to migrate PG3 -> PG3x. (I might include a suggestion to take screen shots of ALL configuration pages for node servers you are running before the migration. Couldn't hurt just for visual reference if they need to be setup again.)

I think the "differences" really only impact Node Server developers. @bpwwer would be the best to answer if there's anything impacting us, as users, between the two. But, it's probably not anything that would make one better/different than the other on the user side. It's more developer based from everything that's been posted previously. Without getting into the weeds (mostly because I don't know what the stuff means) I'll just leave it at that. But on the surface (for users) as best as I see it (currently) PG3 = PG3x PG3 runs on Polisy - able to update/upgrade to PG3x on Polisy (not a reversible update) PG3x runs on eisy natively (just like @MrBill said in the first reply) Current node server store for PG3 and PG3x are exactly the same.

When you say you "installed admin console" from my.isy.io what did you do? Or do you mean that you just added the admin console URL to your ISY Finder window? Make sure you got the "Admin Console URL" link and not just the "URL to ISY" link. The Admin Console link needs to have "desc" at the end of it. (It appears that it did in one of your shots) I'm not sure if it makes a difference, but are you using the start.jnlp that's downloaded from the wiki (via direct link to UDI's site)? Are you local to your ISY or attempting this while remote? I know I ran into an issue a few months ago, but it was a glitch with UDI's site at the time I was attempting to connect while remote. It resolved itself once their site/portal was stable again. If you log into ISY Portal does it show the ISY994 online? (since you posted in ISY994 area I'm assuming this is indeed ISY994 equipment.) Try not double clicking on the URL and single click and see if you get an option for "Admin Console (Cloud)". Lastly, what Firmware are you running?

Like this: https://wiki.universal-devices.com/index.php?title=Polisy:User_Guide#Can't_Find_Polisy or https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Can't_Find_eisy Now that you've got it working it might not be a "fair" test, but clear your Java again (selecting all 3 options). Then run start.jnlp to put the icon back on the desktop and run IoX Launcher. If it doesn't "Find" the IoX what happens if you hit "Refresh"? Usually devices aren't randomly hopping IPs unless the router reboots or multiple devices come online at nearly the same time as you rebooted the Polisy. If something randomly took the IP during a reboot of the Polisy you might have other network issues. Either way, glad you got it sorted out easily.

Probably not moving away from Java anytime soon. Problems are usually all that get reported/posted about. Don't see people posting when stuff works as designed. Yes, I believe there is hope that UD Mobile would be available on computers (it's already able to run on macOS (though think only M1 and better, but might recall somebody saying they got it on an Intel MAC). Some have been able to get it to run on Win11 with an Android emulator (I think). I've seen @Javi post that it's hopeful to get on Win11 natively, but maybe not a high priority.

There was a quick comment about that in a recent news post from UDI https://www.universal-devices.com/eisyir-flirc/ I haven't seen any posts of people performing this step, but it's an option. Here's recent discussion about it:

Sorry to take the topic off topic so much, but just had to. The claims were absurd. Back to point of OP using better methods of getting alerts. I think @MrBill's post above with the link to the variables is very helpful. @Jimini I think you could try both options to get a feel for how both work. I believe Pushover allows a trial period and then just a one time purchase for $5 and think that would cover any other devices you own and any in a "family" plan on Apple (not sure how Android does family/share purchases). @Jimini What Phone OS are you using?

I don't want to argue the point, but I'd like to know where this happens. I live in Atlanta (once, if not still, the largest local calling area in the nation) I don't have to use 11 digits. I have family in LA, they don't have to dial 11 digits. I have friends in NYC and they don't have to dial 11 digits. So if some of the most populated areas and largest local calling areas don't then what "metropolitan" area has to dial 11 digits to "call across the street"? Do you have first had experience of such or just read some random blog that might have inferred that?

Man...those were the days! When systems were simple and not overly complex! As we all incorporate more devices and systems into a single controller that ability becomes infinitely more complex. At least I've got to assume so...just from a user standpoint. (And yes, that's all I am...a USER!) I joined the ISY community shortly before 5.x branch started being released. I only had Insteon devices at the time so I viewed 5.x mostly for the Z-Wave users and never upgraded until very late. But I can recall some really brutal 5.x "beta"/"test" build releases that would be updated almost overnight. Now we have Insteon and Z-wave for IoX and PG3/PG3x for over 100 different sytems all being incorporated into IoX. Good luck getting it right the first time! I'm only suggesting/saying that because you're implying it. You're begging for a release for something to make YOUR life easier. You're expecting perfection, or at least something better than you're inferring from other posts from people that have attempted to migrate before now. However, you're ignoring the fact that many of those issues have been fixed, or are in the process of being fixed (I would expect). You aren't even getting the posts from people that have migrated without issue, or easily resolved issues that they handled on their own and never posted to the forums. As I said, it's like making positive reviews online. It's always easier to complain than complement. It's always easier to post when you have an issue (so that you can get help!) than post just to say "went smooth as silk for me". Those days are long gone. To expect such perfection (sorry..."bug free release") now would be a fallacy. As stated previously -- too many unknowns! You must be referring to information only YOU have. I don't recall seeing any posts here from UDI saying that there's no planned releases until something happens. UDI isn't known to forecast when releases will be made so assuming as much is far fetch for any user to assume something is "pending release". Again, by simply being active on the forums I've seen lots of posts of issues. I think if UDI makes a "major release" as you're implying possibly releasing "5.6.x" that any subsequent bugs that get reported will be fixed post-haste. Just like they ALWAYS have been. Most recently from January - February when there were incremental releases right away. Some within days. As the problems subsided so did the incremental releases. But yes, given the size of YOUR system I would expect there to be bumps, bugs, and issues. There's just too much involved to not expect something to not work. Your system has grown to the size it is now over a long period of time. It would be foolish to think such a major equipment and system migration would be something that you could knock out in a very short period of time. Heck, I even planned for several hours to allow me the time to completely rebuild my system if it became necessary at the time I migrated. Thankfully it didn't take anywhere near as long as that so I was super happy and excited to have made the change. Here you are, saying you got a Polisy "early on", but you never fully migrated from the ISY994 to the Polisy. That might have given you at least a step forward by going to a similar product. And honestly, near identical since Polisy and eisy run the same IoX version and now can run the same PG3x versions (as of recent update anyway). We wouldn't even need this discussion if that were the case. Again, you must have some information that isn't talked about on the forums as I've never experienced UDI to not have "fixing bugs" at the top of their list. If there are known "major" bugs that are keeping some from moving forward I would think that would indeed be at the top of the list. Does that mean that it would be rushed out in a release, maybe not. Maybe there is more that they want to add to a release and just haven't achieved that yet, but I can say from experience when major bugs have been encountered they are fixed very fast. Here's hoping for a release to meet your needs arrives soon! 🍺

I think the notifications are simply if the device (IoX) isn't registered with the Portal in some method. So it could have been fine locally and the wifi could have been fine, but there could have been something funky between the device and the portal. I would suggest opening a support ticket. Include your UUID and if you still have the time that those notifications came in perhaps it can be checked in some logs with UDI to see if something in fact was in error with your device. What device are you using? What IoX firmware are you running? Good point about possibly having a wait period. I'd include that suggestion in your support ticket. Start a support ticket here: https://www.universal-devices.com/my-tickets

As I said, you can find issues. It worked for countless others. I think there was another post (maybe yours) worried about a dry run and the process to "roll back" to the ISY994. Nobody really knows if they'll have issues until they just do it. You've got to figure, forum posts of issues are like complaints for products. Only those with issues will post (some much more than others!). Those that can help will reply. Many that don't have issues go unreported and just work as expected. I'm sure there were others that didn't post here and went straight to a support ticket. But, for the most part things work well. It will NEVER be 100% perfect. And don't expect that it will. You've been a member of the forums since 2010. So I'm sure you probably went from an early device to ISY994. Was that easy swimming? (maybe it was, but it was no were near as complicated as the systems are now.) You didn't go from ISY994 to Polisy, was that easy? Not really, but got much better as time went along. I'd say even now (3+ years after release) that it might not be smooth sailing to go to a Polisy. But being afraid to make the move is personal prerogative. Stop asking/thinking/begging/wishing that there be some miracle release that solves EVERY SINGLE issue. It's already better than December 31. Will it be better July 31st? Maybe. But why not migrate now and then fix what doesn't work and allow UDI the chance to squash even more bugs - if you end up with issues on products that others haven't had products to test the migration. You're approaching this from too much of a cautionary tale approach. Others dove in head-first to lead the way for the rest of us to have a more pleasant experience. It's probably not something that can be answered easily. It's not like UDI has a log of everybody that updated and how long certain steps took. They'd only know for limited test sessions, and even then it might not be representative because they're TEST SYSTEMS. The best case would be to ask others here...maybe PM some that you quote above as having issues to get their "real world" experience. Migration isn't something you can do in 10 minutes. It might take all weekend. Depends on the size of your system and what you're doing during the process. If you've got a ticket open that long then reply back to it to get their attention again. It isn't typical, but with all the issues being tracked it's sure a question that doesn't really have a clear issue could have gone unanswered simply because they can't say for certain and don't want to answer with something and you have a vastly different experience and complain that they said "x minutes" and it took you "y minutes". Enjoy & good luck!

The Geofence can trigger a program that could evaluate the time of day and fire or not fire as needed. It's not built into the app ability at this point. Not sure if it's on the future upgrade process, but easiest way is to trigger a program.

@johnnyt I think 5.5.9 has been fairly stable for many people. I know there are a few nagging issues here and there, but it's night and day different than initial release versions for eisy. I think somebody said it before or maybe in another post there are so many variables at play that there's probably no way to get "every bug" that might happen in a migration. Everybody's system is different. So while you might think they'll get most of what you have the likely hood of you having a device that somebody else hasn't migrated could be high and mean it would work for YOU. For my system, I was able to migrate fairly early on and have had a solid/stable system since mid-January. I've been able to work around some of the jitters in some updates because I had the time and ability to either live without or other reasons. By holding out now you're just asking for a potential/possible bigger issue when you finally do migrate. Thinking that it will go smooth sailing and then something breaks and you're in a bind worse than you would be if you just did it now. I'm not sure what the worry/concern is. Just take the plunge. It's great in the eisy pool! Speculation does nobody good. Kind of foolish to even think/push/hope/wish that something is "just around the corner" that might make everything wonderful. Sure, the next big update might fix something that is broken for somebody right now, but it could easily break something else for others. That's the nature of the beast at the moment. It's been that way since ISY5.x when Z-Wave became a much more important system to support. The way I see it from a user side that there are endless Z-Wave manufacturers that for some reason or another do just enough to be "Z-Wave Certified", but probably not do everything that the IoX/Z-Matter system can control and would therefore "break" something in an existing system that would need to be fixed. It's just the nature of the beast.

@GTench if you get that alert when trying to run “local” access be sure you clear the Java cache (selecting all three boxes in the process) then download a new start.jnlp from UDI site and it will match. https://isy.universal-devices.com/start.jnlp

@MWoods329 You've got 2 posts going on the same issue? Instead of posting in a thread that appeared resolved you should keep the help in one spot. Please use your new thread for further help/troubleshooting -

This question is probably best served by contacting UDI directly. https://www.universal-devices.com/contact-us/ If it's not a normal option then nobody here will know and would just speculate.

@pepethecow From the screenshots you've posted it looks normal. Your ISY is registered and the ISY Portal sees the device as online (the green circle on the portal page) Your HTTPS port doesn't matter when you're connecting through the portal so hopefully you're not trying to add that port to the URL it's using. For UD Mobile you just need your ISY Portal user/pass credentials and it should sync automatically. https://wiki.universal-devices.com/index.php?title=UD_Mobile#Existing_Portal_Users What version of the app are you running? Make sure it's updated to a recent production or beta version. Appears you're on an Android device. Should be close to Version 1.0.33. I might delete the account in the app and then add it back in. If you still have problems the best bet is to open a support ticket and get help directly with UDI to confirm setup in the app. https://www.universal-devices.com/my-tickets And no, ISY Portal should not require you to be a network genius. It's actually there to keep things ultra simple (and a bit more secure than port forwarding).

In the admin console. Click on the "Programs" tab. Then below that is a "Summary" tab. From there you can sort the columns by clicking on the title. click "Last Run Time" twice to sort from most recent to oldest. If you see an offending program about the time that the lights/devices turned on you can select that program, right click and then "Edit" to modify what's happening. Also, you said ALL devices turned on. Are you sure every single device did or just "a lot", "most" or "some"? If you have program issues you would like to review post the entire program by selecting the program, right click, and select "Copy to Clipboard" (should be the very last option in the menu). Then you can paste the program as TEXT into your forum post. It's easier to read and assist with any modifications by not having to retype or recreate the program. Yep, I know. I'm just saying don't change that and put the PLM on the UPS thinking it might help. Your setup is fine. Ah. Okay. I thought you meant something like you leave the Admin Console running 24/7 (it's not advisable to do that!) and it was still active and not "locked up" or something funky with the IoX access.

I know just enough to get into trouble sometimes. I don't really know the answer to that questions, but suspect others will. Offhand I would say that NO, any friendly name is not the same as how the device is broadcasting itself on your network. I don't force computers to use external DNS lookup, but leave them default to the router for DNS lookup for local access. Is that what you mean by all clients use 8.8.8.8 for DNS lookup? The router should be handling that (IMO). The eisy appears to be broadcasting as eisy.local. When IoX Launcher runs it opens a IoX Finder window. It should find the eisy and display as: Sometimes mine will jus find it by underlying IP, but most times I get it populating this way. If you window ends up with "Not Found" then hit "Refresh" and what happens? Now, since you've added it to your host file it might find it because of that, and since your on macOS other things can come into play. But on my several Win10 devices eisy comes up just fine 99-100% of the time. I suspect if you allowed the devices to rely on the router to handle DNS it would work more often for you. But, again, I'm not a network guru. Ultimately, you've got it working. For you. I don't think it would be a widely used method of resolution.