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.
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.
1 Like
Hi @rlkoshak, all,
finally figured out the reason for the problem. The general statements made above lead me to the wrong path. The update to bullseye did not make any difference, as I used Java17 here.
Key problem was the ebusd binding that caused the problem.
Never looked into the architecture of openhab so far here, but obviously this binding was able to bring down the complete DSL-rules-engine after some openhab-reboots. Did not expect that this is possible at all.
The problem is now fixed with the 4.0.3.19 version, see here.
The behavior is identical on bullseye and buster. Even if the path was wrong, anyways thanks for the support here!
Hi there,
I am facing some trouble since I updated my OH3.4.4 to 4.0.3. After a while (some hours, or 1 or 2 days) it stops executing some of the rules and e.g. updating the netatmo items. I am using it on a windows machine directly.
I recognized some warnings in the openhab.log file, which did not appear in the former version.
Perhaps someone may help in interpreting those.
After startup while initializing i see those:
2023-10-19 12:10:39.033 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'SI'.
2023-10-19 12:10:39.179 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/rest/items's Observer
2023-10-19 12:10:40.154 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://localhost:8080/rest/events's Observer
2023-10-19 12:10:40.154 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://localhost:8080/rest/events/states's Observer
2023-10-19 12:10:40.154 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://localhost:8080/rest/events's Observer
2023-10-19 12:10:47.646 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'telegram.things'
2023-10-19 12:10:49.564 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/icon/pressure's Observer
2023-10-19 12:10:49.569 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/icon/status's Observer
2023-10-19 12:10:49.586 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/icon/flow's Observer
2023-10-19 12:10:49.586 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/icon/fan's Observer
2023-10-19 12:10:49.601 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.5.20:8080/icon/blinds's Observer
2023-10-19 12:10:50.399 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2023-10-19 12:10:59.044 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'heating.rules'
2023-10-19 12:11:02.427 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-27,name='context:1055085021',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:1055085021',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@3ee351dd}}: C:\OH4\userdata\tmp\ROOT\context:1055085021
2023-10-19 12:11:02.898 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@3930854b[provider=null,keyStore=null,trustStore=null]
2023-10-19 12:11:02.901 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@3930854b[provider=null,keyStore=null,trustStore=null]
2023-10-19 12:11:02.949 [INFO ] [nding.http.internal.HttpThingHandler] - Using the secure client for thing 'http:url:hkv2og'.
Then I get the following from time to time
2023-10-20 05:30:02.144 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-46,name='context:1597035936',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:1597035936',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@5f30d5a0}}: C:\OH4\userdata\tmp\ROOT\context:1597035936
and shortly before some of the rules stop working I see this
2023-10-21 03:13:23.243 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-49,name='context:1869371297',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:1869371297',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@6f6c57a1}}: C:\OH4\userdata\tmp\ROOT\context:1869371297
2023-10-21 03:18:37.701 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-52,name='context:33174517',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:33174517',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@1fa33f5}}: C:\OH4\userdata\tmp\ROOT\context:33174517
2023-10-21 05:18:09.625 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-55,name='context:233973968',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:233973968',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@df228d0}}: C:\OH4\userdata\tmp\ROOT\context:233973968
2023-10-21 05:26:25.823 [WARN ] [ce.jetty.internal.JettyServerWrapper] - Can't create temporary directory for OsgiContextModel{HS,id=OCM-58,name='context:1410483843',path='/',bundle=org.jupnp,context=WebContainerContextWrapper{bundle=org.jupnp_2.7.1.OH1 [239],contextId='context:1410483843',delegate=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@54124683}}: C:\OH4\userdata\tmp\ROOT\context:1410483843
I would appreciate any help
Windows cannot handle the : in the filename. It is fixed in the 4.1.0 milestones and snapshots after upgrading Pax Web with Karaf 4.4.4 see also openhab-core#3425.
Thanks for replying.
So you think this may be the reason for this unstable behaviour?
So your advice is to update to 4.1M2 with a good chance to have a stable system back again?
I don’t know what the impact if the filename warning could be. I only run on Windows for development work, not for production. So I wouldn’t have seen it.
I have some “strange issue” with OH 4.0.3 and the bindings
I have two installations of Openhabian running on two Raspi 3B+.
The one installation is still on openHAB 4.0.2 - Release Build… That one acts absolutely normal.
The other installation is on openHAB 4.0.3 - release build… There I can use all the bindings that where installed, but if I want to install or uninstall a binding or add-on I only see the community bindings and addons…
The official bindings and addons are not seeable and so neither installable, nor uninstallabe…
Does anyone have any idea, what could cause it?
Following steps already taken, without success:
- clearing browser cache
- restarting openhab
- making sure latest stable version 4.0.3 release build is running
- restoring rights and standard settings with openhabian-config tool
- checking free diskspace with DF, result: maximum occupation is 43% on zram1 and persistence mount. everything else is 20% or less occupied.
I updated to the 4.1M2 build two days ago, and those warnings disappeard.
Unfortunately, this morning the strange behaviour occured again. The netatmo items are not updated anymore and some other rules as well do not operate.
I recognized one other warning:
2023-10-27 05:13:39.050 [WARN ] [handler.capability.WeatherCapab27:8d:4a' : java.util.concurrent.ExecutionException: "java.net.ConnectException: Connection timed out: no further information"
After that, no update from the netatmo items was recognized. I checked, that this warning appeard exactly at that time, when my DSL line was offline during the daily reconnection cycle. Maybe something changed that openhab gets a hickup there?