i am running openhab 3.x on raspberry pi zero 2W on debian 11 bullseye with
openjdk 11.0.15 2022-04-19 LTS
OpenJDK Runtime Environment Zulu11.56+19-CA (build 11.0.15+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.56+19-CA (build 11.0.15+10-LTS, mixed mode)
First steps was to create swap and zram :
Filename Type Size Used Priority
/var/swap file 2097148 135740 -2
/dev/zram0 partition 262140 261200 100
after starting openhab
razem użyte wolne dzielone buf/cache dostępne
Pamięć: 467Mi 330Mi 66Mi 0,0Ki 70Mi 84Mi
Wymiana: 2,2Gi 386Mi 1,9Gi
my config is based on file /js configuration… and it takes a while to load rules from .js even pretty short ones. i did change also : rg.eclipse.smarthome.threadpool:RuleEngine=45 in runtime.cfg - which helped a lot.
CPU and MEM usage is not 100% so i don’t know why it takes i.e. 2 minutes to load a simple .js script
2022-06-06 21:50:07.020 [INFO ] [rulesupport.loader.ScriptFileWatcher] - Loading script '/etc/openhab/automation/js/simplyecho.js'
==> /var/log/openhab/events.log <==
2022-06-06 21:51:26.107 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'RadiatorAC2_scheduled_TargetTemperature' received command 19.0
==> /var/log/openhab/openhab.log <==
2022-06-06 21:52:04.391 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@67eb2d37' takes more than 5000ms.
==> /var/log/openhab/openhab.log <==
2022-06-06 21:52:13.974 [INFO ] [automation.script.file.simplyecho.js] - how long echo takes
You can run OH on a RPi 0W but it’s not going to perform super well. I can provide a few bits of advice but unless you plan on a very small system and don’t mind waiting 20 minutes for it to start up you will be unhappy.
Do not use ZRAM. There are two big problems with the RPi 0W when it comes to openHAB: the single CPU and the low amount of RAM. Trying to use ZRAM is only going to make the lack of RAM worse.
Don’t use file based configs. You’ll add dozens of minutes to the load time when using file based configs compared to managed configs (i.e. configs done through the UI, REST API, or karaf console). Using all managed configs will mean maybe a ten minute boot time and file based configs will be 20-30 boot time. *
The RPi 0W has only the one CPU. Only one thread can run at the same time no matter what. Increasing the thread pool is just going to allow more threads to be sitting around waiting for their chance at a few CPU cycles.
In short, what you are seeing is what you can expect trying to run OH on an RPi 0W and some of the things you’ve done will only make it worse.
TANSTAAFL: while you’ll save on boot time, the first time the rule runs will have a delay. By using managed rules you are spreading out the loading and parsing of the code, not eliminating it.
Cześć Jacek,
I am pretty sure you don’t want to create 45 threads for rule engine itself as pi zero will not have any chances to deal with such amount of concurrency once its needed. Better keep pool with few threads (half/same as available cores) and let rules be queued if there are too many executions of them. I do believe that this setting is also not an effective one as threadpool key you mentioned indicates smarthome and not openhab, it must be something else.
Reason why starting up js stuff is that long is trivial - it must be interpreted at the runtime. Your script is not compiled so its parsing takes a lot of the time, same thing will be with xtext which will require parsing and generating some bytecode in order to execute it within java virtual machine.
Another point - with low memory (512 megs) you are dangerously close to start swapping things from ram to disk and so on. Adding zram which also wants to use memory you will have mixed startup results depending on who got access to memory. I’d say that absolute minimum for memory is 1-2 GB. If you wish to stay with less you simply have to start trimming down openHAB from memory hungry things (jetty/netty/jackson), but then you have to sacrifice functionality which you probably depend on. Another path is native compilation (java > x86/arm binary) which probably nobody have attempted.
Thank you so much. It seems there is not much to improve, i will check your insights, but i was already there trying (like with no zram)
The reason is not complicated - lack of rapsberry pi on the market, i bought few pi zeros and would like to make use of them. Now searching for some used boards with more RAM. This setup has been designed for simply heating controller with PID & PWM, but even triggering simple rules like turn on/off 2-3 rules, and send comand to 2 items are not working as expected.
i am still not convinced why interpretation of script including "console.log(“test”) is taking so long - especially if the resources are available
Threads at a low level are helpful when you have either multiple cores or if you have a very spikey load. The additional threads can in a way queue things up for cpu and allow some processes to execute faster because the cpu will switch through the threads doing bits of each. This may make the appearance of faster execution but only really helps in some tasks. Ultimately things will take roughly the same time. Threading can be helpful in network tasks and such since alot of the time there is waiting. That said most modern setups (openhab included) will move to other tasks while waiting and not block. Some scripts though can be blocking depending on how they are written.
Depends on what you mean by interpretation. doing a console.log or anything where you are preventing execution until it completes prevents any async nature. So if you do xyz and then log before doing 123 then the cpu has to get to and gain control of that thread to log it out then continue. whereas if the script is xyz123 then as much of the tasks that can be asyced out and dont require certain resources will go faster.
In general File IO will always be the slowest thing you can do in a system (besides network) and that is a console.log. You further compound the issue with a rpi because the storage isnt fast. Micro sd cards (even nice ones) are slow. That is also compounded further by the fact that the sd card in a rpi is not fast. The overall “bus” speed of the SD card slot is approx. 23MB/s. Not to mention that sd cards are typically not fast when it comes to random reads/writes (logging, app data).
