Get a warning when any device has low battery?

Hello!

Is it possible to get a notification if any of the devices that use battery, reports less then 20% battery or similar? Or do a need to create a flow for the specific devices?

2 Likes

I already have that, but now I have a device that has 1% battery and I did not get a warning.
Maybe some other fault?

I have such a flow for the charge 20% and 10%. With the flow 10%, the condition I have is logic = less than 11%. This means that a warning is given every time the batteries drop below 1%. This gets on your nerves so much that you voluntarily change the batteries. Some sensors have a bad habit of suddenly dropping from xx% to 1%. The 10% flow is then always triggered, since it reports every change below 10%.

2 Likes

You only get a notification when the value changes, e.g. from 15% to 9%.
If the battery capacity was already at 1% before the flow was created and there has been no change since then, then the flow will not be triggered and you will get no notification.

2 Likes

Yes, You’re right. This is quite big disadvantage for such approach. Another one is the fact, You never know, when exactly the change occurs. This may be during the night, during traveling…

So, may-be little better is approach, when during specific time all bat devices are scanned and if needed reported into one message(mail). And of course this time-started flow is also possible to disable on specific conditions.

As quite new on Athom and JavaScript (but not so new in general HomeAutomation and other lang’s) -
I hacked the HomeyScript, which one is scanning all devices and checking low bat’s and long not reported ones. Right now it’s a quite dirty hack without a flow start and mailing - so, sorry, i not post it right now and right here. If there is interest and someone ask - yes, then i will do little corrections and post it here. But also… may-be it’s a good tutorial for everyone to DIY :wink:

2 Likes

So u wanna scan all battery devices every day to check on battery status?
Also the ones that lasts for more then a year?
Best send the low battery reports to Telegram bot. Easy to check urself instantly, or later if u wish.

Yes, of course. Hmm, actually, how to make sure, the battery lasting a year(s) or week(s)?

Not necessary to say me, this takes processing power :wink: Actually the spread power is taken also by “scan every change”. This is my personal preference to have a fresh report every day (or week), which one includes all currently attention requiring devices, no matter, if i may-be miss them in previous report or not.

So u gonna wake up all battery devices to ask the battery status?

Asking from me? :slight_smile:

Hmm, from where You take that? May-be i’m wrong, but as i understood, it’s impossible from remote (with script) to wake up a “sleeping beauty”. The extra wake-up requires a physical button press.

Actually, what my script does - it asks the Homey’s current opinion about device bat state. The state is saved (by system) during the “regular reporting”. So, i hope, this is in numbers the same, which one triggers “bat level change event”, just saved by Homey at moment, when this info was sent.

1 Like

Ah, ok.

Actually, thanx for You!
I started re-think/design my script and discovered, that the information about battery status may be quite old.

*** “Smoke Sensor” in “Tv Room” has low battery 30% Prepare CR123A
*** “Koogiuks” in “Kitchen” has low battery 30% Prepare LS14250
“Smoke Beedroom” in “Bedroom” has reported bat status 2761 hours ago as 100%
“Netatmo— Odoor” in “Court” has reported bat status 24 hours ago as 69%
“Netatmo — Tuul” in “Court” has reported bat status 44 hours ago as 56%
“Netatmo — Vihm” in “Court” has reported bat status 95 hours ago as 53%
“Smoke Sensor” in “Saloon” has reported bat status 2757 hours ago as 100%
“Hooviuks” in “Entry” has reported bat status 174 hours ago as 65%
“Termostaat” in “Bathroom” has reported bat status 37 hours ago as 40%
“Postkast” in “Court” has reported bat status 157 hours ago as 70%
“Motion Sensor” in “Bathroom” has reported bat status 49 hours ago as 48%
“Dushivesi” in “Bathroom” has reported bat status 696 hours ago as 44%

So, seems, the bat state is (at least by some of devices) not so often reported thing, but actually this is a maliciousness hope - the same happening with the “bat changed cards” to.

PS. Using the capabilitiesObj.measure_battery.value and capabilitiesObj.measure_battery.lastUpdated values.

This is a recent example of what happened today.

The battery capacity shortly jumped from 32% to 100%, and then dropped to 1%.
If the battery scan you use runs e.g. at 11:00, then you don’t know until the next day at 11:00 that the battery is empty.
Maybe the method with the script and the scan once a day is not a good solution after all?

I prefer to be informed immediately when a battery needs to be replaced. If I receive the information during the night, which you have criticized, then I still see immediately that a battery must be replaced due to the already existing push message the next morning.

Yeah… may-be You right. It’s totally a question of taste. I personally do not like to jump up during night, step on cat’s tail… ok, sorry 'bout my to descriptive speak here, but happened with me in reality :stuck_out_tongue:

Just a last comment: if the system is acting like You describe, then may-be the method (selection) of watching is the last problem here. First of all it’s required to fix actual bat measurement system. Because i actually start thinking about the change/charge on ~30% and hope to have some spare days before the device sets completely.

At night, my smartphone is silent as the grave. That was the reason why I wrote:

Perhaps it was unclearly written.

Indeed, that’s what I suspect.

I’m using the same as @undertaker, but in addition you should know that you can go in the Homey app on your phone to Energy and then click the battery icon in the top right hand corner.

By the way, my experience is that battery drain levels are usually not really well detected. It depends on the brand/hardware.

In important cases you can design a flow to notify when a sensor stopped working. In case the sensor battery died, it is usually left in one state (active) or another state (inactive) forever.

1 Like

@Undertaker Just a couple of questions to the flow you shared.
image

What does “[[Text]]” do? Is it just formatting?

As far as I understand this is a timeline notification? How come you have a red icon? Mine’s yellow. Care to translate the text? I think google translate had a smal embolism trying to translate it for me :wink:

I felt free to answer your question.

That is a Timeline notification.
The phone app shows indeed a yellow icon, but when you share a flow, it suddenly is a red icon. Why? > support@athom.com

The freely translated text:
Timeline
Create a notification with
Battery [local tag “Name”], [local tag “Zone”] just has left [local tag “Value”]%

I don’t know what the [[text]] part is, it seems part of the German card description, not something entered by Uwe.
Example of my timeline card, in Dutch

2 Likes

hello, joining the crowd here as I the same need. By the way I think this should be standard from Homey as this is a very generic need.
I want to implemenbt the flow proposed by Undertaker (thanks), but I’m not sure how to do it.
I understand the logic is to ask Homey to send a message when the battery of any device gets below a certain level. that’s great.
However, I don’t know:

  • how to indicate any device. When I create a flow I need to indicate a device and don’t see anything like “ANY”
  • in the notification message how to report the name of the device that has triggered the notification? In the same way I can only seem to select a specific device, nothing that I can see alllows me to say identify the device that has triggered the notification
    Thanks

I chose to go the somewhat more complex route and have a per device flow.

The benefit is that I can receive a daily notification on the battery level of each individual device after it goes beyond a certain treshold. Instead of only a single notification at the moment the device reaches the threshhold.

The downside is of course that I need to create seperate flows for each device.