lhranch

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.

I've been aware for quite some time of the "Set Userid/Password" menu in the Admin Console, but never did anything with it. I currently have a long-term tenant in a "vacation rental" residence on my property. It has a number of Insteon devices in it, most notably the thermostat. He was away for several days during which time we had a power failure, and came back to find his home at 103° (for some reason, the thermostat came back up Off). I got the idea that perhaps I could register a non-admin account on the eisy, and give him shared remote control over the units in his residence via a simple smartphone app like UD Mobile or MobiLinc Pro. I tried setting a name and password for User1, and it seemed to be accepted, but nothing ever actually changed. I went looking for how the multiple user feature worked, and found nothing. One posting indicated that whatever plans there were for this feature dead-ended when some other package or protocol was developed. So, rather than trying to reinvent the wheel from first principles, is there anyway to achieve the goal of what I want to do?

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?

Yes, that's just a low-level interface difference between Windows and Mac. MacOS provides a "disclosure triangle."

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 went bats trying to figure out how to list the devices inside a scene. They were all visible on one computer, but all I had on my other computer was scene names. Tried right clicking, no soap. It wasn't until I revisited the other computer that I finally detected the nearly invisible flippy arrow to the left of the scene name. Is it clear on your devices? Because on mine, it's practically undetectable. Light gray on medium blue. A little thicker and a lot whiter would really be nice! (Edit: This is MacOS.)

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?

Well in fact, I status my outdoor devices three times a day, specifically to detect popped GFCIs (there are devices on the grounds that have limited backup batteries and I need to know when they've lost power). I even have a micro module in one location that controls nothing, just so I can status that circuit to detect when it pops. But my mention of the outdoor modules was merely to explain why I didn't think my PLM had failed. When Admin Console specifically calls out the outdoor modules as inaccessible upon launching, that implies that it had no problems accessing the indoor modules, or else I would have gotten error messages about them, too. And yet it won't control anything, indoors or outdoors. And it also reports bogus on/off status for most of them. Meanwhile, the physical switches and pushbuttons continue to work the lights properly, both indoors and out.