[InnogySmartHome] [SOLVED] Bridge-Thing is not going ONLINE on OpenHAB 3.1.M4

[RalphSester]

On OpenHAB 3.1 M4 the bridge-thing of the innogySmartHome-Binding does not come ONLINE. While opening the websocket is occuring an error. the same binding is working well on OH 3.1.M3 There were no changes in the binding. perhaps there are changes in the jetty-behaviour of OpenHAB

Expected Behavior

If you start with a clean OH installation, activate the innogysmarthome-binding and create the bridge-thing, then the thing should go ONLINE.

Current Behavior

The bridge-thing goes OFFLINE with the following error in the log:

Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 404 Site Not Found

Possible Solution

Perhaps, there has something changed with the websocket-handling of jetty or some trouble with the certificate-tree.

Steps to Reproduce (for Bugs)

1. Expand the OH 3.1.M4
2. Run OH
3. Process the first run setup
4. Install InnogySmartHome-Binding
5. Create a new thing on this binding, with correct AuthCode from Innogy
6. See the log - you will get the Error.

Context

The destination server of innogy is running well. on OpenHAB 3.1.M3 there is no problem. See my attached log - snipped. TraceLog.txt

Your Environment

OpenHAB 3.1.M4 running on Windows Server 2016 with ZULU But the error is occuring too on RASPI

[RalphSester]

@wborn : Do you have some idea ?

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-1-milestone-discussion/116025/129

[wborn]

It would be interesting to know if other add-ons using the Jetty websocket client have similar issues. I don't use any myself, but I see deconz and kodi also use the Jetty websocket client. Do you see something similar with those add-ons @cweitkamp?

[cweitkamp]

At the moment I am not using Kodi myself. For deCONZ I do not see any issues. It is working for me.

[RalphSester]

@Hilbrand Do you have any idea about this behaviour?

[RalphSester]

@Novanic Nobody has an idea....you are the last stand ;-)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/innogy-binding-3-1-0-m4-and-snapshot-is-not-working/122188/2

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-1-milestone-discussion/116025/161

[wborn]

@RalphSester in community topic:

we have contacted LIVISI and the deverlopers reported us, that the websocket-request coming from OH is missing some protocol and header standards…the websocket is handled by jetty and jetty is openhab core…

so what we can do?

I don't know what is exactly missing. But perhaps the binding can customize the Jetty behaviour e.g. by using one of the other connect methods that use the ClientUpgradeRequest and UpgradeListener parameters.

Currently InnogyWebSocket uses:

org.eclipse.jetty.websocket.client.WebSocketClient.connect(Object, URI)

But there's also:

org.eclipse.jetty.websocket.client.WebSocketClient.connect(Object, URI, ClientUpgradeRequest) org.eclipse.jetty.websocket.client.WebSocketClient.connect(Object, URI, ClientUpgradeRequest, UpgradeListener)

If that doesn't help, since openHAB uses OSGi, it is also possible to add the older Jetty Websocket version as dependency to the binding and use that as workaround.

[RalphSester]

@wborn Thank you.

See the statement of the Innogy Developers :

We have just analyzed the log files and we can see one 404 WS response in the firewall but the details of the response are not clear yet so we need to do some further investigations.

The issue could be caused either by some TLS handshake problem or due to the client call type. All WS calls handled properly by the firewall are regular WSS requests: GET WSS api.services-smarthome.de HTTP/1.1 101 34122 1135 0

The difference in the 404 request is that we don't see a regular WSS request but a TLS1.2: GET TLSv1.2 api.services-smarthome.de HTTP/1.1 404 2939 1137 0

and

I would suggest to check the differences in the 2 versions for this specific request (protocol, headers, etc.). We suspect that either the call is not a WS upgrade request or some headers are missing since we see that TLSv1.2 request (plain GET request, not WS upgrade).

As a hint, the wss protocol should be used for the call with the following headers (WS standard): Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Extensions: ..., Sec-WebSocket-Key: ..., Sec-WebSocket-Version: ...

so why the jetty takes "Tlsv1.2" instead of "wss:" in the header?

[profigriller]

Problem still exist in 3.1.0-M5

[RalphSester]

Hi there, the problem was fixed now by LIVISI. It was necessary to make a change on the backend-systems to handle wss-calls with explicit port definitions. since OpenHAB M4 the underlaying jetty-library is specifying the port 443 in the URI....before only 'wss' was specified - without port. This was not handled correctly by the backend.

thanks livisi for fixing this and keep the binding back to life !!!

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/innogy-binding-3-1-0-m4-and-snapshot-is-not-working/122188/8

[wborn]

That's good news! 🥳