Use CPU load percentage in LOGIC

I would like to be able to use the CPU load percentage as a value in Homey’s logic.

The data is available in Insights, and at times, the load peaks. Flows that run every x seconds/minutes that aren’t related to immediate tasks like lighting, could be skipped when the system load is too high.

It seems small, but would help me a lot.

Or try to find out what’s causing the peaks…

1 Like

have you tried the sysInternals app?

If I knew, I would’ve reduced the load of course. I have a ton of very complex flows, with lots of calculations running frequently (not every 10 seconds, but still quite often).

I cannot trace back those peaks. But if I can skip some calculations at high CPU load, that could be a solution as well.

Thank you Adrian, I didn’t know there was an app for that. Will try it!

1 Like

Thank you so much, this is exactly what I’m looking for! I will integrate it in my flows, and hopefully the peak CPU loads will no longer interfere with delayed switching of my lighting.

1 Like

@robertklep @Adrian_Rockall

I created a variable when CPU load (1min) exceeds 39%, then 90% of my periodically started flows won’t start until the next time, and when the CPU load is below 30% again. This was implemented yesterday around 16:00.

I was quite hopeful this would help. But sadly, this hasn’t changed anything. I checked the CPU usage of all my apps, and there is no single app that could be responsible for peak CPU loads.

Is there anything else I could check? My RAM usage is around 75-80%, but rarely exceeds 80%.

Thank you for thinking with me.

Do you actually disable those periodic flows, or did you add a guard to then (“AND cpu load < 30”)? Because with a guard your flows are still started, they just don’t continue. It might be worthwhile to see what happens if you actually disable those flows so they don’t get started at all.

Other than that, there are a few apps that can provide flow logging, which might be useful to see if there are specific flows running at the same time the peaks occur.

1 Like

I start flows, but the first card is the check of the CPU load. Do you still think it will make a difference whether I disable the entire flow? There are more flow sections in each advanced flow, so in that case I could split them up, and disable only the periodically started sections.

Do you have suggestions of those flow logging apps?

I don’t know if it’ll make a difference, but it’s something to check. I can’t recommend any logging apps since I don’t use them myself.

1 Like

Came across this topic when looking for something else…

Tried to use sysinternals originally, but wanted to have troubled App-CPUvalue instead (I have rather heavy HomeyScrip every 15min).

so created this (propably ugly but working code):

// Fetch current CPU load of App
const targetApp = args[0]; // Get the target app from the arguments

const appsInfo = await Homey.apps.getApps();
for (let entry of Object.values(appsInfo)) {
let appName = entry.name;
if (appName !== targetApp) {
continue; // Skip this iteration if the app name doesn’t match
}
// If the app name matches, get CPU and memory usage
let cpuLoad = entry.usage.cpu; // Access the CPU usage
let memUsage = entry.usage.mem; // Access the memory usage
console.log(App: ${appName}, CPU Load: ${cpuLoad}, Memory Usage: ${memUsage});
return cpuLoad; // Return the CPU load if found
}
// If no app matches the target app, return -1 to indicate no match
return -1;

Then flows like this:

And

---- update —

Improved upper part of flow when tuned some low-prio flows to run even faster (now also 5sec
(+ 3sec delay) level wo issue) as blocking to be too slow to stop…

Small explanation:

  • HomeyScript as before
  • “10.10…” is flow where (all of my) lodash functions are introduced like in example
    image
  • “testing only…” card is testing just one of them to verify if passes (as if HomeyScript taken down they are gone as well)
  • Any Low-prio flow can be (safely) started with e.g. (running check just to double sure if wished):

And updated insights for the same - blocking shorter than before but yet more effective: