Has anyone’s sensors stopped working after 2022.5 update?
Ah you’re right! Thank you for raising. “count” of the history stats sensor now appears to reset at the end of the configured duration, so doesn’t keep high values the way it is currently written
I started an issue here: History_stats count not working · Issue #71736 · home-assistant/core · GitHub
Feel free to add to it. I think what they’ve done has value as a seperate history_stats sensor, but trying to get them to revert to old style. You all probably have more experience with it so may be able to add weight to the conversation there.
2 Likes
Looks like you got it fixed @muddro! This behavior has been resolved in 2022.5.5
Thank you for opening the issue
4 Likes
Really Really Cool and exactly what I am looking for.
I still need to configure the sensors when I have the time. But It’s exactly what I need.
@timgiwo please update first post, because “Import blueprint” button is not working.
It returns this error:
No valid blueprint found in the topic. Blueprint syntax blocks need to be marked as YAML or no syntax.
It’s due multiple code blocks in this post (based on this comment: Zigbee2Mqtt - IKEA five button remote - #53 by starbuck93)
Since HA has stepped up its game with media players, would those entities also work with replay? Have the radio or TV play in a natural way when you are present?
I am just getting in to Home Assistant and this looks awesome, thanks for the blueprint going to set this up so it works during the holidays.
Quick question, since all states is already recorded in the logs, why do we need separate sensors for this. Can’t the state be pulled from the regular logs for the specific lights?
/Danny
Hi @danininodk
Unfortunately the states are buried in the HA DB and aren’t easily accessible by blueprints.
The intents of this implementation was to make use of blueprints and common well-supported HA building blocks.
There was another user that was also interested in querying the DB for state changes and has an alternate post here!
The thing that I’m not 100% clear on is the history states. I’ve set up the sensors properly, but when I go into the history page and choose one of the sensors as the entity, it doesn’t necessarily have the correct status. And when I change the state of the light, the status doesn’t change in that history. When I pull one of the sensors up in the history, am I actually looking at the history of it one week ago? What is going on?
It is your latter suggestion. The sensor is displaying the state at the exact same time, one week in the past. The amount of time in the past it looks is derived from this formula. If you want to troubleshoot and see what’s going on in a smaller interval, you can mess with this formula in the sensor using a value different than (7*86400)
{{ as_timestamp(now()) - (7*86400) }}
(Now - amount of time in seconds)
(Now - (7 days x (60sec/min x 60min/hr x 24hr/day))
Perfect, that totally makes sense. Thanks!
I just found this and it looks exactly like what I needed a few weeks ago before I went on vacation, LOL. I noticed that it’s set up for light entities that can dim. A lot of my lights are just switches, what needs to be done differently for the switches if anything? Thank you!
lights and switches are both supported.
1 Like
Thank you!
Hi Im very new to this how do i create the Sensors?
1 Like
exactly what I needed, thank you!
Haven’t tested this out but can default brightness not be specified? All my lights are adaptive so when they turn on they’ll immediately receive a brightness and temperature. An initial request for brightness would be wasted.
The blueprint only turns a light or switch on/of
If you have other automations or default light values that apply when lights are turned on then they’d continue to run when triggered by the blueprint
Interesting, so under default brightness if “default” is not specified I should be good to go?