You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: apparently, my unit stores the time in nvram, which has the effect of whenever there is any power outage the clock picks up the last known time--even if the power came back up hours later. I suppose this is better than resetting to 12:00am, but this has the effect of throwing the schedule off. If you want to retain any scheduling function on the controller, it would be super useful to be aware when this happens.
There is a sensor device classtimestamp, so that can be used to hold the current clock time... and a device class duration which would work for recording clock skew. Probably just m would be sufficient resolution, though we could get fancy and try to come up with a s value...actually probably not a good idea, as that would likely oscillate a lot and make noise in the sensor history.
The text was updated successfully, but these errors were encountered:
This may require an option to specify the time zone for the pool controller? Is it sufficient to require that the aqualogic_mqtt process run in the time zone (via TZ env) the controller is set to?
Background: apparently, my unit stores the time in nvram, which has the effect of whenever there is any power outage the clock picks up the last known time--even if the power came back up hours later. I suppose this is better than resetting to 12:00am, but this has the effect of throwing the schedule off. If you want to retain any scheduling function on the controller, it would be super useful to be aware when this happens.
There is a sensor device class
timestamp
, so that can be used to hold the current clock time... and a device classduration
which would work for recording clock skew. Probably justm
would be sufficient resolution, though we could get fancy and try to come up with as
value...actually probably not a good idea, as that would likely oscillate a lot and make noise in the sensor history.The text was updated successfully, but these errors were encountered: