Why no MQTT transport for developers?

That is good to know! I will try this.

1 Like

Thank you. I now have better understanding on how to better use WU and also how I can get MQTT in the meantime, as I already run HomeAssistant on Pi.


Another new user looking for MQTT. All my HA system uses it. Lots of other alternatives but MQTT would be way preferable.

Can bridge to your server if that’s an easier option but would prefer it all local.


Yes… if already able to send MQTT to your servers, why not allow us to change that setting on the HUB, so we can keep data completely private, or for me, I would just like the ability to send to a second local MQTT server.


Hi and BIG thanks to you :+1:
With the help of your UDP listener I am now able to receive MQTT in my FIBARO Homecenter and finally get weather data without a working internet connection!!

In case someone is interested how to receive these messages in Fibaro Homecenter, have a look at here at 10der’s work (a MQTT handler for Fibaro)

Finally I can get the local weather without a working internet connection.

I whish the MQTT Server could be intergrated in the Weatherflow Hub.
Which would make the setup much easier.
Thanks again for this solution!!

I would like to also ask that we be able to configure the hub to publish the data via a private MQTT broker. With the network being WiFi only, there is too much chance of a flaky WiFi connection causing lost UDP broadcasts. If the hub could be connected to a network cable, it might not be so bad.

Any update on the topic? MQTT would make things a lot easier in terms of local integration with things like Home Assistant. Can we please have this enabled in the hub? I already own a few stations and things are getting more complicated…

1 Like

Sorry, no update on MQTT. Curious, why do the REST & WS interfaces (with UDP fallback if the network goes down) not work for Home Assistant? Note you can also get forecast and other enhanced data via the remote API (REST & WS) so there is real value in using that as your primary data source.

First of all some of my stations are in remote areas where Internet connection is only a (good) dream. These locations run on solar only and i use home assistant to run the place - all fully offline and localized. Second, i have to maintain a custom integration so i can ingest data from UDP to HA. Even more i get too much data so i have to filter it out and do all of this by hand, in code. Whenever HA changes something i have to change my stuff as well. MQTT would simply solve these issues - i can simply ingest data in HA and do all of the stuff i need in HA itself. Even when i upgrade HA i would have nothing to do as MQTT works by default. I am not saying that UDP is not working, quite the contrary. It just needs time and effort to keep it integrated in HA. I am willing to alpha test if you have something, does not even need to be bullet proof :slight_smile:

Thanks for the explanation. It’s true that MQTT (as a higher level protocol) is “easier” to work with than UDP. For the same reason, MQTT adds a lot of overhead to the code running on the Hub. It’s not as simple as “turning it on” unfortunately.

I am most certainly sure that it’s not that simple to have in a product. It’s true you can have this done with an Arduino but it’s far from being product grade and depending on what’s already in there it can become quite bothersome. Still, MQTT would be just great. By the way, and i guess i speak for most enthusiasts in here which supported both product campaigns from the beginning, MQTT without authentication is enough - no need to get into complex certificate based topics.

1 Like

I have played around with this and have made a program that runs within a docker container, and retrieves the data using UDP and then publishes that data to a MQTT Server, supporting Home Assistant MQTT Discovery. So you will get all the sensors automatically setup plus a few extras that are calculated values, like Sea Level Pressure, Feels Like temperature etc.

If you want to, the same container can also get the forecast data from WeatherFlow and also publish this via MQTT Discovery. The later requires you to enter your Station ID and get a personal Token.

Please note, as we still cannot buy Tempest units here in Europe :face_with_raised_eyebrow: this has only been tested on AIR & SKY, but Tempest units are supported, I just havn’t tested it.

You can find the stuff here: GitHub - briis/hass-weatherflow2mqtt: WeatherFlow to MQTT for Home Assistant. Use UDP to get local weather data in to Home Assistant using MQTT Discovery

So you don’t fall under one of these locations?

EDIT: I just realized the Add to Cart button grays out. Maybe it is just Kickstarter/Indiegogo orders being sent out right now.

1 Like

Exactly - Everything you select besides United States & Canada, you get a gray basket.

when i run that, i makes everything a battery sensor, though the icons are likely correct for the measurement (flash, windy etc)
this is the log from the container

which i assume comes from line 315

        if is_tempest:
            sensor_name = "Battery TEMPEST"

Thanks for reporting this. I will correct this ASAP. That happens when you can’t test.

EDIT: It is now fixed (I hope)
To update:

docker pull ghcr.io/briis/hass-weatherflow2mqtt
docker stop weatherflow2mqtt
docker rm weatherflow2mqtt

And then execute the run command again to use latest docker image. Let me know if it works. If not make an issue on Github and I will take it from there.


now were talking!



Thanks, @bjarne ! Would you mind posting your Home Assistant information to our Third-Party Integrations page? A short description and would be fantastic!

Done. There is now a specific post for this integration here: WeatherFlow2MQTT for Home Assistant


Added also to the wiki on top of the category. Thanks for sharing the docker.

1 Like