It is troubling that the app often indicates information that isn’t true. For example, it may show a door sensor as being closed, when in fact the sensor has been removed from the network by removing the battery. But there is no way to tell this from the “things” status display.
It would be very useful if the devices showed whether or not they were actually functioning in the network, so that it was possible to tell if the information being provided was reliable.
Um, there isn’t any information being provided by a device with no power, so it is neither reliable nor false. What you’re talking about is the device’s appearance in the mobile app. The system isn’t really in the business of checking on the state of your devices; instead, the devices tell the system what their state is or when an event happens. If you open a door, then pull the battery on the contact sensor, you would expect the mobile app to show the door as open, until such time as it reports being closed. What other behavior would make sense? A device that has it’s battery pulled has no way to tell that to the system!
You can use an app to check on the battery status of devices, and alert you (there’s a built-in way to do this). So I suppose you could discover that the battery died (or was removed).
If you’re referring to the ‘Low battery warnings’ notifications on the Hello Home settings page, it doesn’t appear to work consistently. I had a device that went non-functional. When I checked the device status in the Things page, the battery status was at 1%, which I would think is clearly a low battery status. I never received a low battery notification for this device. When I replaced the batteries, the status was back at 100%, and the device began working again. I’ve submitted a ticket with ST support for this issue.
In other industries, heartbeat indicators are used for main connections and stale/stagnant value indicators are used for individual transmitters. This only goes so far… but if you know the device should check-in every so often and it hasn’t checked in for a long time then it’s reasonable to at least flag the data as stale.
Edit: This is especially important when you consider that the device is responsible for transmitting its battery level. So if the last reported battery level was normal then the device suddenly disconnected (eg. battery pull), then the system would never report an issue - this is where having an indication of the freshness of data is important.
But the whole point of mesh networks, z-wave and zigbee, is to use very low power, and accept that at any moment any given device may or may not be awake, or have a good battery. Both networks are designed to accept these dropouts of individual devices.
I wrote an app recently for someone who was concerned about lost batteries on embedded contact sensors. The app runs once an hour and looks at device logs. The particular device is supposed to report on some schedule. So the app can notify if there has been no log entry for longer than that.
Inability to communicate with a device is information, and very important information. In such a condition, the state of the device is unknown, and the app should not be indicating a state one way or the other. It should be indicating that the state is unknown.
The only behavior which makes sense to me is one in which knowledge of system state is bounded in some way. If a sensor in the network loses power, and my system will never tell me that within some configurable timeframe, IMO that’s a fundamentally unreliable design.
As discussed, a heartbeat protocol is the usual method to indicate normal operation and to synchronize status.
Sure, accepting dropouts is great. So long as there is a bound on knowing when such a thing has occurred. Otherwise we can never have any confidence that the state information is correct.
Many devices do report periodically, and their failure to report can be detected. As I said above, I wrote an app that checks this periodic reporting for contact sensors, and notifies if any of the monitored devices have not reported within the appropriate time frame. The particular use case for this was for Aeon z-wave recessed door sensors which report on a known schedule (4 hours or something). The nice thing about this approach is that it does not tax the battery any extra.
There is always a certain amount of non-determinism in a SmartThings system. At any given moment, the state of the system is, in fact, non-deterministic. Eventually, it’s state is known, after the fact. There are ways to work around this, but you can’t be certain about the state information. This isn’t as big a weakness as you might think. You just have to think through exactly what it is you need to know at any point in time for the system to function properly.
This is a fundamentally different approach than industrial systems that have complete real-time knowledge of all of the devices in the network. Of course, there is a huge difference in the cost.
I agree with the premise of this Topic that some way is highly desirable to have Things change their State to a “stale” or “unknown” value if the last check-in from the Device is unusually old.
I have an original SmartThings Multi on a back door… I put in on the outside to get outdoor temperature as well as open/closed.
Perhaps because of the cold or faulty batteries, the battery status went to 50% after a few days… And stayed there. Sudden death, apparently.
The Thing Tile (and therefore the status Attributes) show Contact Sensor as “closed”, Temperature as “62°”, and Battery as "50%“. In other words, it looks like a completely healthy Device until you see that the last Event (a battery value update) was more than 7 days ago, and realize that the door has opened many times with no status change… A serious security perimeter hole.
I know that many Devices must be “sleepy” to minimize power use, but since they all seem to wake periodically report something (battery, rssi, …), it is definitely possible to determine that the Device has failed or disconnected in a reasonable amount of time. Unfortunately, the Platform doesn’t offer a universal value of “stale”, so even if we put in external SmartApp(s) to check freshness of last logged data, there’s no easy way to indicate this in existing SmartDevice Type Handlers.
In other words, we need “Capability Freshness Reporting”, I guess, or a new Platform feature.
+1 on this. I work in the Human Machine Interface world and one of the hottest topics is data integrity. Data always has a quality stamp as to whether the data is trustworthy or not. We need something like this as I sometimes get alarmed when my door says it’s unlocked when it’s not, perhaps z-wave blip or whatever but I’d love to see a Red X or something next to it.
@Ben is this maybe something we can look forward to one day soon? (sorry if you’re the wrong person to ask, I don’t even know anymore since you guys are getting big which is good.)