Just to clarify: it shouldn’t be considered a “rate”, but rather an increment of measurement. The reason is that if there is very slow rain that takes more than the reporting interval to detect, it’s possible to get an incorrect idea of how fast the rain is actually falling. Of course, as long as you’re aware of this (minor) caveat, feel free to use it. If you’re using a tipping bucket rain gauge this is even more important to understand, as you get bucket sized increments as they accumulate.
I’m using the weather calculation binding to perform a sum of the day’s rain, and then I dump it into influxdb. From there, you can do things like perform the derivative of the data and get the rate (and all kinds of other crazy numbers).
The rain and lightning events aren’t trigger channels; they’re Precipitation and Lighting Strike events transmitted over the openHAB event bus. They have actual datapoints in them that couldn’t be expressed using a trigger channel. If you’re using the new rule engine, there are a set of triggers provided by the binding for this purpose… you just have to select the “thing” that has the sensor and the trigger will handle the rest. Plus, (for example,) the lightning trigger includes the “power” and distance values, which you can access in your rules.
There’s a readme with some examples for using these triggers, along with an example of how to access the event data:
I’ve built a version of this binding for the latest 4.0 milestone. There are no code changes, it’s just recompiled. I don’t have a 4.0 installation (yet), so it’s untested, but I don’t think there should be any problems using it. Please give it a try and let me know if you run into any problems.
Hello Bill,
with the debug info I was able to fix it, there was a wrong reference in my items file when I switched back to it.
Thanks for your help and for the great binding
I just wanted to say thanks for creating this binding. I know how much work goes into one of these (done a few bindings myself), so very much appreciate your effort here! I’ve been using the 3.4 binding with my Tempest station for the last 6 months. I’ve not had any issues.
Have you considered posting this in the OH Marketplace? It’s as simple as moving this topic to the Marketplace Bundles (Add-on Marketplace - openHAB Community) category and add a link to the jar file. And adding an Icon on the first post for Weatherflow…
Thanks for your kind words… it can be quite a lot of effort, especially when you release it to others and discover that not everyone has things set up the way you do!
Yes, actually, I’d like to get a version in the marketplace. My other “weather” related binding, Weather Calculations is already there, and is sort of a test of the process for me. The primary reason I haven’t done the same with the Weatherflow binding is that I didn’t get the sense that there was a good way to deal with providing a version of the binding for a particular version of OpenHAB.
With new releases coming as fast as they do, I find myself usually a version behind (and I’m sure I’m not the only one). I think there is an ongoing effort to have a solution for that, so this request might become a reality soon.
Mr. Welliver, please do so.
It’s the best way for a not so experienced user to get a beneft from your well-designed binding.
Thanks for your good work.
Since OH4.0.1 the jar i not loading anymore…anyone have the same issue?
Getting this error
2023-08-02 08:09:33.353 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.weathercalculations-4.0.0.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weathercalculations [28]
Unresolved requirement: Import-Package: org.openhab.core.config.core
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]
2023-08-02 08:09:33.551 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.weatherflowsmartweather-4.0.0.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weatherflowsmartweather [29]
Unresolved requirement: Import-Package: org.openhab.core.automation
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]
Just updated my test system to OH v4.0.01 and the binding is working as expected.
FYI for anyone else, the version 3 weatherflow binding - while it looks like it’s online and all is good, no channels are getting updated, so you definitely need to use the version 4 weatherflow binding.
I haven’t tested 4.0.x yet, but I’ll try to find some time this weekend to get a new version ready… I’m sure it’s just a matter of recompiling for the latest version.
I’ve made the necessary changes for the binding to work on 4.0. The previous version may have worked but was missing some changes in order to be recognized as proper openhab 4 add-on. I’m not running 4.0 yet myself, so this only received minimal testing. Please let me know if you run into any problems using it.
I just installed the updated binding on 4.0.2 and it seems to be working. The only thing I noticed changed from my previous installation is a lot of log entries for rapid wind data in the event log which wasn’t there in my previous version. I would be interested in turning that off if possible. I also am seeing events in the openhab log for every data update, but I think that is actually related to the weather calculations binding.
I upgraded this morning and found a fix to the item update - add these two lines to your userdata/etc/log4j2.xml file (in the “openHAB specific logger configuration” section):
Thanks for developing this binding. I just installed the .jar from above in the addons folder on my Pi4B running OH4 release version. The Hub thing appeared almost immediately. It took me a minute to realize I needed a separate thing for the weather station, but once I realized that, I manually added a thing and the station was automatically detected. Working great so far.
Moving the 4.0.1 .jar into the /usr/share/openhab/addons folder let me add autodiscovered things for both the Hub and the Tempest on OpenHab 4.0.4. Thank you!
I would love to see this added into the marketplace or standard addons distribution for maintainability and installation. Let me know if there is something I can do to help with that!
