WeatherFlow2MQTT for Home Assistant

This project monitors the UDP socket (50222) from a WeatherFlow Hub, and publishes the data to a MQTT Server. Data is formatted in a way that, it supports the MQTT Discovery format for Home Assistant, so a sensor will created for each entity that WeatherFlow sends out, if you have MQTT Discovery enabled.

Everything runs in a pre-build Docker Container, so installation is very simple, you only need Docker installed on a computer and a MQTT Server setup somewhere in your network. If you run the Supervised version of Home Assistant, you will have easy access to both.

There is support for both the AIR & SKY devices and the TEMPEST device.

For installation and configuration instructions look at Github

4 Likes

Thank you for this. I had been looking for an off-line integration for HA to backup SmartWeather (Thanks for that too) but the UDP custom integration is not getting any love and I don’t use Node Red. In any case, all your great work has elevated you to the top of my list of favorite people!

I have been up and running for a day or so and mostly working great, but there are a few things I can’t yet explain. This is my first MQTT integration in HA, so the oddities may be on my end. I came to the forum to see what I could learn and found this post. I will log my observations on GitHub.

Thanks again, and these guys should really find a way to get you a Tempest device!

Thank you Charles. Please post anything you find in the issues section on Github, and I will do my best to help/fix.

And WeatherFlow has been very helpfull, so I will get the possibility to get my hands on a Tempest station

Any chance of a version to run on ARM? :slight_smile:

I just tried installing this, but only have a PI here at the moment. Will have to see if I can get something else to run it on.

Cheers
Simon

Hi Simon,
I am learning all that Docker stuff at the moment, so I am not exactly sure how I build for a different platform, but I will figure it out.

Could you add an issue to Github, so I won’t forget?

In the meantime, you could try and build the container yourself, by doing the following, in a terminal on your PI:

  1. Download the source from Github to your PI.
  2. Unpack the ZipFile, and go to the directory where you find the file Dockerfile
  3. Build the container locally by issuing this command: docker build -t weatherflow2mqtt .
  4. Now follow the instructions from README on Github, with 1 exception: Whenever you see ghcr.io/briis/hass-weatherflow2mqtt replace this with weatherflow2mqtt. This will ensure you use the container you just build.

As I said, I am learning how to really deploy things in Docker, so I am not sure it is enough just to build on a PI, to make it run on a PI, but it is worth a try.

Let me know how this goes

1 Like

Many thanks for the instructions and the integration. I managed to get it working within the Home Assistant OS docker environment.

I’ve added comments over on Github.

Cheers
Simon

THANKS for this Simon. I have copied your instructions to the Discussions on the Github, and you can all find them here

1 Like

Figured I might as well post here since this is probably better then having a discussion in GitHub
From GitHub post:

The below are the only inputs allowed for HA weather condition. Currently this is pulled from the web API. I was toying with the idea of expanding my weather condition template to pull this locally. I understand I can't get the forecast local only; but I like as much self-hosted as possible. I think the only things I can't verify is clear-night, due to light conditions at night. Thoughts below:
‘clear-night’ can't check if fog at night since no light level to compare to (open to ideas)
‘cloudy’ can get a base line lux amount and compare and if not any other precipitation
‘fog’ same as cloudy but with window below a determined temperature
‘hail’ sensor for this
‘lightning’ sensor for this (maybe any number in last 3 hours)
‘lightning-rainy’ combine sensors for this
‘partlycloudy’ same as cloudy, with maybe a trend/derivative sensor to determine intermittent light levels
‘pouring’ Rain Rate > 0.31 in/hr (7.8 mm/hr)
‘rainy’ sensor for this
‘snowy’ a little more complicated but maybe temperature combined with blocked UV sensor and rain sensor
‘snowy-rainy’ same as snowy but easier to assume around 0C / 32F
‘sunny’ easiest just base on UV/lux level
‘windy’ wind speed >25mpg (11.17 m/s) without clouds
‘windy-variant’ windy with clouds
‘exceptional’ dewpoint between 50-60F, temperature between 68-77F, UV below 2.5 index, not any of the above (except sunny).

So...the actual point of this... should I make my condition template and then PR to the readme example or should we incorporate this to give another calculated sensor output? I'm leaning toward a sensor, but this would add a lot more code and wanted to run it past you before a PR without a big change with any other info. I would keep the current web api returned status as you have it and create some other named sensor. Thoughts?

So I am working on the order to determine conditions but I have some things to start. Not in yaml format yet, just working thru the logic.

Fog is likely when:
Air Temperature - Dew Point < 4.5F (2.5C)
Relative Humidity > 95%
Wind Speed < 10 knots / 11.5 mph / 5.14 m/s

*** near seawater >70% Relative Humidity and wind speed <10 knots (5.14 m/s)could cause fog
Need more conditions for fog, it looks like this might throw a lot of false fog.
There is some trends for heating/cooling but most would not have a derivative sensor for air temperature.
windy:
Wind Speed > 25mph (11.17 m/s)
Pouring
Rain Rate > 0.31 in/hr (7.8 mm/hr)

Need to get real world data, but this is a start for figuring out cloudy day & night. Might need to import ‘astral’ into the code. Astral is a python library for Sun & Moon position, we need sunrise/sunset times without pulling from an external source (maybe). There might be other ways.

0.0001 lux – Moonless, overcast night sky.
0.002 lux – Moonless clear night sky with airglow.
0.27–1.0 lux – Full moon on a clear night.
3.4 lux – Dark limit of civil twilight under a clear sky.
100 lux – Very dark overcast day.
400 lux – Sunrise or sunset on a clear day.
1000 lux – Overcast day
10000–25000 lux – Full daylight (not direct sun).
32000–100000 lux – Direct sunlight.

More to follow.

Just updating this post for now.
Exceptional does not appear to be used by some weather integrations. I looked at the code for the animated weather card and ‘exceptional’ does not reference an icon.

Version 2.0.0

Release Date: June 15th, 2021

Changes in this release

  • NEW: There is now a new sensor called pressure_trend. This sensor monitors the Sea Level pressure changes. The Pressure Trend state is determined by the rate of change over the past 3 hours. It can be one of the following: Steady, Falling and Rising. Please note we will need to gather 3 hours of data, before the returned value will be correct. Until then the value will be Steady.

  • NEW: The simple storage system, that used two flat files, has now been rewritten, to use a SQLite Database instead. This will make future developments easier, and is also the foundation for the new Pressure Trend sensor. If you are already up and running with this program, your old data will automatically be migrated in to the new SQLite Database. And once you are confident that all is running, you can safely delete .storage.json and .lightning.data.

  • BREAKING CHANGE: To better seperate the sensors created by this Integration from other Weather related sensors, this version now prefixes all sensor names with wf_ and all Friendly Names with WF. As each sensor has a Unique ID that does not change, the sensors will keep the old Entity Id, and just change the name, and only the Friendly Name will change after this upgrade. But if you delete the Integration, and re-add it, then all the sensors will have the wf_ as a prefix. The same goes for new sensors that might be added in the future. So if you want to avoid any future issues, I recommend deleting the WeatherFlow2MQTT device from the MQTT Integration, and then restart the Docker Container, to get all the sensors added again, with the new naming convention.

1 Like

Version 2.0.3

Changes in release 2.0.3

Please make a backup of weatherflow2mqtt.db before upgrading. Just in case anything goes wrong.

NEW: A new sensor called wf_visibilityhas been added. This sensor shows the distance to the horizon, in either km or nautical miles, depending on the unit_system.

FIX: If the forecast data from WeatherFlow is not available, the program will now just skip the update, and wait for the next timely update, instead of crashing the Container.

CHANGED: Attributes for each sensors are now moved from the event topics, to each individual sensor, so that we can add sensor specific attributes. This will have no impact on a running system.

NEW: Started the work on creating Sensors for High and Low values. A new table is created and daily high/low will be calculated and written to this table. Currently only day high and low plus all-time high and low values are calculated. The values are written as attributes to each individual sensor where I believe it is relevant to have these values. Note It takes 10 min before the daily max and min values are shown, and all-time values are first shown the following day after upgrading, or on the first run of this program.

Attribute Name Description
max_day Maximum value for the current day. Reset at midnight.
max_day_time UTC time when the max value was recorded. Reset at midnight.
min_day Minimum value for the current day. Reset at midnight.
min_day_time UTC time when the min value was recorded. Reset at midnight.
max_all Maximum value ever recorded. Updated at midnight every day.
max_all_time UTC time when the all-time max value was recorded. Updated at midnight every day.
min_all Minimum value ever recorded. Updated at midnight every day.
min_all_time UTC time when the all-time min value was recorded. Updated at midnight every day.

The following sensors are displaying Max and Min values:

Sensor ID Max Value Min Value
air_temperature Yes Yes
dewpoint Yes Yes
illuminance Yes No
lightning_strike_count_today Yes No
lightning_strike_energy Yes No
rain_rate Yes No
rain_duration_today Yes No
relative_humidity Yes Yes
sealevel_pressure Yes Yes
solar_radiation Yes No
uv Yes No
wind_gust Yes No
wind_lull Yes No
wind_speed_avg Yes No

Version 2.0.4

NEW: A new sensor called wf_wet_bulb_temperature has been added. This sensor returns the temperature of a parcel of air cooled to saturation (100% relative humidity)

NEW: A new sensor called wf_delta_t has been added. Delta T, is used in agriculture to indicate acceptable conditions for spraying pesticides and fertilizers. It is simply the difference between the air temperature (aka “dry bulb temperature”) and the wet bulb temperature

NEW: Added monthly min and max values to selected sensors. Note Data will only be updated once a day, so first values will be shown after midnight after the upgrade and new Attributes will require a restart of HA before they appear.

FIXED: Daily Max value did not reset for some sensors at midnight.

FIXED: When using the WeatherFlow forecast, there could be a mismatch in the condition state.

CHANGES: Some Under the Hood changes to prepare for future enhancements.

Attribute Name Description
max_month Maximum value for the current month. Reset when new month.
max_month_time UTC time when the max value was recorded. Reset when new month.
min_month Minimum value for the current month. Reset when new month.
min_month_time UTC time when the min value was recorded. Reset when new month.
1 Like

This component is really, really nice. Thanks for making it.

EDIT: Never mind. I see that’s described on the github README.

I can see the hourly and daily forecast attribute info and display them as text in entity card. I’m still finding out about HA nooks and crannies. Has someone already worked out a way of displaying that info in lovelace in something better than YAML text? (I’m not afraid to do some YAML editing, if that’s what’s needed.) I found the Weather Forecast card in the UI, but it doesn’t have any available entities.

How do you want to display it?



Your options are almost unlimited.
I have posted the code and backgrounds for Dewpoint and Temperature, I used the UV that someone else posted (all on the Home Assistant Forums).
I have not posted the background picture for the Beaufort Scale yet, still tweaking it.

That is pretty cool. @glenngoddard

Actually…it is Very Hot, but thank you.
If you search the Home Assistant forums for this:
https://community.home-assistant.io/t/cool-uv-index-gauge-for-my-swimming-pool-area/116223
You can get started with the UV, I fill it in with data from the Tempest.

Probably should have mentioned this before.
You can use any weather card in Home Assistant also to display the data.
I personally use the animated weather card and all the info comes from this.

You’ll have to excuse my inexperience, but how exactly is everyone installing this in Supervised Home Assistant? I’m guessing you’re not running HassOS, correct?

You have to follow the instructions on the GitHub page for this.
This will create a docker container which will publish topics to a MQTT broker, which in turn will be automatically picked up by Home Assistant if MQTT integration is installed.

You will need to have docker and a MQTT broker running.
Depending on your setup, getting docker up and running could be an issue.
As for the broker, that is fairly easy.

Hey Glenn, perhaps I should clarify that I have given it several solid attempts.

I am running Home Assistant Supervised using HassOS on a Proxmox i5 NUC. The docker command is pretty well gutted it seems, as a result. First, I tried using Simon’s build on the Raspberry Pi I’m using for a remote ZWaveJS2MQTT instance through Portainer. It connected over MQTT and populated sensors in my HA instance, but values were only ever provided for the rapid wind speed, wind direction, uptime, and a few other sensors. Deleting the sensors and restarting the container gave the same results. I can see the DB is being created, but it is always empty when I open it.

The next attempt was in a Ubuntu Server VM I also have running in Proxmox. Container started up, HA was populated with the same sensors, and the same few sensors which had values before were updating. I checked the MQTT sensors this morning, expecting the same, but they all had values! Closer examination showed the values were all from just after midnight, with nothing more recent, aside from the rapid wind velocity and associates.

I believe there is an issue with my SQLite database, but that is where I’m stumped.

Do you have WireShark or another way to monitor UDP traffic?
If you are seeing the database then you have a relatively new release since that has been with in the last week or so.
Do you get all the information on the app?