WebSocket API not returning data on listen_start request

Hi all -

I just bought a Tempest weather station a few days ago, primarily because of the API which looked friendly and easy to use.

The WebSocket API does not seem to work. If I send the message for listen_start_events, I get an ack and receive event info for my station. If I use listen_start, I receive no ack from weatherflow API and no data ever flows to me. The REST API always returns data to every request as expected.

Is anyone having a similar experience with issues with the websocket API or just me?

Hi Josh,

It took me a bit to notice but listen_start and listen_rapid_start both want the device ID while listen_start_events wants a station id. I’d be curious to see the response you’re getting from listen_start_events as I get something like this…


For the other two commands I get an actual ack that looks like…


I’d be super curious if that’s what you see or if you get an ack in the message for listen_start_events as I’ve got an open ticket open about never getting device offline/offline events. Otherwise though I have good luck with listen_rapid_start and listen_start sending me rapid wind and observations.

Hope that helps!


I see something very similar when using listen_start_events. I guess I was just a little giddy that something was actually coming across. I didn’t even realize it was the wrong thing.

Whenever I try to request with listen_start, the connection is established, but I never receive an ack message or any data. The connection just closes after the expected ten minutes.


Is the station id supposed to be the exact same as the device id that is passed in?

It would appear that the station_id and device_id are two different values. That resolved my issue. Sorry for the incompetence on my part.

I do wish it would have been made more clear that the two values are different. The types of values seem very similar in the example requests and the device id was hidden deep in the settings.

Think of Station ID as the ID of the hub and the Device ID as the ID of the Device attached to the hub. Only the hub has a connection to the internet so it makes sense that its ID is the Station ID.


Not incompetent at all. At least I hope not because I made the exact same mistake to start with!

Happy coding Josh


Suggestion for Weatherflow:

  • Update the APIs so all calls that take Station IDs would accept either the plain station ID number, or that same value with a preceding “S”
  • Update the APIs so all calls that take Device IDs would accept either the plain device ID number, or that same value with a preceding “D”
  • Update the documentation to always show the S and D prefixed values
  • Update the customer UIs (web & app) to always include the prefixes when showing station and device ID values.

I got what I wanted out of it. I just wrote a quick script in Node.js to get the data from the socket and write it to a SQLite db. If anyone is interested in it, here it is: tempestwx-adapter-node/index.js at main · JoshieB/tempestwx-adapter-node · GitHub