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
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!
Unpack the ZipFile, and go to the directory where you find the file Dockerfile
Build the container locally by issuing this command: docker build -t weatherflow2mqtt .
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.
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.
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.
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:
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.
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.
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.
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?
