Is there a way to get a list of the apps active in appdaemon? Not necessarily from code, but just a appdaemon --status command or something?
Depends what you mean by running? It should probably be all the apps listed in the config which you could grep for.
looking for ones that have stopped overnight and died without having to go through the error log. Think of it as a watchdog of sorts that will restart apps that have died.
How do you define “died” though? If AppDaemon is working correctly it will run callbacks when you tell it to - it has no way to know if you didn’t program a call or bombed out due to an error.
I thought when you did the sudo killall -10 appdaemon that the objects list was files that were “working”
Again, what do you mean by “working”? Among other things, the kill command lists all the objects that represent AppDaemon apps - that is the objects list. To be in there they just need to be in the config file and survive the loading process.
They are just lumps oif code that do nothing until AppDaemon calls into them for one reason or another they are doing nothing between these calls so can;r be said to be running or working or not. One possible definition of working could be “an object has one or more active callback” and you can also get that information from the kill command. If you think it is useful I am happy to give you a way to get this kind of info programatically - some introspection functions on Apps could be a cool thing to have.
A list of callbacks and schedules would be nice, especially if I could restrict it based on the app I’m working on. I guess the running/working app doesn’t really make much sense or at least I’m not sure how to explain it. It may just be that the apps don’t have any callbacks associated with them anymore so there isn’t any way to get them to do anything. I’m not sure. Let me think on it some more now that I have a better understanding of what AppDaemon is doing and how.
That’s it in a nutshell - that’s the only useful definition I can think of. Maybe a flag that automatically restarts an app if it’s last callback expires? You wouldn’t want that on all apps probably but it might be a nice idea.
maybe ,could be.
Hi
I have recently experienced the same issue. Without any errorlog Appdaemon stopped running any of my apps. When checking with ps (on debian jessie) I see the PID is still around and has not changed from the moment I had started it.
When I make apps with for instance nodejs I use “forever” as a safe mechanism to reboot the app when it stops running, but that really needs the app to stop its active PID. Problem is that appdaemon seems to have frozen, when I kill the PID and restart it just works as if nothing has happened before.
I was thinking of letting an external app (maybe python or nodejs) listen to a heartbeat signal from appdaemon over mqtt. When the heartbeat does not update it could kill the PID and start a new one ?
this is the last part of my log (also shows the new startup)
2017-08-22 08:28:56.958068 INFO wunderground: get weatherdata
2017-08-22 08:29:01.529418 WARNING Scheduler clock skew detected - delta = 1.606292963027954 - resetting
2017-08-22 08:29:06.476501 WARNING Scheduler clock skew detected - delta = 2.947082042694092 - resetting
2017-08-22 08:30:20.013580 WARNING Scheduler clock skew detected - delta = 2.5371100902557373 - resetting
2017-08-22 08:30:27.211273 WARNING Scheduler clock skew detected - delta = 1.19769287109375 - resetting
2017-08-22 08:30:32.818389 WARNING Scheduler clock skew detected - delta = 4.607086181640625 - resetting
2017-08-22 08:30:47.323669 WARNING Scheduler clock skew detected - delta = 1.5052788257598877 - resetting
2017-08-22 08:31:56.516815 WARNING Scheduler clock skew detected - delta = 1.193145990371704 - resetting
2017-08-22 08:32:00.511413 WARNING Scheduler clock skew detected - delta = 2.9945991039276123 - resetting
2017-08-22 08:32:01.556304 INFO wunderground: get weatherdata
2017-08-22 08:33:30.597290 WARNING Scheduler clock skew detected - delta = 1.0858759880065918 - resetting
2017-08-22 08:34:14.652587 WARNING Scheduler clock skew detected - delta = 6.055298089981079 - resetting
2017-08-22 08:34:37.582122 WARNING Scheduler clock skew detected - delta = 1.929534912109375 - resetting
2017-08-22 08:34:41.174774 WARNING Scheduler clock skew detected - delta = 2.592650890350342 - resetting
2017-08-22 08:34:53.460235 WARNING Scheduler clock skew detected - delta = 5.285462141036987 - resetting
2017-08-22 08:34:54.497680 INFO Check_Servers: checking uptime servers
2017-08-22 08:34:56.496551 INFO wunderground: get weatherdata
2017-08-22 10:44:33.059570 INFO AppDaemon Version 2.1.7 starting
Any ideas ?
regards
Cor
Wow do you get all of those clock skew messages normally
Sometimes they keep coming. Might be due to the uncommon platform. I am running Appdaemon on an Android phone in a chroot Linux Debian environment. I have no idea how to cure those skews. What I have done before is to change the skew threshold in appdaemon.py to 15 seconds or so. But I then would need to do this every update …
regards
Cor
See below the log after I changed the skew to 15 seconds
Things run OK and only 2 skews were reported in a timespan of 30 minutes.
2017-08-22 14:00:00.393219 INFO Timeline: NRC
2017-08-22 14:00:43.446868 INFO Alarmmode: binary_sensor.serredoor_status
2017-08-22 14:00:51.271820 INFO Timeline: NRC status changed
2017-08-22 14:01:14.259429 INFO wunderground: get weatherdata
2017-08-22 14:04:14.887420 INFO wunderground: get weatherdata
2017-08-22 14:04:35.641815 WARNING Scheduler clock skew detected - delta = 18.40997290611267 - resetting
2017-08-22 14:07:14.677642 INFO wunderground: get weatherdata
2017-08-22 14:08:06.677429 INFO Check_Servers: checking uptime servers
2017-08-22 14:10:16.722686 INFO wunderground: get weatherdata
2017-08-22 14:13:14.679382 INFO wunderground: get weatherdata
2017-08-22 14:16:14.677703 INFO wunderground: get weatherdata
2017-08-22 14:18:06.677398 INFO Check_Servers: checking uptime servers
2017-08-22 14:19:14.677398 INFO wunderground: get weatherdata
2017-08-22 14:20:13.780883 WARNING Scheduler clock skew detected - delta = 21.139069080352783 - resetting
2017-08-22 14:22:14.815643 INFO wunderground: get weatherdata
2017-08-22 14:25:14.817749 INFO wunderground: get weatherdata
2017-08-22 14:28:06.815521 INFO Check_Servers: checking uptime servers
2017-08-22 14:28:14.809845 INFO wunderground: get weatherdata
2017-08-22 14:31:23.488586 INFO wunderground: get weatherdata
does it lockup with the longer skew threshold?
Clock Skew occurs when the main loop of the scheduler is unable to get through all of it’s tasks within the 1 second period of each tick. This should mainly be housekeeping stuff like checking of files have changed and processing scheduler callbacks - it isn’t related to anything directly that happens in Apps as they are running in separate threads. On an under powered machine it’s possible that this could happen if maybe you had a large number of scheduler callbacks and lots of files to watch. Setting the skew to a larger value will really just kick the can up the road, you will end up with events firing up to 15 seconds late. The error is actually a good thing because it is correcting the skew and resetting the clock so drift doesn’t occur.
Thusfar its running for several hours with a 15 second threshold …
Hi
Any idea how I can diagnose if the skews are indeed due to housekeeping. As stated with a 15 second setting I get thusfar no freeze of the system. I have used that before without problems. if it will lead to an event firing 15 seconds late the most I prefer that instead of a full freeze. Like stated if it would not freeze but stop I could detect/restart it easy. But I am going to see if I can find a way to prevent this happening.
I really like the way Appdaemon allows me to build a system that is far more flexible and easier to maintain than only using HomeAssistant. Thanks for providing this !!
Cor
I can add some additional debugging in the next version.
That would be very nice. Its always good to find out the root of something that causes issues.
The devices I am using are definitely not standard but they do work fine most of the time. I am running Appdaemon in a linux Debian chroot on an android phone.
The processor and memory are alike Rpi3, tried with sysbench they are nearly on par. On another spare old phone I am running Homeassistant.
I have to say, it’s a first as far as I know. I guess you aren’t using a zwave stick with homeassistant though. 