I’m fiddling around with trying to duplicate my python UDP listener via the WS interface, mainly as a learning exercise, and had some questions…
I see a development/personal-use key we can use that “has some limitations in terms of frequency of requests and volume of data” that are undocumented. What might those limits be ? When does a personal-use only app need to contact WF for a unique key ?
the WS API is very inconsistent with the approach of the UDP API.
for UDP, we listen once to udp/50222 and hear everything
for WS you seem to need to connect, then send listen_start for each physical sensor, and the Sky requires at least two listen_whatever messages to subscribe to observations plus rapid_wind and perhaps station up/down events… so for my station with two Sky units, I’d need to send:
an initial connect to the endpoint
a listen_start for the air
a listen_start for sky1
a listen_start for sky2
a listen_rapid_wind for sky1
a listen_rapid_wind for sky2
a listen_start_events for the station as a whole
I can’t find any hub_status messages in the API
I can’t find any device_status messages in the API
The bottom of the WS API page has a couple confusing notes in it:
“A client should only open one websocket connection.” - is one connect and multiple ‘start’ messages one connection or many (guessing it has to be one)
“A client will be disconnected after 10 minutes of idle time.” - does this mean if I simply listen on the opened Websocket I’m considered idle and the connection will be terminated ?
Lastly - I left my WS listener python program listening for many minutes, far above 10 minutes, so how does WF detect ‘idle’ ? Is there something in WS that acts as a keep alive or the like under the hood ?
Not understanding the answer or the effect in real life. One seems incorrect.
I started listening 12 hours ago, and the websocket is still open and working. Network monitor on the MacBook says 7 packets sent (same as 12 hours ago), about 31k received (constantly incrementing, as is the display to my console window of the received response messages).
If you want to see the hopefully obvious python code, it’s on GitHub
Yes, that was my expectation…but that’s not what the WF server is doing. It left the socket open for over 12 hours with me just listening. So I thought I’d ask if my reading was correct (apparently it is).
And yes, I mentioned I was doing this as a learning exercise, so no I haven’t done WS before, although I’ve been doing tcp/ip networking for well over 30 years now. Hence my confusion. I thought I’d need to periodically send something to keep the connection active as the server-side sees it, but that’s not apparently the case.
Perhaps they ‘said’ 1 hour but have not implemented any cutoff on their end. I dunno.
Perhaps that’s what’s going on here. There ‘are’ events to send, many per minute (rapid wind) and many per 10 minutes (observations), so there is data moving all the time.
@GaryFunk is correct… IF all you do is connect to the WF WS, and do NOT request any data stream (obs_air, obs_sky, rapide_wind, etc… ) the WF server will close the socket after the timeout.
Since you have requested data, the server will not close the connection… that’s one feature of using WS connections…
ok, that makes more sense to me. If you open a connection and do nothing else, it’ll close it on you since you didn’t ask for anything.
If you ‘did’ ask for data and your Internet dropped offline for a couple hours, presumably they’d close it as well since there’s nobody on the receiving end of the connection (???)
Correct-ish.
If your internet dropped off for any length of time, the WS connection would be severed.
Kinda the way that if you were on a land-line phone call, and someone cut the cord… the point to point connection no longer exists, so the communication path is gone.
?