Why OH4 burns more CPU than Home Asistant

Hardware Home Automation
1

Hi

I am sharing some observations of my latest experiments on OH4 and HA, so take my comparison with some tolerance and grain of salt for posible OH5 imporvements.

1. My New LAB and impovements

So i started my fresh LAB on mini pc with clean OH4 and i also loaded the new boy on the block Home Aisitant, that felt all to complicated and buggy back then, it appers it evolved and it can help integrate more devices together with OpenHAB.

I havent figured out how to conect both together, it apears MQTT is a way, any others?

I was runnig into issues with integrating EcoFlow devices in OpenHAB as i was unable to send comands with my python script so i resorted to prebuilt solutions on GitHub made for HA, so HA it is.

I run pepermint 12, build debian 12 on N100 GMKtec G3.

I loaded HASS OS VM in Virtual Box on N100 mini pc and it starts and runs with zero noise from CPU fan.

I installed openhabian on my pepermint without VM.

So i don’t know why OH is so much heavier to start that it burns CPU fan to the max.

image
image646×125 4.64 KB

All i know is that OH runs on JAVA VM, while HA on Python and Docker.

So here is my idea for improvement
I understand that OH is busy parsing bunch of my items rules and other config on start, but i think in OH5 that could be improved to take less CPU power, maybe with come chache when nothing changes.
But anyhow i see loading OH prior to config is also heawy.

I am surprised like how HomeAsistant starts like nothing needs to get loaded and crunched by CPU.

And here is OH and HA running with all lightweight config on new system, while OH does surge sometimes with rules on data analisis.

image
image641×140 3.77 KB

2. My OH Backrground story

I started with OH in 2018 as per my posts on comunity, and back then i started with central heating automation on Luxtronik heatpump and MAX thermostat binding, it was like magic tool to conect diferent devices.
Luxtronik heatpump bunding works perfectly, MAX destuch thermostats are mediocre cause of crappy bridge, but it works for water flow metrics fine to decide for heatpump target temperature, if i dont touch any room temperature settings in OH.

Then in 2020 i started with MQTT devices like ESP8266, Tasmota smart Plugs and so on, i built greenhouse controllers and water storage sensors, automatic shades, Power monitoring and more.

And i arrived into the era where i see i used OH as monitoring tool so heavy for so many devices that it’s time to step back and optimize the performance of all the automations, as CPU load was higher than ever every few months. Not to mistake that with my new clean system i mentioned earlier.

3. Conclusion

Now i wish all MQTT devices could get integrated with few clicks, where i see convenience with other bindings to get devices in OH by autodiscovery, and got blown my mind in HomeAsistant that a device got from discovered to integrated with entities and on dasboard with 4 clicks and while its not yet custom and pretty its good enougs to start automatin. Thats efficient.

And here i face the temptation to have my MQTT devices act like that, conectt integrate automate and test in 15 minutes opose to 1 hour.

While the evil with colud devices remains, as i mainly used HA for those that they are unavailabe and buggy, errrr, even tho others dont notice like dishwasher or powerstation being offline :sweat_smile: ocasionally.

And i also miss some more comenters on some niche topics i post sometimes :grinning_face:

Best
Matej

2

Node red.

3

Question is, what’s configured?
I’m using openHAB since 1.0 back in 2012(?) and always used it in virtual environments. My current system is an amd Ryzen 5 3600 6 core/12 threads processor based platform.
Over the years I had sometimes issues with heavy cpu load, but that always rooted from other issues, may it be network, may it be a faulty hardware or time consuming workload from access (VS Code via LSP
).

grafik
grafik1315×659 28.6 KB

This is the average CPU load for the last month. If looking for maxima, the picture is slightly different, there are definitely some peaks, but the machine gets updated regularly and there is quite some data flow (some of the channels get updated every second), so this is to be expected.
All in all an average cpu load of 3.2% (one cpu thread) seems to be ok for me.

4

My 2 cents, I think startup CPU is not that interesting, but probably it’s normal Java behaviour at startup. Loading classes from jars, increasing heap, garbage collection takes some effort during startup of an application. Starting any big web application on a Jetty also peaks CPU at startup.

However, when it runs on my Raspberry Pi 4 (combined with mqtt, 25 rules and 6 nodejs apps) CPU is between 6% and 9%. I’m happy with that.

5

Exactly, it’s just on startup (which normally is any some weeks only).
And you must not attempt to compare HA and OH here as they’re completely different architectures.

Bottom line: CPU load is of negligible importance.

1 Like
6

Can you elaborate why? From end user perspective they serve the same purpose.

This doesn’t seem right, there must be something which bothers your environment. Full use of 4 CPU cores may appear during startup of the OH, but beyond that it should consume low amount of processor. Can you confirm that Java is the process which consumes your CPU time? If so, please try playing with scripts pointed by Tomasz Nurkiewicz: Which Java thread consumes my CPU?. They may help you identifying which thread among ones started by JVM is taking time.

7

OH is Java and HA is Python so due to parsing/JIT compilation w.r.t. CPU what OP sees is to be expected, isn’t it?
But it’s pretty meaningless at the same time. Home automation now isn’t a CPU bound application.
Typically (short of bugs or bad user side programming logic 
) neither OH nor HA perform better with more CPU power at hand.

1 Like
8

There are many threads where this difference has been discussed and analyzed. Here’s a recent a discussion of the cost-benefit of this approach:

3 Likes
9

Although I will have to upgrade my system when OH 5 arrives, I am astonished to see how low the CPU usage of my current system is.

afbeelding
afbeelding871×495 20.6 KB

Here is my configuration:

  • Raspberry Pi 3B (1GB memory, 32 bit)
  • OH 4.3.4
  • 47 things
  • 268 items
  • 58 rules

The peaks are mostly when I am actively looking at pages or editing things. The peak at 4:00 is the daily restart of the system. I do this to discover eventual startup problems and to flush the rrd4j persistence data from zram to the SD card.

10

I am glad to see others experience with OH, that chart with cpu is a valuable solution i did’t have, so i was scrambling to get CPU load in persistence to see over time what is it doing on my LAB and Main system.

I did ran into all posible limitations over time with heavy data analisis of persisted heatpump eficiencies, greenhouse and power analisis over the month so CPU, RAM and HDD writes were all a bit high.

Sounds interesting to use, i will install it and see how it goes, how simple it is done actually to get data over to OH or back to HA?
i did see it Node RED in action at the Swiss Accent guy on YT.

Well i run it on power eficient hardware, that istn a big desktop machine :hugs:
Prodesk mini G1 i5 4590t 8G 120G, minimal fan noise 20W
Main system, latest OH2.5
85 things
262 rules
2053 items, lots persisted, lots of querries over a day,

Home automation, power analisis, greehouse controllers heating, and device automation based on data analisis over minutes or hours that apears to the heaviest, load.
And 4 VLC services * H264 to MJPG streams for survailance, they burn around 15% cpu.
It lacks cpu % but it apears to take like a big hit on Load Avg ocasionally.

image
image500×253 14.6 KB

Gmteck G3 N100 8G 256G, quiet idle but super noisy under load, cheapest new performer 10W :sweat_smile:
Lab system OH 4.3.2
85 things
262 rules
2053 items, lots persisted, minimal long querries over a day, home monitoting only

image
image497×255 21 KB

Rasperry pi 4 2G 32G 5W
Remote system OH 4.2.0
28 things
93 rules
1084 items, some persisted, short but frequent querries, for real time power analisis and smart plug automations for load shedding.
image

And on all of them i see high cpu load except on LAB its rarely high, but when it is it brags that fan lke taking off :rofl:.

Seems like HA does this History partly by itself, like nice state log and charts.
It seems not to task the sistem much,compared to sth like Influx DB i use on main OH system.

While on new system and raspberry at remote house i use rrd4j that apears to use less CPU, but back in the day it used more SSD writes, it apears fixed in OH4 :grinning_face_with_big_eyes:.

It’s actually both heavy usage and heavy system beneath regarding JAVA, anyhow reliability is quite fine now i figured out the edges.

Except when the cloud connection goes offline and notifications stop working, i dont enjoy that it apears to go off no mater the OH version or load. I dont care it going offline but it seems not to go back online by itself i need to reset colud connector or OH.
I may have to do the script that does so.

That sounds smart move i didnt consider, but it apears i have some issues on Raspbbery related to the rrd4j disapearing or file being broken.

11

You don’t. You expose the HA and OH items in node red, from there everything is handled in node red. This is an absolute win because node red has much more automation possibilities than HA, and OH gets to leverage all addons from HA.

12

Wait i dont understand

I get the automation part is mint :grinning_face:, but well i dont get it to act like bridge or?



To shed light on my experience so far regarding OH:

I may have focused too much on startup cpu load, i meant all around performance, but that is heaviliy related to the configuration, and in some cases it is too easy to eun it over the edge wirh RAM or CPU depending on like type of work like Influx DB average since(now.minusHour(1)) is heahy if there are 3600 data points.

I found out OH has some flexibility but its a lot of time, and work to have skookum system all round when lots of devices get in. And then shortcuts bite later with heavy scripts with unecesarry data being procesed, and aslo lots of errors, i see OH lacks internal checks if there is no value, theze rules suspend but shuldnt flood the log.

In reality i only bogged down the N3050 back in 2020 and had to upgrade to Prodesk wirh i5.
So everything here is no critic to OH but more so to shed light on where are performance kinks that apear when system grows.

So i started an era or reimagining how i do home automation, valuing time that it is more about smart solutions over long programming of devices and then also OH.

I enjoy adding a device, a script and automation here and there that is fully custom, but i got over with devices with lots of items they are the whole system and they will require autmation to integrate to the new system.

So for me HA complements OH as it brings inspirations and some fresh air of choice, that i do it where it fits me given the compatibility or ease of use. Mainly for automation prototyping.

OH still feels like main pain of glass that everyone of us at home uses already to check on watering, heating, power, survailance.
I can say i have the new proper 4 channel CAM player in HTML website runing on OH only locally :grinning_face_with_big_eyes:.

13

Nah, you expose items of OpenHAB and home assistant inside of node red. Some nodes will pull information from both, others send commands or updates to them. Simple example would be : get state from OH → if OPEN → send command ON → to HA lightbulb

All this is done on nodered which can see the states of both applications (or public APIs, or tasmota/mqtt devices directly, etc etc etc)

1 Like
14

FWIW, I recently started a binding. I’m using it for zero export (storing excess solar power to battery, take power from battery when needed) with my Delta 2 Max + Powerstream, it works fine for that purpose already.

1 Like
15

The MQTT binding can autodiscover and create Things for the following standards:

Notice that the HomeAssitant standard is in there.

Which rules langauge?

If you are running zram and you restart the machine without nicely shutting down (e.g. pulling the plug or issuing a STOP to a VM or the like) zram and waiting for it to flush the files to the file system, you’ll lose everything.

But unless you are running off of an SD card (you mention SSD above) you should not be using zram.

like Influx DB average since(now.minusHour(1)) is heahy if there are 3600 data points.

Use a rule to keep a running average and you won’t need to hit the DB. Or you can use the inmemory persistence for an operation like this and you won’t need to go out to a third party service to get the data.

An Item always has a state. What specifically are you referring to here?

In general, OH is RAM bound but not CPU bound. It’s rare for OH to be taking up more than 5% of one CPU once it gets going. And I have a bunch of sensors reporting once per second and each sensor reading may kick off two or more rules depending on which sensor it is. So my OH is doing quite a bit even when running at a steady state. During startup indeed OH kits the CPU pretty hard, but only for about five seconds or so at a time a couple of times for the first three minutes of the process running.

But there are some things that are known to hit the CPU pretty hard.

  • Rules DSL takes more CPU than the other rules languages during startup.
  • If you force the types of your variables in Rules DSL code, that can add a ton of extra CPU needs when your rules are first loaded.
  • If you force the types of your variables in Rules DSL code to be primitives, it’s ten times worse (I once was able to add five minutes of solid CPU to the start of OH on a VM by adding three variables forced to be primitives and doing one equation with them).
  • External persistence is going to require more CPU than the internal persistence options.
  • Rules languages like JS and jRuby (especially jRuby) are usually much faster than Rules DSL when running in addition to startup.
  • I’ve seen anecdotal evidence that forcing the type of variables in Rules DSL also increases the amount of CPU it takes to run too.
  • I’ve seen anecdotal evidence that managed configs (e.g. configs in jsondb) take a lot less CPU and time to load than file based configs (.items, .things, .rules, et al).

If you are seeing lots of CPU being used after startup, I’d guess (based on other things you’ve said) that you have Rules DSL rules that pull lots of values from external databases and then processes them in a way that forces the types instead of letting OH figure out the types at runtime.

If it were me, I’d do a little work to see which rules are taking the longest amount of time to run. That could be an OK proxy for which rules are using the most CPU (unless you are using sleeps).

You can see when each rule starts and stops by changing the org.events.RuleStatusInfoEvent to INFO. That will add entries to events.log which can be used to see how long each rule is taking to run.

Then look into those rules. Are you unnecessarily forcing the types of your variables? Are you doing expensive persistence operations which could be handled without hitting persistence (e.g. calculate it as the data comes in) or using a different persistence which might be more efficient? Maybe experiment with rewriting it in a different language and see if that makes a difference.

Some of my experience is a little old at this point, but they come from helping HestiaPi get OH 2.4 to run on an RPi 0w where it would take up to five minutes to start up before I changed things and I brought that down to 1.5 minutes. I mainly achieved this by:

  • all configs possible were moved to become managed (JSON is much easier for OH to load than DSL)
  • moving the rules to JS
  • adding in “fail fast” where we test as early as possible to determine if something needs to be done and only if it does actually run certain code.

In this case it was CPU limited and exacerbated by the fact that the RPi 0w has only one CPU core.

I don’t think there has been much that has changed from then until now that would change how this improvement would work today too.

1 Like
16

Hi Rich

Exciting to see your post :grinning_face_with_big_eyes:

Indeed i run rules dsl and some expensive influx dbb querries, i had to actually put in switch items to turn off some heavy querries to run them on demand only.

Regarding the Raspberry and rrd4j i run on USB key, i wish SSD would work, but i seen low voltage issues cause of power draw, i havent found proper SSD for Pi 4 yet and proper adapter.

I may be runnning zram if it is on by default in openhabian, i will ckeck out, but it may also be USB key failing on some sectors? I hadd issues with failing CRC on latest USB clone backup, so maybe red flag, but system works for 6 months still, i changed no config to play safe untill i get there in summer holidays and bring new configured USB drive in, to swap out old key.

I usually never written the check if null and operations like string parsing fail, alike the JSON parsing in Items when there is no json entity being found by path.
I did some tests with JSON in things being more flexible and actually alowwing string to number conversions even on OH 2.5 i still can’t stop using :sweat_smile:

These rules grown like mushrooms over the rain and mainy on autopilot with old MQTT integration i wrote years ago.

Apears JS is quite famliar toso that seems promising,
Will see what’s the cleanest way to do it, but sure i will have to make better interface for devices without rules that lod devices still use, new are on JSON already and no rules for ingest only analitics.

That no DB on RAM data analisis is smart idea, how i actually use it?
You mention inmemory, i will have to research that :grinning_face:

I only grsaped over and already seen loads of practical solutions, so grateful for that :innocent:

Thanks
Cheers Matej

17

But that can’t really be automated or done for you because we don’t know what should be done in that case. If an Item’s state is NULL that means it’s never been initialized with a state. That might be an error. That might be expected. That might be a warning. That might be a catastrophic error and an alert needs to be generated.

We can’t do that for you. So it’s up to you to test for those cases and handle them accordingly.