Which version are you running now? You need >= 1.8.4.
E.g. From my setup. Only works if the value is provided by the app.
if you’re missing the information, please provide me with the following details
in my example:
"energyObj":{
"W":NULL,
"batteries":[
0:string"CR2032"
],1 item
or wherever you see the information you’re missing 
Could you make a then card to do this via flow?
Yes, added since - three new Flow cards for this:
And: “A specific device is paused” - check whether a device currently has an active pause.
Then:
All in the latest test version: 
Install Test version
Am on 1.9.0.
Yes some devices do not provide battery information. Am having issues with some Aqara devices but here we are talking about devolo heater devices that do have battery information like:
"energyObj":{
"W":NULL,
"batteries":[
0:string"AA",
1:string"AA"
],2 items
A devolo door sensor has no battery info too:
"energyObj":{
"W":NULL,
"batteries":[
0:string"CR123A"
],1 item
Aqara temp sensors with battery info are displayed:
"energyObj":{
"W":NULL,
"batteries":[
0:string"CR123A"
],1 item
Looks identical
Found it - real bug on my end. Turns out the battery type is reliably populated in energyObj.batteries, not energy.batteries (which I was reading) - checked against real devices, and energy.batteries was empty for the large majority even when energyObj.batteries had the correct value. Fixed in 1.9.3.
Also added a manual override for cases where Homey genuinely has nothing (sounds like your Aqara devices might be in that camp) - under a device’s “Details”, there’s now a free-text “Battery type (manual)” field. Whatever you type there shows up instead of the auto-detected value, both in the widget and the details view. Leave it empty and it keeps using auto-detection.
Fast reaction on a sunday morning. Where battery info available it‘s now displayed.
Thanks
Had a quick time slot please continue to report improvements. Can’t test them all since I don’t own all the different sensors 
Update (v1.9.5):
As always, happy to hear what’s working and what isn’t 
Was looking at my zwave sirene. Homey app had a popup. Something like: haven‘t seen the device a long time. Couldn‘t then open the device. Tried a „test“ with device watchdog. As the device is under: not watched no indication wether the test worked or not. Looks like it did. Only I get only an okay when the device is on the watched list. Is it possible to get an okay on test when device is on the not watched list?
Thx for the input. Just shipped v1.9.6 with a small addition: the Test button now shows a clear “✓ Reachable” (or the error) directly on the button itself for a couple of seconds after every test — regardless of whether the device is on the monitored list or not. Should give you the confirmation you were missing on that sirene.
Thanks. Works.
Just noticed when a device is on the not monitored the search function does not find it.
You are correct, they are under not monitored. I asumed when having selected all devices the search does include the not monitored ones too. Presently I have to remember to search 2 places. A bit confusing, or?
Will fix it next time online
That message now only appears when a search truly has zero results anywhere.
While I was in there, I also made search results easier to actually see: any zone group containing a match now auto-expands as you type, instead of leaving you to click open a collapsed zone to find what you just searched for.
Just had to restart my homey and watchdog tells me thirty something devices are not reporting. Now down to 9 devices. Any idea. Maybe wait a while after a restart bevor a scan starts?
Had a look at the last seen time stamp. After 18 min all have one. Started several scans via widget still some are not talking?
Script started at: 10.08.2026 15:11:03,403
Devolo PS_2 - vor 00:00:11 Std
Nous P2 - vor 00:00:11 Std
Nous P1 - vor 00:00:11 Std
H_Mari.Zi - vor 00:00:29 Std
H_Arb.Zi 1 - vor 00:00:38 Std
H_Schla.Zi. 2 - vor 00:00:51 Std
DP5 - vor 00:00:57 Std
H_Arb.Zi 2 - vor 00:00:59 Std
NP5 - vor 00:01:03 Std
Aqara plug 2 - vor 00:01:04 Std
Arb.Zi OG H1 3 - vor 00:01:07 Std
NP1 - vor 00:01:08 Std
Wandschalter H1 4 - vor 00:01:30 Std
QB1 - vor 00:01:48 Std
NP7 - vor 00:02:14 Std
Aqara Temp 14 - vor 00:02:14 Std
NP6 - vor 00:02:25 Std
H_Wohn.Zi - vor 00:02:38 Std
Aqara Temp 12 - vor 00:02:42 Std
H_Wohn.Zi. 2 - vor 00:02:51 Std
NP3 - vor 00:02:54 Std
Devolo PS_1 - vor 00:03:08 Std
H_EssZi. 2 - vor 00:03:17 Std
Heizkörperthermostat - vor 00:03:23 Std
Schlafzi. OG H1 2 - vor 00:03:26 Std
H_Schlaf-Zi - vor 00:03:26 Std
H_Kevin.Zi - vor 00:03:34 Std
Licht Wz. OG - vor 00:03:42 Std
Aqara Temp 10 - vor 00:03:49 Std
Aqara Temp 6 - vor 00:04:17 Std
DP3 - vor 00:04:31 Std
NP2 - vor 00:04:35 Std
Flood sensor Dach - vor 00:05:18 Std
Wall Plug 5 - vor 00:05:26 Std
BM 3 - vor 00:06:06 Std
Aqara doorS1 - vor 00:06:26 Std
Aqara Temp 5 - vor 00:08:48 Std
Aqara Temp 1 - vor 00:09:22 Std
LF - vor 00:09:31 Std
FP1 - vor 00:10:04 Std
RaumTh_2 - vor 00:10:33 Std
Fibaro_SS2 1 - vor 00:10:59 Std
Aqara Temp 2 - vor 00:15:05 Std
Aqara Temp 11 - vor 00:15:21 Std
Fibaro 2 (S1) - vor 00:17:57 Std
Sirene - vor 00:18:06 Std
FP2 - vor 00:18:13 Std
Wall Plug 4 - vor 00:18:13 Std
Aqara plug 1 - vor 00:18:13 Std
Aqara plug 4 - vor 00:18:13 Std
Aqara plug 3 - vor 00:18:14 Std
DP1 - vor 00:18:36 Std
Tür Eingang - vor 00:18:36 Std
DoorS_6o - vor 00:18:36 Std
DoorS_1 - vor 00:18:36 Std
Tür Balkon - vor 00:18:36 Std
BM 5 - vor 00:18:36 Std
BM 2 - vor 00:18:36 Std
BM 4 - vor 00:18:36 Std
FP3 - vor 00:18:40 Std
BM 1 - vor 00:18:47 Std
Thanks for the detailed report, that’s really useful. Two separate things going on there:
The initial burst (30+ → 9): Right after a Homey restart, the app’s own device cache isn’t fully settled yet when the first scan runs - that’s very likely what caused the temporary spike, exactly your own suspicion. Just shipped v1.9.8 with a new setting: “Wait after app start (minutes)” (default 2 min) - delays only that very first automatic scan after a restart, giving things time to settle first. Manual scans and every later scan are unaffected.
The remaining 9: Looking at your screenshot, most of those (window/door sensors, the flood sensor, rain sensor) show “last update” from days or even months ago (e.g. 23.3. for the flood sensor) - that’s unrelated to the restart, they’re just event-driven sensors that haven’t had a reason to send a new value in a while. Not a bug, just how event-driven devices work - see the FAQ entry on “not reporting” for more on that.
Think you can record in your log when you detect a device became available again? Would love to see some positiv entries too. 
That leads me to my next question. How many entries or how long do you keep the log?
Thanks again for the feedback - v1.9.9 added exactly that: the log now shows recoveries too (“device available again” / “reporting again” / “battery no longer low”), green icon right next to the problem entries. Also fixed a small related thing while testing this: the log tab wasn’t refreshing itself while the settings page was already open - it now reloads every time you switch to it (v1.9.10).
The improvments are partly working. I have a zigbee xiaomi doorsensor that was flagged and reported in the log as not reporting. It defenitely works now, it’s also no more flagged. Even after a manual scan no good record in the log. 2 other devices have their 2 records.
