New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with sun_down sun_up #889
Comments
it would help if you share the code you use |
Sure - appdaemon --version returns 4.0.2 in the docker container
|
i think its a bad idea to mix sync apps with async functions. and it seems that Andrew already did set dev to 4.0.2 so you are running a dev version. i just tested
and it returns false as expected. so please try to use a sync way to log to see if that makes a difference. and please dont use unsupported ways like: you can simply use |
I used the unsupported api just to point out that next_sunrise is in the past
at 12:31 the next sunrise returns 6:04 for the same day - this should not be possible? I only mixed sync/async to await the async functions for logging purposes - it is the same when I also do that with just sync functions |
it helps more if you use supported api to point out something is wrong ;)
that is correct. so now we need to find out why you get a wrong sunrise back the first time.
i can see you did it for logging, still its better just not to do it. i am trying to find out if its something in this app that makes that it gives back the wrong info or that its something in general. so if you would try to add logging this way:
we can make sure that its not something else that is creating the problem. |
I also have the impression that sun_down uses an old setting - that's why I tryed to not only log the official api, but also internal values to find discrepancies. I'll adapt the logging accordingly - I also logged self.AD.sched.get_now()) for now and it turns out that this time is also not correct (-1h), although the time_zone(self.AD.time_zone) should be set correctly:
|
thats the problem with internal values. i leave the internal coding to the other devs, but i can imagine that get_now() is used internally some other way and is corrected when the time is given to the user. does your logging show the right time? |
i also advise to add the admin interface to your appdaemon.yaml |
@HerrHofrat i didnt notice it at first, but i saw strange behaviour in your logs. you got
in your appdaemon.yaml
to make sure AD will function correctly. |
self.get_now() also returns a wrong time (-1h): the time of the log would be the correct one Thanks for pointing out the app_dir issue, fixed that!
I also changed the logging to only use the official API Here are the logs from today - with the official API: the first time triggered at 8:49 Sun Down returned True, while the second trigger at 9:05 returned False
|
if self.get_now() returns the wrong time then somewhere a setting must be off. i dont use docker but venv, and for me all times are correct. |
So, I think I found an issue - I again added some logging of internal values of the scheduler. self.AD.sched.now is not up to date, therefore the if in scheduler.py#L220 is true. Probably in the if self.get_now() should be used?
|
Correct - self.AD.sched.now is only updated infrequently, which was a change that went into 4.0 - the wrinkle here is that you are using a listen_state() to trigger the lookup. I had tested that any time related triggesr should update now appropriately but forgot about listen_states (). Your fix would work, but it would still be broken for time travel so I need to make the scheduler update every time now is accessed internally |
OK, I made a fix and pushed it to dev. It's kind of hard for me to test it, so I was hoping you could take a look. If you aren't comfortable using a dev build it will be in the next full build for you to take a look at (4.0.4). Please let me know if this fixes the issue. |
Scratch that - I had to recert the change it caused an issue ... watch this space |
Here's another code snippet and logs that (I think) demonstrate this issue https://community.home-assistant.io/t/sunset-trigger-not-working/90764/8 |
For anyone else who's impact by this, there's an (alleged) workaround posted at the bottom of #926 (comment) |
This problem still exists in the 4.0.4 docker image. Here's the workaround I implemented in the meantime: a cronjob runs |
Fixed some bugs in this area in the current dev (for 4.1.0) - please re-open if there is still an issue. |
I noticed a strange issue with my light automation after upgrading from 3.0.5 to 4.0.2 - it should only trigger if the sun is down, but when the automation is triggered the first time every day, the sun_down function returns true - regardless the actual state of the sun or time of the day. I added some debug logs and this happened today:
The next sunrise is in the past and therefore the logic for sun_up/sun_down is messed up.
I'm using appdaemon in docker on a raspberry pi 3 B+ with Raspbian 10. Appdaemon is version 4.0.2 git commit 4bea956. I had to apk add libressl-dev in the Dockerfile to get it built successfully - no other changes were made. /etc/localtime is also mapped from the host to the container.
The text was updated successfully, but these errors were encountered: