openHAB 4.2 Milestone discussion

laursen · July 5, 2024, 7:03pm

I have to admit that I only upgraded my (Linux) production system this evening. I’ve been running 4.2 snapshot versions on my (Windows) development system since the beginning, but never saw this exception before.

Tuny · July 5, 2024, 8:05pm

I see.
After updating to RC1 still the same, because I have a directory in the openhab conf directory.

seb@odroidc4:/etc/openhab$ ll -la | grep _infdb
drwxrwxr-x   3 openhab    openhab   4096 Jun 30 18:34 _infdb/
seb@odroidc4:/etc/openhab$

J-N-K · July 5, 2024, 8:14pm

What user is running openhab?

Tuny · July 5, 2024, 8:21pm

Should be “openhab”:
grafik

milo · July 6, 2024, 7:25am

Seeing this now on startup

[WARN ] [service.spi.util.WebContainerManager] - Can't get a WebContainer service from {org.osgi.service.http.HttpService, org.ops4j.pax.web.service.WebContainer}={org.ops4j.pax.web.log.ncsa.extended=true, org.ops4j.pax.web.ssl.keystore.password=********, service.scope=bundle, org.ops4j.pax.web.ssl.key.password=********, org.ops4j.pax.web.session.cookie.name=JSESSIONID, org.osgi.service.http.connector.name=default, org.ops4j.pax.web.enc.iterationcount=1000, org.ops4j.pax.web.log.ncsa.file=yyyy_mm_dd.request.log, org.ops4j.pax.web.server.eventDispatcherThreadCount=1, org.osgi.service.http.checkForwardedHeaders=false, org.ops4j.pax.web.enc.suffix=), org.ops4j.pax.web.digestAuth.maxNonceAge=60000, org.ops4j.pax.web.ssl.ciphersuites.included=, org.ops4j.pax.web.session.url=jsessionid, org.ops4j.pax.web.formAuth.errorRedirect=false, org.ops4j.pax.web.ssl.ciphersuites.excluded=^.*_(MD5|SHA|SHA1)$,^TLS_RSA_.*$,^SSL_.*$,^.*_NULL_.*$,^.*_anon_.*, org.ops4j.pax.web.enc.prefix=ENC(, org.ops4j.pax.web.server.maxThreads=50, org.ops4j.pax.web.validatePeerCerts=false, service.id=163, org.ops4j.pax.web.session.cookie.maxAge=-1, org.ops4j.pax.web.ssl.truststore.password=********, org.ops4j.pax.web.ssl.session.cacheSize=-1, org.ops4j.pax.web.ssl.truststore.type=JKS, org.ops4j.pax.web.ssl.keystore.type=JKS, org.ops4j.pax.web.ssl.session.enabled=true, org.ops4j.pax.web.ssl.protocol=TLSv1.3, org.osgi.service.http.port=8080, org.ops4j.pax.web.log.ncsa.file.date.format=yyyy-MM-dd, org.ops4j.pax.web.ssl.renegotiationLimit=-1, org.osgi.service.http.secure.enabled=true, org.osgi.service.http.enabled=true, org.ops4j.pax.web.server.idleTimeout=300000, org.ops4j.pax.web.log.ncsa.retaindays=90, org.ops4j.pax.web.log.ncsa.logtimezone=GMT, org.ops4j.pax.web.enc.algorithm=PBEWithHmacSHA256AndAES_128, org.ops4j.pax.web.validateCerts=false, org.ops4j.pax.web.config.files=/usr/share/openhab/runtime/etc/jetty.xml, org.ops4j.pax.web.ssl.renegotiationAllowed=true, org.ops4j.pax.web.digestAuth.maxNonceCount=1024, org.ops4j.pax.web.enableOCSP=false, org.ops4j.pax.web.ssl.clientauth.needed=false, org.ops4j.pax.web.enc.enabled=false, org.osgi.service.http.port.secure=8443, javax.servlet.context.tempdir=/var/lib/openhab/tmp, org.ops4j.pax.web.enableCRLDP=false, org.ops4j.pax.web.server.connector.idleTimeout=30000, org.ops4j.pax.web.session.timeout=10, org.ops4j.pax.web.ssl.clientauth.wanted=false, org.ops4j.pax.web.ssl.protocols.excluded=SSL,SSLv2,SSLv2Hello,SSLv3, service.bundleid=232, org.ops4j.pax.web.server.minThreads=2, org.ops4j.pax.web.session.cookie.secure=false, org.ops4j.pax.web.enc.masterpassword=********, org.ops4j.pax.web.log.ncsa.append=true, org.osgi.service.http.secure.connector.name=secureDefault, org.ops4j.pax.web.ssl.session.timeout=-1, org.ops4j.pax.web.listening.addresses=0.0.0.0, org.ops4j.pax.web.log.ncsa.buffered=true, org.ops4j.pax.web.session.cookie.sameSite=unset, org.ops4j.pax.web.log.ncsa.enabled=false, org.ops4j.pax.web.ssl.protocols.included=, org.ops4j.pax.web.session.cookie.httpOnly=true, org.ops4j.pax.web.server.showStacks=false}

After a reboot it’s gone

milo · July 6, 2024, 7:36am

Don’t see it anymore @Lolodomo

berni · July 6, 2024, 8:51am

Updated to 4.2.0.RC1 yesterday, and the Shelly binding seems to be pretty broken now and unusable.

For all ~~non-battery~~ Shelly devices (Updated: My battery devices are handled by MQTT), the Shelly binding reports errors like

COMMUNICATION_ERROR “Verbindung zu Gerät fehlgeschlagenh: API Timeout for”
COMMUNICATION_ERROR Verbindung zu Gerät fehlgeschlagenh: java.lang.IllegalArgumentException: Unsupported Auth type/algorithm requested by device(class java.lang.IllegalArgumentException)

The binding also seems to DoS my shelly devices, some became unresponsive last nighty

Lolodomo · July 6, 2024, 10:29am

What was your previous version ? I do not see recent merges for Shelly.

milo · July 6, 2024, 10:47am

this issue is still there

berni · July 6, 2024, 11:10am

Before I had the last stable version of Openhab 4.1.x. I didn’t try any other Milestone version before. So maybe the problem has been introduced with [shelly] Various small fixes for BLU HT, Range Extender, Plus 10V, TRV set temp by markus7017 · Pull Request #16746 · openhab/openhab-addons · GitHub with 4.2.0.M4? All I can say is that with 4.1.x all my 15 shelly devices were working and now ~~80%~~ all are broken.

Lolodomo · July 6, 2024, 11:17am

Pinging @markus7017 for the Shelly problems.

milo · July 6, 2024, 11:23am

Hello,
I see now also this warning

Failed to use TransformationStep{serviceName='JS', function='| (parseFloat(input) > 0) ? input : 0'}, service not found

laursen · July 6, 2024, 11:36am

All these PR’s were merged since 4.1:
https://github.com/openhab/openhab-addons/pulls?q=is%3Apr+in%3Atitle+shelly+milestone%3A4.2+is%3Aclosed+-label%3Adocumentation%2Cpatch

When @markus7017 is available, he will probably need debug or trace logs. Can you provide those?

log:set trace org.openhab.binding.shelly

Lolodomo · July 6, 2024, 11:46am

I guess you just have a wrong channel link somewhere that you have to fix. Nothing that we can fix in the software. You can also try the new health checks feature available in Main UI.

milo · July 6, 2024, 11:53am

If you change the items file…the old link is still there and not deleted only after cleaning the cache its deleted…the non existing item is also listes in the health check…

Is it clear now @Lolodomo

berni · July 6, 2024, 12:41pm

sudo apt install openhab=4.2.0~M2-1 openhab-addons=4.2.0~M2-1

Shelly binding works in M2, all things are online.

sudo apt install openhab=4.2.0~M3-1 openhab-addons=4.2.0~M3-1

Shelly binding is broken after update to M3. Knowing that, it must be some change in M3. So either 16625 or 16744.

I will now update to RC1 again, and try to come up with some debug log.

hmerk · July 6, 2024, 12:54pm

No, I am running M3 on two different locations with >50 Shelly devices, mains and battery powered. Don‘t see any problems.

berni · July 6, 2024, 1:07pm

Shelly trace logs, filtered for shelly device shelly25-relay-98f4acf2a04c to reduce logs.
Device ID and IP addresses are obfuscated.

shelly-4.2.0.m3-trace.log (5.4 KB)

The thing is defined like this:

Thing shelly:shelly25-relay:98f4acf2a04c "Wohnzimmer - Lampe" @ "Wohnzimmer" [deviceIp="192.168.5.221"]

Username and password are defined in the global binding config and are correct.

This shelly device is a SHSW-25 / Shelly 2.5 with the latest firmware 20230913-112234/v1.14.0-gcb84623

J-N-K · July 6, 2024, 1:20pm

I really wonder what is happening there. I have installed RC1 on a brand new Ubuntu VM and I’m not able to get an AccessDeniedException.

J-N-K · July 6, 2024, 1:38pm

After chmod a-r I finally managed reproduce it. So it sure is a rights issue. I have prepared a fix which will log

15:36:46.003 [WARN ] [yaml.internal.YamlModelRepositoryImpl] - Failed to process /etc/openhab/.git: AccessDeniedException

instead of the stacktrace.