thanks to your great manual how to do that (which i would never found out by myself) it’s piece of cake 
only downside is that i needed to set log:level again
maybe consider by default log:level ERROR instead of INFO? as it’s filling up openhab.log with pretty useless informations on every weather change… or direct it to the event.log instead which makes more sense to me.
Hi-
Yes, I know that with a default logging configuration the binding is pretty verbose. The reason for that is that it makes troubleshooting for new users a lot easier. I think eventually I will be able to turn the noise down a bit. I’m not able to control where the log entries appear, that’s something that would need to be done at the openhab installation level. For now, you can turn it down with
log:set WARN org.openhab.binding.weathercalculations
Also, I’m not sure why you’d lose those settings during an upgrade… I’ve not seen that happen here.
Hello, all!
I just wanted to let everyone know that I’ve uploaded a version of the Weather Calculations binding that has been compiled for openHAB 3.4… no other changes, and I haven’t tested it myself. I’ve also updated the marketplace entry (I think). Feel free to give it a try and let me know if you run into any problems!
https://bitbucket.org/hww3/org.openhab.binding.weathercalculations/downloads/org.openhab.binding.weathercalculations-3.4.1.jar
Thanks, Bill!
Works perfectly. Used the opportunity to switch from .jar files to the Marketplace, no issues there, either.
Many thanks for the report… glad to hear it’s working for you!
Hi-
I’m in the process of updating my development environment, so it will be a few days before I can get something uploaded. Will report back when I have something ready to try.
Bill
Hi-
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.
Link:
Just a quick note to let you know I’ve updated this binding for 4.0. It may have appeared to work with existing installations, but was missing some changes for it to appear was a proper 4.0 binding. Note that I’m not running 4.0 yet myself, so I’ve only done a small amount of testing with it.
I’ve also added vapor pressure and wet bulb temperature calculations to this version. As is usually the case, you’ll probably need to remove any things you’ve already created with this binding in order to see the new channels.
Please do let me know if you run into any problems. I’ll post an update to the marketplace in a week or two if all seems well at that point.
Bill
Thanks, Bill!
Will this roll out to the bindings library in OH at some point? I use the binding from there, and it’s currently at 3.4.1, even though I am at OH4.01.
It’s working fine, though.
Yes, I’m planning to update the marketplace listing in a week or two, once I get confirmation that things are working properly.
The 3.4.1 build /will/ work properly on 4.0+, but only with existing things and items. If you were to need a new calculations thing, or wanted the new channels, Openhab 4 wouldn’t think you had the binding installed. That’s because there are xml files in the binding that describe things to openhab and need to be updated for openhab to realize there’s a binding, even though the code is enabled and running, because that happens via a different process (ie osgi components).
I’ll send another note when I feel confident enough to update the marketplace listing (I don’t know how upgrades are handled using that mechanism, so fingers crossed it will work).
Good to hear that, Bill!
Thanks a lot!
This hasn’t worked for me - still showing INFO in log
It’s possible that your default log setting is set at INFO or higher, or that you’ve got a logger in the hierarchy above that set similarly. You’ll have to look at the output of log:get and see where your configuration is causing INFO messages to show. Logging settings in java can be pretty frustrating, but there is a reason you’re getting those output, you just need to figure what what it is (I know, not helpful unfortunately.)
Hi Bill,
quick question: what are the possible states for the string “PressureTrend” channel?
I know one is “steady”, what are the others? “Rising” and “Falling”?
I had a look at the source code but couldn’t find it.
Reason is that I’m currently programming a little Arduino display with weather information, and I wanted to include the Pressure Trend as a litte arrow, so I need to know which cases I need to cover.
Thanks!
The states are actually numbers which are mapped to the string values you see in the UI. Here’s the definition for the mapping:
<channel-type id="pressureTrend">
<item-type>String</item-type>
<label>Pressure Trend</label>
<category>Pressure</category>
<state readOnly="true" pattern="%s">
<options>
<option value="0">Steady</option>
<option value="-1">Slowly Falling</option>
<option value="1">Slowly Rising</option>
<option value="-2">Rapidly Falling</option>
<option value="2">Rapidly Rising</option>
</options>
</state>
</channel-type>
Hope this helps!
Hi Bill,
Yes, it does, thanks!
Hmm, I wonder if I can retrieve the numbers from the REST API somehow, that would make things easier. Wouldn’t have to parse and compare strings.
I think the /rest/items/itemname endpoint will give you the state without the mapping applied (at least it does for me), and provides the mapping possibilities under the “options” value in the response.
Yes, you’re right. Once I got home and tested it out, I can verify that the API endpoint gives integer values, and not strings. Makes things a lot easier
@hww3 same here
Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.weathercalculations-4.0.1.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.weathercalculations [28]
Unresolved requirement: Import-Package: org.openhab.core.config.core