WeatherFlow UDP listener and MQTT/InfluxDB publisher utility

Developers Third-Party Integrations
,
1

DEPRECATED TOOL

AS OF 2023-0127 PLEASE SEE (HERE) FOR THE CURRENT TOOL

Important Support Information

*As of 9/1/2020, I no longer have any WeatherFlow gear but will try to support dealing with bugs (me?) or change requests via my UDP Simulator utility to the extent simulating the Hub can permit.

While 98% of the support requests are simple enough that I can likely respond, at this point I’m not thinking that I’ll be adding more functionality in the forseeable future. I will leave any Pull Requests up on the GitHub site for folks to merge themselves if so inclined

I will ‘try’ to keep the listener up to date vs. the published UDP API on a best-effort basis, but be aware that I also plan to ‘have a life’ so your mileage might vary from time to time…but it ‘does’ work at this point in time and is expected to continue to work for the forseeable future.

Changelogs

Version 4.2.0 released - 2020-0718

Merge PR #6 from tkeffer:

  • better handle threading
  • import mqtt and influxdb modules only if required
  • a little minor refactoring under the hood

Version 4.1.0 released - 2020-0513

Support for Tempest per WeatherFlow UDP reference v119

Added ‘systemd’ directory with files and instructions for installing+running as a systemd service. Some light editing by the user is required to set your personal command-line arguments in the /etc/default/weatherflow-udp-listener file so the service starts with your desired options.

Standard Blurb follows…

There’s all kinds of good stuff in the UDP broadcasts that you can’t get at via the REST or Websockets APIs, so I’ve been working for a bit cooking up a python program to:

  • report to stdout either the raw JSON it listens or a more human-friendly output of the same
  • optionally publishing to MQTT, potentially supporting multiple Air/Sky devices per hub
  • optionally publishing to InfluxDB as well

Rather than give the long README file here, here’s a pointer to the Github repo if you have interest.

Note: always compare your version to the latest release on the link above

IMPORTANT NOTE ABOUT DATA VIA THE UDP INTERFACE

  • please read the commentary in the README file on GitHub before reporting perceived bugs. Thank you.
7 Likes
2

update - you can now limit the observations to a subset of the types ala --limit "obs_sky obs_air"

current setup:

  • publish WF data to MQTT on a pi3
  • publish VP2 weewx data to MQTT from the Seagate Dockstar (pogoplug) connected to the VP2 console using the weewx MQTT extension
  • subscribe to MQTT with telegraf and save to influxdb on a different pi3 with a SSD drive
  • display the data on a grafana dashboard hosted on the influxdb pi3

14%20PM

The WF and VP2 wind sensors are mounted differently, with the WF at 10.5-ft up and the VP2 at 18-ft elevation above grade, so the VP2 will read noticeably higher for wind. The Air is close enough to the VP2 ISS that I’d expect temperature/humidity to match assuming the VP2 sun shield is equivalent to the one I built for the Air.

1 Like
3

What is in the UDP packets that is not in the websocket packets?

2 Likes
4

Primary benefit is that you can just listen on the wire(less) and not need to have any internet connectivity or uptime of the WF infrastructure to get your data. It’s also far easier to program as you just listen, no setting up the socket etc (lesser benefit).

That said, the websockets and udp do have different capabilities, mostly in the area of reporting device/hub status and firmware revision levels. They also report device_id or serial numbers differently.

Here’s the list from the current websocket API and the v91 udp API…

evt_precip
 - websocket returns device_id, udp returns sky sn, hub sn
 - udp returns timestamp

evt_strike
 - websocket returns device_id, udp returns sky sn, hub sn
 - udp returns timestamp

 evt_device_online
  - (not available in udp)

 evt_device_offline
  - (not available in udp)

evt_station_online
  - (not available in udp)

evt_station_offline
  - (not available in udp)

rapid_wind
  - websocket returns device_id, udp returns sky sn, hub sn

obs_air
  - websocket returns device_id, udp returns air sn, hub sn
  - udp returns firmware_revision

obs_sky
  - websocket returns device_id, udp returns sky sn, hub sn
  - udp returns precipitation type
  - udp returns firmware_revision
  - udp reurns wind sample interval

device_status
  - not available via websockets according to docs
  - udp returns:
      air/sky and hub serial numbers
      timestamp
      uptime
      firmware_revision
      voltage
      rssi
      hub_rssi
      sensor_status
      debug state

hub_status
  - not available via websockets according to the docs
  - udp returns:
      hub serial number
      firmware_revision
      uptime
      rssi
      reset_flags values
      seq (undocumented what this is)
      fs (undocumented what this is)
      radio_stats (reboot count)
      mqtt_stats (seems to be for future)
5

I agree on the benefit. I’m just questioning your original statement as the websocket actually offers more useful data, such as summary.

Whether the packet returns a serial number or device ID is pretty much equal.

By-the-way, the websocket and upd documentation have not been updated to match the current firmware.

2 Likes
6

An API that isn’t documented is basically not worth the paper it’s (not) written on.
We can’t just magically interface with a mystery.

Ignoring the serial number vs. device_id difference (which is silly, pick one way guys…) the lack of device+hub status to me is a big deal…

3 Likes
7

WF emailed me yesterday that the API and docs will soon be updated.

Regards

1 Like
8

I reported issues but the topic was renamed and moved and now no one notices it.

2 Likes
9

Thanks for publishing this. I am only just getting around to setting up my devices now and this looks like a great way for me to integrate this with openhab.

10

I get a few errors when I receive data back from the broadcast.

ERROR: unknown data[‘type’] in {u’uptime’: 5591, u’timestamp’: 1536296369, u’reset_flags’: 234881026, u’rssi’: -21, u’serial_number’: u’HB-00xxxxx’, u’firmware_version’: u’17’, u’type’: u’hub-status’}

ERROR: unknown data[‘type’] in {u’hub_sn’: u’HB-0000xxxx’, u’uptime’: 5013, u’timestamp’: 1536296403, u’sensor_status’: 0, u’version’: 43, u’voltage’: 2.64, u’rssi’: -23, u’serial_number’: u’SK-0000xxxx’, u’type’: u’station_status’}
Traceback (most recent call last):
File “./listen.py”, line 414, in
elif data[“type”] == “obs_sky”: process_obs_sky(data)
File “./listen.py”, line 138, in process_obs_sky
obs_sky[“precipitation_type”] = data[“obs”][0][12] # 0=none, 1=rain, 2=hail
IndexError: list index out of range

11

It looks like the firmware on your Hub needs to be uodated.

@vinceskahan You need to put firmware version code in to check.

2 Likes
12

v91 is the current production version of the firmware, so I’m starting there. No plans to chase old variants that nobody should still have by now if WF has indeed pushed updates everywhere. I’d suggest contacting support to get the old firmware hubs updated to at least v91…or follow the old sysadmin credo of 'when in doubt, comment it out’ if you run older firmware and this throws version-related errors.

FWIW, a quick read of the v94 docs on the web page says there are no changes in the UDP API.

13

I’m not suggesting you do.

Check the firmware version and instead of loading, display a message that the firmware needs upgrading.

1 Like
14

Certainly, but I’d prefer to not go that way at this time, given (a) everybody is supposed to be at v91 by now anyway, and (b) it seems that it’s only the really old versions that would blow up in this particular way.

A quick glance at the API docs tell me that even v35 should work as-is. Given my gear came from the factory 3 weeks ago with v47, I’m calling the as-is good enough for me.

1 Like
15

It’s good enough for me too. However, for my customers, I like to provide them with good service.

2 Likes
16

You know, I wasn’t going to respond equally in public, but I feel the need to do so in this case.
I find that response extremely offensive. Really.

I volunteered my time to publish something that folks can use if they meet a documented minimal rev level of the software. If they want to use it, great. If they don’t, equally fine. While I definitely want to hear bug reports, I reserve the right to decide which ones I spend my limited time dealing with.

3 Likes
17

I am sorry you got offended.

2 Likes
18

Out of interest my manually upgraded hub at version 49 (I expected vs 47) had a different error. Now it has updated to version 91 and I get this error part way through the stream if I use -d switch.
device_status => device_type = sky ts = 1536365625 uptime = 74253 voltage = 2.63 firmware_revision = 43 rssi = -14 hub_rssi = -26
obs_sky => Traceback (most recent call last):
File “./listen.py”, line 414, in
elif data[“type”] == “obs_sky”: process_obs_sky(data)
File “./listen.py”, line 154, in process_obs_sky
print (" timestamp = " + str(obs_sky[“time_epoch”]) , end=’’)
KeyError: ‘time_epoch’

19

I’ll take a look at it. Thanks for the info.

20

No worries thanks for your work on this. I going to see if the mqtt feature will work now. The raw output seemed to work fine for my short test. It may be a system config issue on my end that the error occurs. I haven’t delved into your code at all but I am not a developer as such more of a cut and paste coder to get me a working solution.