If it works, that’s all that really matters…
Most ZigBee clusters support reporting of their attributes based on settable thresholds. The most common thresholds are:
- Report on new value
- Report on new Max value
- Report on new Min value
- Minimum reporting time
The minimum reporting time is exactly what you guys are looking for. Lets say it is set for 5 minutes. The device will report its attribute at-least every 5 minutes regardless of the value. This will send a report packet to the hub every 5 minutes and can be used by some type of watchdog method or app to make sure the device is still alive. No polling is required. Now, there are a couple of additional things that need to happen for this work. First off in order for attribute reporting to work correctly, the ZigBee device must be bound to the hub correctly. If its not the reports will not be received by the hub. It is possible to read attributes (send a read attribute request) and get the results if your device is not bound correctly. So just because you can poll a device and get the results doesn’t mean that bit is correct. The second gotcha is in the SmartThings cloud. By default a SmartThings device handler will not fire an update event if an attribute’s value doesn’t change. So if your device sends its minimum report with say a value of 61 but your attributes value is already 61 then your device handler will not fire an event so a smart app that may be looking at this will not know an update has occurred. To get around this use the isStateChange: true attribute in your custom device type. Here is an example of how I use it when my parse method detects a temperature report from one of my devices.
send(name: "temperature", value: Math.round(obs.temp_f), unit: "F", isStateChange: true)
Now that you have all this working the next bit will be to write a smart app that monitors the time stamp of the data. Here is a screen shot of the temperature data and you can see it is reporting every 10 minutes and at 6:00am and at 6:10 this morning it reported 61F two times in a row. If I didn’t have isStateChange: true set it would have missed the 6:10 report.
As you may have guessed you have touched on a hot topic for me. Lets take this one step further. So you have gone to all this trouble to create a “watch dog” smart app for this device, and now lets say the connection to your iPhone is down or the SmartThings cloud is down. Your SmartApp that is monitoring this device will have no way of alerting you. If this was truly mission critical what you could do is create a physical device that sits on your ZigBee network and receives updates from the cloud and alerts you if it doesn’t get an update from the cloud on regular intervals. Put this device on your desk or in the kitchen and when it turns red and starts to beep you know something is wrong! That is what my analog panel meter in the June 2016 Nuts and Volts is all about.
1 Like
Awesome, thanks for the response. This is basically what I ended up doing but with a bit of a hack in the sense of using the approx. arrival time capability to pass a datetime. As the datetime is always different it gets propagated but very useful to know about that flag!
Can we have a hint at what it might do?