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.
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:
I encountered two issues with OH4.0.1:
Regrettably, my main focus was on the second issue, to observe the impact of various changes. Here’s what I did:
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 
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:
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.
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.