LeeG

The thermostat does not respond to the Scene when using Fast On. Need to use the On command.

Show Device Links Table will display the link records in the thermostat.

Sorry, I have not accurately described the conditions. When the Group Cleanup Direct messages for Group 2 and Group 4 were traced the PLM had other links. I had done a Set button link between the Leak Sensor and the PLM but had not cleared the PLM of other link records that had been established for testing of Group 4 messages. I factory reset the PLM, relinked to the Leak Sensor with the Set button, which is the configuration I have been using for these last series of tests. With these last tests the PLM started out with only a Responder link for Group 2 which was established with the Set button link. With that as the only link record in the PLM the only thing being passed out from the PLM were messages for Group 2. I added a Responder link for Group 1 to the PLM at which point I now get Group 1 and Group 2 messages. These include the Group Cleanup Direct messages because of the unusual Controller link record in the Leak Sensor that it created when I Set button linked with the PLM. Something in that link record directs the Leak Sensor to include sending Group Cleanup Direct messages. I have not yet seen a Group 4 message of any kind since I factory reset the PLM. Have not yet reached a full 24 hours yet. Once that time passes I will add a responder link in the PLM for Group 4. I expect at that point to see Group 4 messages. That activity will not be done until this evening when I get back. After that I will change one of the existing responder link records to Group FF and erase the other links to see if that allows the PLM to pass all Group numbers

What kind of responder link records were generated in the thermostat to support this Scene that is changing Heat and Cool set points with the same Scene number. It would be unusual for a device to react to multiple responder link records with the same Scene number.

The Group Cleanup Direct messages are generated as a result of that Set button generated link record in the Leak Sensor. That is the only link record in the Leak Sensor for the test PLM 13.AC.99 0FE8 : E2 FF 13.AC.99 03 1F 01 Obviously the Group number (FF) is unusual but the On Level (03) and Unit number (01) are also values that might have some control over whether the Leak Sensor sends Group Cleanup Direct messages or not. Since what I would call conventional Controller link records generated by the ISY when the device is add do not result in the Cleanup messages, something in the above link record is controlling. I would hope something in the Developer information would explain what is directing the Leak Sensor to send the Cleanup messages.

With the following link record in the Leak Sensor which was generated by the Leak Sensor when it was Set button linked to a PLM 0FE8 : E2 FF 13.AC.99 03 1F 01 the Leak Sensor is sending a Group 2 On with a tap of the Set button on the Leak Sensor. The following link record was generated in the PLM by the Set button link with the Leak Sensor A2 02 21.7A.CC 00 00 00 I was not getting a Group 1 On with a tap of the Set button on the Leak Sensor until I added a Responder link for Group 1 to the PLM A2 01 21.7A.CC 00 00 00 With both Responder link records in the PLM and the single Controller link record in the Leak Sensor I now get Group 1 On and Group 2 On. I have not yet seen a Group 4 On without a Responder link in the PLM for Group 4. It has not been 24 hours with this link record configuration in the PLM. Since the PLM did not pass the Group 1 On message to the application until the PLM had a Responder link for Group 1 I suspect the PLM will not pass a Group 4 On to the application until the PLM has a Responder link for Group 4. I am waiting a full 24 hour cycle without the Responder link for Group 4 to confirm this. Once a full 24 hours has passed I will add a Responder link for Group 4 to the PLM and see if Group 4 On message is then passed to the application. I believe with the Responder link for Group 4 in the PLM the Group 4 Heartbeat message will be passed to the application. It appears like the single odd looking Set button generated link record in the Leak Sensor causes the Leak Sensor to send Group 1,2,4 On messages. The PLM, a v92 2413U, only passes those Group x On messages to the application for which it has an equivalent Responder link record. EDIT: "Is the opposite true that if the responder's link db record specifies group FF then it sees all other group messages?" I don't know the answer to that question yet. The initial evaluation of what messages are received by the application is using the Set button link generated link record in the PLM. I wanted to see what the results were when the links were generated by the hardware/firmware of the respective device. Since the PLM firmware was written long before the existence of a Leak Sensor I am not surprised that the PLM requires a conventional link record for each Group it passes On to the application. Once I confirm the Group 4 On will not be seen by the application without a Group 4 responder link in the PLM I can change the PLM link record to Group FF as the only responder link for the Leak Sensor Insteon address and see what messages the PLM passes to the application. It will be Wednesday evening EST before I can run those tests. I will be out of town for most of the day Wednesday.

When a Motion Sensor LED blinks several times when motion is sensed it indicates the motion sensor is not getting an ACK from one of the Responders. This can be a comm issue including RF problems or a Responder has lost a link record so it does not see the motion sensor messages and thus does not send an ACK. A PLM should not lose link records. It does happen from time to time based on the number of times a Restore Modem (PLM) resolves a problem but some might be attributed to an accidental factory reset of the PLM. I have one very old PLM that does lose its link records pretty consistently. It is not connected to any of my ISYs and is used primary for testing against a very old PLM. If it were not that it still functions for powerline communication I would have junked it long ago.

Since there are no Adjust Scene statements in the posted information it must be the KPL itself that is returning to the last Bright (On Level). The newest SwitchLincs have a Resume Bright feature. It may be the latest KPLs have the same feature. What is the KPL firmware level? It is displayed on the second line in the right pane when the KPL node is selected.

barrygordon Insteon does not support X10 devices in a Scene. An ISY Program can be triggered by whatever device paddle/button is controlling the Scene and the Program can issue X10 commands. If the Scene is being turned On/Off by a device paddle/button and an ISY Program will issue the X10 commands, add a Wait 2-3 seconds before issuing the X10 commands. The Scene commands being issued by the device paddle/button press can interfere with the X10 commands if a Wait 2-3 seconds is not used.

oberkc makes an excellent point about the wiring. The electrician should install the wiring as if the light and fan will be controlled by separate switches on the wall. This will support the installation of a FanLinc in the Fan/Light housing but also allows the restoration to a manual switch configuration if the house is sold without Insteon. Some consider the existence of automation a plus, some consider it a minus. Beyond the Fan/Light question, make sure ever box has a Line and a Neutral. Minor difference in wiring cost (if any) but makes it much easier to install Insteon devices at a later time.

A single link record for that particular PLM - I generated with the Set button so the Leak Sensor generated the actual link record. I don't have a subscription so hopefully your doc will explain the details. 0FE8 : E2 FF 13.AC.99 03 1F 01

I'd like to run an existing scene at a level dimmer than called for in the scene. (1) Is that possible? (Set Scene doesn't offer a % level at which to set the scene.) Yes, with an Adjust Scene Program statement. However, it requires an Adjust Scene statement for each Responder so if there are lots of Responders it will take lots of Program statements. (2) If not possible, is there an easier way to do this other than just making another scene with different on levels? I tried setting the scene to level "Brighten" and repeated that 5 times, but that seems to overwhelm the ISY - sometimes it takes a very long time to come up. (3) The obvious way appears to me to be just to make another scene with the different on levels. There are a LOT of devices in each scene I want to do this with - is there an easy way to copy a scene to a new scene? I don't think so but anyone who knows of a way please jump in.

I’m not sure the group bit is a mistake in the broadcast message. With the right format link record the Leak Sensor generates the standard Group Cleanup Direct message. 0 :11 0250 217ACC 000002 C71102 0 :11 0250 217ACC 000002 C71102 0 :11 0250 217ACC 13AC99 411102 0 :11 0250 217ACC 110102 C70600 0 :11 0250 217ACC 110102 C70600 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 13AC99 411104 0 :11 0250 217ACC 110104 C30600 0 :11 0250 217ACC 110104 C70600

An Insteon Direct command cannot affect a Secondary KPL LED, either On or Off, because the Direct command has no placeholder to identify the specific Secondary button. As a Responder to a Scene the specific Secondary KPL button is identified so the KPL button LED can be turned On or Off with a Scene.

jjwinston Post the Program(s) involved. Right click Program name, select Copy to Clipboard and paste to forum. Also the Scene(s) involved. Images are still being suppressed so unless you have the means to put the images on another host Server simply define the Scenes with text Scene X What are the Controllers What are the Responders Scene Y What are the Controllers What are the Responders etc. As Mike already mentioned using Main A or button H on the same KPL as the Controller the outlet level is controlled by the Local On Level. When the controller is not a KPL button on the KPL with the load attached, then the KPL response is determined by the Responder On Level for the respective controller. Insteon is very flexible regarding how each Controller can have a different Responder On Level for each Responder but it makes changing those values on the fly more complex. The ISY does so much automatically when ISY Scenes are defined or altered through the Admin Console it is not always obvious just how many different values have to be changed dynamically to make it all work together. That is why it is important to see the actual Programs posted along with the Scene definitions. If not on 3.3.10 that should also be an activity. Earlier images going back to 3.2.6 might not be getting the Local On Level set correctly. Also if on an earlier image now, once on 3.3.10 right click the KPL primary node, select Diagnostics | Query Insteon Engine to be sure the ISY has the correct Insteon Engine information.

"Would I make this new ISY scene to include the ControLinc (as controller) and ONE of the devices (matching one of the buttons on the ControLinc) to be controlled (as responder)?" Exactly right. Define an ISY Scene, add the ControLinc button as a Controller and the device as a Responder. "If so, how does this scene know which button on the ControLinc is linked to this device? If this is correct, I would then make a new scene for each of the buttons on the ControLinc?" When the ControLinc is/was added to the ISY there were six nodes defined, one for each ControLinc button. When a ControLinc button is pressed it sends a message to the ISY which indicates which button was pressed. That way the ISY knows which ControLinc button just turned On or Off and what Responder(s) to mark On or Off as appropriate. Yes, each ControLinc button requires a different ISY Scene with the ControLinc button as Controller and whatever devices that should be controlled by that button as Responders. Insteon limits each button such that it can be a Controller in only one Scene. However, a Responder can be controlled by multiple buttons and therefore can appear as a Responder in multiple Scenes. EDIT: when I discussed each ControLinc button, I am referring to each On/Off button pair as a single button. Each On/Off button pair has the same button identifier. The ISY knows whether the On or Off button is pressed by the command that is sent to the ISY.

oberkc An If Control 'xxxxx' is not switched Off by itself does not trigger a Program when a On command is received. Independent of the not, If Control must match the command received, Off in the example, for the Program to be triggered. Easy enough to verify. Code up a test Program that contains an If Control 'xxxxx' is not switched Off as the only thing in the If section. Tap the On paddle. The Program does not trigger, True or False as the command received does not match that specified in the If Control. The only thing that triggers the test Program is an Off command and it always drives the Else because the 'not' results in False.

That half link should not work anyway unless the PLM is not following protocol requirements. Those messages are Group Broadcast messages. The Leak Sensor would send a Group Broadcast message for Group 4 but the PLM should not pass it to the application (ISY) without a corresponding Group 4 Responder link.

Either And or Or works. This is one of those 'what I think' answers rather than 'what I know'. Because If Control is looking at a specific command flow the condition being checked can only exist for the split second the ISY is analyzing the inbound command from the device. It makes And a useless construct where If Control And If Control are involved as that could never be True. I think based on that the And is actually treated as an Or when If Control is combined with If Control. What I think rather than what I know. It certainly looks more logically correct to code it as If Control 'xxxxx' is switched On Or Control 'xxxxx' is switched Fast On but tests show either And or Or produce the same result.

Get rid of the Else in the first Program! As coded whether the If is True (between Sunset and Sunrise) or False (during the day) the same thing happens, invoking Program 2.

dimensionzero If Control looks at the commands coming from the device. With If Control the command from the device must match the command specified in the If Control statement for the Program to trigger. If Control 'xxxxxx' is switched On is looking for the On command and if found triggers the Program. The Then clause runs because it 'is switched On' is True If Control 'xxxxxx' is not switched Off is looking for the Off command and if found triggers the Program. The Else clause runs because 'is not switched Off' is False because of the 'not'.

Program 1 If From Sunset To Sunrise (next day) And ( Elk Zone 'garage1' is violated or Elk Zone 'garage2' is violated ) Then Run Program 2 Else Program 2 If Then Send X10 '03/On (3)' Set 'garagecornerflood' On wait 2 minutes send x10 '03/off (11)' set 'garagecornerflood' off Else

It would be good to post your actual Program. Right click Program name, select Copy to Clipboard and paste to the forum. Did you add the parens as noted earlier by someone If From Sunset To Sunrise (next day) And ( Elk Zone 'garage1' is violated or Elk Zone 'garage2' is violated ) Without the parens the Elk Zone is not included in the Time range check. EDIT: also the statements in the Else run when the If is False which means they run day and night, any time the Program is triggered and the If is False. Requires using two Programs so the Wait is not bothered by the If reevaluation. Was the Program broken into two Programs

Sorry, I should have been more clear. A message with Max Hops=1 Hops Left=0 is great. It means the device message made it from the device to the PLM on the first attempt. A message with Max Hops=3 Hops Left=0 is bad. Also situations where Max Hops=3 and Hops Left=x count is varying from message to message is an indication of problems. Finding Insteon comm problems is a challenge. I always suggest starting at the beginning. Be sure the PLM is plugged into an outlet, not a surge/noise suppression power strip. Other electronics powered from the same circuit (PC, UPS, etc) as the PLM should be isolated with a FilterLinc. Then start analyzing communication with various devices around the Insteon network. Using the Admin Console with the Event Viewer running at LEVEL 3, turn various devices On and Off and watch the Hops Left=x counts. Messages from the PLM will have Max Hops=3 so Hops Left=2 is the best, Hops Left=1 is okay if the count remains consistent over several command executions, Hops Left=0 does not leave any room for additional sporadic noise or signal absorption. As mentioned before if Hops Left=x count is changing from command execution to command execution to the same device, that indicates problems even if some have Hops Left=2. It is common to have some change in Hops Left=x count if enough commands are sent. By analyzing what devices have good comm and what devices have marginal/bad comm a pattern may evolve. All the marginal devices are on one circuit for example would require looking at what is powered from the circuit. It can be useful to unplug (not turn Off) appliances/devices to see if that improves comm on a particular circuit. Some cell phone chargers have been known to destroy comm in the area where they are plugged. Other devices can cause the same type of problem. The first thing is determine how well comm is working around the structure and then evaluate what is causing problem areas. Not a particularly fun project and time consuming but there are no good Insteon based devices for Insteon network analysis. Some of the X10 tools can be used to measure the noise level. Insteon is on a different frequency and Insteon messages start earlier in the AC cycle but I have used an X10 Monterey Powerline Signal Analyzer to successfully locate noise. It is an expensive tool from my attempts to get X10 to run many years ago. Only if you already have something like that. I would not suggest getting one for Insteon.

redsfancfp The ISY Program characteristic that is key here is using Wait and/or Repeat statements allows the Program If section to be reevaluated when something the If is checking has changed. Without a Wait or Repeat statement the If section is not reevaluated. The change in state/status often results in the If going from True (running the Then clause) to False (running the Else clause). When this happens the statements after the Wait or Repeat in the Then clause are not executed. One solution is to split the single Program into two Programs where the If in the second Program has nothing to be reevaluated. Another solution is to add logic in the Else clause that executes when the If reevaluation drives the Else clause. It is the possible reevaluation of the If when a Wait or Repeat statement is used that is the driving force. Whether additional logic is added to the Else or the single Program is split into two Programs with nothing in either Else clause are two of the possible solutions. Understanding the implications of using a Wait or Repeat statement which allows If reevaluation is most important in understanding how to code ISY Programs.