Question:
Do all Zigbee sensors "check in" occasionally?
And, if they do so on a regular basis, can this be used to determine if that Zigbee device is still operational (i.e. still on the Zigbee mesh)?
I believe (not 100% sure) that, for example, many Xiaomi/Aqara sensors check in approximately every hour.
Do others (e.g. NYCE, Audurosmart, RGBGenie, Samsung, etc.) do the same thing?
Is there another approach to determining if the Zigbee sensor is still operational? For example, perhaps doing a custom action, and seeing if there is some activity by the sensor. In other words, is it possible to "wake up" Zigbee sensors?
There is an app by @bptworld called device watchdog that does this for you.
Here is an example of 3 sensors that are no longer used but I have left just to make sure the app is still working.
Unfortunately, results of that app have been inconclusive.
For example, an Adurasmart Motion Sensor NEVER checks in, and only reports when there is motion.
How can I check if that device is still operational?
Furthermore, my Xiaomi/Aqara devices sometimes go to sleep for hours, only to wake up!
(They start to show up on my device watchdog report, and get cleared up later.)
Perhaps I'm too much of an engineer, in that I want to know when something is broken. I don't want to be surprised later.
To add to device watchdog. I also use HE dashboard and have various dashboards for quick glance for update or dead sensor. Here's an example of my door/window contact sensors with Attribute/last updated tiles.
Any tile with no update longer than a day is questionable.
It all seems to depend on the device and driver. Most Zigbee devices check in when their primary operation occurs (open/close, motion, lux, temp, water, ...) some have secondary sensors like temp and will usually report on large changes of the secondary or occasional reporting to save battery, some devices are more interested in saving the battery than others then they usually drop the occasional reporting these devices usually don't have a secondary sensor and a lot of times they don't seem to report battery changes nearly at all making them not work with Device Watchdog, Sengled Door/Window sensors don't report except for open/close and very occasional battery level.
Most of my Zigbee devices check in regularly and so work well with Device Watchdog they are mostly Iris v2 or v3 contact, motion, keypads, and water sensors, I also have some SmartThings Motion and water sensors and a MCT-340 that report well as well.
So, what do you do about your smoke detector that hasn't checked in since 30/10/2019?
I'd bet "dollars to doughnuts" (a unique expression), that your sensor is still alive, and operational.
But, your activity monitor shows....
I think what you're doing and what you've read above is probably best, but some Zigbee devices will respond to a refresh() command and check in--for example, it makes my SmartThings Button and Iris v2 motion sensors report a new temperature reading. This is likely per-device (some may not even have this command available), so you'll have to see if it does anything for you on devices you care about. But most of my devices do report "secondary" attributes (temperature, etc.) with enough frequency that they more or less check in on a regular basis, even if less predictable than the hourly-ish basis like Xiaomi. I wouldn't go crazy with refresh(), especially on battery devices, but if you always run a Device Watchdog report at 6 PM for devices in, say, the last 72 hours, automating a refresh() every few days, possibly shortly before 6 PM, can't hurt.
Yeah, devices like those are tricky. Their button/remote is the same (it doesn't check in for battery reports, which you might expect to at least get once in a while even if it hasn't been used). I figure I'll notice when the button device isn't working and so don't need to depend on Device Watchdog for that; for the motion sensor, though, if you want to use it with Device Watchdog, you'll have to just pick an interval you feel comfortable enough with--a time period in which it should have seen motion (say, a couple days?)--and hope you don't go on vacation long enough for spurious notifications to matter. (That is, of course, unless you can force it to communicate with a refresh() or other command that you could run before the Device Watchdog reporting time.)
Related to this:
I've noticed this too. The trick with Device Watchdog is that you need to know how long your devices normally take to check in for something, and I have a "Device Watchdog - 1-Week Devices" child app (with a 168-hour gap allowed, maybe even a bit more) created for devices like these that are rather quiet under normal circumstances.
I figure it's either this or battery monitoring, and I trust this (despite being a bit more reactive than proactive--but as a bonus it helps you identify non-battery cases where a device may have fallen off) a lot more.
Just throwing another idea out there on how I solved this. I have NodeRed hooked up via web socket logging events and logs. I have a table in a MySQL database on my NAS, where NodeRed runs too, for all my battery devices. As an event comes in a trigger checks the battery table to see if that device ID exists and if so updates a time stamp. If the event is for battery it will also update the battery value there. Then I have a flow that runs every 24 hours and checks for battery records not updated within the last 24 hours and updates me via pushover. I also have a table of batteries in Grafana too that I sort by lowest battery level that I can view when I want.
Point of all of this is I get notified if something is off versus having to babysit this or view a dashboard.
(That is, of course, unless you can force it to communicate with a 
