Generating derived weather calculations with the Weather Calculations Binding

Add-ons Bindings
305

I"m not really sure, I know that regular items work because of the events that occur (that’s really what the binding is doing, watching for ItemStateChangedEvent events). You could turn up your logging on org.openhab.core.events to see if there are events being generated that reflect the changes you’re interested in. If there are, then we might just have to widen the filter a bit…

If you can give me an idea of what your configuration looks like for these group items, that might be helpful as well… then I can set something similar up here to see what’s going on.

Bill

306

Hi @hww3,

looks like your certificate is invalid, and it’s not possible to install it from marketplace again… :person_shrugging:

wiill do force no-certificate and manual install, but worth to take a look. Thanks

wget https://bill.welliver.org/dist/openhab/org.openhab.binding.weathercalculations-4.3.2.jar
--2025-07-31 17:59:48--  https://bill.welliver.org/dist/openhab/org.openhab.binding.weathercalculations-4.3.2.jar
Resolving bill.welliver.org (bill.welliver.org)... 192.99.78.190
Connecting to bill.welliver.org (bill.welliver.org)|192.99.78.190|:443... connected.
ERROR: The certificate of 'bill.welliver.org' is not trusted.
ERROR: The certificate of 'bill.welliver.org' doesn't have a known issuer.
The certificate has expired

ah I see it’s not compiled for 4.3.5 nor 5.0

will there be an update please?

307

@hww,

Basically just a group with an average in an items file, where both temperatures are members of. Something like this:

Group:Number:AVG Temperature_AVG "Average Temperature"

But I worked around it by defining a regular item as the average temperature and use a rule to update that and calculate the average every time one of the temperatures changes.

I was just curious on why a group item, which looks exactly like a regular item in the console, wouldn’t work.

308

Hi-

Sorry, I’ve been away for a while… it looks like my automatic cert renewal was a bit behind schedule, though It looks like it did get renewed since you reported the problem.

I haven’t had a chance to look at openhab 5.0 yet, unfortunately I don’t get early notification of releases (it would be nice if there was a mailing list that made announcements like that). It’s possible that the binding for previous versions will work just fine; in most cases, the code of the binding itself doesn’t require changing as long as the dependencies used don’t cause compatibility problems.

I’ll look into getting a new version published, but it may be a few days before that happens. In the interim, you can try dropping the 4.3.x jar in your addons directory and see how it responds to that.

Bill

309

Hmm. I’ll try to remember to have a look at this when I’m digging into the core next. It seems like it should send change messages onto the bus which would be picked up by the binding.

Some background: The “B” in openhab means /bus/ and there is in fact a message bus at the core but it’s well hidden from users. Everything that happens is represented by a message on the bus and any change to an item should result in an Item State Change event. For example:

log:set TRACE openhab.event

log:tail

22:22:55.036 \[TRACE\] \[openhab.event.ItemStateChangedEvent  \] - Received event of type ‘ItemStateChangedEvent’ under the topic ‘openhab/items/SmartWeatherSky_SolarRadiation/statechanged’ with payload: ‘{“type”:“Quantity”,“value”:“26 W/m²”,“oldType”:“Quantity”,“oldValue”:“27 W/m²”}’
22:22:55.036 \[INFO \] \[openhab.event.ItemStateChangedEvent  \] - Item ‘SmartWeatherSky_SolarRadiation’ changed from 27 W/m² to 26 W/m²
22:22:55.826 \[TRACE\] \[openhab.event.RapidWindEvent         \] - Received event of type ‘RapidWindEvent’ under the topic ‘openhab/things/weatherflowsmartweather:sky:HB-00004550:SK-00011971/rapid_wind’ with payload: ‘{“bridgeUID”: “weatherflowsmartweather:hub:HB-00004550”, “thingUID”: “weatherflowsmartweather:sky:HB-00004550:SK-00011971”, “hubSerialNumber”: “HB-00004550”, “serialNumber”: “SK-00011971”, “epoch”: “2025-08-20T22:22:52Z”, “windDirection”: “0 °”, “windSpeed”: “0 m/s”}’
22:22:55.827 \[INFO \] \[openhab.event.RapidWindEvent         \] - Rapid Wind at ‘RapidWindData{bridgeUID=weatherflowsmartweather:hub:HB-00004550, thingUID=weatherflowsmartweather:sky:HB-00004550:SK-00011971, epoch=2025-08-20T22:22:52Z, windDirection=0 °, windSpeed=0 m/s}’.

log:set DEFAULT openhab.event
310

Don’t sweat about it. There’s probably a very small number of users who would want to do this, and as I said I just used the workaround of defining an item that holds the average and calculating that myself. So no real need to spend significant time on this.

Thanks!

311

Eventually I’ll find some time to look at this in depth, as it seems like it ought to work. I’m glad you found a workaround in the meantime!

312

I’ve uploaded versions of the binding compiled for 4.3.5 and 5.0.1. There are no binding code differences between these versions and previous releases, they’ve just been compiled against the dependencies of these newer versions. If you’ve got an older version that continues to work for you, feel free to continue using it.

If you run into any problems with these, please don’t hesitate to let me know. If things do work, let me know that as well, and I’ll work on updating the add-on store.

313

Thanks, Bill!

FYI, there’s still a problem with the certificate of your website.

WARNING: The certificate of ‘bill.welliver.org’ is not trusted.
WARNING: The certificate of ‘bill.welliver.org’ doesn't have a known issuer.

Also, I noticed the 5.0.1 package is almost twice the size compared to 5.0.0.M2. Are you aware and is that expected?

Thanks!

314

10-4.

The workaround was rather obvious, but still thanks for your effort!

315

Do you have the LetsEncrypt issuers in your trust store? The cert appears to be okay according to my web browser (Safari).

The 5.0.1 jar includes a number of ancillary files that aren’t in the milestone release. Suspect there was a change to the upstream pom rules between the milestone and release.

316

They should be there, need to see how I can check.

The system running OH isn’t my desktop computer, so I download with wget. But it’s a Debian Trixie system, so rather up-to-date since it was released just two weeks ago.

317

My Firefox has no problems with the certificate either.

318

Just tried it from my Windoze work computer and Chrome doesn’t like it, either:

net::ERR_CERT_AUTHORITY_INVALID

It does, however, accept my own let’s encrypt certificate I use for my webserver, so there’s definitively something amiss with Bill’s certificate.

No biggie, though, next time I just download with http instead of https.

319

What exact link are you trying? It’s not like my Firefox doesn’t complain if it thinks there’s an issue, so I find this very strange. I’d never run Chrome though (because privacy), so I have no experience with it.

320

Here’s me using Chromium:

image
image857×802 71.8 KB

321

https://bill.welliver.org/dist/openhab/

Firefox doesn’t like it either, but that may be because I’m on a corporate network right now.

322

This is really bizarre, could it be that your corporation manipulates the trust store and don’t trust LetsEncrypt?

Or, is this some other “stupid” thing like timezone/time differences? That can make certificates fail, but it shouldn’t result in claiming that the certificate authority is invalid.

Either way, I assume that your Debian installation is free from “corporate control”, so that doesn’t really explain it either.

323

I fired up an updated Fedora VM I have, and “finally”:

wget https://bill.welliver.org/dist/openhab/
ERROR: The certificate is NOT trusted. The certificate issuer is unknown.
Failed to connect: Certificate error

I don’t get why this is though, my Windows computer things the certificate is OK, but Fedora doesn’t…

curl says:

 curl -v https://bill.welliver.org/dist/openhab/
* Host bill.welliver.org:443 was resolved.
* IPv6: (none)
* IPv4: 192.99.78.190
*   Trying 192.99.78.190:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

edit: Could this be some TLS 1.2 vs 1.3 issue?

edit2: Nope:

 curl -v --tls-max 1.2 https://bill.welliver.org/dist/openhab/
* Host bill.welliver.org:443 was resolved.
* IPv6: (none)
* IPv4: 192.99.78.190
*   Trying 192.99.78.190:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
*  CApath: none
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

edit3: However, if I force TLS 1.3, the handshake itself fails. Is that “typical”/normal?

 curl -v --tlsv1.3 https://bill.welliver.org/dist/openhab/  * Host bill.welliver.org:443 was resolved.
* IPv6: (none)
* IPv4: 192.99.78.190
*   Trying 192.99.78.190:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
*  CApath: none
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure
* closing connection #0
curl: (35) TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure
324

Unlikely, as my own let’s encrypt certificate of my server at home is accepted.

Edit, for the record, this is what my server gives me:

* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1