I’ve stumbled upon an interesting issue concerning the reception of obs_st messages over the WebSocket API.
If one opens a second concurrent connection and issues listen_start for the same device ID, that connection will reply with an ack along with an initial obs_st message ("source":"cache"), but no further messages. Meanwhile, the first connection will receive all of the messages.
Disconnecting the first connection does not seem to unblock the second one.
In contrast, rapid_wind messages (from listen_rapid_start) appear to be broadcast to all connections.
Is this behavior expected? If so, it would be nice if the API would expose the error rather than being silent about it.
I’m aware that “A client should only open one websocket connection” (from the API docs) – my use case unfortunately requires two connections for two realtime displays in independent locations, and I’d prefer not to insert my own MQTT server as a point of failure. I’m hoping that this behavior is an oversight, and that there’s a tiny bit of slack on the “one connection” policy…
Unfortunately this behaviour has been occurring for a while. I don’t think it is to do with the “A client should only open one websocket connection” policy, but rather an issue with the Websocket itself. I am going to loop in @corrineb who might be able to shed more light
I’m interested to find this. After having used UDP for a while, I decided last friday to dive into the websockets and observed the exact same behavior. Rapid Wind comes in every 3 seconds. Obs_st only comes in once and then never again. Figured I’d come back to it later only to find this. Guess it’s not just me.
Thanks for the reports @tris and @mabeatty1978 and for the tag @peter. @mabeatty1978 I will have the team test things using your account info and let you know what we find. @tris I looked up your account info, but it doesn’t look like you have devices attached to your account. Feel free to dm me the email address of the account you are working with and I can take a closer look.
Thanks for looking into this. The behaviour @tris describes has been a bit of a persistent issue for a while. I had to implement a connection watchdog in the PiConsole to reset the Websocket if this condition occurred, or else users kept reporting that the display was offline and not receiving new observations (except rapid_wind). I can reliably recreate the issue by opening two Websocket connections on two separate clients using the same internet connection