lhranch

Oh! Genius! Thank you!

I'm confused by both these responses. My standard method of maintaining the eisy (and the subject of my password complaint) is the Admin Console. There aren't any URLs involved in that process, so I'm not sure how to apply this advice. If I pop the URLs offered above into a browser, I get varied results. Using either https or http to the name of the eisy (with appropriate ports 8080 or 8443), I get a blank page. If I add /desc onto either of those, I get the same config file both ways, so I know the ports are working OK. But neither case requires a password. If I simply browse to the name of the eisy, http or https, no port specified, I get the new login window regardless, which does require a name and password, but I haven't set it up to be useful yet and might not for a while. I'm assuming this is the interface Techman suggests I can bypass or augment. But in that case, I am unsure how to interpret the shorthand instruction, "add the attached URL entry to the admin login."

I didn't get any completion popup at all, which was the reason for my post. I rebooted the eisy and cleared cache, and I haven't run into anything yet that isn't working. Thanks for your advice. I'm not happy to have to use the Portal login info (which has a strong PW) instead of the weaker local credentials I used to type in every time I needed to fix something, especially since Java doesn't interface with any of my PW managers OR honor the Keyboard Shortcuts / Text Replacements feature of MacOS. Is there any way (SSH, whatever) to set up an alternate (local) user ID/PW I can use for frequent logins? Does this imply that I will not be able to login to the admin console during an Internet outage because I cannot reach the portal?

I started the v6 upgrade (with admin console Upgrade Packages) over two hours ago. I never got any acknowledgement that it completed, but all the checks I know how to perform seem to indicate it may have. Checking https://eisy.local:8443/WEB/sysconfig.txt says: FreeBSD eisy 14.3-RELEASE-p3 FreeBSD 14.3-RELEASE-p3 #4 releng/14.3-n271444-30ad842dd970-dirty: Sat Sep 20 23:18:26 PDT 2025 root@bsdev143.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64 *** Package Information *** ************ UDX ************ udx-4.0.4 Name : udx Version : 4.0.4 Installed on : Sat Oct 18 14:06:04 2025 MSTWhen I call up https://eisy.local:8443 in a browser, I get a login that responds to my portal ID, and an invitation to add stuff to a blank page. When I SSH into the unit, it has reset the admin password to the default. The unit still responds properly to manual device and scene commands from my iPhone MobiLinc Pro app (won't try the admin console as it hasn't officially announced completing the update). How do I know if everything is cool despite the lack of completion dialog?

Last night I tried the admin console's own instructions first, and they failed entirely. Then I tried the instructions with the 10-second push. I was a bit disturbed when the switch's load didn't cycle, but when I returned to the console there was a window saying it had seen that device raise its hand and would configure it as soon as I clicked Finish. It completed successfully. If I can remember how, I should lodge a bug against the faulty instructions in the console itself. Thanks for the help.

In a (now closed) thread called "Unknown Address," the OP is referred to the page https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Adding_a_Device#Adding_by_Linking_Method for the proper procedure to add a device whose address label is unreadable or obscured. Unfortunately, this page provides conflicting information. The text says to choose one of the three linking options, then press the set button on the device for 10 seconds until the load blinks, then return and click Finish. The image (and the instructions you actually get from the Admin Console) says to press the set button for 3-5 seconds first, then return and choose one of the three linking options, then click Finish. One or the other of these ought to be corrected. Which one is correct?

I'm not sure whether this is an eisy feature or an Insteon native feature, but I'll try here first. I have a 2477D Dual Band dimmer. It's in a remote location where it almost always responds well... but not always, due to distance, or noise interference, or some other reason. I have a periodic program that queries (via a scene) a half dozen of these very remote devices (other buildings, outdoor installations) and then sends me a notification if any of them are not responding (indicating that there's likely a GFCI breaker needing to be reset so other equipment in that location has power). It works very reliably except for devices at this one location, which fail to respond maybe one out of 10-20 times. Now, the question: While tooling around inside the Admin Console, I have occasionally come across a setting that allows me to increase the retries for failed attempts. I'd like to increase it in this case. But I don't remember exactly where it is or how to get there. When I go looking for it, both on the device screen and on the scene's screen, I can't call it up. Can someone tell me if there is a way to do what I want to do here, and how to access it? Thanks.

Dunno what to tell you. I posted the entire contents of that directory in transaction 3. It's there for anybody to see. Again, maybe it has something to do with me not using the portal services, I really don't know.

The tech at UD identified the relevant file as /var/isy/FILES/CONF/0.UCF . It's binary, so changing it isn't trivial, but it's a very short file and it's doable. I have my secure eisy port set to the value I want now. Thanks, all.

Perhaps it is significant that I do NOT use the portal facility at all? My operation and administration are completely local.

I opened one last night. UDI seems less than eager to accommodate. "...this is not "seemingly arbitrary restriction". This was done in order to reduce our support issues."

So did I, you will notice I am operating from root. I also tried precisely the syntax you used from admin, but it didn't change my results.

OK, well, I have no response to this. My machine clearly doesn't have this file, I'm not imagining it. Perhaps you have some add-on that I don't -- mine is straight factory configuration.

Ooh! I was totally up for this! However: Any suggestions?

Yup, dialog box, popup, potato, potahto. October 2023 also sounds like about the same time frame I roached my launcher and had to download a new copy. The images in 42176 are exactly what I was seeing.

In General / Temporary Internet Files / View, I deleted everything under Applications, Resources, and Deleted Applications. Then in Settings, I punched the Delete Files button, clicked all three boxes, and hit OK. Then I launched my copy of start.jnlp, and got the same error. I finally got rid of the message by doing all of the above over again, then deleting my copy of start.jnlp, re-downloading it, and then launching it. Thanks for putting me on the right track.

Every time I start up ISY Launch, the IoX finder scans my network for ISYs, finds them, then puts up a dialog box saying "Error, not found." I think this is because at one point no ISYs were coming up for some reason, so I typed in the DNS name of the ISY and managed to type it in wrong. Now it looks for that bad name every time it comes up. There's no way to remove an ISY entry that never comes up. I haven't been able to figure out where the names are stored so that I could patch it out, and clearing the Java cache doesn't do the trick. Does anybody know how I can remove that bad name from the list of ISYs the finder scans for every time it starts?

I looked at the content of the thread ISY994 to EISY .. go with USB PLM or stay old Serial PLM ... ? to see what people thought, and I'm not sure anybody really answered the question I thought OP was asking. So let me ask it a little differently. I also recently moved from ISY to eisy, and just afterward, had my serial PLM go belly up. I replaced it with a new-in-box serial PLM that I had on stock specifically due to my experiences with the fragility of PLMs... but now I need to restock a new spare. I have no preference as to whether the new PLM is serial or USB, now that I could run either. Given that I am entirely free to choose between both architectures, is there any advantage in reliability, efficiency. or (most important) demonstrated longevity between them that would make me prefer one over the other? Comm distance is not a factor for me.

Problem turned out to be the PLM. UD clued me in to the existence of the "Diagnostics / PLM Info/Status" function, which reported zeroes. Replaced the PLM with my new-in-box unit, which also showed zeroes at first... but shortly woke up and began throwing links around. I ran the Restore PLM function and all seems to be fine now. I would assume the cable subsystem on the old PLM failed, as its connection to the other Insteon devices was still good (as shown by the triple tap test). US also clued me in that Reboot and Restart are two different buttons, and that I needed to be using Reboot after a software upgrade, which I wasn't. Thanks for your help, everybody!

When I had the ISY, I could set the network port preferences as I wished. Now with the new ISY, the ports are baked in and grayed out. Unfortunately, the port chosen by the developers for secure control communication -- 8443 -- is already assigned to the CalDAV protocol, which I also serve inside my LAN. That means that when my router sees CalDAV or EISY traffic arriving from outside our LAN, it has no way of telling to which of two different devices to forward it. Is there any way around the "locked" ports that would allow me to choose the old port I used to use, that worked?

Good suggestion. Unfortunately, nothing changed. Same behavior, same error messages. I have a ticket in now.

Verified that Insteon support was checked, rebooted (not the first time for this problem), re-entered the admin console, pulled up level 3 events (there were some existing lines for housekeeping after the reboot) and sent commands to my closest device. Same results as before, except that the first error message had more details in it: As I mentioned, the eisy was operating very satisfactorily for three or four weeks before puking in this fashion. Guess I'll research how to "submit a ticket to the UDI team." I'm pretty certain this thing still had to be under warranty.

I may have misunderstood your testing instructions, and also unintentionally weasel worded my description of what I did. When I was seeing no log contents, I was not physically pushing buttons on Insteon devices – I was issuing on and off commands to indoor and outdoor devices using the admin console. Does that change your assessment? Do you want me to physically press buttons on devices while collecting the log?

When I re-read this, I just had my attention drawn to the word "portal" in the first weird error message. I went back to the configuration screen and saw this: I'm not sure what "portal online" indicates. I have never configured or used ANY portal services (that I know of). I wouldn't even have a portal account if I didn't need one to post to this forum. Did I accidentally click something that tethered me to the portal, and perhaps that's why nothing works anymore? Or is this just something that every eisy displays? I don't see any obvious way to turn "portal integration" off.

@IndyMike: I researched what a "3-tap test" was and tried it. Nothing "beeped" except the PLM clicking, but all the indoor devices that were capable did blink red or green. (I have some switches that are so old that the only LED they have is the dimness indicator.) Couldn't inspect the outdoor devices because it's too soggy to run out there today, but at least I determined there is SOME communication out of the PLM. When I opened the Admin Console today, I didn't get any complaints about any un-reachable outdoor (or indoor) devices, and none showed up in the LH column. Just a data point. I pulled up the event viewer to level 3 (again, not very familiar with it) and cleared it. Then I ran commands directly on indoor and outdoor devices. My first action was to set a plug-in dimmer to ON, and got this weird error: I never saw it again -- from then on, any device I attempted to control gave me no response to the first command, then to every subsequent command. Meanwhile, the event viewer was 100% mum except for a periodic poll about "[ Time]". 1. Is the PLM the most probable culprit? 2. I do have a spare one I could easily swap in, where are the steps I need to get it loaded with my current config? 3. Is this the sort of failure that Insteon's "repair PLM" service addresses, or it is more worthwhile to can the serial PLM (which I've perpetuated since the time we all had to run the system from a PC) and go USB?