I stopped posting downloads to bitbucket as they’re phasing out that feature, unfortunately.
As a side note, you /should/ be able to do bundle:install bundleurl and get the same result, possibly with additional diagnostic information in the log file.
I got the error on Debian bookworm, so I’m rather surprised it didn’t accept the Let’s Encrypt certificate. I use that on my mail server as well, without issues.
Strange.
yep, mine is debian bookworm as well, indeed updated. … 
and OH is running on that machine, so it does then makes sense it’s failing instalation from marketplace. 
I’d say.
But a quick search shows that problem is at least not unheard of.
For me, this was the first time I’ve seen that error.
Hello @hww3 ,
Might it be possible that you can compile it for openhab 5.x?
Hi-
I’lll try to build a version for the 5.0 pre release versions, will probably take a few days.
Whew, that ended up being a lot more difficult than I expected!
https://bill.welliver.org/dist/openhab/org.openhab.binding.weathercalculations-5.0.0.M2.jar
Here’s the binding compiled against the latest 5.0 milestone. I have not tested it so it’s possible there might be problems. Enjoy!
Running since 2 days no issues so far thanks for compelling 
Can someone provide me all the possible values that can show on this channel (pressureTrend)?
When I first set this up it use to be values 0 through 2 and 0 through -2, now I’m seeing “Steady” on this channel.
Best, Jay
According to the code
It’s -2, -1, 0, 1,2
Agreed, but why am I getting “Steady” now in that channel. I saw 0 before that value which means it still seems like it’s using number range, but I think additional values where added.
I’m not sure bitbucket is the latest code base when I looked at it also.
Best, Jay
Here’s what Bill wrote in February about that:
The pressure trend calculation is fairly simplistic (by definition), and is based on the change in barometric pressure over the last 15 minute period. There are other time periods that are used, such as 1 hour or 3 hours, but the calculation is the same: look at the pressure at the beginning of each period, and compare it to the previous. For a 15 minute period, a change of 1mb or more represents a changing trend, and a change of 2 mb or more represents a fast change. Obviously, longer periods would warrant a larger change to qualify. The upside of a short sample period is that changes are detected more quickly, but with the downside that they can change more quickly as well. Longer periods take longer to register change, and also lag actual conditions, but that value remains longer as well (unless you changed the way samples were assessed: such as the value now compared to the value 3 hours ago)
I also see mostly “steady”, but the integers corresponding to the differen states are correct. Here’s what I use in an arduino that displays the weather data:
if (pressuretrend == -2) { gfx->print("Rapidly Falling"); }
if (pressuretrend == -1) { gfx->print("Slowly Falling"); }
if (pressuretrend == 0) { gfx->print("Steady"); }
if (pressuretrend == 1) { gfx->print("Slowly Rising"); }
if (pressuretrend == 2) { gfx->print("Rapidly Rising"); }
Hi!
Internally, integers are used to represent the 5 trend states, and there’s a mapping on the value that translates those integers to a more friendly string for the various UIs. That behavior has always been present, but if you look at the values through the items command in the karat client, you should see underlying value there. In my case, right now it’s displayed as “Steady” in the UI, but “items list” shows 0 (zero):
WeatherCalculationsTempest_PressureTrend (Type=StringItem, State=0, Label=Pressure Trend, Category=Pressure, Tags=[Point], Groups=[WeatherCalculationsTempest])
Also, here’s a random snippet of persisted data (I use influxes) from my weather station:
1747152900838000000 0
1747152915867000000 -2
1747153800838000000 -2
1747154700836000000 -2
1747154745868000000 1
1747155600835000000 1
1747156500837000000 1
1747157400836000000 1
1747157429871000000 0
1747158300838000000 0
1747159200836000000 0
1747160100838000000 0
1747160113875000000 -1
1747161000837000000 -1
1747161028874000000 -2
1747161900836000000 -2
1747161943874000000 -1
1747162800835000000 -1
1747162858875000000 0
1747163700836000000 0
1747163712875000000 -1
1747164600837000000 -1
1747164627876000000 -2
1747165500837000000 -2
1747165542876000000 1
1747166400836000000 1
1747167300837000000 1
1747167311876000000 0
1747168200837000000 0
1747168226889000000 -2
1747169100837000000 -2
1747169141878000000 -1
1747170000836000000 -1
1747170056879000000 0
1747170900837000000 0
1747170910878000000 -1
1747171800837000000 -1
Let me know if that explains things a little better, or if you’ve got more questions.
Bill
What weather station are you using? Have a binding in OH for it?
I’m not Bill, but there’s a binding for anything that’s a Fine Offset Clone. Ecowitt, for one. Although it doesn’t have all the channels that are available.
That’s what I currently use. Well, just their gateway and a few select sensors.
Other than that, you can get the data from almost any weather station into OH if you go through weewx/mqtt. I complement the channels the binding doesn’t offer through that.
I’ve got an original weather flow smart weather station. I like it because it’s in 2 parts, so you can install the temperature sensor in a proper spot. The newer tempest stations are all-in-on, which I’m less sure about. I wrote a binding for it, and they also have a hyper local forecast based on observations from their sensor network.
I also have a home brew station that spits out data in the same format. That uses a Davis rain gauge and anemometer plus some sensors like the bmp280 and sht41. The sensors are really the weak link, I’ve had a few give up the ghost both in my own setup and in the weatherflow station.
Plus, they’re not all that accurate. I have the bmp085 for pressure only since it only reacts very slowly to temperature changes, and before I got the Ecowitt wireless sensors I had (and still run) a SHT31 and AHT20 off the Pi that also runs my rain gauge. They’re usually almost two degrees F apart from each other, even though they’re in the exact same location.
The DHT11/22 and the like are even worse.
What a fascinating topic! IIRC, the Bosch data sheets specify a +/- 1.0C accuracy, which is not the greatest, but if you need all three values and only have room for one sensor, it’s reasonable. There are certainly better options if you have the budget and space.
It’s also been my experience that sensors out of the box need to be calibrated against known standards before they can be used for quantitative purposes. They’re also a fraction of the cost of serious instruments, so I think that’s a reasonable tradeoff. I don’t know about other vendors, but Weatherflow claims to calibrate their sensors at the factory, and having examined their PCBs, I can confirm that they’ve taken steps to limit the effect of things like PCB thermal mass on sensor performance.
I’ve read a semi-scientific study comparing various sensors[1], and there are a whole raft of factors that need to be considered when seeking maximum accuracy. The Bosch sensors are known to self-heat when left continuously running, so care needs to be taken. Like so many things, it’s possible to go down a rabbit hole when you (might, for example) only care about whether it’s colder or warmer than it was yesterday.
Just for fun, I checked and the SHT and BMP report temperatures about 0.6C different from each other. They’re not calibrated/compensated, but the sensor boards are in free air separated from other sources of heat and the BMP chip is set to sample only when queried (auto-mode being the major source of self-heating).
[1] DHT11 vs DHT22 vs LM35 vs DS18B20 vs BME280 vs BMP180 | Random Nerd Tutorials, I think.
Very fascinating indeed.
But if you think about it, there are not that many applications where high accuracy is actually required.
I agree, it’s always a nuisance if a sensor reports 0.1C values, but it’s accurate only to 1C.
But we’re looking at outside/inside temperature here, at least for me ±1C isn’t a deal breaker. Especially with cheap sensors.
Even seemingly critical applications like, say, coolant temperature in our NPPs, a degree plus or minus doesn’t affect operations at all.
And if you need that accuracy, well, then just use expensive sensors and calibrate regularly.
@hww3:
I’m currently changing my setup and would like to use average outside temperature/humidity for the weather calculations.
Those now are group items that average the individual sensor values.
Does that work with the binding? Currently it seems not, since the values don’t change…
As an alternative I could define the average as a regular item and use a rule to calculate the average…
Thanks!