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!
Thank you Kai! I am now running v 2.2 and everything is working so far. I will continue to test and share any feedback.
For others who might be unsure on how to switch, I documented the process here:
2 Likes
To late to submit a new binding for 2.2 I guess?
Considering the amount of bindings waiting for a review and merge, this would be unfair if you can get a merge in a week 
The IoT Marketplace is always open for submitting new bindings. 
I do wonder if there is a version compatibility check. People with OH 2.1 may end up with OH 2.2 only bindings and vice versa?
It appears that there is still a problem with the powerview binding. Please see
Problems with powerview - Could not set field value for field 'id': Can not set int field
Did you created an issue and tried to contact the author?
Merged!
Maybe a stupid answer, but I donāt know how.
The binding is maintained in the openhab2-addons repo on GitHub.
You can file the issue under this link:
All,
Dec 18 is coming closer and out latest distro #1140 can be regarded as a kind of release candidate - it is pretty stable in all my testing over the past days and no bigger changes will be done to it anymore.
All remaining work is on the add-on side, where we will still accept bugfix PRs today and tomorrow.
So Iād like to ask all of you that are anyhow already snapshot builds to update to build #1140 and report any severe issues that you encounter; if any binding that you use is completely broken for some reason, please flag this asap, so that there is still a chance to fix it!
Note that the offline āaddonsā kar support should work as well again, so please go testing this, if you used it in the past.
Thanks!
Kai
1 Like
@Kai : I just tested the new snapshot 1140 and the kar file. My feedback is positive. I have just encountered 1 issue which is apparently not new:
I am running the netatmo binding corresponding to the PR not yet merged. I will provide a feedback tomorrow morning. I hope this PR could be finally merged and included in the coming OH 2.2.
1 Like
I also just upgraded (as I did the rest of the week ), nothing relevant yet, tested / worked on some rules and other small things.
1 Like
Manual installation snapshot 1140:
with config files from snapshot #996 + adjustments in runtime.cfg
ui = paper,basic,habpanel
binding = ntp,sonos,weatherunderground,mqtt1,tcp1,caldav-command1
persistence = rrd4j
transformation = map,regex
remote = false
legacy = false
Startup effect:
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
After execute āulimit -c unlimitedā and reboot startup OK.
HABPANEL problem:
Image Widget
Static image URL: http://192.168.1.14:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=admin&pwd=123456 (Foscam C1, Firefox)
Refresh interval: 2 seconds
The old picture is deleted before the new one is displayed (-> results in flashing image)
With Snapshot #996 the picture is stable (not flushing at all)
/opt/openhab2/userdata/etc/shell.init.script
With snapshot #966 it was possible to put e.g.
log:tail-boot = { log:tail }
log:tail-boot
in the script file
wich executes log:tail after startup
this is no longer possible with #1140
is there another way to do this ?
Thanks for testing and reporting it would be great if you could report the HABPANEL problem at Issues Ā· openhab/org.openhab.ui.habpanel Ā· GitHub
Did you use the update script?
No, fresh install (unpack tar) and replace conf-folder with old one.
I jumped from S1137 to S1141 and I am testing things out.
So far, all works fine with:
bindings: 1x: knx,mqtt,weather, wol,networkupstools & 2x: zwave,samsungtv,astro,ntp,mpower,unifi
misc: homekit
actions: mail, pushover
persist: mapdb, influxdb
xform: json, map, regex
ui: basic, paper, habmin, habpanel
Main system on Debian 8 with Oracleās 1.8.0_151 JVM
Additional tests on Raspberry Pi3 & Windows hosts look good also so far.
Only 1 significant ussue for me:
When restarting openhab2 it starts up in a certain state with certain configured bindings. Any new binding added after that state does not get activated or installed after the restart. I need to enable/install these missing bindings through console after each reboot.
I am running the latest version op openhabian.