LeeG

Post back the results with the new devices. First time I have heard of an issue that was traced to an Insteon address range.

Line 2 on the right side, this one is v.43

The Hidden Door Sensor cannot be queried because it is a battery device which goes to sleep. The ISY does issue a Query command which is a bug UDI acknowledged a few days ago. The Insteon address does advance over time as new devices are manufactured. Look at the Hidden Door Sensor firmware level which is on the second line, right side of node display.

I doubt a device that did not receive the query of the Insteon Engine could communicate in the reverse direction. Thus the question whether the device was near the PLM when state change messages not received. I was considering the possibility this Hidden Door Sensor is at a different firmware level, thus the question about whether on the latest ISY firmware.

Hops processing is built into the devices. No options. Could try adding a Dual Band device that is on the same 120v leg as the PLM if there is a circuit nearby.

The remote Controller sends an On command which has no specific On Level. No place in the Scene message for an On Level and each Responder could have a different On Level defined. The Responder looks at the matching Responder link record in its link database to determine the On Level to set. Does not matter whether the first Scene On message or the x Scene On message, same processing happens. A Fast On command bypasses the use of the link record On Level and the Responder goes to 100% On. Standard Insteon response that is not controlled by the ISY.

Is the Hidden Door Sensor still positioned near the PLM? What level ISY firmware is being used?

Tap the button on the end of the Hidden Door Sensor. That will produce the first state change message. The heartbeat default time is 24 hours.

The linking process does not take the Hidden Door Sensor out of linking mode. It will time out in 4 minutes (approx) or can be taken out manually (see user guide for Set button sequence). It will not signal state changes until out of linking mode.

The motion sensor comm is at the furtherest edge of success. The Hops Left=0 is as bad as it gets and still function. No room for any interference. Would like to see Hops Left=2, Hops Left=1 is fine if it generally stays at 1. Fri 10/03/2014 12:16:36 : [iNST-SRX ] 02 50 2D.64.89 00.00.01 C3 11 01 LTONRR (01) Fri 10/03/2014 12:16:36 : [std-Group ] 2D.64.89-->Group=1, Max Hops=3, Hops Left=0 Fri 10/03/2014 12:16:36 : [iNST-ACK ] 02 62 1B.5D.49 0F 11 FF 06 LTONRR (FF) Fri 10/03/2014 12:16:36 : [iNST-SRX ] 02 50 1B.5D.49 28.CB.F2 2B 11 FF LTONRR (FF) Fri 10/03/2014 12:16:36 : [std-Direct Ack] 1B.5D.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

That is the first command and the Hidden Door Sensor did not respond to the three attempts. Make sure the 2B is not really a 28. Move the Hidden Door Sensor near the PLM if it is a 2413.

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Repeat the add process and post the event trace. Check the Insteon address for an 8/B, 0/D type misread. The query of the Insteon Engine is usually the first command issued which would mean the Hidden Door Sensor is not responding at all to that Insteon address.

The need to change to a different weather information provider was the result of WB starting to charge for the use of their APIs. Not something UDI initiated. UDI will have to confirm but I believe the underlying ISY firmware had to change to work with the HAM. Those changes cannot be rolled back to the 99i which was discontinued about 2 years ago, before the need to change weather source. I believe the 99i can be upgraded to a 994i for $99.

"1) During the day, the on level is still 50%. Nothing seems to change that." Unless part of the program was not posted there are no "In Scene" statements to set the On Level to 100% at Sunrise - 20 minutes. "2) Clicking the top stairs switch operates exactly as expected. One click, 50%, next click or two clicks = 100%." Normal for a device that is physically controlling the load. "3) Clicking the bottom stairs switch doesn't work as expected. If light is off, one click is 50%, next click does nothing, but indicator lights go to 100%" A remote Controller directs the Responder to turn On to the linked On Level. Going to 100% on second click is unique to the device that is physically controlling the load. That does not apply to a remote Controller. The double tap sends a Fast On which ignores the defined On Level of the Responder and the Responder goes 100% On. The described results are normal. ISY Program(s) can change the results of the remote Controller.

"no detectable changes in events recorded for either setting." Check the Motion Sensor link table for a FF 00 01. My MS stops sending Group Cleanup Direct with retry=0

"I tried to "stop" the program via the drop down menu during a cycle " Stopping the Program means the Enable statement did not execute, leaving the trigger Program Disabled.

"will send an On to scene 1 when activated and an off to scene 2 when decactivated (close to the magnet)." It sends an On to Scene 2, I think, when closed and jumper removed..

It is possible to do that. It requires some ISY programming for that type of logic. Making A,B,C Responders to the ON/OFF button will get those button LEDs to turn On/Off with with the ON/OFF buttons. Turning the ON button Off when A,B,C have been turned Off is where ISY programming is required.

Like anything else it depends on your skill level. I find it easy to program as the Admin Console insures the statements are structurally correct. No need to learn the physical format of each statement. If you have no previous programming experience then there is learning curve for sure. Some folks are experts, some chose to use examples from others and learn little. UDI has a 30 day return policy so if it is too difficult return it. Most folks do not have major issues but it will be based on your past experience and willingness to learn new things.

Setting the PLM retry count to 0 does suppress the Group Cleanup Direct traffic to the PLM. Your second trace shows no Group Cleanup Direct was sent to the PLM.

Remove it from the Scene and add it back as a Controller. The question of Controller or Responder is asked before a device is added to a Scene.

Both the KPL button and switch controlling the load must be Controllers in the ISY scene.

Only PLM comm can have the retry count adjusted. A Scene link between a MS and Responder will always generate at least one Group Cleanup Direct message. If ACKed that would be the end of the Group Cleanup Direct messages. If not ACKed the Responder would receive another Group Cleanup Direct message. These are messages that have been used forever which makes me think they are not responsible for a 20 second delay in traffic.

Sorry, I do not understand the two conditions. Every Insteon device sending an On/Off command sends a Group Broadcast message and a Group Cleanup Direct message. Insteon has worked this way from the beginning 2005. The Group Cleanup Direct message is normally ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 00.00.01 CB 13 00 LTOFFRR(00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->Group=1, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [DOF] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] DOF 0 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [sT] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] ST 0 Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 41 13 01 LTOFFRR(01) Wed 10/01/2014 10:48:13 AM : [std-Cleanup ] 1C.FD.D5-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Wed 10/01/2014 10:48:13 AM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 13.01.01 CB 06 00 (00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->13.01.01, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [iNST-INFO ] Previous message ignored. The Group Cleanup Direct was not ignored in your situation because a Fast On, Scene On and Fast Off were issued by the Program delaying the Group Cleanup Message to the point where it looks like another On scenario. For I2CS devices the retry count can be set. This is for the IO Linc I used in my trace. I think rather than adding a Wait or changing the retry count your Program could be split into two sections. The first Then invokes Program 2 which does a Disable of Program 1 so the command activity generated by Program 2 will not allow the delayed Group Cleanup Direct from triggering Program 1.

If Err is only blinking LED power off the unit and check the SD card to be sure it is seated correctly. if Mem and Err blinking the ISY cannot connect to the Ethernet network.