Geddy

That's interesting. Guess they still have a few display issues happening. Are you running on a Polisy or eisy?

What browser are you using? It's possible a browser is blocking the redirect to Ring. When I click on the authenticate button it directly goes to the site for oauth.ring. I'm using Chrome with no blocking on the browser or router. I would attempt with a different browser first to see if that had a different result. If you're sending logs it would be best only for the ring plugin log (NOT the PG3 log). I would suggest you open a support ticket and possibly reference this thread and include a plugin log file. Before pulling the log try this: Switch the log status to debug then press "restart" for the plugin. Allow a few minutes for it to completely start then click on Authenticate. After about 5-10 minutes download the log package for the plugin and attach it to your ticket Start a support ticket here: https://www.universal-devices.com/my-tickets

Typically it's only one per device found automatically if local. There was a period of time that two popped up and that messed a lot of people up, but that's been a few years. For the more current time I only recall having 1 come up per device. You can add a second and it will remain until a period of time (usually with a Java update or a temp file dump). Since the IoX Finder window information is kept in the UD*.state file in the temp folder it's not always a "fixed"/saved list. That's why many will suggest saving the finder list for the time(s) it does go away and you had a specific system added to your finder list. It is easier to load a saved list than trying to remember what address(es) you had saved previously. I think with the introduction of eisy_ui and requiring the UD Portal credentials has become the default found when IoX Launcher is first run. I have two entries as one uses the UD Portal creds and the other is the local (unit specific) creds. Thankfully it now shows which one to enter when selected on IoX Finder.

@raymondjiii This is similar to an issue that was in another post over a month ago. Make sure you've updated recently. Since UD isn't posting release announcements I'm not sure if they've updated again, but the last time I updated it installed 6.0.4_1 You can find what you're running on a web browser: https://eisy.local:8443/WEB/sysconfig.txt (click advanced and continue if you get a security/connection warning). Also, you can apparently see on eisy_ui if there are updates available (I'm not sure as I haven't used that ui much). However, the fix in the past post was simply a power cycle of the eisy. https://forum.universal-devices.com/topic/45990-trouble-with-new-device/#comment-399971

If you haven't removed and reset yet this part gets a little tricky. It might, but might not have any impact on programs. I would suggest the following two steps if you haven't removed them yet: Make a text copy of ALL programs On the programs tab right click on the root "my programs" folder. Select the last item of "Copy Folder to Clipboard" Paste all programs into a text editor (i.e. Notepad on Windows) https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Tree_View On the Programs tab you can (again) right click on the root folder and use the "Find/Replace" option. You can then search by device and make note of each program that device is referenced. https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Tree_View#Find/Replace Sometimes when you remove items and add them back exactly as you have them they might not mess up programs. Just don't do anything in IoX while you're doing this process. Don't close Admin Console, don't click on a different tab, just remove the device from Admin Console, Factory Reset it (at the switch), Link in Admin Console. Use the exact same name for the device. It could be that it will re-populate in the programs, but having the text copy and knowing what programs it is referenced in will help a TON by being able to go back and repair any broken programs. There is no way to backup the programs then re-import them so having a text copy of ALL programs is key to try to fix if stuff does go into a broken state of missing device in programs.

@raymondjiii usually the "name" is what is the root or actually one under the root when in admin console. You can change the folder name and then clear java cache and run start.jnlp again and it should change the name. I'm not sure why you have different entries for the same device, but it explains why on a newly installed (computer) they would all show the root. Perhaps you changed the name at some point and the cache or .state files that UD use still have the old name. I have my root as "eisy" then the folder just under that has a personalized name. When I open the IoX Finder window it shows just the second folder name (the personalized folder name). I only have one system though.

@DennisC thanks for the info. Maybe it's progressed far enough to be reliable. Too many moving parts to keep up when things are moving this quickly. I know it's the ultimate goal to have eisy.ui replace the Java admin console. I've just experienced enough issues with the web ui to not find it reliable for my comfort level. Maybe someday...but I've not had issues running admin console and updates from there so works for me. Currently every time I log into eisy.ui I have to refresh the browser (Chrome) because it just goes to a blank page. It's a minor annoyance, but that's the unreliability that is just enough not to want to use such an interface. I guess more have issues with Java and admin console so UD is finally (after many, many years) going to a web ui, but the growing pains (for me) with that system outweigh the reliability I've had with the Java interface. By a long shot! I'm with you! There was debate several years ago about allowing automatic updates when the device reboots. I was told then, and numerous times since that UD would not implement "automatic updates". However then @bmercier indicated there was indeed an automatic update after 6.0.x came out due to an underlying issue that required an update of an apparent "minor" part. I would hazard a guess that something in 6.0 triggered the auto update to the current 6.0.4_1. The issue remains that an unexpected update could crash somebody's system. If they were away from home it could be days/weeks/months before they returned to get the system working again. That's the underlying concern that UD addressed in the past by not having an automated update process. Sadly, I think the error that was caused recently was an unavoidable situation that forced an automated update somewhere, but even then that's seeming causing issues for some users. I would suggest opening a support ticket to let them know of the issues you faced. Even though you've fixed it on your own for now maybe there was something they could review with you to see what happened to cause a failure. This is the time that when issues are experienced during an update that tickets are best for both UD and the users as a whole to potentially fix what could break everybody's systems.

@mullercentral not sure if you were still having issues when you posted this as you had several posts about this time that seemed to indicate you had a successful update. I just ran the 6.0.4_1 update (coming from 6.0.3_3). The last few times I have updated I just pay attention to the alerts on UD Mobile. It will tell you that the system has been updated and should be rebooted. I run 100% of the update process through Admin Console (the trusted Java access process). In the past there would also be an alert on the admin console, but I think that's gone away as of late...at least I haven't seen it. But once the UD Mobile app sends a notification to the phone (iPhone) I probably wait another 5 minutes then press the reboot button in admin console. Then after a bit of time UD Mobile will say PG3 is stopping and system rebooting then I get some alerts that it's come back up. I wait another few minutes then clear java cache, download a fresh start.jnlp and run that to access admin console. All seems well. Every now and then another reboot might be needed, but it's not been a common occurrence. I think somebody posted recently that the updates can sometimes take a while, but certainly not hours. This seemed to be a very minor update from 6.0.3_3. While I didn't time it seemed to be less than 5 minutes. I was busy doing other things while it ran. Since eisy.ui is still being developed I have been cautious to try to update from that side. I rely more on the tried (and true) admin console process to update the device. Until UD publishes something that says different that's the way I'll continue to update. One thing I wouldn't suggest is just pulling power. Either attempt a reboot in admin console or press and hold the power button to force a shutdown of the device.

@PAstrachan first, in the future to post a program to the forums please right click the program then select the last option of "COPY to Clipboard" then paste as text to your post. This way it is able to be edited by people trying to help. Is the external plug an Insteon device? It is a wired plug or a plugin module? How close is it to another wireline product or a dual band device? It could be that it's not getting a strong enough signal and Insteon communication is lost. You should open Even Viewer and set it to level 3 and turn the switch on a few times and see if the external plug respond with the program command. Additionally, you might want to an an "OR" statement and add "Control Pathlights is On" - this will then add to the "IF" line and show as "Pathlights is switched On". This indicates a physical control of the item for Pathlights. If it is a switch (or dimmer) then it will be "controlled" when you physically switch it. Even though the device status will go to "On" the physical process of turning the device on would trigger this program and then the "OR" would run "True" if something else turned the device on (meaning the status changed to "On") or if you physically turned the switch on (meaning "switched ON". If the off side is not working you might want to create a different program to control the off process rather than just being the else of this program.

I think @paulbates is right that the switches need to be reset. Look up the proper way to reset the switch in the Insteon "manual". What you're describing sound like a direct link has been made for "Switch B" to control "A". Might be odd that B doesn't turn both on, but turns both off. Since the link isn't in the IoX system, but direct connection with the devices resetting them should work. I would remove the devices from IoX, factory reset them, then add them back to IoX. When you add them back to IoX be sure to select the option to remove existing links (even though you factory reset them this is an additional step that the IoX should attempt to remove any links i the device as it adds it to IoX. If that doesn't work then could be a wiring situation.

This is because your program is using "switched" (the text), but the program us using control (or controls, I forget and not able to log into admin console currently). With "control" used that is changed to "switched" in the program and is looking for that physical control of a device. So by using admin console or an app it is not "controlling" or physically switching the device. So has proabbly always failed if using an app. I don't think there is a status of "fast off" so not sure if that would work instead and not rely on the physical operation of a device. Some good options above for how to make this work with an app controlling the situation.

Will you please provide more information? What firmware did you upgrade to? (give actual number, if known) Open this page in a browser: https://eisy.local:8443/WEB/sysconfig.txt (Click "Advanced" and "Proceed..." if you get any warnings) What versions do you see for: udx iox eisyui How are you trying to log in? eisy-ui admin console If you're trying to log into admin console with the IoX Launcher you'll need to manually add the local credentials address. Try adding "https://eisy.local:8443/desc" then using your previous local user/pass combo to login. If your IoX window shows the local IP without a port then you will need to use the email and password that it used to log into the UD Portal site (https://my.isy.io). If you're having issues with the web UI be sure to perform a page refresh and/or close the browser then open it again and hit refresh (or even hard refresh - varies depending on computer OS and browser).

@johnnyt thanks for the info/update. Agreed would be bad to find this out if relying on a restore to fix things. Hopefully resolved quickly. If you get any updates please update here.

@Brian H is right. However, If you used the start.jnlp you can delete that specific file (be sure you leave the IoX Launcher icon on the desktop). I’m not so certain about the admin.jnlp as I haven’t used it in a long time. Did it put an icon on your desktop to connect to the admin console? start.jnlp adds the IoX Launcher to the desktop. That is then the applet used to launch into admin console. admin.jnlp might not add an icon/applet to use in the future and the admin.jnlp file might be the only way to open to the admin console. If memory serves the admin.jnlp goes directly to a login screen. Meaning that file will be required each time you want/need admin console access. You can delete it, but remember you will need to “download”/get it again when you want to access the admin console for altering the ISY994 settings. If you don’t want it on the desktop or in the download folder I would suggest you move the admin.jnlp to another folder on the hard drive (I have an ISY folder in the root of the hard drive that keeps start.jnlp, finder addresses, and backups). Lastly, you’ll need to remember on some Java updates it breaks the connection with IoX Launcher and you’ll need to go through the clear Java cache and download/run one of the .jnlp files to gain access to the system again.

@Bill S glad you got things sorted out. The post I mentioned is in the ISY994 Z-wave area. Specifically this post. The part you would have looked for is: The issue is 5.0.16C was the last to support the 300 series boards. The later versions supported the 500 series and there was enough different that would cause issues in addition to the issues you experienced when trying to run 5.3.4. Lastly, make sure when you're next in Admin Console that you check the Help -> About and confirm the firmware and UI versions match. To make sure they match you need to clear the java cache (be sure to check all 3 boxes in this process!). In the image I posted above your versions DID NOT match. While it might not make a huge difference it can cause programs not to show up and/or have items missing. So it's always been important that UI and Firmware versions match. Usually, it's best when you clear the cache to also download a fresh start.jnlp from the UD site (and clicking "My ISY" on the top right of the front page) or getting an admin.jnlp file directly from the ISY994 (http://ip.of.isy/web/admin.jnlp - be sure to replace "ip.of.isy" with the actual ip address of your device). The difference between start.jnlp and admin.jnlp is not important in your case as you will not be updating the ISY994 beyond where you are currently. It might be easier for you just to get the admin.jnlp and always use that applet to open admin console. Good luck and hope it continues to work well!

My understanding from a while ago (maybe 6 months or more) is that UD did not (at least at that time) have anything that would auto update and did not plan to have anything “auto update”. If your system is updating then you need to open a support ticket to see what is happening for your system. https://www.universal-devices.com/my-tickets UD Has not posted updates for minor releases. When so many things are getting little updates at random times it is not as easy for them to post updates. Sadly, many don’t know there is an update until they randomly run the update packages process then look at the sysconfig file to see what changed. I, as well as many, would like to see release noted BEFORE I update, but know that’s challenging when there are so many moving pieces. It would be best served to contact UD through their site to see what is updated.

@btreinders For future reference posting programs please right click the program and select "Copy to Clipboard" then you can post as text in your reply. It's helpful for anybody trying to support your program as they can edit and change things a lot easier. Rather than describing what to change and where to put it. The "Copy to clipboard" option copies the TEXT of the program and makes it easy to post in the forums and thus easy to edit as well as makes your situation searchable in case others have similar issues in the future.

@Bill S as @Techman suggests please clear your java cache. Your images show your Firmware and UI do not match DO NOT upgrade to 5.3.4 unless your system meets the requirements for that. Since you're running Z-Wave and your device is old (you claim from 2001) then you probably have the old Z-wave board in it (unless you updated it somewhere along the way). You can find on the forums how to determine which board you have. I think it's in a post from @lilyoyo1 . I'm not sure why/how you have a backup with 5.3.4 in the name when your firmware is 5.0.16. Did you have a different device at one time in the past that might have been a higher firmware than the device you're using now? In the future please post images inline and not in a document file. Sometimes people will not download such files. Images are best used when posted directly in the message (as the image above). Having to download a file then open and review it takes time and puts unnecessary files on other user computers.

@ccclapp seeing that it's been this way for YEARS and isn't specific to eisy. Your question is probably better handled through a support ticket with UD for further diagnosis and review. I don't alter ramp rates once I've set them so I don't really need to go back and see what a ramp rate or "on level" is. My expectation is this is automation. I set up my automation and slightly tinker when I first set it up. Once I had it set the way that works best for my family I don't change it. I might tweak a few things over the years as our patterns change, but I don't go back and try to see if a ramp rate is "x" that I want it to be "x+y" different now. I just set it to a different value and see how that works.

I might suggest running update again. I'm not sure if UD is using different IoX versions for eisy or Polisy, but you might want to run the upgrade packages again to see if it will update IoX to 6.0.3_3. If it doesn't update then you should open a support ticket with UD to see what might be causing the socket issue. More than likely a network issue and or computer running 3rd party firewall or anti-virus is causing the connection with the Polisy to be dropped. Do you have a ton of devices and/or programs? I have probably less than 100 devices and not many programs, but doesn't take long to get into the system and be able to select different tabs. Although, I must have more patience than others as I don't need it to be instant. I've never timed it, but I guess with larger systems and lots of programs it might slow down. Have you attempted to adjust the memory setting in Java to try to speed things up? https://wiki.universal-devices.com/Main_Page#Admin_Console_is_very_slow_or_hangs I would suggest if your system has a lot of memory to use 1024 or 2048 in place of 512. Sometimes it helps to set the max and min values. You can Google how to do that if you aren't sure. Either way, I wouldn't encourage admin console to be left open 24/7. Especially if you're on a laptop or wireless connection.

This means things are correct. It's not an issue. But you can post in UD Mobile area or open a support ticket just to get UD to confirm this. I've synced many times and not get an alert about unused items. I'm not sure what has triggered that in the past, but if the system isn't changing then I wouldn't expect this to be an issue. Usually mine was when I would sync my phone then sync my ipad after making small adjustments. Edit: Split your post out from another thread to be able to focus on resolving different issues.

Also note that there has been an issue since 5.x days that the custom settings do not show on the device once you've closed admin console and return to it. So you have to go on faith that the settings are written when you click on the item label as @gdntx outlines above. I'm not sure about the new i3 items, but I know older devices if you set a ramp rate and then come back to the device or the next time admin console is opened that ramp rate does not display.

Please post a screen shot of what you are seeing when it says "not found". Can't help you in the macOS world. I don't have any experience there other than what I've read from others. Be sure you've reviewed this post: https://forum.universal-devices.com/topic/44943-admin-console-not-working-on-mac/ I'm guessing you have since you seem to have IoX Finder window showing so at least you're able to run IoX Launcher app. Since the eisy is hard wired to the new router it shouldn't matter what the DHCP table is. eisy, by default, is set to auto connect to the DHCP (thankfully, that was a change UD made since the isy994 so users could not hard code a static IP on the device). So changing routers with different DHCP should not impact the eisy connectivity these days. If you've had a support ticket with UD for this issue and it has not been resolved I would go back to that ticket and get further assistance. For us (other users) to randomly suggest things might not be as helpful as the information provided directly from UD. I'm not sure what pressing the power button to reset or to turn wifi on/off has done to the state of the eisy, but you might be in a state that it's not ready to work correctly. I would perform a power cycle and allow it to fully boot before trying to connect.

Does it happen on loading admin console or if you leave admin console open for an extended period of time? AC is not intended to be left open 24/7 and it has often been suggested (by other users) to close admin console when not in use. Unless there is a reason to have it open (for troubleshooting) then it's best to only run when adjustments are needed. If you are needing to reboot often then you might have other issues that should be addresses. It's probable that you should open a support ticket with UD to see if you're having system issues they can help troubleshoot more than users randomly suggesting things on the forums. No, I'm not having any issues, but again I don't open admin console often and haven't rebooted the device since 6.0.3_3 was installed back on December 5th (for me). Try this page: https://eisy.local:8443/WEB/sysconfig.txt What version of IoX does it show? (please give actual and full numbers shown)

@kmosmen You potentially have a couple of issues. With the Orbi 770 being a mesh system it could be blocking some communication. First please clear Java cache (be sure to check all three boxes in this process) and delete any UD*.state files you might have Information about .state files found in wiki here: https://wiki.universal-devices.com/Main_Page#Admin_Console_Minimized/Invisible_and_Cannot_be_Restored Then download a fresh start.jnlp from the UD site and clicking on "My ISY" on the top right. If adding the address manually be sure to add the port and "/desc" to the end of the IP address. Information can be found in the wiki how to manually add the eisy to the IoX Finder window: https://wiki.universal-devices.com/Eisy:User_Guide#Can't_Find_eisy The above process clears Java cache, but also removes any stored values that IoX Launcher might have for your system so it forces it to try to find the system at the new IP (more than likely) with the new home router system. If still having issues and if you can connect multiple devices to the same satellite then connect your computer to the same device the eisy is connected to (hopefully both with a wired connection). If the eisy is using wifi connection do you have a way to attempt to connect it with a wire during this time for testing?