IndyMike

Not dangerous - Insecure Unreliable - As you've already learned, the 2450 is powerline only. It has issues with communication in "problem areas" (no news here). In my experience, is it also susceptible to powerline transients activating the switch contacts. Transients are typically caused by inductive and capacitive loads activating/deactivating (motor loads, florescent, etc ). Many HA devices have problems with powerline spikes activating them. The 2450 seems "more" susceptible. I used on one my sprinkler controller to de-activate the system. The garage florescents would routinely activate the 2450 even though it was behind a filter. No Security - No Insteon device is "secure". You won't find an Insteon deadbolt on the market because the protocol does not support secure communication. Your garage door remote has rolling code encryption to prevent capturing and replaying the open close commands. The 2450 does not and can be easily defeated. Susceptible to All-On commands - Most (if not all) IOLinc modules are susceptible to all-on/all-off communication. This is a command built into the Insteon protocol that activates ALL LINKED UNITs. Unfortunately, the PLM can generate this command erroneously under certain conditions. I've had several occurrences, as have others - Another All ON EVENT. If you're lucky, your lights turn on. No great harm. If you're unlucky, your fireplace, house vent fan, and garage door activate. Edit: Wanted to be sure that the 2450 activated it's contacts due to an all-on. I verified that My 2450 with firmware v.36 responds to both All-on and All-off and activates it's contacts accordingly. This would absolutely open/close a garage door during a "All On Event".

Thanks for the input on the YoLink temp/humidity sensors. I looked at them for bathroom humidity and refrigerator monitoring. Would up going with Zigbee Aqara sensors since I already had the dongle on Home Assistant. I do have a friend who is looking at door sensors for his outbuilding 400 feet away from his house. We are looking hard at the YoLink. I assume that you are using their hub - correct?

Sorry, I completely missed this post. It sounds like your chargers may have large EMI caps installed. These are rather effective at absorbing Insteon signals. It's probably not just the chargers absorbing things. All devices installed on the circuit (and near the PLM) can contribute to noise and absorption. Unplugging one device may re-establish signal levels and look like a smoking gun. In actuality, what normally happens is you have improved signal levels just enough to allow things to operate (barely acceptable signal to noise ratio). Unfortunately good, easy tools for Insteon don't really exist. The best commonly available method I know of to assess communication is by removing and/or filtering loads and then monitoring communication with the Event Viewer. I normally choose the "Show Device Links Table" as this is rather communication intensive. You are looking for transmissions where "Hops Left" is the same as "Max Hops" or possibly one lower. Retries will be signified by multiple transmissions with no response from the device. Your 2450 could be an I1 device (uses Peek/Poke rather than I2 extended comm below) in which case the communication will be FAR more intensive. Good communication (I2 Extended Comms: One read returns 8 bytes of data) Mon 01/15/2024 08:56:09 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 08:56:09 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 08:56:10 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:10 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:10 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 15 2F 00 01 01 0F FF 01 A2 00 53 BC 3A FF 1F 01 C2 Mon 01/15/2024 08:56:10 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 01/15/2024 08:56:10 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA Mon 01/15/2024 08:56:10 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00) Mon 01/15/2024 08:56:11 AM : [INST-SRX ] 02 50 18.93.83 53.BC.3A 2F 2F 00 (00) Mon 01/15/2024 08:56:11 AM : [Std-Direct Ack] 18.93.83-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 08:56:11 AM : [INST-ERX ] 02 51 18 93 83 53 BC 3A 11 2F 00 01 01 0F F7 01 22 47 53 BC 3A FF 1F 01 CA Mon 01/15/2024 08:56:11 AM : [Ext-Direct ] 18.93.83-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Mon 01/15/2024 08:56:11 AM : [INST-TX-I2 ] 02 62 18 93 83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 Mon 01/15/2024 08:56:11 AM : [INST-ACK ] 02 62 18.93.83 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 06 (00) Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 08:56:14 AM : [All ] Writing 0 bytes to devices Communication Re-tries (no INST-SRX 02 50 from device) Mon 01/15/2024 09:02:44 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:44 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:02:53 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:02:53 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:02 AM : [INST-TX-I2 ] 02 62 16 5B DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Mon 01/15/2024 09:03:02 AM : [INST-ACK ] 02 62 16.5B.DC 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices Mon 01/15/2024 09:03:06 AM : [All ] Writing 0 bytes to devices I1 Communication ( 2 Operations required for 1 byte of data) Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:41 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:41 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F8 Mon 01/15/2024 09:07:41 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F8 06 PEEK (F8) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B A2 PEEK (A2) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 28 0F Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 28 0F 06 SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 28 0F SET-MSB(0F) Mon 01/15/2024 09:07:42 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 01/15/2024 09:07:42 AM : [INST-TX-I1 ] 02 62 05 4B 4B 0F 2B F9 Mon 01/15/2024 09:07:42 AM : [INST-ACK ] 02 62 05.4B.4B 0F 2B F9 06 PEEK (F9) Mon 01/15/2024 09:07:43 AM : [INST-SRX ] 02 50 05.4B.4B 53.BC.3A 2F 2B 00 PEEK (00) Mon 01/15/2024 09:07:43 AM : [Std-Direct Ack] 05.4B.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

@DwayneA, Both your 2450 and 2443's will flash their LED's on Insteon traffic. If you have Mobilinc you should be able to activate the 2450 remotely and watch for traffic on the LED's. This may help to isolate the problem further. Just noticed that you indicated that the 2450 is also CONTROLLING your garage door. Sorry, but I think that's a very bad idea. The 2450 is not the most reliable module. It's totally devoid of security, and it's susceptible to All-on/All-off communications. I understand to desire to monitor your garage door status, but please re-think controlling it with the 2450.

@paulbates, I would think your "If 'Sump Pump Monitor..." program would be triggered anytime there is a state change in the 2450 (including an Error). Nonetheless, specifically calling the "Sump Runtime program..." from you first program is Belt and Suspenders. I can't see any downsides. I am happy to see you building error handling around the 2450. They are not the most reliable devices and are susceptible to All-on/All-off communication. It looks like you are using the 2450 for notifications NOT control. I would not trust a 2450 to control things where damage could result. Let us know how it works.

Sounds more like a communication issue. Garages can be very problematic with all the devices that are plugged into outlets (chargers, etc). Since the 2450 is a plug-in device, try moving it closer to your PLM to check communication. If it works, you need to look for signal absorbers/noise generators on the garage circuit.

This is how I query my All-On detector. Make sure you have "run at startup" selected for the program All on Poll - [ID 0023][Parent 000A][Run At Startup] If Time is Last Run Time for 'All on Poll' + 5 minutes Then Set 'All On Detect' Query Else - No Actions - (To add one, press 'Action')

@Kentinada, It sounds like you would like to include a "Not switched" for the Ring camera to activate the Else section of a program as shown below for a motion sensor -Correct? Trying to understand the problem and am unclear on the following: 1) Is the option for testing the "not switched off" unavailable for the Ring camera? 2) is the option available but does not trigger when the camera stops sensing motion? Kitchen Motion On Copy - [ID 0012][Parent 0054] If 'Motion/RF / Kitchen Mud.1 Motion' is switched On And 'Motion/RF / Kitchen Mud.1 Motion' is not switched Off Then Wait 2 seconds Set '1st Floor / SC Bar Cans' On Else Set '1st Floor / SC Bar Cans' Off

If I understand correctly, you are worried about "missing" a contact closure on the 2450 OR having it go offline. I don't see a device query anywhere. Is that contained in another program that runs at XX interval?

Snippet from the Insteon developers guide defining All-Link Groups (Group broadcast). Group broadcast is used Every time you activate a Scene. The All-on/All-off command is simply a Scene with a Group #FF (all linked devices).

I am currently using the ISY994 with firmware V5.3.4. It contains All-On/All-Off buttons on the "My Lighting" and "My Network" Tabs. Press either of these and you will get a Broadcast Group All-On/All-Off command to group "FF". For Insteon, group FF is ALL DEVICES. I checked again this AM. The following works like a charm. Hit All-On or All-Off and all of my older devices respond. My newer devices (V.45) do not. The short transmission in the event viewer is the Broadcast group command used (I used All Off) I highlighted the Group # (FF) in the command to show it was for all devices. This is not an error or deficiency. The broadcast group command is part of documented Insteon protocol and group xFF is defined as all devices. What is an anomaly is the "collision" or other event that causes the PLM to transmit the command when something else is being requested (I am assuming here). There are other serial port tools that will allow you to communicated directly with the PLM to generate to command shown below. I actually wrote one using VB years back. The good news is that you don't need them. The ISY994 can do this from the Admin Console. I'm hoping the PolyIsy and Eisy can also.

Curious that the Eisy treats your 2477s that way. I've tried my devices ranging from I1 through I2CS and the ISY994 only writes once. Are you sure you are not seeing an error or Nack when you are writing the 2477S? This could cause the ISY to write a second time when requested. As you inferred the backlight changes are written to EEprom memory on the device. There is a limit to the number of writes the device can undergo. This, I had thought, was the justification for not writing redundant information. I say redundant, because the command is device direct and is fully acknowledged by the device. There is no guessing whether the command was received. Try checking commands for On/Off. These are also device direct commands but do not involve the memory. I think you'll find that the ISY sends the command every time (my 994 does). If the Eisy does not send each command, that is an update. Not wrong, just an update.

@tmorse305, It looks like the Eisy is performing as I would expect it to. When I perform a "backlight change" on a I2CS device I get the same behavior. I believe this is the ISY "remembering" your device backlight. If you are not changing the backlight, there is no work to do (o bytes written). You can perform the same actions using the backlight controls on the Admin Console (on ISY994 - not sure about Eisy). If your device is not responding to the initial change, it should be giving a NACK or a timeout. You should be able to see this in the Logs. 1st write (valid change) Wed 01/10/2024 09:57:10 AM : [All ] Writing 1 bytes to devices Wed 01/10/2024 09:57:10 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Wed 01/10/2024 09:57:10 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Wed 01/10/2024 09:57:10 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Wed 01/10/2024 09:57:10 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Wed 01/10/2024 09:57:10 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 53 BC 3A FF 1F 01 98 Wed 01/10/2024 09:57:10 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Wed 01/10/2024 09:57:11 AM : [41 1E 9 1 ] Memory : Write dbAddr=0x0264 [00] cmd1=0x2E cmd2=0x00 Wed 01/10/2024 09:57:11 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB Wed 01/10/2024 09:57:11 AM : [INST-ACK ] 02 62 41.1E.09 1F 2E 00 00 07 00 00 00 00 00 00 00 00 00 00 00 CB 06 (00) Wed 01/10/2024 09:57:11 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2E 00 (00) Wed 01/10/2024 09:57:11 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Wed 01/10/2024 09:57:11 AM : [All ] Writing 0 bytes to devices 2nd write (redundant change) Wed 01/10/2024 09:57:14 AM : [All ] Writing 0 bytes to devices Wed 01/10/2024 09:57:14 AM : [All ] Writing 0 bytes to devices

Make that Plan C. I was looking at the low end models for Napoleon. They do indeed use standing pilot ignition and milivolt gas valves. Unfortunately, your description of "multiple relays", bluetooth, and controllers does not sound at all like a "low end" standing pilot system. There are installation manuals available for the fireplaces, but that's not the same as specifications.

It sounds like you have a standing pilot gas valve. When the pilot light is on it heats a theromopile to provide electric power to the gas valve. It is essentially a stand alone setup that requires no external power (nice for power outages). The normal method to control these is to "Switch" the theromopile input to the gas valve (just an on/off switch). For automation purposes you could "sense" the switch voltage to determine if power is being applied to the gas valve. Could you provide the Napolean Model # and possibly a photo of the gas valve?

The secondary buttons do not really have an ON/OFF associated with them. They show up as "keypessed" events in Home Assistant. Think of the events as momentary rather than state events. Youtube of the "keypressed" event in HomeAssistant - Skip to 11:25 Testing scene buttons https://www.youtube.com/watch?v=87jquTZ4B_U

Got it. I see now that you originally stated that the device is a new I3 paddle. The Eisy side of communications looks correct (good command syntax). The device should be going to 20%. Possible that the new I3 devices also have a new rule book. We'll need to keep an eye out for that as experience with these devices grows.

That's rather curious. The Insteon command tables do allow for a "Fast On' to a specific level (second to the last entry below). I have never seen it used by the ISY994, nor do I know how to construct the command using any of the ISY994 program features. I can manually generate the command using command line tools and dimmers will respond appropriately. 1) Your EISY event viewer shows the transmission of a "Fast On" to a level of 33(hex). This is equivalent to 20%. 2) The PLM acknowledges the 20% on command. 3) Your target device responds and acknowledges the 20% on. But the device goes to 100%??? I was originally impressed that the EISY would recognize that your device has a local on level of 20% and that fast on commands would sent it there. A nice touch. Now I'm not sure what to think. The command looks correct. It's possible that the device itself has an issue. Is it very old or very new (I3)? Nothing to be concerned about. Just something for us dweeb tech types to mull over.

It looks like you executed a "fast on" device direct command to address 60.2B.E0 telling it to go to 20% level. To be honest, I did not realize this was possible. I had always assumed that Fast On commands applied to 100% level. Regardless, you did receive two valid responses. There are times when duplicate responses are received. The second response could be from a "repeating" device on the opposite phase of your home or "other". I don't believe this is an issue. Edit: I was able to reproduce on my system. I was repeatedly sending a "Fast ON' to a distant device in my system. The thinking being that a distant device would be more likely to produce a Hop "Echo". I received two duplicate responses in about 30 attempts. Again, I think this is a simple artifact of the multiple HOP architecture of Insteon. I would not be concerned.

Based on my rather limited testing, your IOlinc (V.41) would be susceptible and your Siren (V.46) would not be. My testing of devices in my home is located here : https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748 You could also try executing a "all-on" command from the Eisy. Not sure if it's still available in the Eisy. It's located at the bottom of the "My-Lighting" screen on the ISY994. Best to try this when family members are not around

I am assuming that your Siren and GDO are not members of any scenes or programs. You can check scenes by looking at the device in the admin console and looking at the membership tree to the right. You can check program membership by right clicking on any program and selecting "find/replace". Search for your I/O linc and you will be able to cycle through all the programs that it is used in. I'm going to out on a limb and assume that you've already checked this. While it's possible that you encountered an electrical "even" that triggered the 2450, it's highly unlikely that the event would trigger the second floor 2868 at the same time (multiple times). The other possibility would be a "all on event". This purportedly involves a communication collision the generate a "all-on" (or all off) command to all Insteon devices. All affected devices activate. I say affected because Smartlabs has removed the command from more recent modules. It is possible that your 2450 and 2868 were produced prior to Smartlabs removing the command. Please post your device version, firmware and date code

@jhoulihan, not a complete solution, but you could hit save your configuration to a desktop file. You will need to manually enter your address (again) so the IOX finder sees the ISY. The simply press "save" and put the file in a convenient location. You can leave the default name or create something new that you'll remember. The next time the IOX finder "forgets" the address, simply load the file from the desktop. https://forum.universal-devices.com/topic/39489-iox-finder-not-found/?do=findComment&comment=354467

Glad it worked. Hopefully if functions as long as your Icon KPL.

Good idea adding the notification... I'm assuming this is the "new" follow-up program that is talking directly to the devices - correct? Are you still running your scene program and does it still fail to shut off the outdoor lights? Are these lights on GFCI circuits (outside and garage)? I am not familiar with the 'Holiday controller' date control. Assuming the program triggers, the device direct communication should be the same as if you turned the devices off from the Admin console. The PLM will issue device cleanup after each command and will retry communication 5x to devices that do not respond. My only other comment would be to make sure you don't have any other programs running at the same time. The Waits are effective at separating the PLM communication events WITHIN the program. If you have multiple programs executing the ISY could insert communication from other programs within the waits. This normally would be a huge concern, but if your PLM is performing retries to a problem device, it might abandon the cleanup in favor of the new command.

Just noticed that your problem lights were outside - i.e. on GFI outlets. GFI's can sometimes degrade powerline communication. What model Insteon devices are you using outside - are they dual band? Can you temporarily bypass the GFI for testing purposes? To @apostolakisl's point above. Much of this revolves around your programs. Please post them.