EventStream / WebSocket closes immediately after connect to Hue bridge

[gopher.ny]

@rfg81

So the interface is closed because of that error?

I don't believe so, that would affect message parsing but not connectivity.

@rfg81

Do you think this change is going to make it for the next update?

Yes, although I don't know when exactly that update will be.

[rfg81]

Hi @gopher.ny ,

I was doing a little bit of digging yesterday to find why the stream was being closed. I tried to use curl to get more debug information and I found out that there is an event being sent every 55 seconds (per documentation https://api-docs.home-connect.com/events?#availability-matrix) and using curl I could really see that. That's what I get every 55 seconds:

event:KEEP-ALIVE
data:
id:BOSCH-SHEM78WH5N-68A50E0EE80B

This event is never passed to the parse(String message) method in hubitat. So maybe this is related to the error I reported and that makes the stream to be closed when using hubitat after around 1 minute. In curl the connection is kept open and I receive events when turning on/off my dishwasher even after 1 minute. In hubitat I can see the events of turning on/off just inside the 1 minute window but never the KEEP-ALIVE event.

Hope this information is useful for you to be able to see why the stream is being closed in hubitat. Please let me know if you need any other info.

[armand]

Are you implementing the void eventStreamStatus(String message) method to parse event message? I do not know, but I suspect it may appear here. I do not receive those types of messages on the Hue event-stream.

[rfg81]

@armand

eventStreamStatus

Yes, I just receive START, STOP and ERROR using the eventStreamStatus method:

START: EventStream Started
ERROR: Unexpected length of data line.
ERROR: Exception during EventStream Request: java.lang.Exception: Unexpected length of data line.
STOP: EventStream Stopped

[armand]

I wonder if the event stream handler is an incomplete implementation of the event stream API standard. I wonder if the empty data throws off the handler, or maybe the event message…

I found a great review of the SSE protocol here

Stream Updates with Server-Sent Events - HTML5 Rocks

Looks like I didn’t realize a double \n ends the message, so now I have a good way of grouping all elements of a message into a single message packet. It would be nice if the interface we are provided sent a message of type Map to the parse method, so we could parse it easily….
[id: ……., event: ….., data: ……

I will use atomic state to buffer each line into a message packet, and when I receive an empty line, I will commit the packet. I will also implement the multi-data line option so if multiple data lines are provided, they are all merged into a single data line as per the standard.

This will help me out with some issues I came across in the protocol. But nothing we do in our code can resolve the implementation issues we are having with the current interface. I trust the upcoming update will improve current message handling.

[rfg81]

Hi @gopher.ny,

I got another error that I believe is worth mentioning. If I use the parameter "rawData: true" I get this message in the method "parse(String message)" as expected:

data:{"items":[{"name":"Operation state","timestamp":1636664226,"handling":"none","uri":"/api/homeappliances/BOSCH-SHEM78WH5N-68A40E0EE70B/status/BSH.Common.Status.OperationState","key":"BSH.Common.Status.OperationState","displayvalue":"Ready","value":"BSH.Common.EnumType.OperationState.Ready","level":"hint"}],"haId":"BOSCH-SHEM78WH5N-68A40E1EE71B"}

If I don't use the parameter there is a typo at the beginning of the message. There is a missing brace "{" for the correct json syntaxy. Could you please take a look at it?

"items":[{"name":"Operation state","timestamp":1636664226,"handling":"none","uri":"/api/homeappliances/BOSCH-SHEM78WH5N-68A40E0EE70B/status/BSH.Common.Status.OperationState","key":"BSH.Common.Status.OperationState","displayvalue":"Ready","value":"BSH.Common.EnumType.OperationState.Ready","level":"hint"}],"haId":"BOSCH-SHEM78WH5N-68A40E1EE71B"}

Thanks!

[gopher.ny]

@rfg81

If I don't use the parameter there is a typo at the beginning of the message. There is a missing brace "{" for the correct json syntaxy. Could you please take a look at it?

The fix will be in the next beta iteration and follow into the next release. If your hub isn't in beta yet, please PM its id to me, and I'll add it.

[armand]

@gopher.ny

The fix will be in the next beta iteration and follow into the next release. If your hub isn't in beta yet, please PM its id to me, and I'll add it.

Can I request another update for the beta fix?

Part of the standard for the event-stream protocol is that all messages received from the stream are linked together as a single message until an empty line is received. If we have the event-stream in raw mode, can you please send us the empty line message too?

This is implemented by the \n\n (double EOL) at the end of the last message in the event stream.

In this way, when we receive the empty line of text, we will be able to know when the message is complete. Note that a single event on the event-stream may consists to more than one data message.

[gopher.ny]

@armand

Part of the standard for the event-stream protocol is that all messages received from the stream are linked together as a single message.

Multiline data: handling will be in the next beta iteration. Driver will get a \n delimited string put together from the consecutive data: lines.

[armand]

That works too. Thanks!