I can see mine growing up slowly.
Will see after few days.
Regarding the number of threads used by the java process:
The load of the java process:
It looks like the memory usage first grows up but finally it stabilizes.
So I see no obvious general memory leak in OH4, that is a good news.
2 Likes
I’m starting to plan my upgrade to 4.0 but the section on breaking changes is missing from the documentation. Where can I find this information?
Check the 4.0.0 release notes for more details including breaking changes:
1 Like
I encountered two issues with OH4.0.1:
- 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.
Conclusion: It’s all my fault!
2 Likes
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.
Today I added some addiontion jar file from the community Weather Calculations Binding
now I get this error all the time
2023-08-14 09:20:11.602 [WARN ] [eatherFlowSmartWeatherHandlerFactory] - ? SupportsThingType: tlpicker:tlp? false
Is this the correct behaviour?
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.
1 Like
Doesn’t look like the same issue to me but maybe related to the way how OH reload configuration changes.
I doubt these are related.
I can’t comment on 1.
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.
1 Like
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…
1 Like
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.
There are another thread about this issue: Bug since OH4: Why are the default.sitemap and *.things files not loaded on startup? (empty sitemap list) - #13 by wezzix
I now used the workaround to reload all thing configurations when system starts
1 Like
Hey,
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!
Your system needs to be on bullseye. Also make sure that JDK17 is installed
Hi @Oliver2,
thanks for the quick feedback. JDK17 is clear. Since when is bullseye necessary? Is there a note on that or “a general recommendation”?
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.