Not everyone has the time or patience to read through thousands of posts to discover that a quite convenient (not matter how buggy) feature was removed.
3 Likes
That is one reason many people try to keep reasonably up to date on versions.
I remember one system I worked on, whenever I had a problem the first thing I would do is update to the latest patches & verify if the issue was still there. If I called paid support that is the first thing they would tell me anyway before helping further.
EDIT: Others that wait a long time just rebuild from scratch, duplicating their old setup.
1 Like
Yes, but we do speak of an unstable branch, don’t we?
This would be the place to discuss experiences with it, but don’t expect support on specific not yet final documented behaviour outside dev-channels… or did I miss something?
1 Like
Perhaps you can help others; where did you look, that you would expect this to be noted?
2 Likes
Meaning: others must do that so you don’t have to ?
It’s nowhere near “thousands of posts”. And to read the release notes and spend at least some time on a quick browse or search on the forum before you upgrade is a thing that can be expected from any user.
Even more so as we talk about a free product.
4 Likes
Hey guys, relax, please!
Yes, users clearly cannot follow the details of the many discussions that are going on here and developers don’t have the time and breath to do fully complete summaries and up-to-date documentation, especially for unreleased versions.
So let’s show understanding for each other and work together on improving the situation.
I have created https://github.com/openhab/openhab-distro/wiki/Breaking-Changes-in-openHAB-3 as a temporary place to gather the most relevant information - if all of us help keeping that list up to date (so yes, everyone has write access and is invited to help on it!), we should have a pretty complete and helpful list together by the time of the openHAB 3 release!
28 Likes
How is it going the time schedule??? Are you on track?? When is the release date planned like late December or early??
Hope and plan is to release just before Christmas, like the last years. Let’s see how work proceeds.
M2 is coming very soon.
6 Likes
@Kai Could you tell us a little bit about feature not implemented yet? I think everyone is keen to see the feature comming latest under the xmas tree.
What I see is that the main activity is to fix few remaining regressions (chart/persistence/rule for example) and to fix/improve the new main UI.
1 Like
What do you mean with it got removed? Its still there (in the docs).
As you can see… It says its no longer supported and considered deprecated. But its not removed!
This would be the first and most obvious place to start making changes, if its suppose to be removed! (my personal opinion).
This is openHAB 2.x Docs, not openHAB 3
Correct.
I have no knowlegde on OH3 and its docs, as its not released official, as far as I know.
Atm this is the only docs available for Mosquette. It does not mention anything about OH3. But it do mention is will be removed. Perhaps its time to get rid of it for good, (including for next OH2 update, as it will make it more clear to everyone, its gone. And then add it to the release notes of OH2). Noone will expect it to show up in OH3 by the time OH3 is official released.
Just my suggestion.
There’s no need to remove deprecated service from OH2.x, purely for the point of breaking stuff.
It’s not present in OH3.x, and it seems this will get highlighted in the release notes.
End.
4 Likes
I run 3.0.0-SNAPSHOT - Build #1995 since a few days, and I noticed that persistence (rrd4j in particular) is now storing UoM instead of raw values. Is this by design?
For example,
.Items:
Number SpeedtestResultDown "Downlink [%.2f Mbit/s]" (gSpeedtest)
with SpeedtestResultDown being updated in a .rule
var float down = Float::parseFloat(transform("JSONPATH", "$.download.bandwidth", speedtestCliOutput)) * 7.629395E-6 SpeedtestResultDown.postUpdate(down)
results in
{“time”:1604406240000,“state”:“742.85215745724 Mbit/s”},{“time”:1604406300000,“state”:“742.85215745724 Mbit/s”},{“time”:1604406360000,“state”:“742.85215745724 Mbit/s”},
That is correct, here aus a links to the Github Documentation.
In short , rrd4j dies have the defaults, ohne for pure numericals, one for numbers with a dimension and one for others (switch… ).
In order to keep the old data, which was saved in a default setup, one has to create a custom database using the old default setup.
For those that rely on https://www.openhab.org/docs/installation/security.html#nginx-setup to secure their installation, and do not use myopenhab.org to remotely access their installation, need to alter the Nginx server configuration to include a
proxy_set_header Authorization "";
to clear out the Basic Auth token in order to make the iOS app work again.
@Kai on a separate note, and this goes back to a discussion we had a long time ago (https://github.com/openhab/openhab-distro/issues/312), IMO, partly securing openHAB (e.g. only /rest) does not make sense. I would prefer to revive https://github.com/eclipse-archived/smarthome/issues/4088, so that most people can get rid of nginx (e.g. most only use Nginx to secure their installation with Basic Auth / .httpasswd entries)
@opus, sure there is this difference, but it does not explain why UoM are stored in the database. As far I understand the documentation, the difference relates the averaging of values.
For those that rely on https://www.openhab.org/docs/installation/security.html#nginx-setup to secure their installation, and do not use myopenhab.org to remotely access their installation, need to alter the Nginx server configuration to include a
proxy_set_header Authorization “”;
to clear out the Basic Auth token in order to make the iOS app work again.
Does this still apply on Milestone 2? There is now Basic Auth for the API, at least.
hmm, but that is not a Quantity Type of Item. Is your rule posting a quantity type value to it? (see your events.log)
This is a bit of a funny situation.
It has been possible to post Quantities like “2.5 Mbit/s” to plain Numbers in OH2. But that does not make the Item a true Quantity Type. You cannot auto-convert to kbit/s for example. You can have another rule posting “13 km” to the same Number later, without error.
While we all want persistence to store (and retrieve) e.g. Number:Length as a Quantity Type, I’m not sure about this case.
It’s arguable that Number types should ignore units, because they are not properly functional.
It’s just as arguable that it’s none of persistence business, just store what you are given. That might bring surprises when persistence retrieves a Quantity with units and you expected a Number.
Maybe the underlying issue is that posting Quantities to plain Numbers should not be permitted.
Comments?