openHAB 4.0 Milestone discussion

When I converted from OH 3.4 to 4.0 I’ve decided to give HTTP binding a try (I was using SmartHome/J HTTP Binding). But HTTP binding does not support special characters (that is the reason why I was using SmartHome/J HTTP Binding in 3.4). The error message is Requesting '****************/sendMessage?chat_id=5003595502&text=Alerta%20-%20O%20videoporteiro%20não%20está%20registado' (method='GET', content='null') failed: 400 Bad Request

Do I need to return to SmartHome/J HTTP Binding ? How ? I can wait for HTTP binding to be updated.


Looking into the /var/lib/openhab/tmp folder during runtime of “openhab-cli console” a copy of libjansi should be created in the folder and the lock file.
Do you see these files ?


openhabian@openhabian:/var/lib/openhab/tmp $ ls -lsh | grep jansi
 24K -rwxr--r-- 1 root    root     22K May  6 11:01
   0 -rw-r--r-- 1 root    root       0 May  6 11:01

Here is the output of the ps command, I’m not sure I fully understand what you mean.

Running “ps -ef | grep jansi” you should see the path where libjansi is taken from ( source of copy ).
Is that the case ?

openhabian@openhabian:/var/lib/openhab/tmp $ ps -ef | grep jansi
root      9492  9489  3 11:01 pts/0    00:00:02 /usr/bin/java -Dopenhab.home=/usr/share/openhab -Dopenhab.conf=/etc/openhab -Dopenhab.runtime=/usr/share/openhab/runtime                                                                                                                                        erdata=/var/lib/openhab -Dopenhab.logdir=/var/log/openhab -Djava.library.path=/var/lib/openhab/tmp/lib -Djetty.http.compl                                                                                                                                        iance=RFC2616 -Dorg.apache.cxf.osgi.http.transport.disable=true -Dorg.ops4j.pax.web.listening.addresses= -Dorg.osgi.service.http.port=8080                                                                                                                                        =8443 -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:+ExitOnOutOfMemoryError -Dkaraf.instances=/usr/share/openhab/runtime/instances -Dkaraf.home=/usr/share/openhab/runtime -Dkar                                                                                                                                        af.base=/var/lib/openhab -Dkaraf.etc=/var/lib/openhab/etc -Dkaraf.log=/var/lib/openhab/log -Djava.util.logging.config.file=/var/lib/openhab/etc                                                                                                                                        / -classpath /usr/share/openhab/runtime/system/org/apache/karaf/org.apache.karaf.client/4.4.3/org.apache.karaf.client-4.4.3.jar:/usr/share/openhab/runtim                                                                                                                                        e/system/org/apache/sshd/sshd-osgi/2.9.2/sshd-osgi-2.9.2.jar:/usr/share/openhab/runtime/system/org/apache/sshd/sshd-scp/2.9.2/sshd-scp-2.9.2.jar:/usr/share/openhab/runtime/system/or                                                                                                                                        g/apache/sshd/sshd-sftp/2.9.2/sshd-sftp-2.9.2.jar:/usr/share/openhab/runtime/system/org/fusesource/jansi/jansi/2.4.0/jansi-2.4.0.jar:/usr/share/openhab/runtime/system/org/jline/jlin                                                                                                                                        e/3.21.0/jline-3.21.0.jar org.apache.karaf.client.Main
openhab+ 10080  9648  0 11:02 pts/1    00:00:00 grep --color=auto jansi

I also have both files. That is what confused me and led me to the timing idea.

As to

I get Rpi3 (no message)

openhabian@openhab:~ $ ps -ef | grep jansi
openhab+ 22887 22416  0 09:40 pts/0    00:00:00 grep --color=auto jansi

Rpi4 (message)

openhabian@openhab:~ $ ps -ef | grep jansi
openhab+   916   508  0 09:41 pts/0    00:00:00 grep --color=auto jansi

The files go away once the openhab-cli session is closed.

I looked at the tmp folder and the only difference is that in the Rpi3 (no message) I have a mvn directory. Could that be an issue?
Temp folderrpi3

Have you checked your CPU usage? Those are usually the sorts of issues I see when OpenHAB has the CPU pegged for one reason or another.

as i wrote, every ~30h I have a restart of openhab.

and ~2h after restart I have a high CPU usage.

I already tried, what is written here:

But I’ve still a high CPU Usage after ~2-3h:

I have found the work around in Cody’s post here does NOT survive a restart of the host computer. Since you said:

I’m guessing you restart and the setting in the above post are lost and same thing happens. I’ve found that if I reset the safeCall to 100, openHAB runs for weeks without running away. Typical CPU usage is in the single digits.

When it pins the CPU, follow Cody’s advise in this post above and run top in the terminal, get the pid of openHAB then run

top -H -p <pid of openHAB >

with the pid you got from top where it says pid of openHAB above

Anyhow, having to log into the openHAB console and running the commands every time you restart the host is a pain. Cody mentioned that you could probably write a rule to reset the safeCall setting on a restart automatically but I don’t know how.
I also think this is ah… kind of a kludge :roll_eyes:

Curious @ML1982 do you run jRuby rules? What rules languages do you use?

Is this a problem with jRuby or openHAB in general? Anyone feel like explaining to me

@ML1982 @Andrew_Rowe If your setups contain a lot of items and you have default persistence configured (or persistence for a lot of items), you are probably experiencing an issue recently found in th implementation of nearly all persistence services. This is already fixed for MapDB and InfluxDB in recent snapshots and a fix for RRD is on the way.

1 Like

I’m guessing you restart and the setting in the above post are lost and same thing happens. I’ve found that if I reset the safeCall to 100, openHAB runs for weeks without running away. Typical CPU usage is in the single digits.

Have a look at this file.
You can change the parameters of the workaround there and it will survive a reboot.

Is this a problem with jRuby or openHAB in general? Anyone feel like explaining to me

No, I had the problem before I installed ruby today. I only installed ruby because of the advice in the workaround.

I only use ECMA2021 scripts.

Openhab just restarted after 4 hours… the workaround doesn’t work for me.
I have three startup errors that may be related to the “CPU usage and restart bug”.

Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer
The transformation add-on 'javascript' does not exist - ignoring it.

I’ve have to restart this bundles after each restart of OH manually:

You should fix 1 and can ignore 2.

Wow, thanks Jan! :+1:
So if I uninstall default persistence RRD and install InfluxDB problem goes away? I’m on 4.0M2

Any idea how many constitutes “a lot”? Would that depend on system specification?

Would this issue exist in OH3 too?

Thanks for the hint
Mine was located at /usr/share/openhab/runtime/services.cfg
I’m going to leave it be and try removing RRD

I’ve been doing some firmware development on esp8266 and every once in awhile the com port go sideways and the only way to bring it back is to restart
this issue made that kind of a PITA :wink:

good question T
I never had an issue until I fired up OH4

for me 240 items
default persistence setup

1 Like


I am already using influxDB, the persistence setup is

Strategies {
        everyMinute : "0 * * * * ?"
        everyHour : "0 0 * * * ?"
        everyDay : "0 0 0 * * ?"
        every2Minutes : "0 */2 * ? * *"

        // if no strategy is specified for an Item entry below, the default list will be used
       default = everyUpdate

Items {
        // persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
         * : strategy = everyUpdate, everyMinute
         gRestoreOnStartup* : strategy  = restoreOnStartup

        // additionally, persist all temperature and weather values every hour
        //Temperature*, Weather* : strategy = everyHour

I’ve got 636 items and persistence for all of them. I think 636 is “a lot”.

Did I understand correctly that a bugfix is in recent snapshots but not yet in 4.0M2?

I recently disabled the Samsung bundle via karaf. I also reduced the number of lines in fronttail from 2000 to 200. At the moment the system seems to be stable. I will check again tomorrow morning.

About the other bug:

Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer

how can I fix that? I have only integers there:

openhabian@openhabian:~ $ more /var/lib/openhab/etc/org.openhab.threadpool.cfg
discovery = 5
safeCall = 200
thingHandler = 5

Out of curiousity just checked this and for me I can observe exactly the same situation as @apella12 described.
(4.0.0.M2 - Milestone Build on Pi4)

The system remained stable throughout the night.
Now, after enabling the Samsung TV Binding, the OH web interface became slower, CPU usage increased and an hour later I had an automatic reboot of OH.

Maybe it’s related to this issue (Consistent 100% CPU use of safeCall-queue thread - #2 by morph166955) because the Samsung TV Binding uses UPNP, but to be honest I didn’t quite understand what UPNP is.

By the way, the startup error with:

Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer

is still there.

and this one, after starting openhab-cli console

openhabian@openhabian:~ $ sudo openhab-cli console
[sudo] password for openhabian:

Logging in as openhab
Failed to load native osinfo: Linux/arm
java.lang.UnsatisfiedLinkError: /var/lib/openhab/tmp/ /var/lib/openhab/tmp/ cannot open shared object file: No such file or directory


I gather that from the thread that, for JSR223 Javascript rules (in .js files), Java 17 needs to be installed in OH4 (or the Nashorn addon). Will the rules then continue working without further changes, or are there other migration steps?

Regarding what to to with JavaScript rules, the Milestone 1 announcement (openHAB 4.0 Milestone Builds) gives some tips. For JSR223 JavaScript rules in /automation/jsr223, I think installing the Nashorn add-on should be enough, but you should probably migrate to JS Scripting (/automation/js) to use it‘s great helper library.

How much work is involved in migrating to JS Scripting? Any docs on that? Is JS Scripting where there will be more development in future?

It depends. There’s a simple import you can do to make Nashorn JS work with GraalVM JS. So at worst it would be the addition of one line at the top

if(typeof(require) === "function") Object.assign(this, require('@runtime'));

That imports all the stuff that is available to Nashorn rules by default into a GraalVM JS. Note that there are some collisions in names (e.g. items is a reference to a Map of Item names and their current state in Nashorn but in GraalVM items is your interface to access, create, and remove Items. Therefore it’s better to assign @runtime to a variable but that means everywhere you use something injected into the rule (e.g. events.sendCommand()) you’ll have to prepend the variable. If you are going to go through that effort, you may as well port to GraalJS.

There are reference docs for building rules (and transformations) in GraalVM JS (note Nashorn provides ECMAScript 5.1 which was released almost a dozen years ago and has received no updates to the language since where as GraalVM JS provides ECMAScript 2021).

Unlike with Nashorn, GraalJS comes with the Helper Library (no need to clone a github repo and put it in the right spot) or it can be installed via npm. Also unlike Nashorn, the Helper Library goes to great lengths to provide a pure JavaScript interface to OH (all interactions with OH in Nashorn are through Java Classes and Objects) freeing you from needing to worry about type conversions in most cases.

The docs for GraalVM JS are very thorough and complete and can be found at JavaScript Scripting - Automation | openHAB. But because the Helper Library is so much more complete and comprehensive, porting to it is likely going to largely be a rewrite of most lines of a Nashorn rule. Though in my experience the GraalVM JS version of the code is roughly half the size of the Nashorn equivalent thanks to stuff that used to need to be imported (e.g. access to metadata) that come with the library now and new features added to ECMAScript in the dozen years since Nashorn.

To my knowledge there is no work being done in Nashorn now and none planned for the future. All new JS work is being done on GraalVM JS. The Nashorn add-on is there for backwards compatibility. Note: both Nashorn and GraalVM JS can be installed and used at the same time.