az1324

UPDATE: I was just looking at the I2CS dev note and it actually says that the value 0xFF in the Data 1 parameter means cleanups are disabled. Please refer to page 7. So there is the official documentation. Now the question is do you believe cleanups should be disabled (not sure why you would)? If not then maybe the value 0x03 should be used for all I2CS device controller records from now on. Or at least 0x01 for non-critical devices and 0x03 for critical sensors. Interested to hear your thoughts. This probably means none of the I2CS devices out there managed by ISY are sending cleanups, right? Thanks.

Well I don't see how it is risky to make sure the links you write are the same as what the device would write into its own database if it was sent a start linking command. In fact the opposite is true: writing a link that the device would NOT have written into its own database is risky, if anything. The fact that these are the two newest devices and they exhibit this means future devices could also do so. It's pretty simple to maintain an array of default link data values by dev cat and say if the dev cat is found in the array then replace the link values with the new defaults. Otherwise, do the same old same old. I do think the fact that these devices happen to be critical sensors makes it compelling to make sure the cleanups are sent. But I am interested to see what SH says on the issue of why the cleanups do not occur.

Well it is true that the information is not specified, but it seems the dev docs assume that you are going to use the built in All-Linking mechanisms to let the devices negotiate links with each other. So by choosing to manually write links, you are responsible for making sure those links contain the same parameters that would arise from the negotiated links. Of course it is disappointing that detailed information is not provided for those using this method. For some reason it seems that at least these two devices (Leak Sensor, Smoke Bridge) only send cleanups when the Data 1 parameter is a certain value (or possibly a valid range) but NOT the default value ISY uses of 0xFF. Now as long as you have a sample of the device in your possession, it is straightforward to create some auto-negotiated links and observe the Data 1 values and use them in your links. We know that a valid value for the Leak Sensor is 0x03. I would also think that as a valued partner you have a high-level contact at Smarthome that can provide better information on this and hopefully you would encourage them to add documentation to the developer's site as well for those who want to manually write links into devices. I suspect this problem may apply to other devices and will continue to apply to newly released devices. I think it is necessary to resolve this issue including examining what existing devices this applies to and put a policy in place for future device support. Presumably, this all ties back into the fact that status messages from these devices were labeled as broadcast messages but implemented as group broadcast messages. So I guess one could make the argument as to whether group cleanups are necessary, but it seems like if the functionality is available to improve the chances of message success then it should be used. As a side note, I have seen repeated references (including this thread) to unexpected values in the Cmd 2 parameter of group broadcast messages that imply this should contain the group number when from my understanding this is not true. The Cmd 2 parameter only contains the group number in group cleanup messages. In group broadcast messages the Cmd 2 parameter is specified to contain a default value of zero but in more recent devices it seems to contain extra information. However, that extra information is usually not necessary for interpreting the message correctly. Finally, could you please clarify which of the 7 possible status messages are supported for the Smoke Bridge in the latest ISY firmware?

Seems like this was another case of inactive group cleanups. Have the links been fixed for this (and the leak sensor) so that cleanups are sent? Are there any other devices out there that aren't sending cleanups due to link parameters?

Mine is set to 25 hours. No alerts.

My PLM is v63. The question is do you have any other wireless-only devices working?

Interesting, but not sure why it would use that info as a filter since aren't all Insteon devices capable of group cleanup behavior? If you get bored, see what values work and which don't.

Excellent work. Unfortunately it is not documented in the dev notes.

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.

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 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.

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.

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?

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

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?

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.

No it is processed correctly according to the logic posted earlier by Michel (aside from the typo at line 16) because the state of the sensor is sent within the heartbeat. So a heartbeat could either cause a group Dry ON or group Wet ON event along with the corresponding OFF event. It won't cause an incorrect sensor state to be reported. Questions that remain: Does the sensor still send wet messages every 15 seconds if it has successfully cleaned up all responders? Do the wet messages continue every 15 seconds ad infinitum or is there a timed cutoff?

I've already received many group 4 heartbeats at the 24h interval so they are definitely working properly on their own. I guess as Michel says the only solution is to add all 3 links to the PLM for each sensor. In addition, if the links are going to be written manually into the leak sensor, they should be changed to group FF and the parameters adjusted if necessary so that group cleanups are sent. It's unfortunate that there is not a pass-all type responder link that can be written into the PLM. I don't think any change to the nodes or processing is necessary. A heartbeat program can simply ensure that one of the nodes has been switched on within the last 24hrs.

I get that part, but what I'm saying is that if that test PLM with only one link passes both group 2 & group 4 messages to the serial port then why shouldn't ISY be receiving those as well unless it is filtering them out itself and not the PLM.

That is what I thought too until you posted the following which showed group 2 and 4 messages coming through with cleanups: So where did those messages come from?

Ok I know that when the destination for a message is group FF then members of any group respond to it but this is a record in the link db that specifies group FF which I thought was strange because the leak sensor says it uses group 1. Is the opposite true that if the responder's link db record specifies group FF then it sees all other group messages? This is what I have seen: sensor has group 1 & 2 controller records, PLM has only group 1 & 2 responder records = no group 4 messages passed but they are still sent from the sensor, no cleanups sensor has group 1 through 4 controller records, PLM has group 1 through 4 responder records = group 4 messages are passed, no cleanups This is what LeeG has seen? sensor has only group FF controller record, PLM has only group FF responder record = all group messages (1,2,4) are passed, cleanups are sent LeeG can you confirm the link record on the PLM side?

Interesting because the group is FF. So on the PLM side there is also a single group FF responder link but all the group messages (01,02,04) get passed on via serial?

Hmm that is interesting what link records are in the sensor in that case? The group flag being a mistake refers to the documentation and the fact that there was intent to conserve link records.

Yes in fact you are correct and I had it backwards. A leak sensor will still send out all its messages even with no link records in its database (after factory reset). But in order for ISY to receive the group 4 message from the PLM there must be a link record on that side. So a half link would still work, but on the PLM side. Obviously there is not really any value to saving a record on the leak sensor side so may as well make it a full link. So from the information we have, the group flag being set is the mistake. Unfortunately the only solution seems to be adding the group 4 link unless they plan to recall all of these devices.

Well I would use the PLM as the responder address just for consistency but yes a half-link (sounds Tolkien). Since there are no cleanups then it really doesn't matter it's basically a flag to enable the heartbeats.

Maybe just write a dummy group 4 link record into the sensors? They don't send cleanups so the link doesn't have to be valid. Unless there is some other undocumented way to enable the heartbeats, but really I doubt conserving a link on the sensor side is going to be a concern. Just as an update, I changed my heartbeat program to a 25 hour window and it's working fine, no missed heartbeats yet.