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.
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.
@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.
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.
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.
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
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.