The situation is that I have Philips Hue lights. During the night we have them on at 1% for a night light. However, during a power cut, when power is restored they return on, but return on at 100%.
I created an automation that runs every minute to check if they’re at about 95% and if so, reduce the power back to 1%. However, I’m getting an error…
In 'numeric_state' condition: entity light.office_light state '%' cannot be processed as a number
2025-01-11 05:12:00.204 WARNING (MainThread) [homeassistant.helpers.script] Error in 'condition' evaluation:
So… if I remove the value template, the error goes away, but then I’m left not knowing if the 95 is evaluated as a percentage, or else held to a different value range, like 0-255 or something.
Unfortunately, it doesn’t fire when the light comes back from a power cut. Presumably because it comes back from “unavaialble” rather than “0” Will have to do more testing.
It seems that the value itself, while it can be used as a comparison, it can’t be used as a trigger. Also in the case of a brown out which is enough to cause the bulb to reset, it isn’t long enough for HA to notice that the bulb is unavailable… so it can’t trigger on that. So I’m left with little other choice at the moment other than to use time as a trigger. Unless someone has some other suggestions?
The other option is to also trigger on startup and/or software the state going from unavailable to something other than unavailable. When you add extra triggers you also need to check the brightness in the conditions.
You can use a state trigger for the unavailability tests, with from set to unavailable and to left blank.
As for the attributes: brightness is always 0-255. When setting you can use brightness_pct as a percentage, but that issn’t available as an attribute.
That is not how a value_template on a numeric_state condition/trigger works. Brightness has a value in the range 0–255, if you want to remold the range as a percentage you have to actually write a template that performs the calculation:
(Note: I’ve never had to do the above before, but based on my reading of the documentation, this is how value_template on numeric_state is supposed to work, though the state.attributes.value does look a bit fishy to me….?)
Or better yet, as others have already suggested, rewrite the automation to use a numeric_state trigger rather than time_pattern trigger, and probably add a time condition to only be active at night. Something like this:
The numeric state trigger doesn’t trigger when the bulb has come back from a short black out. I’m not sure why. I’ll continue to try, though. I’ve even tried from unknown to on, but some of the cuts are short enough that HA doesn’t even know that the bulb has gone unknown in the first place. It’s all a matter of timing.
Also, you do know that you can change the power on behavior for each light in the Hue app? Granted the available options aren’t that great.
I have all of my Hue lights set to “Power loss recovery”, as I mostly expect my lights to be off and want them to stay off when power returns. But for any lights that were on, the app doesn’t really explain if they’d be turned on to the same settings as they last had, or some default settings at probably full brightness…
You probably want to set this particular light to the “Last on” setting.
I am already using the last on setting, for it to come back on after a cut, but as you said, the options aren’t that great. No ability to say at what brightness. I’m grateful for what it does have, however.
The state of the bulb is part of the problem. It changes before HA can catch up with the fact that it has changed. And even if it does know “1” at the time the bulb goes off, when it comes back on with 255, it’s as if it never changed so it doesn’t trigger. Likewise the status from on… HA never knows it went away. It’s back again. So that trigger fails as well. It just doesn’t fire.
Both ZHA and Zigbee2MQTT have configurable settings for detecting how long mains or battery devices should stop reporting before being considered as unavailable.
You should try to play around with those settings, but be warned that these are global (applied to all zigbee devices) and setting the value too low might result in your zigbee network being flooded.
Check your Z2M settings. The default timeout for mains-powered devices like your bulbs is 10 mins according to the docs.
If your power cuts last less than 10 minutes, then you might need to reduce that, but be warned that this will cause all your mains devices to check-in more frequently, potentially leading to congestion.
You can find this setting in Z2M frontend > Settings > Availability tab & selecting Availability (Advanced) in the dropdown. Remember to hit Submit at the bottom when you’re done.
Some of the power cuts last a lot less. The trick is that if a fault is on the overhead lines, the breakers are self resetting, so they will try and automatically re-connect within a few seconds. They do this three times. Mostly, they recover from this and continue on. Sometimes they don’t and stay off until an engineer can visit and sort out whatever is wrong with the overhead cable (usually interference with trees and branches where I live) so a good number of power outages are only a few seconds in duration.
Hmm, that complicates matters.
I had a closer look at the brightness attribute of all my lights and might have a potential solution though.
You don’t need the value_template, and you don’t need to trigger every minute.
I suspect the reason you were getting this issue is that brightness is not the same thing as brightness_pct. Only brightness (which goes from 1-255) exists as an attribute for all my lights, and I suspect yours too.
You cannot use the brightness_pct as a trigger attribute, however you can call it in an action.
I’ve additionally added a condition so that it only performs the action at night, like you requested. I also assumed you want the light to go back to 1% brightness as it was before, instead of turning it off.
Either way, try it out as is and if it works, feel free to edit it later.
This is going to sound a bit daft, because I’m still getting to grips with this.
Any action has to be regularly evaluated by HA. Therefore, what’s the difference between checking a value to see if it’s changed, and doing a time based trigger to run a condition check? I mean, surely it’s the same load on the system, right?
An action which results in an actual action… like attempting to send a “turn on” signal to the light every minute… sure, that’s going to result in wasted network chatter and cause the light to turn around and say, “Look, buddy, for the fifty fourth millionth time today, I’m already ON!”
But I’m not understanding why having a trigger every minute, to run a comparison check is all that bad.
I’d be grateful if someone could spend a few moments to educate me on this please, because I’m a little confused.
Event listeners are created aligned to any triggers in your automations, trigger-based sensors or Jinja templates which listen for changes to any relevant entities. It’s an effective and efficient system. You can see this when creating templates in Developer Tools / Templates:
Having a trigger fire every minute isn’t going to bring the system to its knees, but it is inelegant and unnecessary if what you are looking for is a state change. You could be 59 seconds late in noticing it; and if you write all of your automations like this, your system will appear to be laggy.
There are some valid uses for this. I have a “heuristic” sensor to work out the approximate “heat charge” of my hot water tank, which has to evaluate every minute as there is a time component to the calculation — the rate at which the tank can heat up.
Thank you for taking the time to go through this with me.
Well, not necessarily trigger. The way I’m seeing things, there appears to be an evaluation first… the system has to look at the automation to evaluate whether the trigger is to be acted on.
If I interpret what you’re saying correctly, then if my trigger has an evaluation for the light brightness… then HA is going once a minute and asking the light what brightness it is, as opposed to waiting for the light to come back to HA and say, “I’ve changed my brightness.”
If you trigger from the light, a listener is registered in the state machine that says “let me know whenever the light brightness changes”.
The state machine tracks all changes to all entities: that’s the “backbone” of HA. Whenever a new state arrives from anywhere, including your light, one of its jobs is to inform any listeners that are interested in that particular entity.
If you trigger each minute, then you’re right: HA is interrogating the light at the top of each minute.
Imagine waiting at a set of traffic lights for the green light to show. Do you watch the light, or look up every minute?
