I see that V3.0.2 has been released … and replaces bintray with artifactory.
If I want to install 3.0.1 - what do change in these instructions ???
This sort of request really is awkward for developers to answer and support, and likely to result in problems in the future because.
It’s more than hard to keep full track and ensure that all combinations of code, branches, repos, versions etc. will work with each other, but guaranteeing this over time (as you implicitly expect us to) is even harder.
So please just don’t and go straight to 3.0.2.
I would love to go to 3.0.2 but a number of things broke for me with the upgrade from 3.0.1
- Exec a host script from the UI
- Using a script to do a REST update of a Point
I saw nothing of value in the log files (no errors) and don’t have time now to chase down the cause. Downgrading to 3.0.1 instantly fixed everything.
BTW - found a way to install 3.0.1 (in case others have issues with 3.0.2
wget -O /data/oh.deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg/pool/main/3.0.1/openhab_3.0.1-2_all.deb
apt install /data/oh.deb
rm /data/oh.deb
If you use 3.0.1 you will not be able to install any bindings after May 1 due to upstream changes. That was the main reason for the 3.0.2 release.
I’d doubt these have changed as 3.0.2 is just a bugfix release so it is more likely to be about your configuration. Either way you should take the time to investigate, plus prepare a fallback plan for your next upgrade.
That’s not correct. The source to dynamically download from changes but there’s means to deal with that other than an upgrade, too. See the announcement.
1 Like
So if they downgrade they should install the kar file too.
Guys:
Seems all my problems trying to install V3.0.2 are related to a ‘known’ bug with apt-transport-https on some arm hardware. I am using arm (but not Raspi)
Google for : armhf Method /usr/lib/apt/methods/https did not start correctly
Seems there is a bug (segfaults are bad). And the new repos are stored on Artifactory … which does not allow http:// downloads (unlike bintray) so I can’t work around the bug.
OK … so to Plan B.
I successfully installed V3.0.2 using the MANUAL install instructions here:
So far so good. The service starts, and I can get to it via http://ip_address:8080
But … that does not do these 2 important things
- cause these OPENHAB_* environment variables to be created
OPENHAB_BACKUPS=/var/lib/openhab/backups
OPENHAB_CONF=/etc/openhab
OPENHAB_GROUP=openhab
OPENHAB_HOME=/usr/share/openhab
OPENHAB_HTTPS_PORT=8443
OPENHAB_HTTP_PORT=8080
OPENHAB_LOGDIR=/var/log/openhab
OPENHAB_RUNTIME=/usr/share/openhab/runtime
OPENHAB_USER=openhab
OPENHAB_USERDATA=/var/lib/openhab
- install /usr/bin/openhab-cli
- And ?? who knows what else.
I copied /usr/bin/openhab-cli from a 3.0.1 installation … but it needs the OPENHAB_* env variables to be setup.
What do you guys suggest to get openhab-cli & the environment variables working - as in an apt installation?
The apt file profids a file /etc/profile.d/openhab.sh that is sourced for all users.
Within the file first override settings from /etc/default/openhab are checked. Variables that are still unset are set within this file then.
I suspect the code for 3.0.1 is still there on bintray until they shut it down on May 1.
Grab the addons too so you add bindings after May 1.
Well a top notch reason / proof it’s better to move over to openHABian on Raspi, isn’t it ?
Simply because so many more users use that combo so way more issues have been found and fixed upfront than on more exotic platforms like yours. Feel free to continue using your box as a playground but for a production system I’d always go with the mainstream.