lhranch

OK, I'm seeing the same error message, but with no local connection settings specified. I've been running MobiLinc Pro configured to use only the remote (https) service over a canned CNAME no matter where I am, so that is the way I tried to set up UD Mobile. Since the local connection is an "Advanced Setting" that doesn't even come up unless I ask for it, I was assuming the local connection information was not mandatory. I have only the admin user defined and that's the one I'm using, so that isn't the issue. I've verified that the setting strings are exactly the same in MobiLinc Pro and UD Mobile -- one works, the other doesn't. Is there perhaps a bug where UD Mobile doesn't like to work if the local information has not been specified?

Never mind. I mounted the SD card, and it was relatively simply to examine the authentication information. There was no external incursion, just embarrassing user error. Thank you Michael.

If the password is on the SSD, is there a serial command that would let me just reset it? That would be much easier than any of the alternatives. Are the serial commands documented anywhere? Thanks.

I rarely address my ISY994i directly, as the pushbutton controls and timed programs typically satisfy my day-to-day requirements. Today, I tried to manually open a gate for the first time in perhaps two weeks, and was refused with a "bad authentication" error message. Sure enough, I cannot login to the ISY using the proper name and password from either my phone or my computer. My ISY is exposed to the greater Internet, so it's quite possible someone brute forced the password and then reset it. I do maintain backups, so no worries there. I'd like to see if any password resets were logged and when. (Assuming those get logged at all, which I have no way to determine right now.) 1) If I factory reset the ISY, will I lose the log? 2) I can change out the SSD, factory reset it, power it off, and change it back. If I do this, is my new password stored inside the ISY or on the SSD? 3) I can take out the SSD and try reading it on another device; will I be able to find the log? 4) I can use the monitor port and Putty into it, but can I read the log using serial commands? I can't seem to find a guide to the command repertoire for the monitor port. Thanks.

That was the 100% correct answer. Worked like a champ. Thanks.

I have a 2440 remote that I set up long ago, probably even before I had the ISY hub. I want to change what one of the buttons controls. I made the change in the admin console, but have been unable to get the changes uploaded to the remote. I realize it's an RF device that sleeps, so I have to do something to put it into a mode where it will accept reprogramming. I tried using it to turn a light on and then off to wake it up (which I seemed to remember was the trick), and then telling the admin console to upload the new programming, but it doesn't upload. I use the "write updates to device" command, and the AC goes through all the "please do not power off or unplug the device" screens, but when it's done, the icon still indicates there are updates to be uploaded and the switch has not been reprogrammed. I checked out both the 2440 and the ISY instruction booklet, and neither one of them has any information on what I need to do. Can somebody tell me?

I had a thought while trying to wrangle this light last night... the program didn't seem to work properly if I turned the light off using MobiLinc Pro on my phone, or the ISY Admin Console, possibly because those apps don't match any of the physical buttons that were conditions in the program. Is there a syntax that allows me to include apps and the AC, and not just physical buttons?

Yes, that. The last paragraph just confuses the heck out of me. I want every one of these "mirror" buttons to do exactly the same thing as the main button, they are just available in different locations. The only way I have found to associate a button with a scene in the admin console is to drag the button and drop it onto the scene (I literally have found no other way to do this). Doing this always makes the button a controller, and I can't change it. What I want to do here: I have a set of outdoor lights that by default work automatically in conjunction with a motion detector. (This is done via an ISY program, not by physically associating the detector and the lights.) However, when any manual commands are given to that light, through any of the buttons associated with it in several locations, I want the automatic operation suspended (a state variable set). Automatic operation will not be resumed until a "Fast Off" is tapped for the light. I've had this code working reasonably well for a couple years. I recently wanted to program a new remote for this light, and was wondering if I had to change the program every time I did this, or whether just looking for events at the physical load controller would be sufficient. From the answers here, it looks like I have to code for all the buttons. But the whole responder/controller issue is a monkey wrench that I don't understand.

Say I have a load switch A for a device, and several other switches in the home (e.g., on keypads) that do nothing but control that device remotely. Say I want to write a program that does something special when I (for example) do a Fast On for that device. Do I have to write, "If control A is Fast On, or control B is Fast On, or control C is Fast On...", or is it enough to write "if control A is Fast On" on the theory that the action of all the other switches is ultimately to set A itself to Fast On?

I have a half dozen UPS units in the residence. Right now, the PLM doesn't share a breaker with any of them, but if I had to move it to a more central area, it would be a problem. Of course, I wouldn't put a PLM on the business end of a UPS or surge, but finding out I can't even share the feed side of a UPS is disheartening.

The PLM is from April 2018, so relatively new. It talks to all the Insteon equipment reliably. I think you're right about poor signal. I redid my test more rigorously, locating the manual control panel in the same outlet as the PLM. The X.10 module either worked from both or failed from both, depending on in how far away an outlet I placed it. I suppose my Insteon devices are making full use of repetition and dual-banding to work as reliably as they are. I might look at relocating my ISY and PLM to a more central outlet and see if I can squeak by that way. If not, I guess I'll be buying a few Insteon plugin modules.

Nope, I retract this. The problem isn't the room, it's the ISY no longer being able to run my X.10 modules at all. Something happened in the past year.

I have an ISY 994i (1120) on v.4.8.0 (20-06-26) and a score or so Insteon devices on the property that are working just fine. I also have a handful of antique X.10 wall warts I use for undemanding impromptu tasks, like running a seasonal Xmas tree. Tree ran just great in 2018. Didn't have a tree in 2019, so can't say. Went to use the wall wart a few months ago and suddenly it doesn't work. Got the chance to debug the problem only this week. Found the old manual X.10 controller that came with those warts and verified the warts themselves work just great (with a healthy clunk) over the AC lines from the manual controller buttons. Yet, won't work from the ISY on the same address in the same socket. Turn it on, admin console says "yeah, it's on," but it isn't. Same for off. I've verified that "A10/X10 for INSTEON (21060)" is still installed. Running "Manage Modules" just produces "up to date." I'm positive I applied at least one FW update to the ISY over the past year. Was there something in there that was known to break X.10? Is there a fix?

Ugh. I'm not an Insteon hobbyist and I'd rather not risk beta software, especially software that's been beta for eight months without yet being deemed suitable for general release. Thanks anyway.

Here is what I'm seeing (attachment). I noticed today that the Admin Console was offering me to upgrade to 4.8.0, so I performed the upgrade (attachment). Now it's telling me I am entirely up to date. So I have no idea why or how there is a 5.16.

I only had one 2486D, now dead. Buttons B-H started going unreliable, and finally even button A went bad (you'd push it and it would begin pulsing on and off like a metronome). I never had any problems controlling the backlighting on it before it started going bad, not that I tried it after that. But I wouldn't buy another one today because it is a single mode device (when I bought it, dual-mode wasn't available). However I'm still mainly interested to find out how we are expected to control a 2334 backlight from the ISY admin console.

I've changed my mind. I relocated the old 2467D and its test lashup into the breakfast nook. I got the same distribution of hops-left=2 and 1. Then I replaced it with a new 2487S. I got clean hops-left=3 down the line. (I also ran a couple tests on the 2334-2 on the facing wall of the breakfast nook and again got full hops-left.) I moved the test lashup (2487S) to the workshop where the wiring was suspect, and got hops-left=2 across the board. So my final analysis is that the workshop wiring does have minor problems, but the old 2467D is just weak in itself, maybe because it's only single-band, or maybe because it's old and weatherbeaten. I'm going to retire it to "emergency spare" status. Thanks for teaching me about the existence of the diagnostics log.

Not sure what that would do for me, as the new pool switch is a dual band and isn't acting wonky, so wouldn't act any better with the 2632 nearby. I infer that the diagnosis is that the old switch is in good shape and the workshop it's in has powerline noise problems. I'd be willing to believe that, because I have a reliable old X.10 switch that works great on the Xmas tree in the main room, but won't work reliably in here to control a simple lamp. The room is electronics-heavy (laser printer, laptop, Mac Mini, UPS, and strip surge protector). I'll test the lashup in a socket in another room tonight.

That was an interesting exercise of which I was unaware. I ran it on the 2632, and discovered that except for one keypad I replaced last week, nothing in my house was new enough to have that red/green LED. I did, however, have a 2487S in the garage that was blinking all of its center buttons, whatever that means. All the other grounds and outbuilding units were too far or too obscured to examine.

It was either the same device, or the large handheld remote, which won't update until someone gooses it by hand. It had gray 1011 icons so I goosed it until the queued write completed. I plugged a spare 2632-222 (which I believe is a dual-band unit) into the same cube tap as the item under test and ran the test again, with the same set of commands (plus an extra On command so I could see if the LED setting succeeded). I still got some errors, though the test ran a lot faster and gave no errors during the LED set portion; however, when it was done, the LED was still weak sauce, so I don't think it succeeded IRL. ISY-Events-Log.v4.7.5__Sun 2020.06.21 19.21.23.txt

Thanks. Here is a log of the questionable switch while performing: On Off Fast On Fast Off Set background LED level 12 Set background LED level 15 This sequence almost always fails after "Fast Off," and the LED level commands are guaranteed to generate grief. In this case the progress bar ran out on the second attempt, and the AC just dropped it with no comment when the clock ran out. I should stress for clarification that this is the only device that gives me grief, and it gives me the same grief at two widely separated locations on my power grid. I ran the same test on a few other switches, and though I occasionally saw a hops-remaining at 1 or even 0, I never received an error. ISY-Events-Log.v4.7.5__Sun 2020.06.21 18.32.47.txt

You're right -- the old one was a 2476D, which I replaced with a 2477D. The dual band stuff wasn't quite available when I started installing modules. That could explain why it didn't do well out in back of the pool, but it's not doing well on the bench next to me, either. In trying to take the advice to "Open the AC and set the error logging to level 3. Activate the offending switch via the AC and watch the level 3 logs for errors," I've tried the menus, the manual, and the wiki, and can't find anything about how to set an error log level to anything. The only thing I can apparently do with an error log from the AC is dump it to a spreadsheet file, which doesn't seem conducive to watching errors go by in real time. I can't even find anyplace that tells me the version of the AC I'm running, though I updated it sometime in the past couple of months. (My ISY itself is running 4.7.5). Is there some other tool I don't know about, or a URL that explains stuff I can do with the error log?

I recently replaced a wonky Insteon 2486D with a newer model 2334. The Admin Console shows me an "LED Brightness" button for the old unit, but not the new unit. After noting that this feature was not present in the website description of the new unit, I was under the impression that the new unit didn't offer it, but I was referred to the full user manual that explains how to set the backlight manually, and indeed that works. Is there some reason this feature is not available through the AC as it is for the older units, or is it somewhere else?

I spoke too soon. Now I'm seeing (on the old switch in the testbed) exactly the same connectivity issues reported earlier. I start up the ISY Launcher, and half the time the first thing it tells me is "Warning: Cannot communicate with Old Pool Sw (MAC). Please check connections." Yet, all the controls in the device window work (On, Off, Fast, the rheostats) so clearly the hub can communicate, although every so often it gives me the same complaint again, but then next time it will work. The associated switches and iPhone app all work, maybe not the first time, but no more problematically than other devices in the household. What's the best way to figure out what is going on?

Is there any way to find out from a hub whether a remote Insteon device (simple switch) is reachable by powerline, by radio, or both? I just replaced a Decora-style dimmer switch in an awkward outdoor location. The new switch seems to be working better, and I have the old switch on a testbed in my shop where it, too, appears to be working (but of course it is now on the indoor grid and much closer to other radio-band devices). The old switch suffered from bizarre connectivity issues reported earlier, and the reset procedure didn't fix it (in fact, it took it entirely offline, though both the reset switch operation and the location were so physically awkward that I cannot be 100% sure I performed it completely). I am curious to determine if the failure mode was that one of the switch's comm interfaces went bad and the other path was just naturally spotty, so I can figure out whether the old unit is worth saving for an application where only the remaining path is required.