The second card may definitely help, but the first card would not kill Homey by itself either, unless the actions are causing a really heavy load. Have you checked the cpu use per app to see if one sticks out?
Are you using a lot if “every xx secs/mins” flows?
Do you use Homey in conjunction with e.g. the HUE brigde, which is known to do a lot of polling to get the device startes?
If you think this flow kills Homey, the easy test is to disable this flow and see how much difference it makes.
The average load graph doesn’t seem that unusual, except for the peaks. But three HUE bridges might have a lot to do with it. Do the cpu graphs per app give any clue?
I’ve found out that flows which get triggered too often (but don’t know how many times per sec that would be), are being disabled by Homey, with a notification about that.
So with this info, your flow(s) cannot be the culprit (I think!)
I run a full packed non-pro Homey. Mem usage and the number of apps to the max.
This is its system load, just screenshotted:
Could it be a “buggy” app?
Too much zigbee interference? With 3 Philips bridges, you have 4 different zigbee controllers;
I think a good channel separation, also with respect to your Wifi channels is a must.
Just some thoughts.
The protection you mention is there, but is designed to prevent one flow killing Homey. It cannot protect from the cumulative load of multiple bad designed flows.
But you are right, well designed flows you can have lots and lots of. The devil is in the details, and I too have caught myself having flows triggering way way more than I imagined. And more often than not the solution is simple once you realize what is happening.
@Marcel_Ubels is right that for instance triggering on stuff like energy changes may happen really frequently depending on the device. So it all depends how many of those flows you have, how many updates the device sends (e.g. qubino’s seem to send every tiny fluctuation) and what you do in your flow. But that isn’t saying flows like these are outlawed.
I agree it doesn’t seem the case here as there are peaks, and other times things seem ok. So it may me a flow that causes some kind of temporal avalanche of other flows. Or it could be an app. I am wary of the three hubs. If they get polled a lot, each have many devices, and at times get polled all three at the same time, this might well explain this behaviour. When that happens many device states need to be updated.
You have the system load graph here. Could you narrow down on a specific spike and then check for all the apps and their respective load at that same time/date. That should give you a good hunch already I believe
Looks like amazon was way more CPU hungry for a while (steeper line) but now not any longer. I do think you should zoom in on time level more, because the day averages will hide the peaks.
I’m sorry Edwin, I forgot to explain that the picture should be just an example how it looks, not a problem description!
But regarding to your good eye and your hint, I changed the flow handling with the Alexa app (automatic deactivation/activation to keep Homey connected to Alexa) a few days ago. Maybe there is also a positive result to the cpu consumption.
Well, that’s quite a lot. Case you have 200 flows triggered 99 times a minute, that’s 19.800 flows triggered per minute, 330 triggered flows per second…
That could indeed increase the system load “a little”.
Interesting! But, how to run this without mqtt broker…
@Marcel_Ubels and other readers:
To be able to discover what your flows are doing and when, and how many times (per sec), you can consider installing Papertrails app, and add log cards to all of your flows in just one go.
It also adds ELSE logcards, if used.
It even replaces SimpleLog cards if present.
It doesn’t replace existing Papertrails logcards.
Then, select Papertrails at the bottom right side, then select Maintenance.
From there just follow instructions.
Monitoring your logs / flows:
Via mobile Homey app: go to apps/Papertrails and hit “Configure”
Or via developer appsettings and select Papertrails.
This way you can monitor your flows realtime, without needing to leave the mobile Homey app.
Or, on a pc/laptop, you can edit your flows and monitor the logs with two browser panes next to eachother.
This TriggerQueue is specifically designed to work for the MQTT Cliënt app to prevent flows being disabled if lots of messages come in simultaneously. It can probably be adjusted for generic usage. In general it counts trigger executions and delays the execution if the rate limit hits. In this case the counts are registered per mqtt topic, but this could be any trigger identifier.
At this moment i am not sure what or where the problem is. I killed al the apps and are adding one after one. The apps I absolutely need are enabled, still have to enable 14 apps, but it seems it has to be within those apps( Duux, Email sender, Gallery, Gardena, Google Nest SDM, Harmony Hub, Homey Community Store, Homeyscript, IcalCalender, Lametric, Netatmo, Power by the Hour, Solar Panels and Ztatz)
Momentary this is my average load
What may help, but YMMV of course: I have an average load of around 35% on a Homey pro, and lots of apps, devices etc. I also run Harmony Hub, Homeyscript and Power by the Hour from your “todo” list. Homeyscript of couse depends a lot on your scripts. But from my experience those shouldn’t hurt either. I think I may have read somewhere the cummunity store may be a bit on the heavy CPU side. But that may also vary I guess depending on the amount of apps it checks? I’m not sure which of the community store apps I read that about.