This is a good question, maybe @Kai can answer if those weather calculations should remain part of the binding or maybe included into OH.
Regarding other OpenHAB weather data folks, I’m not sure have many people there are, however they should be able to find this topic. In terms of people outside OpenHAB community I’ve already put some comments on indiegogo that the binding is being develped. Also there is a closed Facebook group where I could put some info and links to OpenHAB and this topic…
One more thing can be done. Once your binding is released officially, we can ask WeatherFlow to publish this information on their site in “integration” area, just where IFTTT is mentioned. For example http://weatherflow.com/smart-home-weather-stations/ or https://help.weatherflow.com/hc/en-us/articles/115005229547-Smart-Weather-Integrations
I assume you refer to this question?
Well, it is a good one. I agree with @hww3 that anything that is not specific to this very binding should not be included in it. We just had a very similar discussion here:
So while I cannot give you a good answer how we can best provide “derived information” in a generic way, I would suggest to not include it in your binding. I have created an issue for the further discussion, feel free to involve yourself there!
1 Like
You’ll find a WeatherUtils.java class in the Netatmo binding that provides many of these derived values / computations.
I agree that at one point this should move from bindings to OH or ESH via some yet to be defined mechanisms.
1 Like
So, I’ve started working on a binding that produces derived meteorologic
values, based on your WeatherUtils class. Right now it just provides sea level pressure, but I’m working on adding others. The idea is that you tell it the items that provide raw weather data and it produces a set of items that update themselves based on the raw input. That way, any binding (or combination of bindings) that can provide temp, pressure, humidity and wind speed can generate the full suite of derived results.
It seems to work pretty well; my only wish was that thing configuration values could include the “Item” type, and produce a pick-list for easy configuration.
This is a work in progress but seems to work so far. Comments, suggestions, and code are welcome!
2 Likes
Fantastic. Is there some addon file available?
Not yet; I’ve only added the sea level pressure calculations so haven’t made any builds available. If you want to try it out and have the jdk and maven installed, you should be able to download the source and do a “mvn clean package”… assuming the build goes well, the jar will be in the target directory.
If you do go this route, this binding doesn’t do autodiscovery, so you’ll need to go to Inbox->Search for Things->WeatherCalculations binding and set up a new thing. There are some configuration parameters that need to be set (altitude, and the names of the things that provide the raw data).
I hope to add a few more over the next week or so. Now that it’s working with one value, adding more should be pretty straightforward. I think the biggest risk is that the formula have been interpreted incorrectly and are generating incorrect results.
Will test it 
Cool! I’ve added most of the additional values to the binding (some require wind speed and will default to calm conditions if there is no value). I can upload a jar if you’d rather not build yourself… also, happy to hear suggestions on additional calculations. There are some rain and wind values that I haven’t included since I’m not able to really test them.
I don’t think there’s much I can do from a presentation standpoint with the binding; ultimately I’d like a HABPanel widget or something like that to stand in for the SmartWeather app. Perhaps that’s the next step?
Also, I haven’t come up with a solution for the “event” channel… lightning and eventually rain/wind events. These events feel like they should be sent as data structures, but OpenHAB doesn’t really seem to have a datatype for that… sending the data as a string seems like it could be pretty brittle. Ideally something like JSON would be better.
Happy to hear suggestions… perhaps this is more of a OpenHAB-wide sort of discussion… not sure how to include the other OpenHAB <-> Weather folks in, anyone have a suggestion?
If you could build .jar that would be helpful, i would need to set up separate machine for installing all the libs to run maven, but it’s in other use till next week.
Certainly we have to wait for the Sky to have something for tests, so there is no rush. Can’t wait.
Regarding Habpanel, I have 5 tablets running Habpanelviewer so I planned to work out at least 2 widgets, one - very simple but easy readible and clickable to “Weather” dashboard - for “Status” page and the other one - with all the weather data together with charts - for “Weather” page.
Perhaps “event” channel is used for Weatherflow’s smart features like for exchanging data with IFTTT?
Unless we know what is the meaning of those data it’s hard to say how to deal with it. Do you have examples?
In order to invite other WF station owners maybe it is worth to say something on the Weatherflow Smart Weather Station Faceboook group? The best would be to show some geeky habpanel screen screenshots or videos with data taken by the binding, however since there is not yet any maybe some simple descriptionof Openhab, habpanel and binding would be enough?
I’ve uploaded a JAR built on the latest sources here:
org.openhab.binding.weathercalculations-2.2.0-SNAPSHOT.jar https://bitbucket.org/hww3/org.openhab.binding.weathercalculations/downloads/org.openhab.binding.weathercalculations-2.2.0-SNAPSHOT.jar
Do let me know if you run into any problems!
Bill
Hi there - just to be clear, the binding doesn’t use the cloud API, but uses local UDP packages? that’s fine.
I once stepped in the trap and bought a device, which didn’t offer a local API (was promised for the future) - and now it’s basically a dead device, because I can’t use it in openHAB but only via the manufacturer’s app.
I’m wondering, what would happen, if weatherflow decides to either shut down completely or have us to pay for the service? I guess, the UDP packages won’t be sent anymore to the API, because the servers are either down or only reachable for paying customers?
I’m working on a HABPanel demo; it may be a few days but we can then start to publicize this solution more fully.
As far as the “events” channel is concerned, the data tends to be more than just a simple value… there’s the type of event (such as lightning detected) and some additional data about it (such as estimated distance). I suppose if we could have a channel type that just emitted json data, we could pass that right along from the sensors as they happen.
How that would end up getting used might be more complicated than just a simple value… or not; I haven’t really looked into it too much.
An example use case might be: a widget on a dashboard might light up if lightning was detected within 5km in the last 5 minutes. What other uses might there be? I think the types of events are lightning strike detected, precipitation start, and high wind.
Yes, this binding uses the UDP data feed directly… OpenHAB just needs to be on the same network segment in order to receive the data.
Your situation is all too familiar, and that’s why I decided not to use the smart weather cloud API. In fact, my SmartWeather hub isn’t even connected to the internet; it’s on a wireless network that’s isolated and my OpenHAB instance is connected to that network. I do export all of the data to an InfluxDB database, so I can do historical graphing and such.
THAT sounds just great. If I understand correctly, the SmartWeather devices send their UDP packets regardless, if they are connected to the SmartWeather server or not? It’s not “sniffing” but “intended use”?
Yes, you have to set the HUB up using the smartphone app, but once you do that it connects up to the wireless network and sends the UDP data regardless of whether there’s a connection to the internet.
I think the sensors transmit observations once a minute; the hub transmits a status message every 15 seconds or so.
The binding has logic that marks a hub or sensor offline if it doesn’t receive data within the last few minutes… that way you can be sure that it’s reliably sending data.
Overall, I’m very pleased with the Smart Weather devices… they made some very good design decisions. Note that they’re still field testing the “Sky” sensor but expect that will be shipping to everyone in the next few months.
1 Like
ok. thanks for the update. Yes, I read something on their site of 60sec interval (but lightning alarm would be transmitted asap). So I try to hook up with them (April '18 is the prolonged delivery).