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.