Actually after reading some more it seems that it should not necessary to manually set keepalive when using http2. So I removed this for now and will see how it goes…
1 Like
Setting keep alive should only be necessary when http2 is not available (i.e. plain http).
2 Likes
@jimtng I have not raised a PR before.
@wborn - is backing out your last groovy script change an option for this GA release? It’s been 2 months since I’ve been able to run my groovy scripts. I’m sure there are others in the same predicament.
I will have another look this weekend.
Thank-you. It would be great if this could make the next release.
Will the karaf version 4.4.6 be included in 4.3?
Asking to know if ECDSA ssh keys will be supported.
OH 4.3 will be provided with Karaf 4.4.6. Karaf 4.4.7 is not yet released.
Isn’t OH 4.2.x already with Karaf 4.4.6 ? I do not remember.
I’m using openhab 4.2 and ecdsa does not work
I’m not sure which karaf is with 4.2
Log into karaf and type
openhab> system:version
4.4.6
(this is from 4.3.0.M4)
Thanks.
I have 4.4.6, yet ecdsa-sha2-nistp256 keys are not working for auth.
rsa keys work fine.
Hi @randye007 and @MikeJMajor!
I made this small fix for this annoying 
:
3 Likes
Hi everyone,
I update my Integration Instance from openhab 4.2.3 to 4.3.0 M5.
As a first finding, subdevices from TR064 Binding don’t get ONLINE:
Restarting Bundle doesn’t help.
I had to recreate the Subdevices and relink the items. Now the Things are ONLINE again
After Restarting Openhab the “Configuration Serial” Binding is “always” in status Resolved.
I can restart the Bundle manually, but the Binding status is Resolved after next restart again:
Anyone an idea?
Had a smooth update coming from M4.
With M5 groovy scripts are also back online.
Thanks to all @wborn
2 Likes
I did have a problem last night updating from M4 to M5 in a docker container on a Rpi5. OH would not start, but the update file looked okay and the Docker PS said it was running, but the memory usage (HTOP) indicated it wasn’t. No logs created and couldn’t access karaf. I reverted to M4 and all was ok. Not a docker expert, but wondered if there was a way to kick-start besides docker compose down and docker compose up, because that didn’t work. Was going to try again when I had more time.
Interestingly had no problem with the M4 to M5 on my OH test system with docker on a rpi4, so could be specific to the other system.
I also have problems with M5 running as docker container:
+ IFS='
'
++ find /usr/lib/jvm -maxdepth 1 -name '*jdk*' -type d
Configuring Java unlimited strength cryptography policy...
+ export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
+ JAVA_HOME=/usr/lib/jvm/java-17-openjdk
+ '[' unlimited = unlimited ']'
+ echo 'Configuring Java unlimited strength cryptography policy...'
+ sed -i 's/^crypto.policy=limited/crypto.policy=unlimited/' /usr/lib/jvm/java-17-openjdk/conf/security/java.security
+ capsh --print
+ grep -E Current:.+,cap_net_admin,cap_net_raw,.+
+ rm -f '/var/lock/LCK..*'
+ rm -f /openhab/userdata/tmp/instances/instance.properties
+ NEW_USER_ID=9001
+ NEW_GROUP_ID=9001
+ echo 'Starting with openhab user id: 9001 and group id: 9001'
Starting with openhab user id: 9001 and group id: 9001
+ id -u openhab
++ getent group 9001
+ '[' -z '' ']'
+ echo 'Create group openhab with id 9001'
Create group openhab with id 9001
+ groupadd -g 9001 openhab
Create user openhab with id 9001
+ echo 'Create user openhab with id 9001'
+ adduser -u 9001 -D -g '' -h /openhab -G openhab openhab
+ groupadd -g 29 audio2
+ groupadd -g 32 uucp2
+ groupadd -g 63 audio3
+ groupadd -g 490 dialout2
+ groupadd -g 492 audio4
+ groupadd -g 997 gpio
+ adduser openhab audio
+ adduser openhab audio2
+ adduser openhab audio3
+ adduser openhab audio4
+ adduser openhab dialout
+ adduser openhab dialout2
+ adduser openhab gpio
+ adduser openhab uucp
+ adduser openhab uucp2
+ chown root:uucp /var/lock
**chown: /var/lock: No such file or directory**
stream closed EOF for openhab/openhab-57cc576576-ksm8t (openhab)
Running openhab on a RP4 inside a Kubernetes Cluster.
Some more details: It works with 4.3.0.M5-debian but not with 4.3.0.M5-alpine
Weird as there does not seem to be a specific tr064 related PR. Anything noticeable in the logs?
No nothing. After Recreating the subdevices, everything fine now—
I don’t know if this is a regression or a bug that has always been present. (I suspect it may be a regression though).
1 Like