Thanks @mhilbush, I agree, we should make sure that we don’t have such annoying log messages. I’ll wait what @sjka might be able to solve in short term - all the rest, which doesn’t really mean any bug, I will try to then change the log level configuration in a way that those messages are suppressed.
1 Like
2.534 kilograms
2 Likes
Thanks to all contributors for their effort.
@ganesh.ingle
Think about what you are requesting. OH does consist of a large number of bindings (amongst other parts…) , which are build by a large number of volunteers. Each new release has an number of new bindings comung with it.
Asking the maintainers to test all of them in depth, would require them to buy the devices that make use of those bindings. Such a requirement in an open source project is impossible, we would loose all volunteers, especially the maintainers!
And this is only one aspect to think about when requesting such testing.
I’m happy with the way new “stable” releases are published!
1 Like
@Kai How do the release cycles of ESH and OH 2.2 relate to each other and what does this mean regarding getting issues fixed for the 2.2 release now that there is a ESH 0.9.0 release?
1 Like
There is a topic on this, not decisive though…
My plan was to use the 0.9.0 ESH release in openHAB 2.2, but as there are already important fixes in post-0.9.0 now, I will create an ESH 0.10.0.b1 for the final openHAB release - so no worries, it isn’t yet too late for fixes in ESH!
1 Like
It’s nice to still have the possibility to fix things!
But having ESH inside openHAB is like having Rolls Royce engines in your private dreamliner jet! 
1 Like
ESH has not only many contributions from openHAB side.
The initial ESH project is based on openHAB and was splitted from the “old” openHAB on purpose in 2013.
Further information can be found in the proposal:
https://www.eclipse.org/proposals/technology.smarthome/
You seem to have very little knowledge about ESH. Don’t know where you got those stats from, but my rough estimation is that openHAB contributions to ESH (including my own) do not exceed 20% of the work that is done at ESH.
5 Likes
Currently i’m using the 2.2 Snapshot, almost everything works as expected.
Thanks to everybody involved.
What about after the 2.2 release?
Should i switch to the stable branch?
Will there be still bugfixes in the stable branch or is this an exclusive of the snapshot?
2 Likes
People are tracking this thread because it’s supposed to be about the 2.2 release. Your comments here, while interesting, are off topic.
I respectfully ask that you open a separate forum thread for discussing your topic. Thanks!
4 Likes
Is there a corresponding ESH 0.9 (or the beta version that will be included with 2.2) draft release notes? One thing that popped up on me recently, that is not really a breaking change but may raise concerns, is the deprecation of DateTimeType.calendar. I was recently surprised when I started seeing a lot of these validation issues in my logs when saving rules that use .calendar…
The method getCalendar() from the type DateTimeType is deprecated
It would be helpful if the ESH documentation would include alternatives for .calendar and .getCalendar.
This is great! Nice work all!
How does one go about switching versions?
Is there a link with steps?
I have some issues with groups needing a OH restart to populate changes. Are u guys aware if this might be addressed in the 2.2 release? Thanks
- Will there again be upgrade scripts for manual installations? (see OH 2.1 release notes)
- There should also be a note about breaking changes in logging configuration. (see Karaf Upgrade)
- It would be also helpful to tell users running OH 2.0 (and may be even 1.x) what to do, e.g. refer to previous release notes or start from scratch.
Is there a corresponding ESH 0.9 (or the beta version that will be included with 2.2) draft release notes?
No, we should add such stuff to the openHAB release notes.
I was recently surprised when I started seeing a lot of these validation issues
That’s a good point. Yes, it probably should be mentioned - I tried to do so here. Not sure if this has any further impacts; if so, feel free to amend the wiki page.
That depends on how you installed it. If it is a manual installation, simply get the latest snapshot from here. If you use APT, check out the docs on how to switch the apt repo that is used.
I have some issues with groups needing a OH restart to populate changes.
@waitz_sebastian There was a fix on that about a month ago. If you see critical issues still on the latest snapshots, please let me know, I am not aware of any.
We have the upgrade script in place since early this year (runtime/bin/update) - is that what you are looking for? The info still needs to be added to the release notes though.
There should also be a note about breaking changes in logging configuration. (see Karaf Upgrade)
Right, but the note might depend on the outcome of this issue. But yes, definitely something that needs to be mentioned. Feel free to add it to the wiki page yourself!
It would be also helpful to tell users running OH 2.0 (and may be even 1.x) what to do, e.g. refer to previous release notes or start from scratch.
Yes, the two choices you mention are probably the best advice we could give. Can you add something to the wiki on that? Thanks!