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))
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!
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.
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.
For creating sensors I have not managed it. I tried following the instructions here:
Which as I understand it is to edit the scripts.yaml file to say: binary_sensor: !include sensor.replay_LuzMateo
And later create a file: /homeassistant/sensor.replay_LuzMateo
Containg costumised version:
##########
# Sensors
##########
sensor:
# Replay Sensor - Make a new one for each light to monitor
# All sensors will have naming convention "sensor.replay_xxxxx"
- platform: history_stats
name: "replay_LuzMateo"
entity_id: light.LuzMateo
state: "on"
type: count
start: >
{{ as_timestamp(now()) - (7*86400) }}
duration: 00:00:30
But I think I mis understood because I cannot find the sensor on the blueprint