Binding not connecting to digitalStrom server due to SSL handshake error: failing to debug

I’d appreciate some helpfull insight into debugging connection problems to my digitalStrom bridge.

The problem:
In “things” the digitalStrom bridge has a “ERROR:COMM” specified (on mouseover) as IOException/Connection lost. When I disable (pause button in UI) and enable the bridge I get a SSL handshake error/Connection lost that goes to the abovementioned IOException after some time.

I’m running OH3M5, openhabian stretch.
openjdk version “11.0.11” 2021-04-20 LTS
OpenJDK Runtime Environment Zulu11.48+21-CA (build 11.0.11+9-LTS)
OpenJDK Client VM Zulu11.48+21-CA (build 11.0.11+9-LTS, mixed mode)

dss20, firmware 1.18.0

I had the binding running after migration from OH2.5 to OH3 (for the first time). I can’t say for sure since when it gave the connection error. DigitalStrom have upgraded the firmware to 1.18.0 in april (digitalSTROM | Support | Softwareupdate).

I’ve set logging to DEBUG in openhab-cli console for the digitalstrom binding alone. This did not give me much insight into the SSL handshake problem. So I tried to DEBUG org.openhab which gives a lot more info, but nothing on SSL problems.

Does anyone know if the changes in de firmware are such that the binding is broken somehow?
What other logging options should I switch on to get more insight into the connection problem?

Several protocols that have been used for Transport Layer Security in the past are outdated/vulnerable. Because of this in recent versions of browsers, libraries, set ups and firmware they might have been deprecated or are deactivated per default.

To for debug options you may have a look at:

For this you need to set the variable EXTRA_JAVA_OPTS to one of the values described in the above article. Then OH needs to be started. There might be a different way to get access to the output but as far as I understand the debug output is written to STDOUT and / or STDERR. This is why you need to startup OH in a terminal window. The output then will be visible in the terminal window.

Thank you Wolfgang for pointing me there. I’ll have to dive a bit further into that, setting log levels in Karaf was easy enough. Would have to look where to apply these java options…
In the meanwhile stopping and starting the DigitalSTROM binding in the Karaf console somehow messed up functioning of openhab (does not refresh the “things” list, “Model” in UI.
So have to restart openhab altogether (systemctl stop openhab and systemctl start openhab) and se what that does.
I’ve encountered problems with the binding before that got solved by upgrading the java package or changing it to a java package from a different provider (there are two flavors in openhabian-config to chose from). Maybe I should try to upgrade my openhabian from stretch to buster as I have been planning.

that shouldn’t hurt and will be a good ‘investment’ for the future. Make sure to have a backup.

I have been hesitant because I cannot exactly remember how I backed up my secondary openhab install (dd via NFS on my home server I think). Don’t want to end up with total reconfiguration if I mess up :grimacing:.

1 Like