Problem with a simple program

[Goose66]

I have the following program intended to keep the status light for a KPL button assigned as a controller for an All Lights scene in sync when the lights are turned on or off individually:

If
       Status  'Master Suite / Left Sconce' is not Off
    Or Status  'Master Suite / Right Sconce' is not Off
    Or Status  'Master Suite / Fan Light' is not Off

Then
       Wait  1 second
       Set Scene 'Master Suite / Keypad-All Lights (Status)' On

Else
       Wait  1 second
       Set Scene 'Master Suite / Keypad-All Lights (Status)' Off

The "Master Suite / Keypad-All Lights (Status)" scene is a scene with just the KPL button and is used to turn the status light for the button on and off.

 

Inevitably, when I go to bed at night, my wife has turned off all the lights, but that button is still On. I will turn on a light from the bed, then turn the light back off a few seconds later, but the KPL button remains lit.

 

However, if I get up and go sit at my computer (which is not in the Master Bedroom), start the ISY Admin console, clear the log, and then travel back and forth between the computer and the bedroom to perform tests, checking the status of the lights, the KPL button, and the program periodically, and then review the log, it is all perfect. Everytime it works. Every test combination I can conceive of works. It is almost like this only works if the Admin console is running and I am moving back and forth between the rooms. But the next night, when I go to bed, all the lights will be off, but that damn KPL button will be lit.

 

Can anyone see an obvious flaw in the program that I am just missing?

[oberkc]

The program looks to me like it should work. Maybe I am missing something.

 

Alternatively, is it possible that your ISY/PLM is not consistently seeing the changes in status. That is, until you open the admin panel and perform some query. I suggest opening the event viewer and running through some tests on your two sconces and fan light to be sure it shows up when you turn them off and on.

[Michel Kohanim]

Hi kingwr,

 

Any specific reason for the wait? It's possible that while waiting, the program becomes false and therefore the KPL button stays lit.

 

With kind regards,

Michel

[LeeG]

Are any of the three lights on a dimmer such that one of the lights might look Off but not be at absolute Off. If any of the three were in that condition the KPL button LED would remain On. Try leaving the Admin Console up for a few nights so that when it happens you can look at the current status ISY thinks exists.

[Goose66]

Michel,

 

The WAIT is to "de-bounce" the switch. It seems that the statuses of the devices in a scene as reflected in the ISY change from on to off, for example, in a somewhat random order when you scene OFF is received (from the All-Off KPL button). This was causing the program to be performed multiple times and leaving the light in an incosistent state. By placing the WAIT in program, it will be preempted by the subsequent program runs and the last run of the program should evaluate the conditions in their final state.

 

I left the Admin console running last night and the light worked this morning. Also, my slow fade-up of lights (my alarm clock) worked this morning, it did not work Tuesday. I may have comm. issues on my PLM, but would the Admin console running make a difference in the comm. issues?

[Goose66]

I will have to chat with the wife about the dimmer thing. I asked her how she turned the lights off and she said she pushed the button, but she may be pressing and holding it until the lights all fade down. I will inquire further. However, I will say that when the condition happens, if I go check the status of the devices in the ISY, they show as OFF, as well as the status of the KPL button. But the light is still on. Again, pointing to comm. issues, but I can't recreate to save my life. Could be coincedence, I guess.

[Sub-Routine]

If the lights are not all responding at the same time that does indicate communication errors.

 

What if you increase the Wait?

 

Running the Admin Console should not cause the ISY to perform differently.

 

Rand

[Goose66]

The lights all respond at the same time, and without fail. But the lights and the All-Lights KPL button are all in the same room. The ISY is in the basement. It is the status of the lights in the ISY that don't seem to update in a simultaneous or predicatable order. Without the WAIT, when you would turn off all lights from the KPL button, the KPL button light would turn-off in response to the button press and then sometimes immediately turn back on, from the program running. It would then turn back off again, or remain lit, on a random basis. This, I surmised, was because the statuses in the ISY all don't turn to off at precisely the same time, and thus the program is run multiple times with the statuses in incosistent state. This was even more pronounced when an All-Off was selected from a ControlLinc in the room, which evidently doesn't use an OFF to a scene but simply sends individualy OFFs to all devices linked to the device. The WAIT 1 seem to fix this problem. I will increase the WAIT tonight and see if that helps.

[oberkc]

But the lights and the All-Lights KPL button are all in the same room. The ISY is in the basement.

 

This is not necessarily conclusive evidence of proximity to each other from an electrical path standpoint. Still, it may be a clue.

 

If we are beginning to suspect communication issues, I suggest trying a scene test on those scenes which may be misbehaving, or include many devices. This may provide a clue as to the robustness of communication.

 

but she may be pressing and holding it until the lights all fade down.

 

If this is a possibility, you may want to try different conditions in your program. Rather than using "not off", try "not on". I am also thinking that we can use condition such as "less than 10%", but I may be mistaken.

 

The WAIT is to "de-bounce" the switch.

 

The only time that I have found wait statements useful is with X-10 commands.

 

Also, I cannot remember from your earlier threads, but I wanted to confirm that you have access points properly installed, and if you use any filters on your computer system or other electronic devices.

[LeeG]

I apologize for this long response but the situation is complex. Knowing the Insteon command sequence will help in understanding the results.

 

When the KPL button is pressed a Group command sequence is initiated. First the KPL sends a Group Broadcast command which contains the KPL Insteon address and the Group number of the KPL button pressed. This command is not addressed to any specific Insteon device. Literally every Insteon device on the powerline receives this Group Broadcast message which causes each device, essentially simultaneously, to search its link database looking for a matching “Responder to†link record. All the devices that have been linked as a Responder to the KPL button will find a match and all devices will react nearly simultaneously to the command issued. This is why/how responders seem to all react at the same time.

 

The Group Broadcast is sent once and none of the responding devices send an ACK so the Controller (KPL) does not know if all or any of the responder devices actually saw the Group Broadcast. The KPL then sends a Group Cleanup Direct message to each linked responder individually. This message is ACKed by each responder in turn and if no ACK is received the KPL will resend the Group Cleanup Direct up to a total of three times. For the scenario going on here that means that a send of the Group Cleanup Direct and ACK response will occur for each responder. This is a total of 6 Insteon messages that flow to complete the KPL button press Group command sequence. It is actually worse than that as the KPL is also sending a Group Cleanup Direct message to the ISY/PLM as it is also a responder to the KPL button press.

 

The Insteon architecture understands that this Group command sequence may take some time and should another Group command sequence be detected by the KPL the KPL will abort the Group command sequence started from the KPL button press. This is standard Insteon Group processing and has been in effect for Insteon command flow forever.

 

The effect of this is that the Scene being initiated by the Program in response to a status change by one of the three lights could abort the KPL button Group command sequence and likely would if the ISY has good reaction time. Even software running on a PC can have this affect, cancelling the current Group processing. That is why “Wait†is needed. If would not be needed if a Direct command was being issued but since the Program is issuing a Scene/Group sequence the “Wait†is necessary.

 

If the powerline is good the Group Broadcast will have been seen by all the responders so visually everything looks right even if the Group command sequence is aborted. The problem is that if the Group command sequence is aborted (which is likely even with a 1 second Wait) the ISY will not see all the expected Group Cleanup Direct Insteon traffic. This is how software/firmware can get out of sync with the actual responder devices.

 

Try increasing the Wait time to 5 seconds. Should not need that much but it should take the Scene control being issued from the Program well away from the KPL Group command processing generated by the KPL button press. If the longer Wait delay provides stability to the results then the time can be reduced until unreliable results are seen.

 

Again, sorry for such a long winded response but Scene/Group command sequences and the fact that a Scene/Group will be aborted is not well understood. Not a problem for pure Insteon hardware but it plays havoc with software/firmware trying to track what the hardware is doing.

[Sub-Routine]

This, I surmised, was because the statuses in the ISY all don't turn to off at precisely the same time, and thus the program is run multiple times with the statuses in incosistent state.

 

When the ISY sees the group command it updates all the states, the ISY does not see cleanups to individual devices.

 

This was even more pronounced when an All-Off was selected from a ControlLinc in the room, which evidently doesn't use an OFF to a scene but simply sends individualy OFFs to all devices linked to the device. The WAIT 1 seem to fix this problem. I will increase the WAIT tonight and see if that helps.

 

But a ControLinc does use a group command for All On/Off/Brighten/Dim.

 

If the devices are not all reacting at the same time they are not seeing the group command and are reacting to the cleanup messages as Lee describes.

 

There must be something interfering. Try moving the CL to a different outlet. If that works we will have to look for something on the circuit the CL was plugged into originally.

 

Rand

[LeeG]

Rand, is it the Group Broadcast message or the Group Cleanup Direct that is sent specifically to the ISY/PLM (since each Controller paddle/button has the ISY/PLM as a Responder) that the ISY is responding to.

[Sub-Routine]

I see the Group Broadcast in the Event Viewer Lee. Group 255 for All commands.

 

Rand, is it the Group Broadcast message or the Group Cleanup Direct that is sent specifically to the ISY/PLM (since each Controller paddle/button has the ISY/PLM as a Responder) that the ISY is responding to.

[Goose66]

But a ControLinc does use a group command for All On/Off/Brighten/Dim.

If that is the case, then where is the scene for the All-On/All-Off buttons in the ISY? Why do the link tables for the devices and the ControlLincs themselves not show any type of group command, but simply show the direct links between the buttons and the devices? This is not consistent with there being a group command for All-On/All-Off buttons on the ControlLinc.

 

EDIT: Ok, I will have to lookup this group 255. But if that is the case, and there is no scene, then how does the ISY determine which devices are effected. Does it have to scan the database to find every device that is linked to the ControlLinc?

 

Further, I know very well that the program is run multiple times when the ControlLinc All-Off is pressed. I have seen it in action. So how do you explain that if all the device statuses are changed simulataneously from a single command from the ControlLinc?

[Michel Kohanim]

Hello kingwr,

 

Let me clarify:

All on/off sends a group command to group 255. The outcome of which is that all responders to "sender" go to the on level/ramp rate of the FIRST ever link for that controller/responder relationship.

 

So, in this vein, an All On/Off from ISY will have the PLM as the source. And, the status of devices are based on the first ever link for PLM (as controller) and device (as responder).

 

All On/Off from ControLinc/RemoteLinc have the source as the CL/RL and the on levels are based on the first ever link between the CL/RL and the responders.

 

The scene for ISY all on/off is the PLM id.

 

With kind regards,

Michel

[LeeG]

kingwr,

 

The All On/Off function on the RemoteLinc (and Controlinc) does not have a unique Scene definition per se. To understand how the All On/Off works it is necessary to understand how a normal Scene/Group is defined and works. A RemoteLinc button will have one or more responders linked to it. In this example RemoteLinc button 3 has three Responders A/B/C. The link records will look something like this for button 3 …

 

Three Link records In the RemoteLinc …

Group 3 - Controller of Responder A

Group 3 - Controller of Responder B

Group 3 - Controller of Responder C

 

One Link record in Responder A …

Responder to RemoteLinc Group 3

 

One Link record in Responder B …

Responder to RemoteLinc Group 3

 

One Link record in Responder C …

Responder to RemoteLinc Group 3

 

When RemoteLinc button 3 is pressed On the following commands are issued by the RemoteLinc

Group Broadcast from RemoteLinc Group 3 On

Group Cleanup Direct from RemoteLinc Group 3 to Responder A On

Group Cleanup Direct from RemoteLinc Group 3 to Responder B On

Group Cleanup Direct from RemoteLinc Group 3 to Responder C On

 

The Group Broadcast message will cause the three Responders A/B/C to turn On simultaneously. The Group Cleanup Direct commands follow up just in case a particular Responder did not see the Group Broadcast message. The Group Cleanup Direct commands require an ACK from each Responder and will be retried if an ACK is not received by the RemoteLinc from a given Responder.

 

When the All On button is pressed the RemoteLinc sends ONE command

Group Broadcast from RemoteLinc Group 255 Fast On

 

Just as in the case where button 3 (Group 3) is pressed, any device which has a Responder to link record with the RemoteLinc address and a matching Group number reacts to the Group Broadcast message. For the All On a specially architected Group number 255 is used. None of the Responders A/B/C actually have a link record with Group 255. The Responder firmware is coded such that for Group 255 only the RemoteLinc address has to match a Responder to link record in each Responder. Most RemoteLincs have Responders linked to each button. All Responders linked to all of the RemoteLinc buttons will respond to the Group 255 Fast On because the Responder to link record will match the RemoteLinc address and the Group/Button number is ignored when Group 255 is received.

 

The ISY has only one Controller and that is the PLM so all Responder devices which have a Responder to link record with the ISY PLM address will react to a Group 255 command. This generally does not have the granularity needed unless you want every Insteon device on the powerline to turn On or Off. Of course only those Responders with a Responder to link record with the ISY PLM address responds, not litterally every device on the powerline. Also just like any Group Broadcast command it is not ACKed or retried so it may not produce reliable results if the powerline is anything but absolutely perfect. Another reason why All On/Off is not normally attempted by software/firmware.

 

Anticipating someone running an Event Log level 3 trace of a RemoteLinc All On there are actually 2 Group Broadcast messages issued. This is not unique to the All On function. All RF based devices, Motion Sensors, TriggerLincs, RemoteLincs send the Group Broadcast message twice so it is a little more reliable than if only one Group Broadcast message was sent. When this was initially observed years ago when RF devices first appeared it was thought that the two Group Broadcast messages were the result of two Access Points picking up a Group sequence from an RF device. However, folks have removed all but one Access Point and two Group Broadcast messages still occur. I have not seen an explanation from SmartLabs or Smarthome why this is but all the RF devices I have traced send 2 Group Broadcast messages. You will see in the Event Log that the second Group Broadcast message is dropped as a duplicate, I assume so that Programs being triggered by a Group Broadcast message will not be triggered twice (only an assumption).

[Goose66]

Adding to the WAIT did not appear to help. However, I also tried putting a REPEAT 3 before the WAIT and the status light off, and that has helped. Again, pointing to unreliable communications. Further, I sat in bed last night with my iPad and MobiLinc and randomly turned lights and scenes on and off at 5 sec intervals for a number of minutes. I had a significant number (like 15%) of commands that did not come through. So I guess I will be troubleshooting communication issues, now.

 

They say the more devices you have, the more stable your network should be. It seems to me that my installation was more stable before adding a lot of extra devices and the ISY. For 2 years I never questioned the stability, and even allowed Insteon (through mControl) to handle the house while on vacation. Now I'm not so confident; its like being back with X10.

[oberkc]

I don't know about you, but the recent months and year at my house has seen an explosion of electronic devices added to my house. New TVs, bluray players, internet viewers, mediacenters, electronically-controlled appliances, and home theater equipment have all put a burden on the powerline quality. If your house is like mine in this regard, I am guessing that the relationship between communication and the additional insteon devices is coincidental and more related to other factors.

 

Perhaps there is a few recently-added devices in your house that you can unplug and see if this affects your insteon performance? If so, this would suggest that filters may be helpful. I also think it good practice to put your computer system on a filter, with the ISY/PLM outsie the filtered power.

[Goose66]

I do have filters in place on all UPS. All computers and networking/communicaiton equipment are connected to UPSs and thus behind the filters. Also, my stereo rack is behind a filter. However, these are old filters from the X10 days. I assume they are still useful.

 

I have added a few things, recently. I have DirecTV DECA and DirecTV SWiM both powered from bricks plugged-in in the same closet as the ISY wihtout a filter. Also, the nonshielded cable that runs between the ISY and the PLM could be a problem. While I think it is a serial cable, it is constructed like a CAT5 Ethernet cable. Perhaps making a shielded cable here would help.

 

I also need to completely reset and reconfigure my AccessPoints (4 of them spread about in a 4800 sqft home). Our cleaning service likes to unplug them to plug in the vacuum, and then sometimes only partially plugs it back in.

 

I also wonder about the load that my V2 thermostat adaptors place on the Insteon network. These are relatively new, as well (within the last year).

[oberkc]

I have added a few things, recently. I have DirecTV DECA and DirecTV SWiM both powered from bricks plugged-in in the same closet as the ISY wihtout a filter.

 

This is the first thing that I would be looking at. If these power supplies cause problems for the PLM, then EVERY scene is affected, since the PLM is part of every scene. It sounds as though these devices are such that you could live without them for a few minutes. A scene test with, then a scene test without, might give you a sense of the effect they are having on your network.

 

Yes, I also assume the old X-10 filters are effective to some degree. I continue to find it interesting that Smarthome does not actually sell "insteon filters".

 

I would not expect shielded cable to help. Most of your induced signal would be 60Hz, I assume. I doubt that this would cause a problem for the communication.

 

Interesting, your access points. I would be putting these in places where cleaning services would not disturb them.

[Brian H]

In the Smarthome wiki manual for the FilterLinc. It indicates being used by Insteon and X10 signaling.

 

http://wiki.smarthome.com/index.php?tit ... c_Features

 

Insteon is not that far away from X10s line frequency and it would not take much to slightly retune it to Insteon.

 

I retuned one of the three pin dryer outlet X10 couplers to the Insteon 131.65 KHz by changing a coil.

[oberkc]

In the Smarthome wiki manual for the FilterLinc. It indicates being used by Insteon and X10 signaling.

 

I stand corrected. In fact, I just checked the smarthome web page for the device and it claims insteon also. Either this page has changed recently, or I remember incorrectly. Probably the latter.

[Goose66]

Any instructions/demos/YouTubes out there for "tuning" an old filter?

[Brian H]

I think they may have quietly changed it to both Insteon and X10.

I do remember when it was only listed in the X10 Troubleshooting Section.

The specifications sheet on it still shows the 120KHz X10 frequency attenuation as 49.2dB. No data on the 131.65KHz Insteon line frequency.

 

Though I have seen a schematic of a FilterLinc. I have not seen any data on retuning one. Would require 5 new capacitors if my memory is correct and the ones in it now are not low tolerance ones so it maybe closer to Insteon than many expect.

 

The three pin passive dryer coupler was easy as it is just a capacitor and coil in series from line to line. I can look at what I did.

[gerwitz]

This is a wonderful old thread, I learned a lot from Lee's description of communications, and others.

 

But I'm left wondering: is kingwr's approach for keeping a KeypadLinc button "in sync" with a set of SwitchLincs the appropriate way to do this?

 

The light status would be a nice touch, but my ultimate goal is to use a single keypad button to mean "scene off" in the most reliable, responsive way possible. Currently I use a "if control off or control on" program to disable a scene, which works well enough, but I'm intrigued by this approach.