Closed just-jason closed 1 year ago
Hi,
many thanks for your request.
For reference, the already open FeatHub request's https://feathub.com/MichaIng/DietPi/+96 EDIT: REMOVED OBSOLETE LINKS
Great, I will close this then
It is good to have a GitHub issue opened as well. There was already one but let's keep the new one: #1117 I can't somehow access FeatHub right now but will link this GitHub issue there once I can.
Hmm, will check if I can somehow merge those two FeatHub requests. Hmm, generally there is a lack of development on that platform, code is not on GitHub (anymore), all empty: https://github.com/feathub Looks like we need to migrate to a new platform for such polls. I'd go with a self-hosted solution on our website but we need a guarantee that each person can only vote once per request and GitHub authentication seems a relatively reliable method which I don't know how to implement. Ah going off topic... 😅.
Found this guide on the web https://levelup.gitconnected.com/how-to-implement-login-with-github-in-a-react-app-bd3d704c64fc
Hello
has there been any movement on this feature request?
I'm happy to provide the command lines to install openhab on any Linux system, as shown on this how-to page
https://www.openhab.org/docs/installation/linux.html
Essentailly, this is all that is needed
wget -qO - 'https://openhab.jfrog.io/artifactory/api/gpg/key/public' | sudo apt-key add -
apt install apt-transport-https
echo 'deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main' | sudo tee /etc/apt/sources.list.d/openhab.list
apt update
apt install openhab
systemctl enable openhab --now
It will then be accessible on ports 8080 or 8443
FYI It can happily co-exist with Home-Assistant. even sharing a connection to a Velbus hardware network via a TCP connection.
I'm happy to test and report as required.
Currently, I install almost everything via the DietPi Software menu, with the exception of openHAB and Velbus-tcp
I have written a tiny script to install and configure the velbus-tcp snap package
Can those ports be changed? As we have many software options which use (or would use) these ports already, do avoid port conflicts, we'd need to change them.
apt install apt-transport-https
Skip that. Since Debian Buster, this is a transitional dummy package only, as HTTPS support is natively integrated into APT.
Hi Michalng
Can those ports be changed?
In theory yes, just a matter of editing the configuration file and restarting openhab.
https://www.openhab.org/docs/installation/security.html#webserver-ports
In the top section of this file
/etc/default/openhab
# openHAB service options
#########################
## PORTS
## The ports openHAB will bind its HTTP/HTTPS web server to.
#OPENHAB_HTTP_PORT=8080
#OPENHAB_HTTPS_PORT=8443
#########################
## HTTP(S) LISTEN ADDRESS
## The listen address used by the HTTP(S) server.
## 0.0.0.0 (default) allows a connection from any location
## 127.0.0.1 only allows the local machine to connect
#OPENHAB_HTTP_ADDRESS=0.0.0.0
I assume you have magic code for doing this?
You would have to make an announcement at the end of the setup about it being on non-standard
ports, but I don't suppose that is a big deal
apt install apt-transport-https
Skip that. Since Debian Buster, this is a transitional dummy package only, as HTTPS support is natively integrated into APT.
Right, I'll see if I can pass that comment to the openHAB Wiki editor
A minor detail as I think DietPi pulls down Java11 anyway, but if not, it's worth noting that openHAB now only works on Java 11
it's worth noting that openHAB now only works on Java 11
That's a problem as it does not work with the current default Debian Bullseye Java version (17) then 🤔. We are however switching to Adoptium Temurin Java most likely, to make e.g. newer Minecraft versions run on Debian Buster. This would mean that multiple Java versions can be installed concurrently, based on the installed software needs, which makes everything much more flexible. Only ARMv6 (RPi1 and Zero) do not support those Java builds, but only Raspbian's OpenJDK 8 package.
Debian Bullseye Java version (17) that's odd
My Odroid C4 is showing as having
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Debian-2deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.12+7-post-Debian-2deb10u1, mixed mode)
Let me know how to upgrade the java to the version you want to deploy and I'll run openHAB against it
As long as you did not manually upgrade, the Odroid runs a Debian Buster, so Java 11 is expected there. It can also be installed on Bullseye, but dietpi-software
currently then installs Java 17:
apt install openjdk-17-jre-headless
As long as you did not manually upgrade, the Odroid runs a Debian Buster, so Java 11 is expected there. It can also be installed on Bullseye, but
dietpi-software
currently then installs Java 17:apt install openjdk-17-jre-headless
Hold on, I'll fire up brand new machine and see what has been installed
(I try to do as much as possible from your software menu, so that anyone coming to the machine after me knows where to go)
Ummm
This again
This has been happening on two new machines.
(this time, I simply tried dietpi-software reinstall 8` to see what happens to the Java version.)
APT update
│ - Command: apt-get --allow-releaseinfo-change-suite -q update
│ - Exit code: 100
│ - DietPi version: v7.5.2 (MichaIng/master) | HW_MODEL: 16 | HW_ARCH: 3 | DISTRO: 5
│ - Image creator: DietPi Core Team
│ - Pre-image: Meveric
│ - Error log:
│ Hit:1 https://deb.debian.org/debian buster InRelease
│ Hit:2 https://deb.debian.org/debian buster-updates InRelease
│ Hit:3 https://deb.debian.org/debian-security buster/updates InRelease
│ Hit:4 https://deb.debian.org/debian buster-backports InRelease
│ Get:5 https://dietpi.com/meveric all InRelease [19.4 kB]
│ Hit:6 https://dietpi.com/meveric buster InRelease
│ Hit:7 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InRelease
│ Get:8 https://dietpi.com/meveric all/main arm64 Packages [15.9 kB]
│ Err:8 https://dietpi.com/meveric all/main arm64 Packages
│ File has unexpected size (15477 != 15901). Mirror sync in progress? [IP: 172.67.192.224 443]
│ Hashes of expected file:
│ - Filesize:15901 [weak]
│ - SHA256:aee12cd5a2808aef6aabb46b05bd9660b01202ebaaced9a789e7b29328663eca
│ - SHA1:423012323a735496d56d93604af811652a8bb740 [weak]
│ - MD5Sum:9da2f94d761eb1d282254c1244f825d0 [weak]
│ Release file created at: Wed, 08 Sep 2021 06:44:35 +0000
│ Fetched 19.4 kB in 2s (9427 B/s)
│ Reading package lists...
│ E: Failed to fetch https://dietpi.com/meveric/dists/all/main/binary-arm64/Packages.gz File has unexpected size
│ (15477 != 15901). Mirror sync in progress? [IP: 172.67.192.224 443]
Specifically, this section keeps blocking any progress
Err:8 https://dietpi.com/meveric all/main arm64 Packages
File has unexpected size (15477 != 15901). Mirror sync in progress? [IP: 172.67.192.224 443]
Hashes of expected file:
- Filesize:15901 [weak]
- SHA256:aee12cd5a2808aef6aabb46b05bd9660b01202ebaaced9a789e7b29328663eca
- SHA1:423012323a735496d56d93604af811652a8bb740 [weak]
- MD5Sum:9da2f94d761eb1d282254c1244f825d0 [weak]
Release file created at: Wed, 08 Sep 2021 06:44:35 +0000
Is this article of any use? https://askubuntu.com/questions/1147254/apt-update-fails-at-chrome-stable-main-file-has-unexpected-size-1103-1104
Or is there something I need to be doing?
Can I or even should I do anything in this folder?
/var/lib/apt/lists
I did download a fresh DietPi image for C4 yesterday and try that, but it was exactly the same. In fact, it wouldn't pass the initial setup stage
I just resynced the mirror and removed that file from the Cloudflare cache. Interestingly, gz
and even to my happiness 7z
files are now cached by Cloudflare by default, which was not the case before on free plan: https://developers.cloudflare.com/cache/about/default-cache-behavior
I tried to disable it by setting the cache-control: no-cache
header for these particular packages.gz
files. While it works on a direct access, an access via Cloudflare still gives me the cache-control: public, max-age=31536000
that was set before. Probably it takes a while until it is synced. However, APT should ignore the cache control header, only the Cloudflare cache was an issue here, which shouldn't be done anymore now, that our server sends cache-control: no-cache
. Please try again.
Note that our current Odroid images are not yet migrated to Bullseye, so if you want to test it with Java 17 on an Odroid, you need to upgrade manually: https://dietpi.com/blog/?p=811#2.2-manual-upgrade
I just resynced the mirror and removed that file from the Cloudflare cache
Yep that has fixed it 😄
I'll see what happens now when I try to re-install Java
Note that our current Odroid images are not yet migrated to Bullseye, so if you want to test it with Java 17 on an Odroid, you need to upgrade manually: https://dietpi.com/blog/?p=811#2.2-manual-upgrade
Arrr, right.
What would you suggest?
or rather, what do you want me to do, in order to assist in getting openHAB into the menu?
Indeed....
Odorid C4, shows only Java 11
DietPi-Software
─────────────────────────────────────────────────────
Mode: Installing Java JRE: OpenJDK Runtime Environment
[ INFO ] DietPi-Software | APT install for: ca-certificates-java openjdk-11-jre-headless, please wait... (1/2)
[ OK ] DietPi-Software | APT install for: ca-certificates-java openjdk-11-jre-headless
DietPi-Software
─────────────────────────────────────────────────────
Mode: Installing Java JDK: OpenJDK Development Kit
[ INFO ] DietPi-Software | APT install for: openjdk-11-jdk-headless, please wait...
[ OK ] DietPi-Software | APT install for: openjdk-11-jdk-headless
[ SUB1 ] DietPi-Services > stop
[ OK ] DietPi-Services | stop : cron
[ OK ] DietPi-Services | stop : node-red
[ OK ] DietPi-Services | stop : smbd
[ OK ] DietPi-Services | stop : nmbd
[ OK ] DietPi-Software | systemctl daemon-reload
[ SUB1 ] DietPi-Services > dietpi_controlled
[ OK ] DietPi-Services | dietpi_controlled : nmbd
[ OK ] DietPi-Services | dietpi_controlled : smbd
[ OK ] DietPi-Services | dietpi_controlled : node-red
[ OK ] DietPi-Services | dietpi_controlled : cron
DietPi-Software
─────────────────────────────────────────────────────
Mode: Installation completed
[ OK ] DietPi-Survey | Sending survey data
[ SUB1 ] DietPi-Services > restart
[ OK ] DietPi-Services | restart : nmbd
[ OK ] DietPi-Services | restart : smbd
[ OK ] DietPi-Services | restart : node-red
[ OK ] DietPi-Services | restart : cron
root@openHAB2-C4:~# echo $G_DISTRO_NAME
buster
What do you suggest I do?
If you have time, upgrading via linked guide to Bullseye and then testing openHAB with Java 17 would be nice. But probably it is faster to check the docs, ask them or checking the GitHub repo: https://github.com/openhab/openhab-core It actually states quite clearly everywhere that Java 11 is required, not "Java 11 or up", so more interesting would be then if there is any work done to support newer Java versions.
However, I personally will implement a fix for Minecraft first anyway, hence a multi Java version support, so afterwards that question is not so important anymore. And then openHAB is the highest rated software title on FeatHub counting the duplicating two open requests for it + it is comfortable to implement with the APT repository. So yep, I'll start with this at latest with next development cycle for DietPi v7.7.
However, I personally will implement a fix for Minecraft first anyway, hence a multi Java version support, so afterwards that question is not so important anymore. And then openHAB is the highest rated software title on FeatHub
Arr, right.
If I get time tomorrow I'll take a fresh image and update it, but as you say, if you add support for multi JAVA versions, it cesses to be an issue.
And you can force the JAVA versions in the /etc/default/openhab
file
And you can force the JAVA versions in the /etc/default/openhab file
You mean the Java binary? That is good. I'd otherwise have created a systemd unit override to hack the correct binary inside, but that makes it easier.
I believe I do (given that I'm no expert in these matters)
The start of the /etc/default/openhab
file looks like this
# openHAB service options
#########################
## PORTS
## The ports openHAB will bind its HTTP/HTTPS web server to.
#OPENHAB_HTTP_PORT=8080
#OPENHAB_HTTPS_PORT=8443
#########################
## HTTP(S) LISTEN ADDRESS
## The listen address used by the HTTP(S) server.
## 0.0.0.0 (default) allows a connection from any location
## 127.0.0.1 only allows the local machine to connect
#OPENHAB_HTTP_ADDRESS=0.0.0.0
#########################
## BACKUP DIRECTORY
## Set the following variable to specify the backup location.
## runtime/bin/backup and runtime/bin/restore will use this path for the zip files.
#OPENHAB_BACKUPS=/var/lib/openhab/backups
#########################
## JAVA OPTIONS
## Additional options for the JAVA_OPTS environment variable.
## These will be appended to the execution of the openHAB Java runtime in front of all other options.
##
## A couple of independent examples:
## EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyZWAVE:/dev/ttyUSB0:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0"
## EXTRA_JAVA_OPTS="-Djna.library.path=/lib/arm-linux-gnueabihf/ -Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyZWave"
EXTRA_JAVA_OPTS=""
Maybe I'm wrong??
If I get time tomorrow I'll take a fresh image and update it
@MichaIng
It looks (to the untrained eye) that openHAB fails to load when JAVA 17 is in play.
https://community.openhab.org/t/openhab-3-2-milestone-discussion/125097/18
And the official answer from the team is that openHAB only works with Java 11
https://community.openhab.org/t/openhab-and-future-jdk-versions-when/65572/36
which begs the question...
"How do I roll back Java to Version 11 with Bullseye?"
Or should I just flash the emmc with my Buster Image?
Its okay, this line seems to have done the trick
(openjdk-11 was still installed)
apt remove openjdk-17*
On Bullseye you can still install it manually (if not the case already):
apt install openjdk-11-jre-headless
apt purge --autoremove openjdk-17-jre-headless
Get used to use purge
instead of remove
to have related configuration and "variable" data files removed as well 😉. remove
only makes sense when you plan to install the same package again and want to keep its configuration and possibly created data.
@MichaIng
It would seem that people are working on getting openHAB to work on Java 17.
https://github.com/openhab/openhab-distro/issues/1316
Does this impact your plans to add openHAB to the DietPi software menu? (Or do you still think that being able to specify which Java version to use for each bit of software is the best way forward?)
Thanks from all of us openHAB users.
Regards, Stuart
Great to see. Yes that makes it easier to implement on Bullseye 👍.
Gonna implement this with next release. Was the by far highest voted software request on FeatHub, so let's not forget about it. Seems to be quite easy to implement via APT repo: https://www.openhab.org/docs/installation/linux.html#package-repository-installation And since it's Java, it is generally platform-independent. Java 17 has there as well.
Gonna implement this with next release. Was the by far highest voted software request on FeatHub, so let's not forget about it. Seems to be quite easy to implement via APT repo: https://www.openhab.org/docs/installation/linux.html#package-repository-installation And since it's Java, it is generally platform-independent. Java 17 has there as well.
Amazing news, thanks Michal.
If you're putting openHAB V4 in the menu, I understand that now uses Java17 🥳
I have a couple of fresh Odroid machines coming my way, so happy to test whatever you want.
PR up: #6334
Creating a software request
Formal software information
Are there similar/alternative software titles available with DietPi-Software?
Yes- Home Assistant
What makes your requested software better than the above solutions, if available?
I dont think it is better, but there are people who use open hab and there people who use home assistant
How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?
According to the official install instructions there are a several manual steps to do: DietPi could automate those steps, which saves end users a lot of time and allows installation as well to less experienced Linux users.
Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.?
I do not think I could .