LeeG

I'm not that bored.

Although I don't subscribe because of the NDA, enough of these situations where the doc is either missing or wrong makes me wonder how useful a subscription really is. In the past a Controller Set button link stored the Responder cat/subcat values in the On Level and Ramp Rate fields. Never heard of a case where this information was used in the past. Perhaps the 03 is taken as a PLM responder and generates the Group Cleanup Direct. Pure speculation.

I changed the On Level of FF to 03 for the two ISY Leak Sensor link records. The 03 On Level produces the Group Cleanup Direct messages. I would have thought that detail was covered in the Developer information. 0 : 0FF8 : E2 01 19.70.06 03 1F 01 1 : 0FF0 : E2 02 19.70.06 03 1F 02 Fri 02/08/2013 11:14:22 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.02 CB 11 02 LTONRR (02) Fri 02/08/2013 11:14:22 PM : [std-Group ] 21.7A.CC-->Group=2, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:22 PM : [ 21 7A CC 2] DON 2 Fri 02/08/2013 11:14:22 PM : [ 21 7A CC 2] ST 255 Fri 02/08/2013 11:14:22 PM : [ 21 7A CC 1] ST 0 Fri 02/08/2013 11:14:23 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.02 CB 11 02 LTONRR (02) Fri 02/08/2013 11:14:23 PM : [std-Group ] 21.7A.CC-->Group=2, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:23 PM : [iNST-DUP ] Previous message ignored. Fri 02/08/2013 11:14:25 PM : [iNST-SRX ] 02 50 21.7A.CC 19.70.06 41 11 02 LTONRR (02) Fri 02/08/2013 11:14:25 PM : [std-Cleanup ] 21.7A.CC-->ISY/PLM Group=2, Max Hops=1, Hops Left=0 Fri 02/08/2013 11:14:25 PM : [iNST-DUP ] Previous message ignored. Fri 02/08/2013 11:14:26 PM : [iNST-SRX ] 02 50 21.7A.CC 11.02.02 C7 06 00 (00) Fri 02/08/2013 11:14:26 PM : [std-Group ] 21.7A.CC-->11.02.02, Max Hops=3, Hops Left=1 Fri 02/08/2013 11:14:27 PM : [iNST-SRX ] 02 50 21.7A.CC 11.02.02 CB 06 00 (00) Fri 02/08/2013 11:14:27 PM : [std-Group ] 21.7A.CC-->11.02.02, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:33 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.01 CB 11 01 LTONRR (01) Fri 02/08/2013 11:14:33 PM : [std-Group ] 21.7A.CC-->Group=1, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:33 PM : [ 21 7A CC 1] DON 1 Fri 02/08/2013 11:14:33 PM : [ 21 7A CC 1] ST 255 Fri 02/08/2013 11:14:33 PM : [ 21 7A CC 2] ST 0 Fri 02/08/2013 11:14:34 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.01 CB 11 01 LTONRR (01) Fri 02/08/2013 11:14:34 PM : [std-Group ] 21.7A.CC-->Group=1, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:34 PM : [iNST-DUP ] Previous message ignored. Fri 02/08/2013 11:14:35 PM : [iNST-SRX ] 02 50 21.7A.CC 19.70.06 41 11 01 LTONRR (01) Fri 02/08/2013 11:14:35 PM : [std-Cleanup ] 21.7A.CC-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Fri 02/08/2013 11:14:35 PM : [iNST-DUP ] Previous message ignored. Fri 02/08/2013 11:14:36 PM : [iNST-SRX ] 02 50 21.7A.CC 11.02.01 CB 06 00 (00) Fri 02/08/2013 11:14:36 PM : [std-Group ] 21.7A.CC-->11.02.01, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:38 PM : [iNST-SRX ] 02 50 21.7A.CC 11.02.01 CB 06 00 (00) Fri 02/08/2013 11:14:38 PM : [std-Group ] 21.7A.CC-->11.02.01, Max Hops=3, Hops Left=2 Fri 02/08/2013 11:14:38 PM : [iNST-DUP ] Previous message ignored.

"If I want to have the light "dimmable", do both controlling switches have to be dimmers or just the controlling one on the load?" Only the switch physically controlling the load needs to be a Dimmer. "And if I can mix and match, will the dimmer status show correctly on a linked on/off switchlinc?" No. SwitchLinc Relay devices do not have all the status LEDs installed as a dimmer has. It cannot show mid point status because there are no LEDs in the mid points.

If the Leak Sensor links are defined that way only one is needed although that would introduce a mismatch between the number of links in the device versus the number in the PLM. Actually the Leak Sensor should have three links regardless of their content. "If control wet is switched on will still only happen when the sensor is wet." That is true, except not only does the Program trigger when it goes Wet but hours later it will trigger again when the Leak Sensor has not detected a change in Wet/Dry status. "I would not consider that information reliable and would still assume there is a leak." And that is the problem, what you assume and what 100 other users assume may not be the same, even amoung those 100 users it may not be a consensus. By overlapping heartbeat with the primary Wet/Dry node function an option the user has today will not be there tomorrow. Actually I would like to drop this discussion unless there is a technical question. We are just repeating our individual opinions at this point which is not providing useful information to UDI. I have provided my opinion and that is all it is, my opinion. UDI will evaluate cost to develop and test the various possibilities and chose what makes sense when all factors are considered.

az1324 Has the ISY added a Heartbeat node? I think it is the right thing to do but I have not seen Michel indicate that will happen. Only that the links have been created so the ISY will be aware of the Group 4 messages. I think the user will be more confused if having to content with simulated Wet/Dry node traffic resulting from the heartbeat than checking a heartbeat node. It means the user cannot use If Control with the Wet/Dry nodes and know that they actually were generated by the Leak Sensor. They could indicate a Leak Sensor has changed Wet/Dry states or it could mean a heartbeat has been received.

When running the Scene On/Off away from home how do you know the responders actually turned On? The Hops Left=1 is okay, Hops Left=2 is best. The fact that Hops Left=0 happens at times when the Hops Left=1 is the normal means comm to that device is marginal and may well be unreliable with a Scene On/Off where there is no automatic retry. EDIT: if looking at Fri 02/08/2013 02:42:54 PM : [ 20 84 56 1] ST 255 Fri 02/08/2013 02:43:05 PM : [ 20 84 56 1] ST 0 these simply reflect what the ISY thinks happened because of the Scene definition. There is no feedback from any device with a Scene On/Off that it actually worked.

No. If Control command must match the inbound command to trigger the Program. Without an If Control Off the Program is not triggered. To get the Else clause to run the If must evaluate to False. To achieve both conditions, match the command and be False add a not. If Control 'xxxx' is switched On or Control 'xxxx' is not switched Off Then runs when On is received Else runs when Off is received. Controls works a little differently than Status. Any Status change triggers the Program. Control must match the command for the Program to be triggered.

Turning the Scene On/Off with the Admin Console generates the same Insteon command as when a Program sends a Scene On/Off. If the results are different it is environmental. Easy to verify. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Turn the Scene On with the Admin Console and run the Program to turn the Scene On. The same Insteon command is issued. If the physical results vary (device turns On some of the time) it is comm related. Could also be other things the Program is doing which is affecting comm.

I have no problem requiring a Delete and readd. "can we assume Wet = On and Dry = Off." I think that is reversed if referring to the Heartbeat command received. All my Heartbeat Group 4 messages have been On (Leak Sensor Dry - out of water). The only time I saw a Heartbeat Group 4 Off was that sequence az1324 described. Put the Leak Sensor in water so it goes Wet as expected. Tap the Set button to force a Dry Group sequence even though the Leak Sensor is still Wet. The Heartbeat Group 4 message that is generated after the Set button tap is sent with an Off command. I assumed this means that the normal Heartbeat message in 24 hours comes back with an Off command when the Leak Sensor is Wet at the time of the 24 hour Heartbeat. I have not tested that. The 24 hour Heartbeat message that comes back has an On command when the Leak Sensor is actually Dry.

I think memory has that reversed. Turning the Scene On the ISY marks the SWL On based on how the Scene is defined, not with knowledge the SWL actually turned On. If a Direct command marks the SWL On it is because the SWL responded with an ACK indicating the On command was accepted. It is the ACK (or lack of it) that allows the PLM to automatically retry. If the SWL ACKs the On command but does not turn On physically that is a SWL issue. Really don't think that is the case.

“Currently, the ISY (controller) is setup as a direct link to the device (responder) not as a scene. “ I don’t understand what this means. How was a direct link established between the ISY PLM and the device? If you are talking about the links established when the device was added to the ISY those links are fine. No need to do anything with these links nor should anything be done with these links. They are needed for the ISY to function correctly. By the way what is the “device� Is this the ToggleLinc? 1) Remove the link between the ControLinc and the device (first link) Yes – the direct link should be removed. 2) Remove the device from the admin console on my ISY (second link) No – this is the ToggleLinc (?), there is no reason to Delete this device from the ISY 3) Create an ISY scene with one of the ControLinc buttons (Controller) and the device (responder) Yes - ControLinc button is Controller, ToggleLinc is Responder 4) Add a device (responder) on my ISY for the ToggeLinc to be controlled by MobiLinc This is where I get confused. If the ToggleLinc is already defined to the ISY there is no reason to Delete it as mentioned above. Besides if the ToggleLinc is Deleted from the ISY it cannot be added to an ISY Scene. However, devices are not added to the ISY with the choice of making them Controllers or Responders. The ISY adds them as a Controller or Responder based on the device capability. In the case of a ToggleLinc it is added as a Controller because it has both Controller and Responder capability. Selecting whether a device is added to a Scene as a Controller or Responder is the only place that choice is made.

"With the MS NOT in the scene, and the SWL as a controller and the only device in the scene.... it would seem all the on/off commands are received from the MS, and the program operates as expected, however... the status of the SWL in the ISY switches to ON, but the lights have not come on. Then, when it goes to turn them off... I get the communications error." This is a result of a comm problem between the SWL and the ISY PLM. Things work with the MS as a Controller in the Scene because commands flow from the MS to the SWL directly. That path must be okay if the SWL responds reliably. The path were the Program turns the Scene On/Off is not reliable because there is no command retry between the ISY PLM and the SWL where a Program driven Scene On/Off is involved. When comm is spotty Scene On/Off is often where issues surface.

Michel Personally I prefer the Heartbeat as a separate node. I realize there is not a Heartbeat node now because of the confusion caused by the Developer doc. However, I think it more confusing to the user to explain the Heartbeat function is merged with the Dry/Wet nodes because the original Developer doc was wrong. Better to have new Heartbeat node with explanation that the Developer doc has been corrected/clarified. There is a logistical problem with having a separate Heartbeat node. How do you get a new node for the users that have already installed Leak Sensor(s)? For that matter how do you get an additional Controller link for Group 4 in the Leak Sensor and Responder link for Group 4 in the PLM? Do users have to Delete and readd the Leak Sensor(s) to get the link records and Heartbeat node? I see this as a big enough reason to merge the Heartbeat function into the existing Wet/Dry nodes if there is a means to have the link records added without Deleting the Leak Sensor(s). Perhaps that magic stuff that happens when a new image is installed. I don't see having On and Off for Heartbeat as a problem. That is what SmartLabs engineered. The Heartbeat check would be If Control 'Leak Sensor - Heartbeat' is switched On Or Control 'Leak Sensor - Heartbeat' is switched Off Then Wait 24-36 hours do something - email, light On/Off, whatever user feels is appropriate for missing heartbeat. To summarize, I prefer a Heartbeat node and I do not mind having to Delete the Leak Sensor to get it but understand the logistics problem of getting a new node for users who already have Leak Sensor(s) installed may dictate merging the Heartbeat function into the existing Wet/Dry nodes. How about that for being wishy washy. Each solution has to be weighed against the cost and complexity to implement and test. I cannot do that effectively. I find either solution acceptable.

Michel There is a situation at 3.3.10 related to KPL LED Backlight level. The first trace entry is from the Admin Console setting the LED Brightness to a value of 7/15, the maximum values for Off level and On level, The second trace entry is from a Program "Set 'KPL Relay DB v40' 50% (Backlight Level)" for the same device. Note both of these activities generated the same command with the same data. Yet the Admin Console is setting to max values, and the Program is setting to 50% Fri 02/08/2013 09:03:44 AM : [iNST-TX-I2 ] 02 62 19 21 DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B Fri 02/08/2013 09:03:44 AM : [iNST-ACK ] 02 62 19.21.DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06 (00) Fri 02/08/2013 09:03:44 AM : [iNST-SRX ] 02 50 19.21.DA 19.70.06 2B 2E 00 (00) Fri 02/08/2013 09:03:44 AM : [std-Direct Ack] 19.21.DA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/08/2013 09:05:17 AM : [iNST-TX-I2 ] 02 62 19 21 DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B Fri 02/08/2013 09:05:17 AM : [iNST-ACK ] 02 62 19.21.DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06 (00) Fri 02/08/2013 09:05:18 AM : [iNST-SRX ] 02 50 19.21.DA 19.70.06 2B 2E 00 (00) Fri 02/08/2013 09:05:18 AM : [std-Direct Ack] 19.21.DA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 I verified Help | About show 3.3.10 for Firmware and UI (2487S) Dual Band KeypadLinc Relay v.40

If there will be no Heartbeat node for Group 4, instead a Group 4 On/Off will generate/simulate a response on the existing nodes, the simulated Group 1 On or simulated Group 2 On should match the current state of the Leak Sensor. If the Leak Sensor is currently Dry a Group 1 On should be simulated. If the Leak Sensor is currently Wet a Group 2 On should be simulated. The Status of the Leak Sensor should not change as a result of the Heartbeat. There will be ISY Programs monitoring the Status of the Leak Sensor for changes, producing email warnings or turning On/Off lights. The Heartbeat should not change the Status and produce a false change in Leak Sensor state. Don't want every 24 hours a false change to Wet generating a leak warning. Or have the Heartbeat produce a false change to Dry when the Leak Sensor is actually Wet. In addition to the example of how to test for the Heartbeat (If Control example with Wait) the users have to be told the Heartbeat will generate simulated Group 1 On (Dry) or simulated Group 2 On (Wet) messages to support the If Control tests for the Heartbeat. This situation has to be considered when implementing ISY Programs. Not only will it be possible to trigger a Program with an If Control 'Wet' is switched On or If Control 'Dry' is switched On because the Leak Sensor generates these conditions, the Heartbeat will simulate these same conditions.

It appears from the trace the following devices were set to specified LED Backlight level 1B 9C B6 – 24% 1D 35 5A – 50% 1D 35 BB – 50% 1F B6 D5 – 50% 1F B6 DA – 50% 1F BB F7 – 50% 20 42 40 – 50% Could be off a percentage point or so due to rounding. Which of these devices failed to set the correct LED Backlight level. Based on the command response these devices accepted the values. If one or more did not work what is the type of KPL and firmware level of KPL of those that did not work?

I have not tried to change that Set button created link record. I did put a Responder link record for Group FF in the PLM as the only responder link for the Leak Sensor. The PLM passed no messages to the application.

1) Remove ControLinc/Device link Yes, this Set button link should be unlinked. 2) Remove ISY/Device link. I take this to be an ISY Scene with the Device as either a Responder or Controller. If this is correct simply add the ControLinc button as a Controller of this ISY Scene. The Scene can be controlled from MobiLinc or the Device can be controlled from MobiLinc. Because the ControLinc is a Controller Only device (cannot be turned On/Off from another controller) nothing is lost by controlling the Device rather than controlling the ISY Scene. If there are other devices in this ISY Scene besides the Device and the ControLinc button than the Scene should be controlled from MobiLinc. If the "remove ISY/Device link" is not referring to an ISY Scene please clarify. 3) Create ISY scene with ControLinc as controller and device as responder. This depends on what is meant by “remove ISY/Device linkâ€. If this is not referring to an ISY Scene than I need to know what is meant by this before discussing a new ISY Scene. 4) MobiLinc?? - Use newly created scene to control device?? Because the ControLinc is a Controller Only device (cannot be turned On/Off from another controller) nothing is lost by controlling the Device rather than controlling the ISY Scene. If there are other devices in this ISY Scene besides the Device and the ControLinc button than the Scene should be controlled from MobiLinc.

Michel An additional confirmation that the Leak Sensor does generate and the PLM does pass on a Group 4 On Heartbeat in 24 hours. PLM does have a Responder link for Group 4. 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 13AC99 411104 0 :11 0250 217ACC 110104 C70600 0 :11 0250 217ACC 110104 C70600 The Group Cleanup Direct only occurs when the Controller link in the Leak Sensor has those values I posted earlier. If the Dry/Wet status is not changed by posting an additional command received in response to the Group 4 On, either Group 1 On or Group 2 On based on the current Dry/Wet state of the Leak Sensor, a Heartbeat node is not needed. Users would be instructed to code a Program with If Control ‘Leak Sensor – Dry’ is switched On or Control ‘Leak Sensor – Wet’ is switched On then Wait 24-36 hours do something appropriate to a heartbeat failure I will now run tests with a Responder link with FF as Group in the PLM to see if a single Controller link in the Leak Sensor and single Responder link in the PLM is sufficient to support Leak Sensor messages. EDIT: the PLM does not pass on messages when the only Responder link for the device has a FF for Group.

From the previous information I thought the problem was a Program is setting the LED Backlight level and the device is not responding. What I am trying to determine by asking for the Event Viewer trace is to verify that a command is being issued to set the backlight level and what the command and backlight level values are being used. Here are two samples of what is expected. The first trace is setting backlight level to 50%, the second is setting the backlight level to 80%. Need to know if these commands are being issued and with what values. Set 'KPL Relay DB v40' 50% (Backlight Level) Thu 02/07/2013 06:04:04 AM : [iNST-TX-I2 ] 02 62 19 21 DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B Thu 02/07/2013 06:04:04 AM : [iNST-ACK ] 02 62 19.21.DA 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06 (00) Thu 02/07/2013 06:04:04 AM : [iNST-SRX ] 02 50 19.21.DA 19.70.06 2B 2E 00 (00) Thu 02/07/2013 06:04:04 AM : [std-Direct Ack] 19.21.DA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Set 'KPL Relay DB v40' 80% (Backlight Level) Thu 02/07/2013 06:06:06 AM : [iNST-TX-I2 ] 02 62 19 21 DA 1F 2E 00 01 07 CC 00 00 00 00 00 00 00 00 00 00 FE Thu 02/07/2013 06:06:06 AM : [iNST-ACK ] 02 62 19.21.DA 1F 2E 00 01 07 CC 00 00 00 00 00 00 00 00 00 00 FE 06 (00) Thu 02/07/2013 06:06:06 AM : [iNST-SRX ] 02 50 19.21.DA 19.70.06 2B 2E 00 (00) Thu 02/07/2013 06:06:06 AM : [std-Direct Ack] 19.21.DA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

az1324 You have traced something other than On command from either Group 1, Group 2 or Group 4? EDIT: Also can you identify where the Leak Sensor current state is identified in these Heartbeat messages 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 13AC99 411104 0 :11 0250 217ACC 110104 C70600 0 :11 0250 217ACC 110104 C70600

az1324 I don't like any of that simulated state change stuff. The Dry and Wet nodes are there for a purpose. Trying to shoe horn in something to represent a Heartbeat simply to avoid the Leak Sensor having a Heartbeat node does not sound good to me. My Leak Sensor sends the Wet Group 2 On several times about 15 seconds apart (I did not time it) even with the Group Cleanup Direct messages being sent. After a minute or two the Leak Sensor stops sending the Group 2 On even though it is still Wet. No way to know the engineering thinking but it looks like they wanted to repeat enough Group 2 On messages to be certain the Wet indication was received.

Michel If a Group 1 On is simulated for each Group 4 On Heartbeat what does that do to the normal state of the Dry and Wet nodes. If the Leak Sensor is actually Wet (in water), node Dry=Off and node Wet=On. Does this simulated Group 1 On change the node pattern to Dry, marking node Dry=On and node Wet=Off even though the Leak Sensor is still actually Wet? That does not sound good to me. If the node pattern after the simulated Group 1 On is node Dry=On and node Wet=On that destroys the normal node pattern. Which node state is to be believed? This does not sound good to me either. az1324 I have no doubt the Heartbeat Group 4 On will be received in the next 24 hour cycle. Just want to see it happen as you have to complete that part of the test cycle. Once that is confirmed I will see if a single Responder link in the PLM with Group FF produces the same results as 3 individual Responder links. I don't like the idea of a mismatch in the number of link records in the Controller and Responder. If a single Group FF in the Leak Sensor is required to get the Group Cleanup Direct messages I would prefer a single link record in the PLM to match.

Michel It does look like the PLM is reacting the way it would be expected to react. It needs a Responder link for Group 4 before it will pass either a Group Broadcast or Group Cleanup Direct for Group 4. I did not receive a Group 4 On over a period of 26+ hours. Added the Responder link for Group 4 to the PLM and now receive Group 4 On in addition to the Group 1 On and Group 2 On I was receiving before. The following was generated by two Set button presses on the Leak Sensor. The Leak Sensor sends the Group 4 On a few seconds after the last Set button press messages. When the Leak Sensor is actually made Wet by placing in water or Dry by removing from water, the Group 4 On does not get generated. It will take another 24 hour period to confirm the Group 4 On Heartbeat happens without the Set button press. I feel certain it will send the Group 4 On Heartbeat in 24 hours. 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 000004 C71104 0 :11 0250 217ACC 000001 C31101 0 :11 0250 217ACC 000001 C71101 0 :11 0250 217ACC 13AC99 411101 0 :11 0250 217ACC 110101 C30600 0 :11 0250 217ACC 110101 C70600 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 000004 C71104 0 :11 0250 217ACC 13AC99 411104 0 :11 0250 217ACC 110104 C70600 0 :11 0250 217ACC 110104 C70600