A suggestion: in OpenHAB1 it was possible to keep the local installation static (i.e. by NOT upgrading it automatically with apt-get) by setting “deb https://dl.bintray.com/openhab/apt-repo 1.8.3 main” in the apt-sources.list directory.
In OpenHAB2 this is currently not possible, since there is only the “stable” directory-tree available.
I suggest that for OpenHAB2 the versions get a version specific distribution. Why? Because the upgrade von 2.0.0 to 2.1.0 (by using the “stable” target) is not just a small minor version change but requires a lot of additional work in the rules and especially broke the astro1 binding…
This change makes it much more easy to keep OpenHAB2 static when upgrading a Raspi with apt-get.
I am aware of apt-mark, but I consider it as “more complicated”, because apt-upgrade will always tell you about the packages hold back. The method of keeping OpenHAB1 versions static was well introduced, documented and worked, why change this to something different??
Anyway… I personally didn’t have any issues with my rules when i did the upgrade from 2.0 to 2.1
I use the astro 2.x binding and all is fine with that also.
Is there an issue raised for the astro1 on OH2.1?
There seem to exist a few problems with 2.1, when reading the forum…
I started with 1.8.3 nearly two years ago, mostly for using a lot of heating rules to control (via Homegear) several Homematic Radiator Thermostats. Some other data is added via REST-API by cron-scripts, MQTT is used for owntracks.
Upgrading to 2.0 took some time, rewriting some rules and tweaking syntax. Some difficulties with astro1 binding and action, all got resolved.
Upgrading to 2.1 resulted in a lot of error messages in the log, astro1 binding messages, and data not get filled up (zodiac etc.). But I just learned that probably I had to clean the cache and tmp directories in /var/lib/openhab2 (I didn’t know that). So I went back to 2.0 and will analyse the upgrade in a few weeks… Currently I have not enough time to find out what happens here.
