I feel like I may have made this rule more complicated than it should be. I previously had as a simple automation, and turned the charger off after a set time (connected to a Zooz double plug). I decided to use the meter capabilities and decided to monitor the power to determine when to stop as there were some instances of me turning it on, forgetting about it for a bit, then putting in the old batteries to charge, and the batteries not being fully charged. I'm doing the double check in case it goes to 0 for a second, then jumps back up (especially when it first starts, it happens frequently). I don't mind the 10 minute delay as the charger does have overcharge protection (i believe up to 8 hours, so 10 minutes is nothing).
Any other way I can optimize this rule? Any better options out there I'm not considering? Won't lie, it's been a while since I've changed stuff in my hub, so not well versed on the latest apps.
While that is likely to work (as long as there aren't two 0.0 readings that happen to be 10 seconds apart but actually have other values in between), you could probably make this rule a lot simpler. Here's one way:
Trigger event: AAA Battery reports power = 0.0 and stays that way for 10 minutes
Actions to run: Off: AAA Battery
This takes advantage of the "and stays?" options on triggers, also called sticky triggers, that make automations like this easier to write. This was introduced a few platform versions ago.
2 Likes
i tried this, but the issue was when i would turn it off to top off the batteries before swapping them into the device, the charger would just turn off a couple seconds after turning on. not sure if it remembered the power was 0 previously or what, but it didn't work for me, so i switched my trigger to the power changing
I'd enable all logging for that rule and see what clues Logs, filtered to just this rule, provide. That will give you an idea of what's really going on without having to guess. There shouldn't be a trigger without an actual event from the device, though it's possible something is odd about the value 0 or some other case, which this will clue you in on.
Otherwise, again, your rule does look like it should work, aside from the possibly unlikely case I mentioned above.
