WeatherFlow UDP listener and MQTT publisher utility

I’m not suggesting you do.

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

1 Like

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

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

2 Likes

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.

2 Likes

I am sorry you got offended.

2 Likes

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’

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

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.

yeah - I see it…gimme a minute to fix it…

(update)
@plains203 - change line 223 on the right where it says “time_epoch” to say “timestamp” and that’ll fix it…

2 Likes

@vinceskahan looks to have fixed it thanks!

It also looks like the mqtt feature was working as expected as well.
Now to integrate this into my openhab setup.

update - fixed --limit for events and status messages so they actually report when you want them. If you ever see bugs, please compare your copy with the lastest on github, just in case…

1 Like

update:

  • added --exclude option to easily skip certain observations/events (typically I ignore rapid_wind)
  • added --syslog option to syslog startup message and any unexpected JSON received by the listener
  • updated readme file to match

I’m currently running my host with the following options:

  • --exclude "rapid_wind" --mqtt --syslog

I’ll let it run for a few days and try to remember to bump the release git tag early next week.

2 Likes

added docker-compose.yml and Dockerfile for building and running in a container for those who like containers…

also made the MQTT topic more easily configurable rather than hard-coding it

3 Likes

This is just what I was looking for, thanks so much!!

update - anybody using this should probably grab the latest version or patch your code with a one-line addition I made to have it not take the whole cpu.

  try:
    time.sleep(0.01)             # <=== add this line
    msg=s.recvfrom(1024)
    data=json.loads(msg[0])      # this is the JSON payload

If you patch your code, be sure to use ‘spaces’ and not ‘tabs’. Then just stop/restart your listener and you’ll see the cpu usage drop to basically zero, and the pi cpu temperature will drop a ‘lot’. My pi3plus dropped 9 degC afterward !

4 Likes

Updated to version 2.0b1 if folks want to try a threaded version to not let the listener miss messages (rarely) while processing the data and outputting to the screen/syslog/mqtt/etc. Also updated the README to hopefully make it a little easier to wade through.

Same link as at the top of this thread, just be sure to pick the ‘threaded’ branch. I’m going to let it run here for a week or two before merging to master and calling it version 2.0, but it looks very stable and reliable in my testing on both a pi 3+ and a i3 Intel NUC.

3 Likes

Thanks a lot for your time, this is great and its going to save a lot of time for everyone!

merged to master, so both branches are the same latest/greatest code

1 Like

fyi - coming soon will be version 3.0

  • dropping the --weewx option which I don’t think anybody uses
  • adding the ability to support multiple sky+air per hub especially for MQTT publishing. That’ll let folks with multiple sky (and/or air) keep sensor-A apart from sensor-B and compare their multiple sensors etc.

Should be updated this weekend on the github page once I catch the docs up…

1 Like

RELEASE ANNOUNCEMENT
Version 3.0.0 released and GitHub repo updated.

This release supports MQTT publishing of data if you have multiple Air and/or Sky units in your station, via the optional -M switch.

Debugging-only example for a typical one-air/one-sky system:

/usr/bin/python listen.py -m --limit "rapid_wind" -n
publishing to mqtt://mqtt/wf/rapid_wind

Debugging-only example for a multi-sensor system via adding the -M option

/usr/bin/python listen.py -m --limit "rapid_wind" -n -M
publishing to mqtt://mqtt/sensors/SK-00013695/wf/rapid_wind
publishing to mqtt://mqtt/sensors/SK-00013695/wf/rapid_wind

Python version requirements are unchanged:

  • python 2.x: version 2.7.9 or later
  • python 3.x: version 3.7.0 or later
2 Likes