I experienced a first time ever event in the almost 20 yrs of ISY/Polisy/EISY ownership

All my Insteon lights randomly turned on at 3:00 am this morning. The only program scheduled to run is the usual query to devices at 3:00 am. The query confirmed lights were on in the logs.

I'm on the latest up to date EISY firmware, my PLM is relatively new and line noise has never been an issue.

Anyone else experience this weirdness?

Edit: My wife says she had to get up at 11:30pm and turn off all the light.There is a possibility that the lights were randomly turned on earlier and the query just reported the fact the lights were on.

Edited Thursday at 01:51 PM4 days by mmb
Clarification

43 minutes ago, mmb said:

I experienced a first time ever event in the almost 20 yrs of ISY/Polisy/EISY ownership

All my Insteon lights randomly turned on at 3:00 am this morning. The only program scheduled to run is the usual query to devices at 3:00 am. The query confirmed lights were on in the logs.

I'm on the latest up to date EISY firmware, my PLM is relatively new and line noise has never been an issue.

Anyone else experience this weirdness?

Edit: it wasn’t just lights, it was every EISY PLM device, garage door, lights, etc

Do you have older or newer insteon devices? The all on bug happened with older devices usually with those who have motion sensors. Normally the log doesn't show anything. If you have newer devices where the "all on" code has been removed, this hasn't happened with them so you'll be the first.

I would make sure that an errant program didn't trigger them on.

Once every 20 years isn't so bad 😃

If you haven't modified your programs recently, then it can be just a freak occurrence. There are programming tips you can use to minimize the possibility of this happening, such as avoid issuing any new commands right after sending a scene command.

@lilyoyo @Guy Lavoie Thanks they are older but motion sensors. No program modifications.

Also interesting, the logs shows scene IDs instead of scene names around the time of the event. I checked the logs again later this morning and they're gone.

Hard rebooting everything.

Dying batteries in motion sensors can also be a cause of unexplained events.

1 hour ago, Guy Lavoie said:

Dying batteries in motion sensors can also be a cause of unexplained events.

I gave up on them about 15 yrs ago. Battery devices are too flakey.

Almost 20 yrs - I had a good run.

I never had an all-on event but I did have random individual devices turning on when they shouldn't during the "factory query." I had few/no insteon comms issues and dealt with this problem by disabling the nightly query all. It didn't seem to be doing any good for me.

@mmb , I second the opinion that performing a whole house query may be doing more harm than good. This is particularly true if your overall communication (and scene accuracy) is good - meaning that you don't benefit from the query.

Why you ask? It turns out there are serial communication errors occurring regularly between the ISY and the PLM. Most of the time these are harmless and the ISY simply retries the command and we never know the problem occurred. Rarely, the corruption results in a valid command that the PLM puts on the powerline (think all-on/all-off).

@kclenden was the 1st to document that these errors were occurring and could cause All-on/all-off events. Since that time I have see 1 case of a All-on and 1 instance of the PLM Reset due to corrupted communications.

The communication errors are more frequent during periods of heavy communication - Device restores, Program activity with no delays, and system queries.

I have found a mitigation on the ISY994 using the low level "CD" (configure delay) command through the ISY Shell interface (Telnet). This allows you to reduce the rate of successive commands that the ISY issues to the PLM.

Unfortunately, I don't believe this exists on the EISY. This is why I would recommend eliminating the query-all if you can tolerate it. Another possibility would be to shorten/improve the quality of the serial/usb cable to the EISY. I have not found this to help on the ISY994, but the EISY is a different animal.

@Javi

I tried switching to "light mode" in eisy ui (alt t), The (white) program detail doesn't show up

Is it possiblle to have a background between Black and White i.e. light blue as in admin console, and be able to lock in the theme

On 8/26/2026 at 11:04 AM, mmb said:

Anyone else experience this weirdness?

On 8/26/2026 at 7:27 PM, IndyMike said:

I have found a mitigation on the ISY994 using the low level "CD" (configure delay) command through the ISY Shell interface (Telnet). This allows you to reduce the rate of successive commands that the ISY issues to the PLM.

Unfortunately, I don't believe this exists on the EISY. This is why I would recommend eliminating the query-all if you can tolerate it. Another possibility would be to shorten/improve the quality of the serial/usb cable to the EISY. I have not found this to help on the ISY994, but the EISY is a different animal.

TLDR: I don't think your problem is your hardware or cables. For now, the only thing I know to do is write a program to query a device that is never ON and then alert you if it gets turned on AND/OR automatically turn off all your devices. See below for something you might be able to do to confirm that your ALL ON was an eISY-to-PLM communication error.

When I upgraded from an ISY to an eISY, my observed instances of ALL ON events increased dramatically. Because of that, as @IndyMike indicated, I did some troubleshooting that led me discover communication errors between the ISY/eISY and the PLM. Having a couple Event Viewer logs from my ISY days, I compared the error rate between ISY/PLM communication and eISY/PLM and found the error rate to be about 7-times higher with the eISY/PLM. Errors went from about 0.1% to close to 1%. Not all errors cause ALL ON events, but the more communication there is, the more errors that occur, and seemingly the greater the chance of an error that causes an ALL ON event.

Having an upcoming scheduled vacation, I didn't feel comfortable leaving the house with the eISY running knowing that all my lights could come on randomly and blaze for who knows how long. So I created a program that queries a specific Fanlinc every five minutes. If the fan is on HIGH, then it increments an ALL ON counter and sends an OFF command to a scene that contains all my Insteon devices and then sends me a text message. Then I went on vacation. So far it has counted 8 ALL ON events since then, or about one every six weeks.

I didn't come back to this issue until a couple weeks ago. In that time, I've tried a couple things:

• Switched my PLM from the serial version to the USB version. This made absolutely no change in the quantity of communication errors that I see between the eISY and the PLM. When you learn more about the USB PLM, this isn't surprising since the USB PLM has a USB-to-Serial converter inside the PLM, so the PLM is still receiving serial communication.

• Wrote a relay/logging program that runs on my laptop to receive serial communication from the eISY and pass it on to the PLM while logging the data to a file. I did this because I wanted to see if the eISY was reporting one thing in the Event Viewer but actually passing corrupted data to the PLM. Turns out the eISY is sending correct data but for some reason the PLM is misinterpreting it.

• Updated the relay/logging program so that I can slow down each byte of communication that comes from the eISY before sending it on to the PLM. @IndyMike indicated that he uses the "CD" command on the ISY, but as he surmised the eISY does not have such an option, so I'm doing it the hard way. I haven't had time yet to evaluate the impact of slowing down communication on eISY/PLM errors.

I have another vacation coming up shortly, so no guarantees when I'll get back to this.

The eISY has logging capability that the ISY does not. For this reason, you may be able to confirm what caused your ALL ON. Try the following:

1. Click TOOLS->LOG VIEWER

2. In the Log Viewer window, change from Matter Log to Debug Log

3. Type (INST-TX-I1|INST-ACK) into the "Filter" box and click the Use Regular Expression checkbox

4. Leave "Tail Lines" and "Max Result Lines" at their default of 25,000 and 2,000 and click GO

5. Scroll up to see if you see data from around the time you think the ALL ON happened

6. If you do, you can either copy and paste the results (click the clipboard icon) into a text file and then share that with @IndyMike or me and we can look for corrupted communication, or you can try looking for INST-TX-I1 and INST-ACK pairs that don't match. In my experience, ALL ON events involve the sixth byte changing from 0F to CF and the command in the seventh byte changing from whatever it was to 11, but any corruption is suspicious.

7. If you don't see data from Wednesday at the top of the window, you'll need to either increase the "Max Result Lines" or the "Tail Lines" and click GO again. On my system, I have to increase "Tail Lines" to 90,000 and "Max Result Lines" to 4,000 to see data from Wednesday, but I may have more or less communication going on than you.

I don't know if there is a maximum number of lines captured in the log file before it resets, but I do know that if you reboot the eISY the log file starts over. So if you're going to look for a smoking gun of an ALL ON event, you should do it sooner rather than later.

Edited Saturday at 10:04 AM2 days by kclenden