openHAB 4.0 Release discussion

I have only tried to start openHAB again.

I did not do a pre-check of the scripts at this time.
Wanted to have the Java problem solved first.

I absolutely did not see the new “get [name] of item” block.
Have now rebuilt the scripts with it. The calculations seem to run again now.

I don’t think that’s a new block. We’ve always been able to use that block to get the name, label, etc of the Item even on OH 3. But support for getting the state as a number or quantity from that block is definitely new in OH 4.

Minor annoyance. Thing Event Status changed selection Bubble does not go away after clicking on choice. You have to click somewhere else to close it.

So far everything is working great.

I have now migrated all 4 of my servers to new 4.0 installs. They are working great. Had to learn the scripting changes in 4.0 but they were much easier to do now. I use a lot of timers and clear timer. My main server was a lot of work since it has a lot of things, items and rules. But all is working great now. Thank you again for all the work you do to make this a great product.

1 Like

Initially, I had a lot of trouble when I first tried to upgrade my OH3.4.4 version to OH4.01, though the root cause for these problems was not related to this release.
After fixing these other issues the version OH4.01 is running and things seem to be overall ok.

The only thing I see right now is that my OH4.0.1 container is constantly consuming more and more memory. During the troubleshooting of this my other issues I have installed Cadvisor monitoring so I do not have any older data relating to my running OH3.4.4 version.

Right now I see this situation:

I still have enough memory, I use RPI with 8GB, although I can do math with 100MB/24h when the memory will all be used up.

For me most trouble was getting the java 17, but I found this page on the raspberry forum how to upgrade buster to bullseye (although officially not recommended). After that the upgrade to openHAB 4.01 was a piece of cake. Just had to install the old javascript engine for the old rules, change some rule code and fix (a lot of) units i the things. But that was all named in de OH 4 F.A.Q.

@lukics I was a bit afraid of the memory too, but after a day it all settled. Maybe (because of the reboot) it’s the raspberry file cache and JVM heap filling. After a day I observe the normale garbage collection saw tooth pattern and memory usage is stable again. Maybe it will happen for you too (hardware = rasperry PI and I configured the JVM heap at 1Gb). Timeline is a week, First 2 days messy because of upgrade, reboots and fixes on broken rules. After the last peak my fixes are complete and it runs normal again. It loses memory for about a day. And then the sawtooth starts and memory free stabalizes.

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.


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:

  1. A gradually increasing memory leak, as I detailed in this thread.
  2. 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!


Hello found a wired behaviour in OH4 and it was not there in OH3 taht’s why I choose this thread :slight_smile:

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?

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 ] [] - The retriable error occurred during writing of data. Reason: ‘timeout’. Retry in: 5s.
2023-08-18 15:11:57.006 [WARN ] [] - The retriable error occurred during writing of data. Reason: ‘Network is unreachable’. Retry in: 25s.
2023-08-18 15:12:23.034 [WARN ] [] - 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:

  1. 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
  2. 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

See also 4.0.1: Cannot delete things that are provisioned from file

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.