The config.reachable is a device specific matter, the rather large 24h timeout is due the fact that the legacy code to integrate devices was limited in knowledge about device details.
For example: there are switches which sleep for ever until a button is pressed, some sensors ping the gateway every x minutes, some once per hour. Without knowing this the plugin can’t determine when a (sleeping) device is actually not reachable.
With DDF we have now a way to express such information if needed, so this could be a good feature to add in future versions.
Beside the lastseen and state.lastupdated there is also a more detailed API output available via /devices/<device-mac-address> endpoint:
For example:
192.168.2.34:80/api/12345/devices/00:15:8d:00:01:0f:fd:66
{
"lastannounced": null,
"lastseen": "2022-04-24T18:47Z",
"manufacturername": "LUMI",
"modelid": "lumi.sensor_ht",
"name": "Xiaomi round humi",
"productid": "Aqara temp./hum. sensor WSDCGQ01LM",
"subdevices": [
{
"config": {
"battery": {
"lastupdated": "2022-04-24T10:27:37Z",
"value": 38
},
"offset": {
"lastupdated": "2022-04-21T23:39:03Z",
"value": 0
},
"on": {
"lastupdated": "2022-03-27T13:32:30Z",
"value": true
},
"reachable": {
"lastupdated": "2022-03-27T13:58:16Z",
"value": true
}
},
"state": {
"temperature": {
"lastupdated": "2022-04-24T20:47:04Z",
"value": -2094
}
},
"type": "ZHATemperature",
"uniqueid": "00:15:8d:00:01:0f:fd:66-01-0402"
},
{
"config": {
"battery": {
"lastupdated": "2022-04-24T10:27:37Z",
"value": 38
},
"offset": {
"lastupdated": "2022-04-21T23:39:03Z",
"value": 0
},
"on": {
"lastupdated": "2022-03-27T13:32:30Z",
"value": true
},
"reachable": {
"lastupdated": "2022-03-27T13:58:16Z",
"value": true
}
},
"state": {
"humidity": {
"lastupdated": "2022-04-24T20:47:04Z",
"value": 7920
}
},
"type": "ZHAHumidity",
"uniqueid": "00:15:8d:00:01:0f:fd:66-01-0405"
}
],
"swversion": "20160516",
"uniqueid": "00:15:8d:00:01:0f:fd:66"
}
For most Xiaomi sensors the config.battery field is updated roughly once per hour, so the timestamp of this field could be used to determine if the sensor still has it’s connection.
A few thoughts about your sensors going silent:
In most cases where Xiaomi sensors stop sending it’s not the battery or a bad coordinator, but the fact that (old) Xiaomi sensors stubbornly stick to their parent, and don’t try to reconnect. They only work great if their routers are always on and don’t remove the sensor from the child table.
I think the T1 Xiaomi Aqara line has improved this, but I have only tested the switches so far.
I want deCONZ to poll non-powered/battery-powered devices more often than once a day. That would be a solution, not one of many workarounds.
The coordinator can’t poll sleeping end devices, while they are sleeping, they don’t answer after the initial pairing phase. Xiaomi sensors usually only wake up once per hour for a report if no other measurements are send in between, we call them “deep sleepers”. The sensor reports are one way “send only” so even if the sensor reports a temperature value, it ignores commands from the coordinator right after it. Good for battery, bad for communication.
There are other sensors which work way more robust and can even be reached by the coordinator since they wake up more often, e.g. Philips Hue motion sensor checks if it looses connection to the parent and reconnects automatically, it’s also a “light sleeper” waking up every few seconds and can be reconfigured.
But as mentioned earlier the biggest problem is that some devices don’t handle re-connection properly.
