Many thanks @aimc for the answers, now I got it fully what’s going on. Maybe I will consider getting some more powerful box just for appd, but the skew doesn’t come so often anyway, just when I have the scheduler running for over an hour or so. Never seen a skew beyond 5000ms anyway, which on the scale of things, I don’t think its bad.
Thanks and kind regarsd
Hope you had a nice day? Please I got something else to report, and know not if it is normal.
I do understand that appdaemon is now designed to be standalone, bit when I restart HA, initially it displays
Then sometimes when it reconnects, it reloads the apps.yaml file, which then leads to all the apps being reloaded. This in turn sometimes leads to a few data being lost. Is there something I might be missing?
it still reloads after losing connection.
but i think you got a point.
maybe the reloading after loss of connection should be optional, or based on dependency from an plugin.
Yeah I think that makes sense. Only a few of my apps depend on connection to HA. But I think for it to be truly independent, needs not be reloaded whether HA there or not. There might be a few things i am missing, but that’s what I think anyway. Thanks
It’s working as designed for sure, but you have a point. I have an item to only reload apps dependent on a particular plugin, but was figuring out how to do it. Best way is an optional plugin dependency field per app, then you can tell it if it needs to reload. I’ll take a look at this after the beta.
i can think of many apps that dont need to reload at all.
even when i have a listen_state in it and there is no connection there is no actual need to reinitialize when HA is restarting or a connection is lost for a moment.
i think it would be nice when we can decide which app will reinitialize when a plugin loses connection.
all actions that require a live plugin just should be placed in a queue untill the plugin is back. i think.
or am i talking about v4 now 
I don’t agree with the que idea but I don’t have a problem making the reload optional or dependent on one or more plugins as I was putting to do that anyway
@aimc, many thanks for the understanding and considering it. may I add another if you don’t mind 
Is it possible to view all the schedulers that are running in realtime? I know about the self.info_timer(), but sometimes I just want to know the state of all scheduler like at once? Sometimes I also get confused on what’s happening especially when the system reloads as I don’t know what’s up.
Also when I get the log
2018-02-16 23:18:26.047802 WARNING AppDaemon: Excessive time spent in utility loop: 2232.0ms
It will be nice to know what scheduler or something caused it. I might be running one, and I will have no clue it is running.
Lastly in my system, I have my main app that fires an event using self.fire_event to pass some data to several apps at the same time, who pick it up and seek to know if its for them or not. Now if I was to restart this core app, even if it leads to the apps dependent on it restarting, the other apps that register to the event seems to be broken as they don’t pick it up; unless I restart that app itself by making a change in them or something. I confirmed that fact it was still firing by using a little automation in HA to ensure its running and it was running.
Any ideas please, or do you have better ideas how I can handle this, in case I am missing something?
Thanks
Not currently although I could add some debug statements to help with this
Put logging in your apps so you know
That shouldn’t be the case - once an app starts listening for a particular event it will continue to do so - can you give me an example of your code?
@gpbenton - Global module dependencies have been added and will be available in the next beta.
Many thanks for your responses. I later found out my issue had to do with my network being heavily loaded, and for that reason I was losing packets when communicating between systems. I will let you know if I find out any more problems again.
Regards
OK - made the jump today and everything is mostly working as expected after some tweaking. One thing I am seeing is a lot of:
WARNING AppDaemon: Invalid handle 8440b46c-1945-407f-a385-1d97d1aa84c1 in cancel_state_callback()
messages. I would like to track them down, but there is not a lot of information to go on. What exactly is this WARNING telling me?
Also seeing some of these:
WARNING AppDaemon: Invalid app lockgarage in cancel_state_callback()
Am I doing something not so smart somewhere? 
Thanks @aimc - love me some new AppDaemon features!
Tom
The first error means you are trying to cancel a callback that no longer exists.
The second is basically telling you the same thing but it is confusing, so I’ll change the message in the next beta.
The behavior here has changed since 2.x - previously the same situation would silently fail which means you may have had a bug in your app for a while, or may have been relying on that behavior.
Oh yeah - lazy programming on my part I’m sure. Anyway to actually know what module/app is causing the problem? Actually a full blown trace-back would give me enough info to track’m down.
Thanks,
TK
The second one is talking about lockgarage so that is probably the culprit. I just fixed the error message to give you then app name in all circumstances - will be in beta 4.
Hello @aimc,
I am working on an app for remote management, and the system is in a different time zone from where I am, and so the system will have a different time zone by default from where it is being used since I am running it locally. To over come this issue, I plan moving the app for that remote system, to a different virtual environment within the same machine, so I can give it its own system (don’t feel like buying another machine if it can be avoided ). ). if I was to specify the time_zone in the configuration of appdaemon in the new virtual environment, using the remote sites own, when I use python datetime objects like datetime.now(), which one will it pick up? The machine or what was configured in the app?
I know I could use the inbuilt self.datetime(), which I believe will give me the date and time based on the configured time_zone (I think, please correct if wrong). But I kind of prefer using standard python objects if I can when writing my apps. Or do you just advice I get a new machine and build the app on that, so I configure the timezone on the machine itself?
Or I could use this as I saw as example online
>>> import os, time
>>> time.strftime('%X %x %Z')
'23:01:58 02/21/18 UTC'
>>> os.environ['TZ'] = 'WAT'
>>> time.tzset()
>>> time.strftime('%X %x %Z')
'23:02:25 02/21/18 WAT'
Will the above only affect the app, so I don’t even need to create a new virtual environment or something?
Virtual environment or the os itself?. Sorry I am new to python and just need a bit of clarification on what’s happening before I embark on these changes.
Hope my question makes sense? Kind regards
os is operating system.
so using that will change the timezone from the operating system, so for everything that uses the time. (HA, all of AD in every env)
if i google on python other timezones i find this solution:
from datetime import datetime
from pytz import timezone
def local_time(zone='Asia/Jerusalem'):
other_zone = timezone(zone)
other_zone_time = datetime.now(other_zone)
return other_zone_time.strftime('%T')
so you can create the app with local timezone, and when you set a different timezone in the apps.yaml it will change to that timezone (if you call self.local_time(self.args[“time_zone”]) )
Many thanks for the advice @ReneTode, I looked into it, and having created a timezone aware time object using datetime.strptime("21:45:00", "%H:%M:%S").time().replace(tzinfo = pytz.timezone.('Africa/Lagos')), hoping I could use the remote timezone to run a scheduler, I get the following error:
2018-02-22 01:15:32.012894 WARNING AppDaemon: ------------------------------------------------------------
2018-02-22 01:19:23.372154 WARNING AppDaemon: ------------------------------------------------------------
2018-02-22 01:19:23.372806 WARNING AppDaemon: Unexpected initializing app: nkiru_mum_process:
2018-02-22 01:19:23.373329 WARNING AppDaemon: ------------------------------------------------------------
2018-02-22 01:19:23.388995 WARNING AppDaemon: Traceback (most recent call last):
File "/srv/appdaemon/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 1798, in check_app_updates
self.init_object(app)
File "/srv/appdaemon/lib/python3.5/site-packages/appdaemon/appdaemon.py", line 1438, in init_object
self.objects[name]["object"].initialize()
File "/home/homeassistant/appdaemon/apps/nkiru_mum_dia.py", line 48, in initialize
self.run_daily(self.nkiru_mum_night_insulin, runtime)
File "/srv/appdaemon/lib/python3.5/site-packages/appdaemon/appapi.py", line 357, in run_daily
if event < now:
TypeError: can't compare offset-naive and offset-aware datetimes
2018-02-22 01:19:23.391099 WARNING AppDaemon: ------------------------------------------------------------
It seems the scheduler doesn’t support timezone aware time object. Any advice or I should just work on getting the OS to have the right time zone.
you cant use the timezone mixed.
so what you can do is calculate the difference between your local timezone and the timezone you want to view.
then add or substract that difference from the local timezone to schedule things.
but if you only want to use 1 specific timezone (or just 2) it might be more easy to put the difference in a constant.