EISY Randomly turns stuff on and more...

[JimTurner]

Edit2: I have installed and synced my USB PLM. Took awhile to get things squared away. There was lots of mismatches between Device Link tables and IOX Link tables. I have one old PowerLine device that won't accept updates through the new PLM, but that's minor and a not very often used device. 

Now to monitor and see if this cleared my issues. Thanks to all for the suggestions and assistance!

Edit: I have 30-40 insteon devices in this setup.

 

My ISY994 did the same thing. I've been running EISY since mid 2024. Randomly I will find my outside lights on in the middle of the day. The EISY or UDMobile app does not know they are on. A reboot clears this.

Additionally, the EISY will lose connection with devices. Sometimes, when I turn a scene off, not all devices are turned off - even though the UDMobile app things they are. Again, a reboot clears this.

I have not been able to find a correlating event or sequence that may be the cause.

Thoughts?

Edited Wednesday at 05:28 PM by JimTurner
Clarification

[Guy Lavoie]

Are these Insteon devices? Dual band? Is it always the same devices? Was it the same devices with the ISY994i?

[JimTurner]

Yes, All Insteon dual band. Same issues in the ISY. It's about 8 ish (never counted) devices with the issue.

[Guy Lavoie]

Ok, what program logic and/or other devices are related to these devices? Is there something that they have in common, like a scheduled program, or other triggers like motion sensors?

[JimTurner]

They are all in a scene. I turn the scene off... No motion sensors in my setup. Plus they come on with a program that is based on Sunset and 10:00 PM (on and off respectively). I turn the scene off if I retire early.

Edited Tuesday at 03:17 PM by JimTurner

[Guy Lavoie]

What turns on the scene? Just a schedule? Other things? Could you post the program?

[JimTurner]

I picked one device for each issue - there are many.

Device Issue1: Randomly coming on: 2477S (Front Porch) is a controller for 2663-22 (plug with porch art), and is in 3 scenes (AllOutsideLights; SunsetToBedtimelights, and GoodNight (the one I use to manually shut things off).

The SunsetToBedtimelights scene is controlled by a program. (see below).

Device Issue2: Losing sync with EISY: B2457D2 (plug in dimmer) is in 2 scenes: SunsetToBedtimelights and GoodNight

 

Edited Tuesday at 03:37 PM by JimTurner

[Guy Lavoie]

Did you keep the PLM from your ISY994i and installed it on your eisy? How old is it?

[JimTurner]

I have the original 2413S (Rev 2.9 4716) and had purchased a backup (cause of where I live) 2413S (Rev 2.5 1619). I installed the backup when I installed the EISY. I also have a 2413U that I bought but never put in service.

[Guy Lavoie]

The fact that the status is not updated when this happens seems to indicate some kind of communication issue, or something that is falsely triggering them on. Yet if they all belong to the same scene and they always come on together, then something would be triggering the scene. But I don't see the reason why status tracking would be lost at the same time.

Until you reboot your eisy, are you able to control them from the admin console? 

[paulbates]

A quick test and maybe fix is pick one of the problem devices in iox, right-click and pick "Restore Device"

 

[JimTurner]

20 minutes ago, paulbates said:

A quick test and maybe fix is pick one of the problem devices in iox, right-click and pick "Restore Device"

 

I saw that - but never played with it. I am assuming that it only touches the one that I select...???

41 minutes ago, Guy Lavoie said:

The fact that the status is not updated when this happens seems to indicate some kind of communication issue, or something that is falsely triggering them on. Yet if they all belong to the same scene and they always come on together, then something would be triggering the scene. But I don't see the reason why status tracking would be lost at the same time.

Until you reboot your eisy, are you able to control them from the admin console? 

I haven't tried to control from Console. Good idea - cut the problem in half.

[paulbates]

14 minutes ago, JimTurner said:

I saw that - but never played with it. I am assuming that it only touches the one that I select...???

No.. it will touch every link in every device that's part of the scene. Other than deleting and re-adding devices, which is very drastic, restore is the way to go

Are any of the  devices in question wireless sensors... motion, leak, door?

Edited Tuesday at 06:21 PM by paulbates

[JimTurner]

14 minutes ago, paulbates said:

No.. it will touch every link in every device that's part of the scene. Other than deleting and re-adding devices, which is very drastic, restore is the way to go

Are any of the  devices in question wireless sensors... motion, leak, door?

I have no sensors like this. Just switches, plug in controllers and dimmers - mostly switches. 

[paulbates]

Pick a device part of the group of affected devices and right-click and pick "restore device"

This kind of thing happens with insteon. Not all the time, but it happens

[Techman]

@JimTurner

Your current PLM is over 8 years old and could be failing. Being that you have a new USB PLM, you should probably replace your older PLM with the USB model. The newer PLM's have improved firmware and hardware.

Replace PLM Procedure (EISY or POLISY).pdf

[IndyMike]

6 hours ago, JimTurner said:

Edit: I have 30-40 insteon devices in this setup.

 

My ISY994 did the same thing. I've been running EISY since mid 2024. Randomly I will find my outside lights on in the middle of the day. The EISY or UDMobile app does not know they are on. A reboot clears this.

Additionally, the EISY will lose connection with devices. Sometimes, when I turn a scene off, not all devices are turned off - even though the UDMobile app things they are. Again, a reboot clears this.

I have not been able to find a correlating event or sequence that may be the cause.

Thoughts?

When you execute a scene from the ISY (admin console or program) it does not verify that scene members received the communication.  It assumes that the scene was executed properly.  If you have noise or signal absorption, scene member may not respond.  The ISY will still show these devices as having responded.

When you re-boot the system, the ISY queries devices and restores the correct status.  Queries are performed using retries and are normally very reliable. 

The ISY will normally Query your system in the off-hours (3 AM?) to re-synch things. This is a system installed program that runs nightly.

If you have persistent issues with a few devices you may have noise/absorption issues on the related electrical circuits.  Inspect for chargers, PC's, etc.

If you have problems with MANY devices, the issue may be near your PLM.  Perform the same inspection.

By opening the event viewer on level 3 and performing device queries from the admin console you can observe communication with your devices.    Communication from the device to the PLM will be summarized in the "[Std-Direct Ack] Entry"  and will show Max Hop and Hops Remaining.  Hops Remaining of "3" is as good as it gets.  Lower is less desirable.  

 

 

Device Query Communication in Event Viewer.  Device address 1A.5D.C7 to PLM Address 53.BC.3A.

 

[JimTurner]

4 hours ago, IndyMike said:

When you execute a scene from the ISY (admin console or program) it does not verify that scene members received the communication.  It assumes that the scene was executed properly.  If you have noise or signal absorption, scene member may not respond.  The ISY will still show these devices as having responded.

When you re-boot the system, the ISY queries devices and restores the correct status.  Queries are performed using retries and are normally very reliable. 

The ISY will normally Query your system in the off-hours (3 AM?) to re-synch things. This is a system installed program that runs nightly.

If you have persistent issues with a few devices you may have noise/absorption issues on the related electrical circuits.  Inspect for chargers, PC's, etc.

If you have problems with MANY devices, the issue may be near your PLM.  Perform the same inspection.

By opening the event viewer on level 3 and performing device queries from the admin console you can observe communication with your devices.    Communication from the device to the PLM will be summarized in the "[Std-Direct Ack] Entry"  and will show Max Hop and Hops Remaining.  Hops Remaining of "3" is as good as it gets.  Lower is less desirable.  

 

 

Device Query Communication in Event Viewer.  Device address 1A.5D.C7 to PLM Address 53.BC.3A.

 

My old ISY994i had a query program for the 3AM resync operation. The EISY doesn't expose the node to do that - or at least not that I have found. I get the Reboot clearing the issue reason. 

I'm going to install my new USB PLM tomorrow. 

[Geddy]

2 hours ago, JimTurner said:

The EISY doesn't expose the node to do that

The Polisy and eisy did not come with the previous default query program, but it can be reproduced if it helps your system. There was a post about how to do that in the past. 

Here is one that I shared the program….look for the name of your eisy if you renamed it. Mine shows up near the bottom of the device list.

https://forum.universal-devices.com/topic/42003-query/#findComment-372311

 

[JimTurner]

 

13 hours ago, Geddy said:

The Polisy and eisy did not come with the previous default query program, but it can be reproduced if it helps your system. There was a post about how to do that in the past. 

Here is one that I shared the program….look for the name of your eisy if you renamed it. Mine shows up near the bottom of the device list.

https://forum.universal-devices.com/topic/42003-query/#findComment-372311

 

Found it - thanks. I have so many devices, it was buried.

[IndyMike]

A word of caution when using the "My Lighting" query.  I'll qualify this by saying that my experience is with the ISY994.  The PolISY and EISY may be different.

For the ISY994, a "My Lighting" query hit everything.  Some things that you may not wish to have queried:

1. All Insteon devices, Including MS-II sensors (bug).  You can disable MS-II sensors to get around this.  Note that the query is also a problem for IOLinc devices with "trigger reversed" set.
2. All X10 devices, including receive only devices (bug)
3. Z-wave devices - from memory, this includes battery devices.    

I do not know how Zigbee/WiFi/matter devices are handled on the newer systems.

On the ISY994, I created a "House Query" scene that had ONLY the devices that I wanted updated and used that for the 3AM program query.  This is a maintenance item as you need to keep adding new devices to the scene.

 

[Lore]

Here's how I fix mysterious problems, and I have a 100+ Insteon network previously plagued with almost every known issue.  Make the network more robust against noise by replacing pre-2012 modules.  They don't validate messages and can fix up and repeat noise to the entire network, even newer modules.  Reduce noise by moving modules away from power supplies, computers, and RF sources.  Add Insteon power line filters to equipment with motors or switching power supplies.  Restore devices with problems, and devices that might be repeating the signal.  If something is turning on often enough, try disabling things that might be causing it to see if that stops it.  The A/C, the fridge, the EISY, you can even try disabling just the RF or just the powerline communications in a module to determine which band the problem is on.  My whole system acted funny with just one failing module not near where the issues were.  It can be hard to figure out.  Another crazy issue I had, were modules programed to respond to X10.  A restore won't remove that, only a hard reset, followed by a restore.  I tested for X10 by writing a program on the EISY to send "ALL LIGHTS ON" on every X10 channel, followed by "ALL OFF" after a delay so I could turn on my non-light devices and see if any went off.  False X10 signals are even more likely to be created by noise, but also unlikely to be programmed unless you did it yourself or bought used modules that weren't reset.