LeeG Posted February 7, 2013 Share Posted February 7, 2013 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. Link to comment
az1324 Posted February 7, 2013 Share Posted February 7, 2013 Well to be honest there could be one node but then too many people would be asking "does On mean wet or dry?" All we need to know is that the leak sensor sent some message within the last 24 hours so it's alive. A heartbeat node would be kind of redundant. And like I said the status information is in the heartbeat so it's not going to mess anything up... and it has to be processed onto the Wet/Dry nodes anyway because it is a valid status message. Good to know about the message timeout and the cleanups. Link to comment
Michel Kohanim Posted February 7, 2013 Share Posted February 7, 2013 Hi LeeG, You are 100% correct. I never thought it through. So, we should add another node called Heartbeat that status of which is never changed but we would receive Control. i.e. we always get ON command for the heartbeat so the status never changes. Does everyone agree? With kind regards, Michel Link to comment
az1324 Posted February 7, 2013 Share Posted February 7, 2013 The heartbeats DO contain status information and you will NOT always get ON so they have to update the wet and dry nodes anyway. The question becomes is there any value in having a heartbeat node which would allow you to track the heartbeat messages separately? For me, all I want to know is whether the leak sensor has sent any message in the past 24hrs so I wouldn't need a separate node. But maybe you can think of a case where it is useful? Link to comment
LeeG Posted February 7, 2013 Share Posted February 7, 2013 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 Link to comment
LeeG Posted February 7, 2013 Share Posted February 7, 2013 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. Link to comment
az1324 Posted February 7, 2013 Share Posted February 7, 2013 Try this: Put leak sensor in "water" (i use a metal ruler) Push set button so that leak sensor sends group 1 message Wait 15 seconds You should receive heartbeat group 4 OFF which means sensor is wet Link to comment
Michel Kohanim Posted February 8, 2013 Share Posted February 8, 2013 Thank you both. Time to get working on this change. With kind regards, Michel Link to comment
az1324 Posted February 8, 2013 Share Posted February 8, 2013 LeeG Have you been able to determine if one or both of the group FF and parameter 03 values are the key to the cleanups being sent. For example, if 03 is changed to FF are they still sent? Link to comment
LeeG Posted February 8, 2013 Share Posted February 8, 2013 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. Link to comment
Michel Kohanim Posted February 8, 2013 Share Posted February 8, 2013 Hi LeeG, Reviewing your comments since we have just started the surgery. I need more clarification on this statement: 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 Thanks as always. With kind regards, Michel Link to comment
LeeG Posted February 8, 2013 Share Posted February 8, 2013 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. Link to comment
Michel Kohanim Posted February 8, 2013 Share Posted February 8, 2013 Hi LeeG, Thanks so very much for the clarification. I think that's what we have already implemented. Based on the documentation: To address: 0x00 0x00 0x04 Mode: Broadcast cmd: 0x11 = dry; 0x13 = Wet param: 0x04 And, this is what we have in our code: if (cmd == LIGHT_ON_INSTEON_COMMAND) { if (param == 0x01 || param == 0x04) { //Dry Set Dry Node to 255 Set Wet Node to 0 } else if (param == 0x02) { //Wet Set Wet Node to 255 Set Dry Node to 0 } } else if (param == LIGHT_OFF_INSTEON_COMMAND) { if (param == 0x04) { //Wet Set Wet Node to 255 Set Dry Node to 0 } } [/code] In short, I think all we need to do is to add group 0x04 as responder in PLM & controller in Leak Sensor and everything else should work as is. The main question becomes support. At the moment - and even though we might not have room in 99 - I think having a heartbeat node would be much easier for users. But, at the same time - and unlike the Wet/Dry nodes, the heartbeat node has both states combined into one. A little bit convoluted. What do you think? With kind regards, Michel Link to comment
LeeG Posted February 8, 2013 Share Posted February 8, 2013 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. Link to comment
Michel Kohanim Posted February 8, 2013 Share Posted February 8, 2013 Hi LeeG, I totally agree with you. At the moment, making an automated link is going to be a little problematic. I think we should agree that the unit has to be removed and then added back. The only remaining question is: can we assume Wet = On and Dry = Off. Does anyone have any problems with this? With kind regards, Michel Link to comment
Xathros Posted February 8, 2013 Share Posted February 8, 2013 Hi. I've been lurking in the background watching this thread. This makes the most sense to me. Both the remove and re-add to get all the nodes and On=Wet/Off=Dry. -Xathros Link to comment
LeeG Posted February 8, 2013 Share Posted February 8, 2013 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. Link to comment
Michel Kohanim Posted February 9, 2013 Share Posted February 9, 2013 Hi Xathros, thank you. Hi LeeG, thanks so very much. I do agree with you and we have to keep consistent with the underlying protocol. With kind regards, Michel Link to comment
az1324 Posted February 9, 2013 Share Posted February 9, 2013 Michel -- Have you fixed the links written to the leak sensor so that they are group FF and generate cleanups? LeeG -- Why do the users need to even think about the specifics of a heartbeat function? A heartbeat node only serves to cause more confusion for the average user. All they need to know is that the leak sensor will send a message every 24hrs if it is alive. Link to comment
Michel Kohanim Posted February 9, 2013 Share Posted February 9, 2013 Hello az1324, No, we only added group 4 (PLM is slave in the sensor and sensor is the master in the PLM). And, we have never had to add group 255 and thus it's something I am not comfortable doing without analysis. Confusion is going to be there regardless; I am confused myself! With kind regards, Michel Link to comment
LeeG Posted February 9, 2013 Share Posted February 9, 2013 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. Link to comment
az1324 Posted February 9, 2013 Share Posted February 9, 2013 Hello az1324, No, we only added group 4 (PLM is slave in the sensor and sensor is the master in the PLM). And, we have never had to add group 255 and thus it's something I am not comfortable doing without analysis. Confusion is going to be there regardless; I am confused myself! With kind regards, Michel It is still important to have the cleanups. The links should be something like the following: EDIT: LeeG confirmed that they need not be group 255 but instead have on-level 03. Sensor Links E2 01 13.AC.99 03 1F 01 E2 02 13.AC.99 03 1F 02 E2 04 13.AC.99 03 1F 04 PLM Links A2 01 21.7A.CC 00 00 00 A2 02 21.7A.CC 00 00 00 A2 04 21.7A.CC 00 00 00 az1324I 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. Status wet will still be status wet whether it comes from a heartbeat or a group 2. If control wet is switched on will still only happen when the sensor is wet. The only issue would be triggering on control dry is switched on to indicate going from a wet to dry status and I'm not sure if a combination trigger between status and control would be able to pick this up but even so I would not consider that information reliable and would still assume there is a leak. Link to comment
LeeG Posted February 9, 2013 Share Posted February 9, 2013 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. Link to comment
az1324 Posted February 9, 2013 Share Posted February 9, 2013 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'm not sure why you wouldn't want to know if it was still wet. But anyway, there is no perfect solution. I do think the situation is not resolved until we are sure the sensor is sending cleanups. Link to comment
LeeG Posted February 9, 2013 Share Posted February 9, 2013 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. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.