I have an app that registers a run_at_sunrise callback on initialise:
def initialize(self):
# Register callback for sunrise
self.run_at_sunrise(self.at_sunrise)
But i can see from logging that this callback gets called 3600 times (once per second) from sunrise up to an hour after sunrise. I also can see that the self.sunrise() value does not get updated (i.e. is in the past) for this hour. It finally gets updated for the very last callback.
def at_sunrise(self, kwargs):
device = self.args["device"]
self.log("at_sunrise, device=" + device + ", now=%f" % self.datetime().timestamp() + ", sunrise=%f" % self.sunrise().timestamp())
# set battery low alarm threshold in volts
self.call_service("mqtt/publish", topic = device + "/min_voltage", qos = 1, retain = True, payload = 3.3)
# set device wakeup to be just after the next sunrise. We give it 5 minutes leeway
# (plus an hour for the aforementioned bug)
self.call_service("mqtt/publish", topic = device + "/wakeup", qos = 1, retain = True, payload = int(self.sunrise().timestamp()+3900))
# set level of irrigation based on recent and projected rainfall
last_rainfall = self.recorded_mm_rainfall(24*5)
next_rainfall = self.forecast_mm_rainfall(24)
irrigation = 20 if last_rainfall < 15 and next_rainfall < 5 else 0
self.irrigate(device + "/irrigate/A", irrigation)
self.irrigate(device + "/irrigate/B", irrigation)
Member functions recorded_mm_rainfall and foreecast_mm_rainfall do some web scraping using requests. Member function irrigate posts to an MQTT topic.
I can see from the log message when the function is called, and without the aforementioned offset it is called 3601 times. With the offset it is called once.
i dont use the sunrise without an offset myself, but this sounds like something simular then we had in 1 of the previous versions with sunset. (only that was called 6x)
i have copied the important parts from your code 1 on 1 to 1 of my test apps.
tommorow ill now if i can reproduce this behaviour.
I don’t use docker for HA, so I am not sure if this is the problem, but from what I have seen, most docker configurations configure the timezone of the container to the same as the host, and I can’t see anything in the configuration of your appdaemon container does this.
As you are running on a Linux host, you can map /etc/timezone to the same in the container, but I see you have done something with environment variables on the HA container, so that could work as well.
How this relates to the HA or AD definition of the timezone, I am not entirely sure, but it may be worth trying.
and off course i have the timezone set in linux when i installed it (or at least i suspect that, its so long ago i dont remember )
i run AD in a venv
you have docker so there are 4 different places where the time settings can be set:
your device settings (linux)
HA
docker settings
appdaemon
docker normally gets the device settings if i am not mistaken
appdaemon takes the timesettings from HA if they are not set in AD
there have been some issues where AD had trouble getting the timesettings from HA thats why its possible to set them in the appdaemon.yaml
in both cases (set in HA or AD) python takes the device time and changes that to the set timezone
so in all cases the deviceclock is a part from it.
i hope this info helps you to find out where your time problem is.
@gpbenton@ReneTode you were correct in observing the issue was with the HA timezone. This is nothing to do with AppDaemon but another manifestation of the Alert issue when the timezone in HA does not match the OS. Mapping /etc/timeone from the host to the container in each service of the docker-compose file fixed the issue.
In case it help others looking for a solution, here’s the updated docker-compose file: