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.
Thank you!
Hi Im very new to this how do i create the Sensors?
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.
Where is the link to this schema?