Template binary sensor with state template:
{{ states('sensor.tide_height_now')|float(0) < states('input_number.tide_low_restriction')|float(0) }}
Then a history_stats sensor tracking how long that is on.
Template binary sensor with state template:
{{ states('sensor.tide_height_now')|float(0) < states('input_number.tide_low_restriction')|float(0) }}
Then a history_stats sensor tracking how long that is on.
Thanks, I knew there would be a neat solution I can learn from the experts!
Does this look right to you? I’m asking becuase it will take weeks to accumulate any results:
sensor:
- name: SLWisrestricted
unique_id: slwisrestricted
state: "{{ states('sensor.tide_height_now')|float(0) <= states('input_number.tide_low_restriction')|float(0) }}"
- platform: history_stats
name: SLW restriction last month
entity_id: sensor.slwisrestricted
state: true
type: time
start: "{{ now().replace(day=1, month=now().month-1, hour=0, minute=0, second=0, microsecond=0) }}"
end: "{{ now().replace(day=1, hour=0, minute=0, second=0, microsecond=0) }}"
You appear to have created a sensor. Create it in the UI unless you desperately want to use YAML. Under Helpers:
Then the history_stats entity should be binary_sensor.slwisrestricted
.
Thanks so much Troon. Fingers crossed - it won’t turn true until next week for a few hours.
Just be aware of the need to extend your recorder duration for the history_stats sensor, as on the page. As a test, you could also record the amount of time that the sensor is off
to make sure it’s accumulating.
Thanks - Like this?
recorder:
purge_keep_days: 61
I’ve now got this is configuration.yaml but neither sensor is visible in developer tools: states after reloading all YAML configuraion. Is this because time has to pass?
sensor:
- platform: history_stats
name: SLW_restriction_last_month
entity_id: binary_sensor.slwisrestricted
state: on
type: time
start: "{{ now().replace(day=1, month=now().month-1, hour=0, minute=0, second=0, microsecond=0) }}"
end: "{{ now().replace(day=1, hour=0, minute=0, second=0, microsecond=0) }}"
- platform: history_stats
name: SLW_not_restriction_this_month
entity_id: binary_sensor.slwisrestricted
state: off
type: time
start: "{{ now().replace(day=1, hour=0, minute=0, second=0, microsecond=0) }}"
end: "{{ now() }}"
Edit: I see history stats sensors need a restart before they get created.
Hmm. The one that is supposed to be accumulating the off
time is still reading zero 5 mins after creating it.
Also, the binary_sensor gets switched on during a YAML reload or system restart, until sensor.tide_height_now
gets a value. It’s only a short time, but it would be good to stop this.
Change the number in the float(0)
to something higher than the input number. The unavailable
from the sensor is being turned into 0
.
You might need someone else to help with the history_stats: I have very little experience with that.
There’s also the Statistics sensor:
Your database will now store 61 days worth of activity for every entity in your system. That’s not the most efficient way to keep a record of a month’s worth of tide height.
In addition, you have configured your History Stats sensor to use last month’s data … which doesn’t exist yet because you (probably) haven’t been recording it for such a long time period (until today when you changed the retention period).
I suggest you:
Revert purge_keep_days
to its original value (default is 10 days).
Re-configure the History Stats sensor to record just one day’s total time.
start: "{{ today_at() }}"
end: "{{ now() }}"
I provided an example here for another user who wanted to record total heating time on a daily/monthly/yearly basis.
The suggested solution is far more efficient and will record tide height data starting from today (i.e. you can’t go backwards in time to access data that was never recorded).
Thanks for that. It’s only been running a short while but I’m getting a small number despite the sensor being “off”. This is what I’ve got now:
configuration.yaml:
sensor:
- platform: history_stats
name: SLW_restriction_accum
unique_id: slw_restriction_accum
entity_id: binary_sensor.slwisrestricted
state: "on"
type: time
start: "{{ today_at() }}"
end: "{{ now() }}"
- platform: history_stats
name: SLW_not_restriction_accum
unique_id: slw_not_restriction_accum
entity_id: binary_sensor.slwisrestricted
state: "off"
type: time
start: "{{ today_at() }}"
end: "{{ now() }}"
binary_sensor.slwisrestricted was created with a helper as above. Then I created a new utility meter
SLW restriction monthly
7 minutes ago
Last changed:7 minutes ago
Last updated:7 minutes ago
0.00034447305732303 h
Does this mean I’ve got something wrong?
What leads you to believe something is wrong?
The fact that there are non zero values where i was exoecting zero. The number is tiny though.
What is the state
value of sensor.slw_restriction_accum
?
Tiny, but puzzlingly non-zero
sensor.slw_restriction_accum
SLW_restriction_accum
0.00193005839983622 state_class: measurement
unit_of_measurement: h
device_class: duration
icon: mdi:chart-line
friendly_name: SLW_restriction_accum
0.00193005839983622 * 60 * 60 is about 7 seconds.
It’s reporting that binary_sensor.slwisrestricted
has been on
for about 7 seconds today (more precisely, “today” starts at the time when the History Stats sensor was created).
If binary_sensor.slwisrestricted
has been on
for longer than 7 seconds (since the History Stats sensor was created) then, yes, there may be a problem with how you have configured it.
Thanks. I’ll monitor for a few days before worrying. It’s predicted to be true for about half an hour on thursday night so fingers crossed.
For future reference, I receive a notification if you click this Reply button:
I am not notified if you click this Reply button:
sorry 123 Taras
No worries; just wanted to let you know the two Reply buttons can produce different results depending on how a user is subscribed to a topic.