Not sure if this is exactly what this thread is about, but I wish there was someway to know when a device drops off the network.
I have a Zigbee sensor on my mailbox that lets me know when I get mail. It has worked great. We don't get much mail anymore so it can go days without sounding. Yesterday I realized it had been quite a while. Looked at the events and it hadn't shown anything for several days. Went out to the mail box, end of driveway, and there was mail but no alert. So I replaced the battery. When I did the indicator light started blinking which means it was in pairing mode. I had to re-pair it to get it to work. There was nothing wrong with the battery as it turned out. So have no idea why it would have dropped off the network.
You mean like a built in device watchdog of sorts? I'd love that. Right on the devices page, another column for how long a device has been non-responsive.
If it is raining outside and time between on/off for sump pump exceeds a threshold that indicates a failing pump or float switch. You could also monitor compressor run times on appliances/HVAC to know if its failing too.
I get it, edge cases, but still useful information.
I'm thinking something like mashup of that app and
The second app requires having the healthStatus capability. I could see something like the new ZigBee status feature for the last message time being added to all devices by the platform to be used with that app. Then the usage tracker features of how long something is on an active state.
I am going to share my sure to be unpopular opinion. I do not want the platform tracking devices. Sure, having the data points available for users to do it on their own is great but I'd rather it not be built-in.
A major reason I jumped to Hubitat, over five years ago, was SmartThings' poor implementation of "Device Health". The platform deciding certain functioning devices were offline would render a significant potion of my house dumb. My wife wasn't pleased as I was working away from home 30 weeks per year and wasn't there to cycle all of the switches on a daily basis.
I am hesitant to ask the hub to do any more behind the scenes. Remember, there is a finite amount of resources in our little hub. I don't want to shorten my already pathetic reboot cycle (5 days) because of something else that eats memory. A couple of years ago I'd go about six weeks before the hub would get a little sluggish, but each shiny new platform feature has cut into that.
I'm paranoid that even the @thebearmay 's excellent Hub Information driver consumes resources and haven't been running it regularly. I imagine that self monitoring memory, etc, would be impossible without it, but I wouldn't even know if there's a way to remotely reboot or shutdown without it.
I'm not taking sides for or against the feature request (mostly because what part of it I would use already exists through some other means), but just answering this question.
Knowing whether the intervals between sump pump cycles are getting shorter or longer is critical information for us during a hurricane, or the 3-6" of rain we got earlier this month. I've got a whole section of dashboard dedicated to it. Is the soil saturated so much that the sump pump is running? How often? Is the soil getting more saturated, or beginning to dry out?
Getting this data from the sump pump is a proxy for keeping a close watch on the septic tank. We know from experience by levels of soil saturation just how the septic system is doing. I've got a camera in the septic tank (as one does) but monitoring this dashboard is a lot more pleasant.
Not the full mesh. You need something like an Xbee and it's software XCTU to do a full mapping. The hub will only show what it's aware of (devices 1 hop or less away). So if an end device is on a router and that router is going through another router, it will not show up in the hubs routing table.
So anything that shows up from this is those items that are directly connected to the hub? All the other devices are connected back thru those direct devices? Is that correct?
This wasn't quite my intent, but I did leave it somewhat open in my title at least. And not to say I disagree, something in this space would be quite popular, as are the Community developed options, acknowledging the difficulties that can come with assessing the health of a device
Yes, that and the earlier Light on Table conversation / app from Bruce was where I started to notice people asking for this most recently.
The Device Health Status @FriedCheese2006 linked might be a step further than what I had in mind, being more in the monitoring space, which again I did not clarify in my original post. Again, a great idea / app, just not where I was heading.
I share your concerns @bjcowles, both in terms of the HE hub reporting a health status and the resource potentially required to deliver it. I could understand it would be problematic to deliver a single status that is reliable across all devices that are often unreliable in their behaviour and reporting. I think capturing various data points to support users achieve what they need is likely the right balance.
The kind of thing I have in mind would be a single attribute that captures the time of the last full period of a key state, such as the total time the device was ON. Once the device next turns off, the attribute would get updated. A preference setting could be included to turn this feature on or off, to reduce load on the hub. I would expect the default would be off, as it is not likely to be a widely used feature.
People could track the events linked to this attribute to see a short history of the periods of the device being on, without need to setup rules to calculate / capture it. The same setup could apply to contact sensors being open, presence, motion activity, etc. The inverse may also be relevant, off, closed, inactive, etc.
The more I think about this the more I think it is likely to be an App, rather than asking for changes to ALL built-in drivers That doesn't change (too much I hope) my idea of a process of selectively recording an attribute against devices for the most recent time spent in a specific state. While the capability may need to change, hopefully this does not require a change to the drivers that implement it.
That doesn't change (too much I hope) my idea of a process of selectively recording an attribute against devices for the most recent time spent in a specific state. While the capability may need to change, hopefully this does not require a change to the drivers that implement it.
