i like your part with calling the service instead off turn_on and turn_of.
it would take out half of the if statements.
but it cant be less then 3 if statements because you need sunrise, sunset and time 
and yeah i could decide to set on and off in the csv file, but i decided to make 2 columns 1 for off and 1 for on(and that isnt enough also, but didnt want to make it even more), to get a better overview when i read it in excel.
edit:
you can discuss about it in:
@renetode pointed out a “possibly” major flaw with the run_in callbacks when using sunset or sunrise, are they hard set the minute you generate the date time object or will they automatically adapt through out the year?
/R
they do adapt.
i have used then for quite some time now and they Always go off at the right sunset time.
thats why i splitt out my code to 3 different type of state listenings.
Almost looks like a crontab file. LOL
i guess the process is a lot the same.
i just looked up what a crontab file is, but yeah you could see it as such.
Well now that I understand better what you were explaining earlier, I will rephrase it
when using run_daily together with sunset or sunrise, will the time be set based on the day the date time object got generated or will it follow the changes in sun elevation over the year?
Will I have to move over to using run_at_sunset/sunrise to get that dynamic behaviour?
/R
sunset is a time that will be calculated at the time the code runs. so at init from the app.
run_daily will then run on the time you have set there.
so:
runtime=self.parse_time("sunset + 0:45:00")
# now the time is fixed until you run the init again.
self.run_daily(callback,runtime)
will run every day on 45 minutes after todays sunset.
so yeah if you want dynamic behaviour you need run_at_sunset instead.
When I use run_at, it returns a handle that can be used to cancel the scheduled event. Can I store that handle in a list? I have a list of alarms where each alarm is composed of a room and a time. If someone changes their alarm time though, I need to cancel the existing scheduled event and schedule the new alarm time.
that is possible.
if i am correct the handle is nothing more then a long.
Yes, run_daily() will run at the same time each day. run_at_sunset/sunrise() will change every day to match relative to sunrise and sunset. Two different usecases, just pick the one you want.
It’s actually a UUID which is just a unique sequence of letters and numbers, but yes, you can store it in a list or anywhere else for that matter.
Guys,
I am looking for suggestion/tips in order to find out issue of my AppDaemon stops working in few hours. When I say stops working it is not showing any error on terminal console (Ubuntu) but not triggering any action of any AppDaemon apps which should have taken action as Home Assistant has something changed/triggered. Another restart of AppDaemon makes it work for few more hours.
This started happening more frequent since week or two while my HADashboard project’s HAPush works without any issue on the same Ubuntu machine.
So far I have tried:
Any idea/tips? How do I add more debug info to terminal console to see what’s going on in AppDaemon?
Side notes I am running HA with secure connection using duckdns certificate.
I wish I can setup AppDaemon and HAPush to connect non-secure way (all are on same Ubuntu machine) so it doesn’t have to leave my local network to resolve name/IP to duckdns.
Help please.
Thanks a lot for your time guys.
have you tried if appdaemon keeps running when you dont start hapush?
i am afraid thats not the problem, because you state “more frequently”
could it be a memoryproblem?
I have not tried stopping (not running) HAPush to see if AppDaemon runs as expected. I will try it and report back.
About memory, no, it’s Ubuntu 16.04 with I5 processor + 16GB + 500GB, so resource is not an issue at all.
Machine runs:
)OK, what apps are you running? Is it possible that you are using up all the threads?
What version of SSEClient are you running?
Good point, I think I have more than 10 apps as recently I have added couple.
This makes me wonder that may be the issue as I have doubt (not 100% sure) in past one or two apps were working while others were not.
First thing I will verify this: how many thread I have (I believe default: 10) and how many apps once I go home.
But wait, if at a given time number of running apps is greater than 10 then only it should cause issue correct?
Thanks
I will have to verify the version of SSEClient, but should be the one came with either AppDaemon or HAPush
Its not the number of threads vs apps that is important - the threads are reused. But if you have code in your app that ties up the threads for some reason then you may get thread starvation. You should see messages in the log if this happens for long enough.
I don’t have any app that has blocking call which can lock the thread for extended period as of now. At one point in time I had code to play audio message using Google Cast and noticed getting stuck finding my cast device as of now it is commented out.
I use pushbullet for sending notification but for that I have separate AppDaemon app and that app uses pushbullet.py component not from HA. This can potential block thread for some time but have not seen in logs.
I ran manually AppDaemon (not auto start) so all logs/messages I see in terminal console and I have not seen any error in there except while tweaking an app due syntax or something.
Is there a way to enable more logging for debugging purpose to see any issue?
Thanks
you could try running it with -D DEBUG and see if it is still receiving messages when it goes quiet.