Send device current status when opening WebSocket

[hobinjk]

There's a minor issue using the WS API to look at property values. The gist of it is that the WS API doesn't expose the initial value of a property in any way. Only when the client receives a propertyStatus does it know the value. I usually work around around this by issuing a GET in parallel to opening the WS but this is prone to a race where between the GET finishing and the WS opening the property changes.

I think the best way to fix this is by adding an optional initial: true key to the propertyStatus message and send these initial messages on client connection. This could also be represented as an initialPropertyStatus or propertyStatusInitial message type.

We could also add a getPropertyStatus message but I view that as a bit clunky since then there would be no way to distinguish the propertyStatus sent back by the request from a real propertyStatus.

[benfrancis]

Good point. I agree adding a getPropertyStatus message is clunky, the WebSocket API doesn't need to use a request-response pattern.

What if an implementation just sent a propertyStatus message, with the values of all properties, when the socket is first opened? Given the message is called propertyStatus rather than propertyChange, I don't see anything semantically wrong with that.

[hobinjk]

I think that change in behavior would work well

[draggett]

Automatically sending the current state when the web socket connection is indeed a simple solution, and helps with recovery when re-establishing a connection that closed unexpectedly, e.g. due to a loss of signal.

[benfrancis]

Note that the WebThings Gateway implementation now pushes the values of all properties to the client when a WebSocket is first opened.

@mrstegeman Does it send a separate propertyStatus message for each property?

[mrstegeman]

Yes, that’s exactly what it does.