A gradually increasing memory leak, as I detailed in this thread.
A rise in load when HABApp is running (HABApp Thread)
Regrettably, my main focus was on the second issue, to observe the impact of various changes. Here’s what I did:
I utilized the macvlan network for openHAB and other components of my home automation stack. ==> I set openHAB to be the sole container operating in network_mode as the host. The other services (like mqtt, influxdb, grafana, etc.) ran with bridge network. This alteration had no effect on the second issue; I didn’t evaluate the impact on the first issue.
I configured the HABApp container to map its config directory to the OH4.0.1 automation directory (JSR223). The HABApp config directory also serves as the storage for its log files, which are extensive (log+events).
==> I relocated this volume away from OH4.0.1, which eliminated the rising processor load.
Now, when I observe the memory usage starting at about 6 pm yesterday (marked as 2), the graph remains perfectly flat. Before that in section 1 the memory curve is looking flat too, which point to macvlan to being the issue.
Hello found a wired behaviour in OH4 and it was not there in OH3 taht’s why I choose this thread
I am using this rule from the community
everything is running fine I don’t see any misbehaviour so far but i get this errors in the log
2023-07-30 12:15:04.827 [WARN ] [ore.thing.internal.ThingRegistryImpl] - Cannot create thing. No binding found that supports creating a thing of type 'tlpicker:tlp'.
2023-07-30 12:15:04.884 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'tlpicker:tlp:home' because the thing type was not found in registry.
2023-07-30 12:15:04.887 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'tlpicker:tlp:home' because the thing type was not found in registry.
Hello
After upgrading to 4.0.X, InfluxDB persistence sometimes doesn’t reconnect when the connection goes down. At the same time, there is nothing in openhab.log. To restore work, just enter the InfluxDB persistence settings and save without making changes.
Tried clearing cache, reinstalling InfluxDB persistence. Didn’t help. At the same time, when reinstalling InfluxDB, persistence always restored the settings (?).
Tell me where to look and as a temporary measure - how to programmatically restart InfluxDB persistence?
P.S. Prometheus metrics capture InfluxDB persistence activity but no data is being sent to the database. The base at this time also does not fix any problems on the part of the client.
2023/08/19 -
The problem was confirmed on another installation. And in the same network with Influxdb. The problem arose while the Influxdb container was in a backup state.
I learned how to restart Influxdb from Node Red. But I would like to return to the previous normal work of Influxdb.
It is strange that no one confirms this problem.
I took a closer look at the logs. These messages are repeated in openhab before each end of database writes.
2023-08-18 15:11:51.927 [WARN ] [rite.events.WriteRetriableErrorEvent] - The retriable error occurred during writing of data. Reason: ‘timeout’. Retry in: 5s.
2023-08-18 15:11:57.006 [WARN ] [rite.events.WriteRetriableErrorEvent] - The retriable error occurred during writing of data. Reason: ‘Network is unreachable’. Retry in: 25s.
2023-08-18 15:12:23.034 [WARN ] [rite.events.WriteRetriableErrorEvent] - The retriable error occurred during writing of data. Reason: ‘Network is unreachable’. Retry in: 125s.
Hi all, I’d like to report a strange issue related to startup after I upgraded to OH 4.0.1. There is something strange with loading of .thing and .rule configuration files, what I noticed:
After restart, OpenHAB sometimes doesn’t load all .thing configurations. When it’s running I can edit the missing configuration and it would then load the file without issue
Also randomly after restart, it cannot find the JavaScript transformation. I have some JS transformation to divide temperature readings by 10 from ModBus. It first reads without transformation, but after a short while it finds the transformation and load correct value. In time series history I see a big spike with value 10x of the correct reading
I suspect both of the issues are related and I haven’t experienced similar problem with OH 2-3.4.4. Now I’m on 4.0.2 and still experience the problem so hence I’d like to ask for some help here.
2 is an indication that the JS Scripting add-on is taking too long to come online during startup. So the Things come online and start reporting values before the JS Scripting add-on is loaded and able to transform the values. This was reported on another thread but no fix is near.
A short term work around would be to use the modbus gainOffset profile which, since it’s part of the Modbus binding, should be available before the Thing starts reporting values everytime.
Indeed. (I am the one who reported it). I am not sure if this applies to the OP’s case, but in my own case at startup there are 20…30 errors due to JS not (yet) being loaded; but once JS is finally loaded the errors go away, and everything runs smoothly. So in my case it is not a show stopper; but it would be nice if the OH bundle start sequence could be improved so that JS loads earlier than things that depend on it…
Same here, however I connect the item to HomeKit and that flipping of state cause some issue there, also the history but otherwise once loaded it started to work perfectly. I will try the workaround as @rlkoshak suggested (I didn’t like JS transformation anyways)
I didn’t know this existed and I would give a try (it handles all my number transformations), I use MAP for the rest transformation. Never liked JS transformation anyways.
EDIT: I spent a few hour tonight try to get it to work without luck - it seems to work fine with reading, however writing generates some strange numbers and looks like some compatibility issue with HomeKit add-on.
Will stick to JS for now.
OH 4.0 realy drives me crazy. So far, every update starting from 3.x via the repository caused that my smart home was not working. So far, I could always fix that with a fresh installation (sudo apt-get remove --purge openhab && sudo apt clean &&sudo apt-get install openhab).
However, when migrating to OH 4.0.3 causes an issue that still remains after fresh new installation: The error message I get every min is:
[ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/vnd.openhab.dsl.rule' could not be found for identifier
I am confused here, as this engine should be build in, right? System is a Raspberry Pi 4, 8GB, Raspbian GNU/Linux 10 (buster), with many things and hundreds of items.
I am quite sure that this is not a generic issue, as the forum should be full of discussions around that. However, I am missing the staring point for identifying the root cause. So, happy for ideas… Thanks!
Unfortunately, this is only included in the OS requirement for openHABian
We expect you to use the current stable distribution bullseye for Debian (x86). The current Raspberry Pi image is based on this, too.
If you read further, older versions might work, but are not guaranteed.
There have been some issues reported where users manually got Java 17 running on buster, which could be solved by upgrading to bullseye.
Please be aware, that purging openhab is maybe not sufficient, you’ll also have to uninstall and reinstall openhab-addons, as this packet is essential for openHAB to work.
In fact, openhab should also install this packet, but I’m not sure about side effects if purging and reinstalling openhab when openhab-addons is still installed.
Just to clarify a little, bullseye is sort of necessary because most (but not all) of the JDK17 distros require a version of a library newer than is supported on older Raspberry Pi OS. So you don’t really need bullseye if you find a JDK17 that runs there.
