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 'https://api.telegram.org/bot****************/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 ?
yes
openhabian@openhabian:/var/lib/openhab/tmp $ ls -lsh | grep jansi
24K -rwxr--r-- 1 root root 22K May 6 11:01 jansi-2.4.0-6a213f869437973-libjansi.so
0 -rw-r--r-- 1 root root 0 May 6 11:01 jansi-2.4.0-6a213f869437973-libjansi.so.lck
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 ?
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
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.
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.
/var/lib/openhab/etc/services.cfg
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:
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
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
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.
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
Password:
Failed to load native library:jansi-2.4.0-43230a45d4ce9e45-libjansi.so. osinfo: Linux/arm
java.lang.UnsatisfiedLinkError: /var/lib/openhab/tmp/jansi-2.4.0-43230a45d4ce9e45-libjansi.so: /var/lib/openhab/tmp/jansi-2.4.0-43230a45d4ce9e45-libjansi.so: 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.
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.
