Hi there developers. Just wonder if there is anybody who own this station and has plans to develop binding. The API is described here WeatherFlow Smart Weather API.
START HERE:
Hey there… I’ve got one, and I’ve been thinking about making a binding for the local broadcast (UDP) api… I don’t want to have to rely on having internet/cloud access.
The big hold up for me is that I haven’t decided on how to arrange the data. I sort of wish OpenHAB had better defined data types for common sorts of devices… be happy to hear suggestions.
Weatherflow has a bridge that can have multiple different types of sensors (possibly of the same type) so not sure what the best way is to arrange things without creating unnecessary complication.
1 Like
Hi, binding for local broadcast is something all of us need to have for reliability. This is also one of the main reasons I bought this station. UDP-api based binding seems to be correct solution. I’m not a developer unfortunately but I can be a tester. The weatherflow support is genius so i believe the questions regarding OpenHAB remains only and that would be great to get some help from other developers. The closest weather station which is modular similarly as WF would be Netatmo so maybe it would be good to ask for their experience?
I agree. The cloud is nice and all but I don’t want to be forced to rely on an external service for functionality, and it’s also a better security posture to not have all nature of devices having connections open to the outside.
That’s a good point… I’ve made a note to take a look at the netatmo binding.
I’ve been looking at the UDP traffic from the hub and it appears to be completely reasonable; I’ve just started putting together rough binding outline… getting it to compile and register services. With a little luck I may have something very basic ready to look at in a week or so.
Bill
1 Like
I managed to find a few spare hours to look into this and a happy to announce that I’ve made some progress. I have a first attempt at a binding for the Smart Weather Hub and Air sensors. I don’t have a Sky in-hand yet, but once I do, I’ll add support for it as well.
What works:
- Uses the Smart Weather UDP Broadcast protocol, so no “cloud” functionality required
- Detection of the Hub and Air sensors
- Detection of when a Hub or Air sensor stop sending updates (causes them to go offline)
- Reporting of Hub status data
- Reporting of Air sensor data
What isn’t in place yet:
- Anything involving Sky sensors (as they’re not widely available at this time)
- Reporting of Air status data
- Reporting of Lightning Strike events (I haven’t figured out how best to handle this… perhaps a generic “events” channel? Feedback is welcome!)
I’ve been running the binding for a day or two and things seem to be working as expected… data is appearing in PaperUI and I’m also exporting it to InfluxDB for visualization in Grafana. It might be nice to have some rules in place, especially to alert on low battery voltage, but also to trigger events based on the Smart Weather events. I’d especially welcome suggestions on this front. What do weather mavens like to do with the data once it’s arrived?
I’ve put the source for the binding as well as a binary build (in the Downloads section) here:
Feel free to take a look, try it out (just drop the jar in your addons directory and restart). I should note that the binding prints out a fair amount of debug information, so don’t be surprised to see a lot of stuff in your openhab log file… this will get dialed back in the next build. As always, comments and suggestions are welcome!
Bill
4 Likes
I will look on this asap.
It works!
I’m very glad to hear it’s working for you. I am looking forward to receiving my Sky sensor. Once I have that, I’ll add support for it to the binding. Please do let me know if you run into any problems using the binding, or if you have any suggestions for improvements!
Bill
Thanks Bill, great work! I will monitor the binding and my logs to catch the issues if they occur. Also can’t wait for Sky and Breathe next year. Just wonder, are you happy with the quality of measurements? Is it your first weather station or you have something to compare it with?
Hi! I’m getting this warn:
[WARN ] [nternal.SmartWeatherDiscoveryService] - DiscoveryServiceCallback not set. This shouldn’t happen!
Unfortunately items stopped refreshing. Looking for the reason.
I have a home-brew weather station and I think the results are close, so I’m pleased. I will be interested to see how the sky performs; my station has a Davis anemometer and rain gauge, and the anemometer has been less than reliable.
That’s unfortunate… I saw this error once during development; I restarted my OpenHAB instance and it hasn’t returned. Have you restarted? I’m wondering if it might be a bug in OpenHAB… I’m running the 2.1.0 release version here.
Hi! I’m on 2.2. I did all “soft” solutions I could do. The values sometimes freezes. I see that epoch refreshes and temperature seems to be ok, however pressure is wrong. Also some trivial finsing is that pressure should be in “mb” instead of “MB”. Could you look into the pressure “issue”?
Well I can only offer that I haven’t seen a specific problem with pressure, but have noticed that PaperUI doesn’t always seem to update when values change (not specifically related to this binding). One way to tell for sure that the binding is sending updates is to look for lines like this in the OpenHAB log:
02:43:20.006 [INFO ] [marthome.event.ItemStateChangedEvent] - weatherflowsmartweather_air_HB_000012345_AR_00054321_pressure changed from 985.9 to 985.8
You’ll see that there are Air Observation messages that trigger these, but only when the value actually changes.
I’ve already changed the millibar abbreviation; apparently it was incorrectly autocorrected!
Could you upload updated jar file?
I see that pressure is being updated! However on WeatherFlow status page you can see “sea level pressure” and your binding provides “station pressure”. Does WF station send calculated sea level pressure and other calculated parameters via UDP?
I will post an updated binding; note that the only change at the moment is related to formatting of data in PaperUI… MB->mbar and number of decimals.
I am pretty sure that the weatherflow app generates a number of calculations based on data you specify during setup. The sensors (and hub) only report the raw sensor data, which is what’s being provided by the binding.
Do you think it would be reasonable to include derived metrics as channels into the binding? https://weatherflow.github.io/SmartWeather/api/derived-metric-formulas.html
So, it’s certainly possible for me to include channels that include these calculations, but this is where I start thinking that openHAB, as a base system, should provide classes of functionality… the calculations you suggested aren’t unique to weather flow, and I feel like there are lots of other types of data and functionality that would be well suited to common solutions.
That’s just a thought though. I wonder how we might include other openHAB weather data folks in the conversation?