AppDaemon locks up

Third party integrations AppDaemon
1

I’m just getting into AppDaemon and am liking the concept very much.

What’s brought me to this is I have some sensors that are reporting very frequently (once per second) and they are filling up the log in HASS like crazy.
So I thought I’d use AppDaemon to do some smoothing and only update the sensor I will log once per minute. This I’ve got going and it works quite well.
Currently I’m running AD under a terminal under Windows 10 so I can see all the debug logs. However after some time it stops logging and no data flows. If I go back to the terminal window and press any key on my keyboard then suddenly it bursts into life and a whole load of errors are shown. For example:
2017-11-14 15:31:03.927408 WARNING Excessive time spent in scheduler loop: 7485418.0ms
2017-11-14 15:31:03.946409 WARNING Scheduler clock skew detected - delta = 7484.437695026398 - resetting
Queue size is 160, suspect thread starvation
…
So it seems to get stuck for some reason.

So two questions - why is it getting stuck? Maybe something to do with Windows Powershell terminal window?
And is this a valid use case for AD? Smoothing maybe 10 rapidly firing sensors to some reasonable level? Perhaps its too much although it seems the perfect place to do this. Otherwise I have to build in some smoothing somewhere else which isn’t easy given the hardware I’m using.

2

It’s certainly a valid usecase.

As for the lockups - I suspect this is something to do with the powershell, yes. I haven;t seen this on any other system types.

3

how are you listening to the sensors?

4

I’m using Tinkerforge sensors but HASS has no component for this so using MQTT for comms.
Made an app to listen to the ‘raw’ mqtt sensor, control the state change flow to 1 per min then publish to a new mqtt sensor for the rest of HASS to use. I’ll log the flow controlled sensor only.

Looking again, its standard cmd under windows not powershell. Almost like the process gets put to sleep for a while until there is some user input.
I’ll consider running it under unix but is a pain when everything else is working.

5

If I had to guess, I’d say it was getting stuck in the main loop doing I/O to the screen - the fact that the Q fills up means that the other parts are doing what they are supposed to. Maybe if you have it write to logfiles instead of the screen it might improve matters?

1 Like
6

Yes log files… makes more sense really. I’ve done that, looking good so far and flow control is working well.

Will look to port over to Linux subsystem under Windows at some point, looks a more solid bet in general.

Good to know this is a valid use case, this whole way to automate HASS is gonna be so much better than the yaml files!

1 Like
7

Yes, I tested it briefly under the Linux susbsystem and it seemed to work very well - running it under DOS means some compromises in funcitonality

8

Yes no doubt. I’ve just rebuilt my server to Win 10 from Win 8 so now got access to Linux subsys on that machine. I’ve got a Raspberry Pi but its already busy handling the MySensors gateway and the mqtt proxy service from the Tinkerforge sensors as well as a camera. Don’t want to buy & power another Pi just to host services when already got a decent Windows server so great to get Linux access under windows at last.

9

the RPI can handle a bit more then that if needed.
on my RPI i have running:

  • home assistant
  • appdaemon with loads of apps. including backups from everything on the RPI to my windows PC
  • nginx
  • ftp server to which 3 ip cams save their pics and mpgs
  • mysensors gateway (but i am going to create another wifi gateway for that)
  • hadashboard with 3 tablets connected to that 24/7
  • webcam

i have all data, pics and mpgs going directly to a USB HD.
and untill now i suspect that that is my only bottleneck.
making backups to the windows pc and at the same time 2 cams recording to the same HD is probably not advisable :wink:
and once in a while my RPI hangs probably caused by that kind of circumstances.

i am goin to try to connect a second HD to it.
but you see that a pi can do a lot :wink:

2 Likes
10

Yes perhaps it can do… My issue was the webcam service (‘Motion’) was eating cpu power meaning my mqtt proxy (which is fielding multiple messages per second) ran very slowly. So I’ve tried to keep it a bit cleaner since then. Rightly or wrongly!
I’d def want to run the HA database on my main server so may as well keep it all under one box. Esp now with the linux subsystem option available.

11

i think that you better worry about the amount of network capacity that goes down with sensors that send values every second.
if you can, you better change the setting from the motion sensor not to send every second.
if you cant i would shut it down and place a mysensors motion detector at that place.

i had some sensors in the past running wild (mysensors which i had not programmed well) giving 60 to 120 values every minute.
not only HA doesnt like it, but everything is going to get in trouble because of it.

12

Agreed - I’ve been chasing down excess data for a while now as it keeps overloading things.
MySensors stuff is all ok, as are my Tinkerforge capacitive sensor buttons and motion detectors. Its just humidity/temperature/light sensors that gitter around. Humidity especially will fire 96.5, 96.6, 96.5, 96.6… And the light sensor too - but then light levels do vary even from someone moving around the room, clouds moving etc…
Guess I need to look again at stopping this excess at source… but just wanted a solution so can finally move on to the fun stuff. Feel like I’ve been trying to stabilise things for too long!
Certainly now things feel better in HA - the charts come up without taking 5+ seconds and the log looks a bit better. Altho still it logs all my service calls despite setting mqtt and scripts domain to exclude.

13

the question is if you really need an update for every little change in light or humidity.
i had the same problem with temperatures.
i solved it by just sending the data at a specific moment instead of by every change.
now i update most sensors only every 5 minutes unless there is a big change.

i got this in my loop:

  if ( not gemeld or millis()-time>300000){
    melden();
    gemeld=true;
    time=millis();
  }

and then i use 1 place to send the data

void melden(){
  send(msgcontroleswitch.set(0));  
  send(msg_light.setSensor(101).set(lichtwaarde));  
  send(msg_temp.setSensor(TEMP_CHILD_ID).set(temperature,1));
}
14

The MySensors stuff is behaving fine - I’ve done similar to you only sending at certain intervals.
It’s the Tinkerforge components I have an issue with - there is no HA component for these sensors so I utilised an MQTT proxy python script (supplied by Tinkerforge) then just subscribe to those topics from HA. But they throw out so much data I ran into problems hence using AppDaemon to control the flow. This is working pretty well but I do agree this wants slowing down at source.
Ideally there would be a Tinkerforge component for HA and I could probably write one if time allowed. Hoping someone does this before I’m forced to! For now I’ll stick to this flow control app or I’ll never get anywhere with my automations…