It basically communicates to the cloud to get humidity, co2 and temperature readings.
I have more and more and these 'cloud' devices although I try to stay with zwave for home automation.
I would like an easy way to receive an SMS notification if some of these cloud devices stop responding. It seems like it be useful to just create a rule check for the "Connection Status" of devices that support this capability:
I can create a rule to look for a custom attribute but it's odd to me there's no standardized attribute or method. I saw there's a " HealthCheck" capability but since most cloud based devices already do polling or use web sockets or mqqt, that seems redundant.
I would like something in this space to get developed, but with the view of being a simple offering for the simpler and smaller scaled situations where people may need something like this.
I posed a similar proposal some time ago, though not as succinctly with the concept of leveraging a capability definition. In my head my thought process involved a similar concept, promoting the idea of different Community drivers implementing a consistent way of reporting connectivity or status. This was prompted by me thinking about how some of my integrations at the time like Kasa and deConz reported (included an attribute) for things like a connection status, then translating this to how did I want to set this up in some of my cloud-based drivers. I was also dabbling in "device" status reporting for the various third-party hubs I have in my setup, whether they be Bond, Hue, SensorPush, various Raspberry Pi's or even my laptop.
The outcome from that conversation, for me, is reflected in @martyn 's response. Although I have not implemented it fully. There are other systems better designed to track and report network infrastructure, (Nagios is not the only one out there). Systems like this allow for keeping track (and history) of "server" and service status, offering alerting and other settings to allow for periods where outages are expected.
So I see a capability still as being a worthwhile addition, providing that simple, easily accessible option for both developers and users to make use of this information within HE where there are just a few devices / servers being tracked. For a broader setup, there may be more appropriate systems out there.
Don't think that's what any user of a "smart home" should be doing. Besides, all these 'could based' devices are already doing polling or something similar. No need for separate monitoring of home devices.
The point of the Hub failing or internet connection going down is a good point. But I think that can be addressed by making the Hub itself a "device" that reports connectionStatus or something similar and having appropriate rules to fine tune the user experience with notifications.
That's why I support what you are suggesting be available in a capability, something that able to be available to use alongside what was discussed on the topic I linked.
I would not want the default position for monitoring of IoT devices in particular to be "you need to setup Nagios on another system like a rpi or NAS". Along the same lines as people's desire to have local, simple charts available on HE, there are some basic, yet powerful things that could be done by having a consistent way for devices to represent their status. If you then want to go further and use a purpose built system you can take that step, but you don't have to if you don't want to.
The only caveat I would add is if there are a number of LAN / cloud devices you are wanting to keep tabs on, then that may not scale, but again, the simple and limited use cases are certainly manageable.
It's not a standard capability yet, but Hubitat seems to be using a custom networkStatus attribute on newer drivers to represent some statuses like this (for example, telnet, where this is actually part of the capability; and an upcoming LAN device integration app that you'll see when 2.3.3 is released). A few community drivers have used presence for this in the past due to the lack you noted; I would not suggest that, given that it is intended for physical presence devices and can be confusing for users to see unexpected devices in apps that want to use that kind of device.
My suggestion would be to follow this convention and use a custom attribute, probably networkStatus, though since it's custom (usually), it doesn't really matter right now. Maybe some day it will be standardized. What you've suggested is probably also good, then if it ever changes at the platform level, you could adjust if needed.
But the Rule Machine issue is a separate one; while the dropdown lists some of the most common capabilities and the "primary" attribute most people would want from them (e.g., motion for a motion sensor), it doesn't list all of them. Using "Custom Attribute" in a trigger or condition is still necessary even for some standard/capability attributes, and it's only a couple extra clicks. Even if such a platform-level attribute is added doesn't mean Rule Machine would make it easier to get to.
