LeeG

Turn Off the Broadcast change. That would send Broadcast messages which the ISY is not looking for. Not sure that will resolve the problem as I think once a link is established that overrides the Broadcast message option. Worth getting rid of Broadcast option as the ISY never processes Broadcast messages.

" I connected directly to the EZIO and programmed the inputs and outputs " What was done here?

Right click on the first EZIO2X4 Relay, select Restore Device. Then run another Show Device Links Table. There should be 4 link records displayed. The missing link records are why the Input state changes are not reported to the ISY.

Okay. The EZIO2X4 has no passthru outlet. It looks like the face of a 2413 PLM. Your running ISY 4.2.1. If either of these is not accurate please correct. Right click on the first EZIO2X4 relay which is the first node. Select Diagnostics | Show Device Links Table. Post the displayed link table.

Next thing to look at is total watts. Devices such as KeypadLinc and SwitchLinc Dimmers handle 600 Watts. The FanLinc Dimmer is rated for 300 Watts max.

What type of lights are in the Fan? That is often the issue with a symptom like this.

Yes. The FanLinc Light node has no special requirements. It operates as any other Insteon Dimmer.

Is this an older EZIO2X4 with a passthru outlet? What level ISY firmware is being used?

Can you clarify Input 1 connections. I1+ takes up to 30V DC and I1- takes GND. 12vAC would not be applied to any of the EZIO2X4 Inputs.

Yes, blinking Green indicates the PLM and Access Point are on opposite 120v legs. Which trace was taken with the SynchroLinc and Access Point plugged into the same outlet?

The SynchroLinc and Access Point that is blinking Green are plugged into the same outlet?

Put the PLM into test mode with 4 taps on the Set button (assuming it is a 2413). Now look at the LEDs on the Access Points. Are the Access Point LEDs blinking and what color is being displayed by the Access Point LEDs.

There is at least one case in the earlier traces where two dups of same message was traced. I like your idea about pulling the Dual Band devices, adding them back one at a time. Let us know how that goes. I wish I had an idea of what is causing the dups but have no idea.

Forcing I2 (Extended messages) may not work but does not physically damage the device. There are devices that indicate supporting an I2 Engine which is accurate for device configuration but those same devices do not support I2 for link database management. Most of the issues will be apparent in that the device no longer sends state change messages or some KPL buttons no longer send state change messages. Those devices can have issues with Scenes as the link records needed to support Scenes are not written or written in the wrong location. As long as you understand how the link database works, how to evaluate the accuracy of the link database records, where the link records should be written, and so on. I2 does improve performance of reading/writing of link records for the devices where it works. Note that changing to I2 is not the solution to the duplicate record problem as duplicates are happening on an I2CS device and it’s Engine accurately works with Extended commands. Something is producing the duplicate records or they are not being seen as duplicates. The overall communication of your Insteon network is good for the devices that have been traced. If the duplicate records can be eliminated the Insteon network would be fine. I thought I had posted this earlier but I must not have clicked Submit. Using I2 has no affect on Insteon Direct device On/Off as these are all Standard commands. It could affect Scenes if the link records are not written in the correct location.

Good find. 8's and B's are another easy combination to mistake.

The other thing to check is the Insteon address. Make sure the address being used matchs the label on the device.

The device is not responding to the command. The command was issued three times, the device did not respond to any of the three attempts. There are no 02 50 inbound messages. Thu 04/17/2014 10:47:22 PM : [iNST-TX-I1 ] 02 62 22 8B E0 0F 0D 00 Thu 04/17/2014 10:47:22 PM : [iNST-ACK ] 02 62 22.8B.E0 0F 0D 00 06 (00) Thu 04/17/2014 10:47:23 PM : [iNST-SRX ] 02 50 22.8B.E0 22.80.0B 2B 0D 02 (02) Thu 04/17/2014 10:47:23 PM : [std-Direct Ack] 22.8B.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Try a factory reset of the device. Powered from the same outlet the device and PLM should have no problem talking to each other.

It happens to ALL battery powered devices at ISY reboot because battery powered devices CANNOT be queried. The Leak Sensor sends a Heartbeat message every 24 hours on what is a clock running in the Leak Sensor. If the ISY is rebooted 1 hour before the 24 hours elapsed it will take 1 hour before the ISY is aware of the Leak Sensor Status. If the ISY is rebooted 23.9 hours before the 24 hours elapse in the Leak Sensor it will take 23.9 hours. That is what this Program logic is handling. If $sLeakKitchenSink is 1 And Time is Last Run Time for 'KitchenSink - Variable Control 2' + 26 hours Then If 26 hours elapse the Leak Sensor is not communicating with the ISY.

Yes, if device B and device C have nothing to do with a KPL button.

Run Tools | Diagnostics | Event Viewer at LEVEL 3. With the On/Off Module powered from the same outlet as the PLM run a New INSTEON Device and post the event log.

They are supported by 4.1.2. Plug one into the same circuit as the PLM and repeat the device add.

I set up a V41 Dual Band 8 button KeypadLinc using A,B,C,D with 4.2.0. All buttons worked correctly when pressed as well as using the four ISY Scenes. Suggest moving the sliders for B and C to full On doing one button at a time. Then move B and C back to 0% On, doing one button at a time waiting until each button update is done before moving the slider for the next button. What ISY firmware and UI is being used?

The Dual Band 8 Button KeypadLinc is listed at [01.41] 2334-2. If not in 4.0.5 I suggest going to beta 4.1.2 (not 4.2.0) where it is listed. Beta 4.2.0 has an issue with If Status in Programs. Note that this will not fix the device not answering a Get Insteon Engine command which sounds like a comm problem.

I'm running 4.2.0 and do not see this behavior. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Trigger the Program and post the event trace. Note all the device Insteon addresses the Program is controlling.

The Icon Relay is an extreme on the bad end with duplicate messages after practically every message. The I/O Linc is almost an extreme on the good end with 144 Standard messages and 11 duplicates. The V36 KPL is about in the middle with 80 messages and 44 duplicates. The surprise is the V41 KPL which is an I2CS device with 36 Extended messages, 8 Standard message duplicates and 6 Extended message duplicates. Although not an absolute I think the duplicates with the I2CS device means the duplicates are not caused by the individual device. I would look at the circuit layout. Where are the better devices located compared to the bad devices. Where are the Access Points located regarding the good and bad devices. Is the PLM newer or older. I have no guess as to why the duplicate messages but with duplicates on Standard and Extended messages across several devices I would look at the Insteon network in general rather than an individual device such as the Icon relay or I2CS KPL.