Python code to report (or MQTT publish) WeatherFlow UDP data

mqtt
udp

#1

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
  • and optionally mapping pertinent fields to WeeWX weather software terminology

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


#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

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.


#3

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


#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.


#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…


#7

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

Regards


#8

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


#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.


#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.


#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.


#15

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


#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.


#17

I am sorry you got offended.


#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.