Closed iia closed 1 year ago
24 hours seems unreasonably long. Anyhow,...
I totally agree with your argument. The 60 seconds is equally ambiguous. The goal should be to expire after one or multiple periods, including a grace period. Correct?
Maybe a factor would be better suited? str(int(sleep_period * 1.5))
Btw could you please test how this relates to #149
Hi,
24 hours seems unreasonably long. Anyhow,...
Well, indoor plant soil properties usually don't change that quick. Plus with less frequent polling, hoping for a longer sensor battery life.
I totally agree with your argument. The 60 seconds is equally ambiguous. The goal should be to expire after one or multiple periods, including a grace period. Correct?
Exactly, here the 60 seconds is an arbitrary grace period.
Maybe a factor would be better suited?
str(int(sleep_period * 1.5))
Agreed. I'm going to push the changes to this PR.
Btw could you please test how this relates to #149
On it. Will let you know.
But it seems for Home Assistant the expire_after
value already solves the: the dog swallowed the sensor problem
.
As in this case the old values will be available as retained by the MQTT broker but eventually, based on the expire_after
value, Home Assistant will indicate that the sensor is unavailable.
@ThomDietrich I tested #149 with my Home Assistant setup. It works as expected with MQTT retain enabled. The older values are retained but after the expire_after
duration Home Assistant shows the devices as unavailable.
Perfect.
I use this daemon for my MiFlora sensors with Home Assistant via Mosquitto broker.
My sensors updates every 24 hours. As it is currently, a fixed value of
3600
forexpire_after
(added in #138) made my sensors appear as "Unavailable" after 3600 seconds.This is why I think it makes the most sense to use a value derived from the
period
of updates as configured in the daemon. Because a sensor can only be considered unavailable if there were no updates when there was supposed to be one.