yep, thats what I did too and cant wait to get the EU-version and integrate it in my HA-system 
I have an official integration (which migrates the HACS to core) sitting in PR
Feel free to comment on it as a +1 or a thumbs up or something. I worked with the HACS plugin creator to get it ported with the hope of getting it into core.
3 Likes
Nice,
As the creator of both the current HACS WeatherFlow integration and WeatherFlow2MQTT I think this is great to get a completely local Core integration - good work, and thanks to @natekspencer for helping port the UDP backing library.
One thing that will be be missing here is the Weather Entity as this is not supplied by pyweatherflowudp. So this is āonlyā current weather data.
Once this is done, I should maybe make an option in the WeatherFlow Weather integration to allow for only retrieving the Forecast data. Then the two would supplement each other.
2 Likes
One Issue I discovered, is that the domain name you use is the same used for the WeatherFlow Weather integration, thus these two cannot co-exist without one of them being being renamed. If this gets accepted and merged in to core, I am willing to do a rename of the HACS integration. I might call it WeatherFlow Forecast or something similar.
2 Likes
How did yāall get this shipped to the UK for anything less than $500?! I got the āspecialā link but the cost of shipping and customs is almost the same price as the unit itself.
1 Like
Will this have all of the other calculated sensors, such as Zambretti?
Its a port of the previous version of the HACS one - so it has everything thatās over there. I need to push the latest changes -
Ok, the only change lately was to put a cap on snow probability percentage.
Hopefully, I will have the local current conditions put in for @briis to approve soon.
I was reassigned yesterday from it to āhelpā build a LEGO set that took over 5 hoursā¦so we will see how today goes.
1 Like
Assuming this does get integrated would you be interested in migrating parts of your integration into it? Iām not sure what the differences are at 1st glance, but Iām assuming you are hitting cloud stuff for getting forecast data wherease the code Iām working on is udp local basedā¦
Iām also happy to go with the domain weatherflow_udp if you think that would be more useful?
If your integration only uses the UDP then there is the weather forecast (and current conditions) pulled from WeatherFlow servers but there are also many additional sensors that are calculated based. I have submitted a PR for locally calculated current conditions which will require some tweaks to get working. The current conditions text is not implemented yet because I have no complied the different languages for the translations.
This should be a complete list of sensors:
- absolute_humidity
- air_density
- air_temperature
- battery # voltage
- battery_mode # support for Tempest devices only
- beaufort
- cloud_base
- current_conditions
- current_conditions_txt
- delta_t
- dewpoint
- dewpoint_description
- feelslike
- fog_probability
- freezing_level
- illuminance
- lightning_strike_count
- lightning_strike_count_1hr
- lightning_strike_count_3hr
- lightning_strike_count_today
- lightning_strike_distance
- lightning_strike_energy
- lightning_strike_time
- precipitation_type
- pressure_trend
- rain_intensity
- rain_rate
- rain_start_time
- rain_today
- rain_yesterday
- rain_duration_today
- rain_duration_yesterday
- relative_humidity
- sealevel_pressure
- snow_probability
- solar_elevation
- solar_insolation
- solar_radiation
- station_pressure
- status
- temperature_description
- uv
- uv_description
- visibility
- voltage
- wbgt #Wet Bulb Globe Temperature
- wetbulb
- wind_bearing
- wind_bearing_avg
- wind_direction
- wind_direction_avg
- wind_gust
- wind_lull
- wind_speed
- wind_speed_avg
- weather
- zambretti_number
- zambretti_text
So Iām porting an existing HACS UDP sensor over which supports:
- Air Density
- Dew Point
- Feels Like
- Humidity
- Illuminance
- Lightning Average Distance
- Lightning Count
- Precipitation Type
- Rain Amount
- Rain Rate
- Solar Radiation
- Station Pressure
- Temperature
- UV
- Vapor Pressure
- Wet Bulb Temperature
- Wind Average
- Wind Direction
- Wind Direction Average
- Wind Gust
- Wind Lull
- Wind Speed
- Wind Speed Average
- Up Since
- Battery Voltage
- RSSI
Obviously not as complete as what youāve listed.
There are also some inputs that are needed to get all sensors. @briis has it at environmental variables if running in docker; or from HA and some other manual inputs if running the Add-On. Things like station elevation, LAT/LONG, and some others things useful for generating additional sensors. I run it as a docker container which sends to MQTT then to HA. LAT & LONG along with elevation is used to determine Solar Insolation (estimated Solar Radiation), this is in turn used in comparison to actual solar radiation to determine if there is cloud cover. Cloud cover is not seen directly by the user, but is used in the local current condition calculations. Station elevation is used to determine sea level pressure, which is (in my opinion) more useful then station pressure alone. Elevation also plays a role in Freezing Level and Cloud Base.
@jeeftor
As the weatherflow domain has been around for some time for the REST based HACS integration, I would assume we will run into some issues with these folks, if Home Assistant core, suddenly has the same domain integrated. I am willing to change the name of the REST based integration, but we just need to plan this carefully and announce in good time, as this will be a Breaking Change for the once using the current integration. So you will need to keep me in the loop.
The UDP version you are migrating, was also done by me back in the days, but was abandoned when I created weatherflow2mqtt. This was then optimized, when @natekspencer rewrote the whole pyweatherflowudp package to handle the UDP traffic from WeatherFlow.
On top of both these integrations we have, over time, developed some extra sensors, that the community have been asking for. @GlennHA has been extremely active on the weatherflow2mqtt integration, and many of his suggestions I have then implemented in the REST integration also.
All the above to give you a bit of background and perspective.
As the integration you are planning is using the UDP data, I do think it is important that this is kept as a local data implementation only, meaning that you donāt use any data from the WeatherFlow REST api, like forecast and other server calculated data.
For the forecast piece, I suggest that I make it possible to deselect the Sensors in my current REST integration, and then people can use this to only get the Weather Entity with the Forecast data if they want and then pull the current data locally through the integration you are creating.
For the extra sensors, there is some work to be done, as the data from the UDP API is limited and as such, there is a need to store some local data in Home Assistant to get sensor values correct calculated and to make sure that sensors have data when Home Assistant is restarted. This can be done, I just havenāt done it yet. My suggestion here is to add these sensors over time, and start with the basics - what you can get from the pura UDP API.
So in summary: Go ahead with what you are doing, keep me in the loop and I am happy to chip in/test when you need it.
Sounds like a plan. Iām completely happy to work with you to start migrating parts into the core integration. Generally I think we all win when things are in core because they are more accessible to the slightly less technical folks.
Assuming I get āsomethingā into core ā would you be interested in collaborating to move eventually over from HACS to core? As Iāve added an integration in the past its kinda a hurdle to get the initial integration added but once its in its a lot easier to extend and add to it.
The only thing Iām trying to work out in my head is do I go with weatherflow_udp and then eventually we could try to move your stuff into weatherflow_cloud or are we just better off with weatherflow that starts as local_polling and then we can add additional features in the future to extend its capabilities.
Send you a PM
1 Like
I had the same issue. $70 shipping for one unit, then added the bird deterrent for ~$7 and the shipping went to $360. Quite a lot extra for a rubber band!
If I order one, it will just be the unit without the pole or rubber band.
1 Like
Where do you buy it from for shipping to europe? Cant find it anywhere
Sent PM. Iām off to sleep now, any further questions, just send them and Iāll respond when I get up.
Hi
I signed up here, and received an invite.
You are responsible for import duties and taxes, and about $70 shipping costs as well.
(and shopify isnāt the only option)