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?
This approach is not working with summer/winter-times, is it?
If I have changes e.g at 7:45 or 8:27 am last Sunday, it is replayed at 8:45 or 9:27. Because of the +1 hour summertime and fixed minus 7*86400 it is one our later now.
So one has to change it four times a year or bring another formular in the template. Did somoeone do it already?
This will only ever happen for one week at every time change (only twice a year, not four). After that week the recorder gets purged of all relevant data and it will then use the current time base.
and since this is supposed to generate “random” times for operating your lights (based on historical “randomness” of how you organically use your lights when you are home) being off by an hour shouldn’t really make much difference. If your burglars are sitting around timing your lights to figure out if your lights are operating exactly an hour off from when they were turned on and off last week to know if you’re really home or not then you likely have more to worry about than just some random burglar.
if you are really that concerned you could probably create a sensor that notifies the system of a DST shift and somehow work that into the schedule. But even if you delayed the transition by a week (so that last weeks times are the same as this weeks times adjusted for the DST shift) you would then still have the problem the following week as well since the blueprint would be using a time shifted schedule from the previous week.
you would just be kicking the can down the road and constantly chasing a time shift until you didn’t use the blueprint for a week to let everything catch up to real time. And then it would start all over again on the next DST change.
Yes. all clear. But then this Blueprint is not replaying historical lighning as the name says.
And of course plus and minus one hour could have big relevance in cases, you need to use a real replay.
I have already added the number and will change in one week again.