Geddy

@JBartmess welcome to the UD Forums. In updating the eisy to 6.0.x the default method of logging in on the admin console now uses your UD portal credientials (email address and password). Try using those to log in. If you want to use the local credientials then add this line to the IoX finder window: https://eisy.local:8443/desc You would then have 2 lines on the finder window. You might want to hit "save" and save the list locally in case the one you just added doesn't display in the future you can "load" that file and continue to use the local credientials without having to add the line manually. If this is your only device and you are always local to it then you can also downlad the admin.jnlp directly from the device and it. To do that use this link: http://eisy.local:8080/admin.jnlp (or replace "eisy.local" with the IP of your device). Save the admin.jnlp file locally and run it each time to access admin console directly (bypassing IoX Launcher/Finder process). I think this would always use the local credeitnals you have made.

If you had the portal on your old device there is a migration process. Please see the wiki: https://wiki.universal-devices.com/ISY_Portal_Migrate_configurations_to_a_new_ISY

@johnmsch I will often suggest people make a full backup of your programs in a text file. You can then use the text file to easily search for a device and recreate programs from that rather than memory. It's simple to make a backup for the programs. Programs Tab -> Details Right click on the root folder (usually "My Programs") Select "Copy folder to Clipboard" Open a text editor (not a word processing program/app) so it keeps any formatting basic and as text Paste in new text file NOTES: Be sure you use "COPY" function - NOT export! - this will copy all the programs in a clear "easy to read" format when you paste into your text file. Save the text file somewhere you might keep your IoX backups for future reference. Maybe make note to do this often if you tend to change/update programs throughout the year(s). This file helps remind you of the programs you have and is key in helping to repair any programs that might break if/when you replace items. Good luck with the changes!

As others have said above that you've already got eisy_ui you just probably haven't tried using it yet. And since you're on 6.0.3 it would be a good idea to at least update to 6.0.4 just to stay current and not drop behind. I believe the suggested route (according to other posts here) is that UD is suggesting that you begin running updates in eisy_ui rather than the java admin console. I don't know for sure if one is better than the other, but some have posted here that it's been suggested to them through support tickets. In a browser go to: http://eisy.local/ and use your portal credentials to log in. (Note: you don't have to have an active portal "subscription"/license, but you do need a portal account - that's been necessary from the start of eisy (and maybe later in the Polisy days). Once logged in you'll want to hit the 3 bars on the top left of the screen to open the menu and select the last item "System". Then select "Upgrade Packages" on that screen. I think it might be in a different place in 6.0.3, but it should be similar to this or at least a "settings" option in that menu that might have the "Upgrade Packages" option. Either way in 6.0.4 it's how I describe it. There have been other minor updates pushed out recently (since 6.0.3) that are good to get as UD develops eisy_ui and continue to improve other underlying systems in their more advanced days.

Yeah, that's why the wiki changed in 2022. Google finally phased out the simple password, but if users had already changed over to 2FA and the app password it has always worked that way. Nothing in that standing changed after 2022 or 2025. I've had mine setup using Gmail since I started with ISY994 in 2016+/- and aside from a few times can't recall there being a large issue with how the setup worked. The steps to setup (but also same to change) the app password are in the UD wiki, but it basically used the Google support steps to direct users where to go to setup/change the app password. But if you go the route of the support ticket please post back what troubleshooting finds and if there's a larger issue that is being addressed or might need to be corrected in the setup and ultimately in the UD wiki instructions. But since they work for some/most something else has to be the root for some accounts getting this error. What do you mean? All they did was copy/paste the UD Wiki information. The wiki has had this info (updated) since 2022 - and prior to that worked for how Gmail used to work. As for instructions about the migration they're in the wiki as well, but probably not the most easy to follow. They're simple and written for when Polisy and eisy were first released.

THIS! 100% THIS! Many will forget this step and claim it doesn't work just to find out the device was in a folder. Great reminder @paulbates!

@Ross another thing I might suggest is if you don't log in there often then you should probably reset/change the app password and make it new. What I don't understand is how can several be having this issue, but at the same time others (myself included) haven't had issues. I have even setup a daily email now just to be sure it triggers daily. Since Feb 27th it hasn't missed a beat. One thing to check is at the sending side do (did) you see recent messages in the sent? I wonder if they are being sent, but where you are sending them is blocking them (for some reason). I send from @gmail.com to @outlook.com. I know this doesn't mean anything if there's an error on send, but wondering if some messages are indeed being sent. Perhaps @Michel Kohanim is right that something in Gmail has changed again and old ISY994 firmware isn't able to meet the change. Not sure if UD changed how it's handled in the settings for Polisy/eisy since it seems to work just fine there with the same settings I've had since the ISY994 days. I'm guessing there is some underlying safety/security "handshake" stuff going on. Perhaps this is another indication that the Notification Plugin might be the best option for alerts/notifications going forward. Certainly for eisy users.

UD had to change how the "default" operated. I think that broke it for older ISY firmware versions. I know somebody reported recently that 4.9 had a working default server. I can't confirm it will work for everybody though. My ISY994 was 5.3.4 before I moved to Polisy then eisy. Perhaps your version is one that's broken when you try the "default" option. What is your timeout set to? (when using the gmail server settings) Be sure it's over 5,000. Try 10,000 and see if you still have an issue. Have you actively used the google account you're trying to send from in the last 24 months? Other than just auto sending emails from it. Google does require that you log in (I think once a year) to keep the account active. It's possible some accounts are "throw away" accounts and you're not actually logging into them and Google might flag them as inactive and suddenly blocking the ability to send. If the settings worked on the ISY994 or Polisy (whatever you migrated from) they should work on eisy. The wki settings still work (as of last attempt) if you need a refresher.

@shawnv not sure of a limit, but if you're not able to get more recognized you can install the plugin into another slot and see if that will recognize the other devices. That might be a workaround if there is a limit. Perhaps @Jimbo.Automates can chime in to advise if there's a limit.

What device are you using and what is your IoX firmware version? As this is not widely reported as an issue doubtful there's a "resolution". My notifications continue to work as normal. Tests and random program runs trigger email notifications just fine.

Yes. Thanks. Please post what support steps are completed to correct this issue, if you can. This is strange that it's unable to be deleted. How many customizations do you have? Since you mentioned you migrated from ISY994 to eisy would you also try clicking/opening each one (slowly). Then hitting save. Just close IoX Admin Console (don't reboot the device). Then log back into IoX Admin Console and try deleting again. It's a long shot, but I know that Network Resources needed to be opened and saved in the migration steps. I wonder if it might help/work on the customizations as well.

@larryllix I'm not sure what links you've been following in the past, but I'm fairly certain the wiki links haven't changed in ages (mostly because the old pages the links to start.jnlp haven't been updated in years - in fact I just looked it up - wiki link hasn't changed since 2018.). But more than that UD has always hade the "My ISY" link on the top of their home page that links to start.jnlp. I don't think that's changed in at least 5 years and probably even more than that. At least since they changed to the IoX Launcher method (using start.jnlp rather than admin.jnlp). Fairly certain this has been the link for YEARS https://isy.universal-devices.com/start.jnlp But what's funny is the link @dbwarner5 suggested (http://192.168.68.76:8080/admin.jnlp) has been around since the ISY994 days. It's been the method since browser quit supporting the java web method. And I'll echo what @apostolakisl says...if it wasn't for Java updates and having to clear the Java cache and reloading start.jnlp the java admin console method has been flawless for my use case for as long as I've been an ISY user. I can count perhaps ONE time that UD had to update the start.jnlp file due to an error that somehow got introduced. But that was when a "not found" issue popped up and they had to change the code in the start.jnlp file. That issue lead to my usual suggestion of downloading a fresh start.jnlp each time it was needed. Just in case it happened again, but there haven't been reports of really needing to do that recently.

@leadfoot interesting. I just created a new customization and reloaded IoX Java Admin Console and it deleted just fine. It's an outside shot, but I might clear java cache (be sure to check all 3 boxes) and download a fresh start.jnlp file (delete any old start.jnlp or admin.jnlp files). I wonder if it's a random cache/visualization bug - that has happened in the past. What IoX version are you currently running? (Please give actual number, not just "latest/current"). What Computer OS are you using? Make sure you are logged out of any PG3 or eisy_ui web interfaces while in Java Admin Console.

I might have suggested migrating the portal license from eisy1 to eisy2 then getting a new license for eisy1 when you set it up at the other property. I'm not sure if this would have migrated the plugin licenses (I think it does, but at least did in the past), but would have migrated all the Alexa controls. https://wiki.universal-devices.com/ISY_Portal_Migrate_configurations_to_a_new_ISY The rest looks fine. I'm sure it's fairly simple with the way backups are used now. The only risky thing would be PLM related, but that should be handled with the IoX restore.

@BCreekDave and @Ross no issues running a test message or triggering a program notification using Gmail settings that I've had for many, many years. I don't have a regularly scheduled notification setup so just based on testing now things worked as expected. Make sure you are not sending a lot of messages (not sure what would be "a lot") perhaps Gmail is blocking too many attempts to send notifications. Be sure you've setup in accordance to the wiki information: https://wiki.universal-devices.com/ISY994:Configure_Mail_Server_Settings#Configuring_for_Use_with_gmail Be sure that your timeout setting is high.

I'm not an Android user so can't help specifically. My guess is the settings have changed since the wiki was written. Perhaps other Android users can chime in or @Javi might have an update to this. So people know how to help what version Android are you running? What IoX version are you running (please give actual version number - check here: https://eisy.local:8443/WEB/sysconfig.txt and look for ISY-6.0.4_x )

@JSchumann the wiki lists what sounds are available: https://wiki.universal-devices.com/UD_Mobile#Sounds

@jkraus try a power cycle on the device. Unplug the device. While unplugged I would remove and reinsert the dongle to confirm good connection in the USB port. Plug the device back in. Wait 3-5 minutes for it to fully boot. Then log back into what you're using to see "not responding". Or you can try "reboot" from the web ui (http://polisy.local/system/upgrade - or replace "polisy.local" with the ip address of your system). If you're running 6.0.4 it's at the bottom of the screen). If you are running java admin console try the reboot button on the configuration tab. If a power cycle does not work then please open a support ticket with UD to get further assistance. https://www.universal-devices.com/my-tickets

Where do you see this? I went to UD's site and the price is showing $152. https://www.universal-devices.com/product/zmatter-usb/ I don't see anything on thier store that would be close to $800. https://www.universal-devices.com/store/

@GreyFox there is probably a different value stored in the .state files that UD uses in the temp area on the computer. Check this part of the wiki: https://wiki.universal-devices.com/Main_Page#Admin_Console_Minimized/Invisible_and_Cannot_be_Restored I think @Guy Lavoie and @dbwarner5 have offered valid suggestions for making them work similarly. If both computers are always local to the system then I would probably lean more toward the direct login as @dbwarner5 outlines. I've got Win10 and Win11 laptops and use admin console on my local eisy, but also a remote eisy system sometimes. It gets tricky if/when I'm traveling to the remote location as it will find it, but still list the home device (sometimes). There seems to be a real disconnect in IoX Finder window if/when the computer is not on the same network as it will keep some of the cache info, but other times it is blank and/or just finds/lits the local system. I suspect the valuse stored in one of the UD*.state files (probably: udi_launcher.state) is what keeps the addresses stored locally. Since it's in a "temp" file that Windows controls there's no telling when they'll get wiped out. Saving the list that includes all systems that I might randomly connect to is simple to load if/when the finder comes up without all the options. Perhaps the one thing I do look forward to with eisy_ui is the lack of unpredectibility of how you'll log in. I just hope remote access is as easy as it has been wirh the java admin console.

@JDeRose If you have an eisy then I would just use that device to learn about the portal and UD mobile options. For the ISY994 I would suggest just using Mobilinc and using the local connection setting. If you want to open a port on your router you can do that and still access the device with Moblinc, but it's not as "secure" (since you are opening up your network to risk by having a valid port open. I might suggest using a non-typical port number). The ISY994 can work with UD Mobile, but only with 5.x firmware. Again, I'd say probably just use the local connection. If not able to add the portal to the ISY994 you can still use the local connection option. I haven't taken the time to learn all about the UD Mobile options as I don't really need an app. I still use Moblinc with the eisy since it controls nearly everything I have (I'm basically 99% Insteon devices). It's just more comfortable for me and easy to use what I've had for about 10 years now rather than taking time to set up UD Mobile when it's still changing (and randomly breaking stuff) as eisy and IoX continue to evolve.

I believe UD made an announcement soon after the ISY994 was no longer supported that the portal would cost more for the ISY994 due to underlying security issues that the ISY994 couldn't work with at the time. I know they raised the price for people keeping a portal account with the ISY994. So marginal additional revenue stream might be overcome by having to "support" the connection from unsupported devices. I think it was even said that the portal couldn't be added to ISY994 devices at one point. So I'm not sure even if it wasn't registered to somebody else if you would be able to add it at this point. Perhaps you could, but UD really doesn't want to keep having to support them with the portal connection. Since the ISY994 works so well off line there's little gained by adding the portal at this point. What is your desired outcome by having the portal connection?

@Techowl the instructions in the wiki for setting up the gmail account still work as of somebody using them to set up within the last few weeks. https://wiki.universal-devices.com/ISY994:Configure_Mail_Server_Settings#Configuring_gmail_Account One thing to try is change the time out to 10,000. You might also want to add something in the "From" portion. Then when you try a test message make sure you have a recipient selected for it to send the test to. If you're only using x10 devices and you've had it working on 4.9 as long as you have then I agree with you that I wouldn't want to change the firmware. There were "big" changes in the ISY994 from 4.x to 5.x that would probably require some adjusting. As for using the "default" in 4.9. That was changed due to additional security steps added on the UD side in a 5.x update due to server settings to block unrelated parties from using UD servers to send messages. It was behind the scenes (as best as I recall) and was not implemented in older firmware versions so you more than likely would have an issue using the default server.

Is/was your spoken really “turn off all the lights”? It would appear (to me) Alexa+ thinks it “got smart” and was controlling anything you had in the system as a “light” and turned them off within Alexa(+) rather than the program/scene you have in IoX. I would suggest making the spoken a simple word/phrase. That way Alexa+ knows you want to control something from IoX. I think some have just a “goodnight” scene or program that is run. If you just said, “Alexa, turn on bedtime” and your bedtime spoken ran a program or turned the scene off it would work as you expect. But by using the command “Alexa, turn off all lights” it’s looking for smart devices that are lights and turning them all off. It’s goofy, but the Alexa programmers are trying to be “smart” by trying to control things within their system rather than using linked skills. The proof is basically that you used UD Mobile and it worked as expected. Meaning Alexa+ wasn’t using the skill at all.

Click the label next to the setting you are changing. That will update the setting. This is a change that UD introduced in 5.x many years ago and is discussed here many times. Don’t use the “write changes” at the bottom of the screen (for these changes). Also, some have noticed that if you set a specific on rate or other settings I might not show on that device the next time admin console loads as there seems to be a display issue. No known workaround known for that issue.