Yes, it uses TLS 1.3 “all the way”, while it seems that when using Bill’s server, the connection is downgraded to TLS 1.2. I have a sneaking suspicion that this might be related. Maybe somebody has decided that TLS 1.2 is now “unsafe” and will no longer be accepted in certain software/OS’es?
edit: From Google:
TLS 1.2 has not been completely deprecated, but it is being retired by some organizations in favor of the newer and more secure TLS 1.3. While TLS 1.0 and 1.1 are fully deprecated due to security vulnerabilities, TLS 1.2 can still be considered safe if weak cipher suites and algorithms are removed. However, many companies and operating systems are moving towards complete TLS 1.2 deprecation to ensure the highest levels of digital security and to prepare for widespread TLS 1.3 adoption.
I think this “smells of” TLS 1.2 deprecation from “somebody”, somewhere.
Apparently not “somebody”, but major Linux distributions. Since my Debian 13 (and Debian 12 before that) and your Fedora VM show the same behavior, that’s likely. And your Windows-Firefox just still accepts that, whereas my corporate chrome/firefox does not, likely on a firewall level.
It’s just a theory, I’m not convinced yet. I found a Mint VM that hasn’t been updated in a long time (Mint 18.3, support ended in 2021), it seems to use TLS 1.2 by default, but it still fails:
curl -v https://bill.welliver.org/dist/openhab/ * Trying 192.99.78.190...
* Connected to bill.welliver.org (192.99.78.190) port 443 (#0)
* found 129 certificates in /etc/ssl/certs/ca-certificates.crt
* found 528 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
I’m a bit out of ideas, it’s hard to troubleshoot this as we don’t really get a lot of information about these failures. But, something makes some installations accept the certificate and others reject it.
My first action would be to try to update the server software that runs the server. It might or might not be related to TLS 1.3, but it could easily be something else that is rejected by something somewhere in the chain because of “outdated” defaults or similar.
I think I figured out the problem: it seems the “intermediate” certificate provided by the web server was incorrect. In this case, “R3” instead of “R11”. The Let’s Encrypt machinery is supposed to manage that, but it seems like it didn’t handle that update properly. I don’t quite understand why Windows and Mac clients were happy and others were not. Perhaps tools built on openssl are more literal and Safari/etc knew about R11 independently and just ignored R3 to calculate the trust situation? Troubleshooting these SSL/TLS can be very frustrating because the error messages provided almost never include the detail required to figure out what’s actually wrong… ya gotta go digging.
Anyway, I think the problem should be resolved now, hopefully permanently! Sorry for any confusion and wasted time this caused.
I just know I’ve been doing a manual install since forever. It’s not that difficult, just go into /usr/share/openhab/addons/ and pull it off Bill’s site with wget.
did you happen to change anything regarding the pressure trend? It’s really not very important, but I noticed that OH shows that up as “Err”.
Digging into it, it’s still a string channel, but shows “0”: (Type=StringItem, State=0)
I think we’ve talked about that a while ago (although I can’t find the conversation), and you’ve stated that internally the state gets represented as numbers vom -2 to +2 but is then changed to a string somewhere. I actually use that number to string conversion in the code for my weather display (exporting the item to mqtt). I’ve even found a source code snippet (didn’t you have that on Github somewhere?)
I haven’t made any changes to the pressure trend code (though I’ve had a few thoughts about improving its behavior).
You’re correct: the trend is handled internally as a set of values from -2 to +2 and the UI converts that number to a description. I’m not sure I’ve ever seen it show an error, usually the value in the UI is “-” until there’s data to present, but I think that’s just how openhab displays values for items that don’t have a value yet.
It’s been a while since I looked at the details, but I think in order for openhab to display a mapped string value, the internal value has to be a string as well. At the time it wasn’t possible to express the set of mappings as numbers and have the value mapping actually work (that is, to openhab, the integer 1 is not the same as the string “1”, so the transformation from a number would never match anything and it would just pass the number through. It’s been a few years, so it’s possible that has changed since then.
The source for that mapping is here:
If I get some time, I’ll try to see if that situation still exists, but it might not happen right away. The other potential problem is that switching to a number value would be a compatibility problem for existing users. I think that could be solved by keeping the existing channel as-is adding a new channel with the value expressed as a number, so people could use either. Happy to hear opinions on that approach.
Hi- Sorry for the delay in responding… it turns out both of my pressure sensors had blown out and needed to be replaced (that seems to be an ongoing problem here).
So, my installation displays “0”, etc in karaf, but the “Steady”, etc in the various UIs. I am fairly certain that at least one point (perhaps as long ago as OpenHAB 2.x), Karaf displayed “Steady”, etc as well.
I will try to find some time to add new channels that are Numbers rather than Strings for all of the current channels that use Strings to store numerical values. I’ll post back here when that’s ready to go.
Wow, you’re trying to measure air pressure on Jupiter or something?
But I agree, I, too, remember that at some point the String item in Karaf reported “Steady”, etc. Else I would have wondered back then why a String item only contains a number.
But a MAP file works fine converting the number back to the usual string, FYI.
Yes, there’s definitely been changes in the way the whole mapping and display of values works, not all of it’s been documented so there’s been a certain amount of fumbling around in the dark here.
I’ll add a new item that uses a number for folks that works better with leaving the existing items unchanged for compatibility. Might happen this week; I’ll pose here when it’s ready to test. Thanks for your patience here!
