Try if uninstall/reinstall works now. You had a premature version installed, that’s why.
Done:
It works now:
$ sudo openhabian-config
2020-10-20_10:11:24_CEST [openHABian] Checking for root privileges... OK
2020-10-20_10:11:25_CEST [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2020-10-20_10:11:25_CEST [openHABian] openHABian configuration tool version: [stable]v1.6-880(769ea17)
2020-10-20_10:11:25_CEST [openHABian] Checking for changes in origin branch HEAD... OK
2020-10-20_10:11:28_CEST [openHABian] Switching to branch stable... OK
2020-10-20_10:11:34_CEST [openHABian] Updating Linux package information... OK
2020-10-20_10:11:56_CEST [openHABian] Removing ZRAM service...
$ systemctl disable --now zram-config.service zramsync.service
Removed /etc/systemd/system/basic.target.wants/zram-config.service.
Removed /etc/systemd/system/basic.target.wants/zramsync.service.
$ rm -f /etc/systemd/system/zram-config.service /etc/systemd/system/zramsync.service
$ systemctl unmask unattended-upgrades.service
Removed /etc/systemd/system/unattended-upgrades.service.
OK
2020-10-20_10:12:10_CEST [openHABian] Removing ZRAM...
$ rm -f /usr/local/sbin/zram-config
$ rm -f /usr/local/sbin/zramsync
$ rm -f /etc/ztab
$ rm -rf /storage/zram
$ rm -rf /usr/local/share/zram-config
$ rm -rf /usr/local/lib/zram-config
$ rm -rf /etc/sysctl.d/zram.conf
$ rm -f /etc/logrotate.d/zram-config
OK
2020-10-20_10:12:28_CEST [openHABian] Updating Linux package information... OK
2020-10-20_10:12:29_CEST [openHABian] Installing ZRAM code...
$ mkdir -p /opt/zram
$ update_git_repo /opt/zram/overlayfs-tools master
2020-10-20_10:12:29_CEST [openHABian] Updating overlayfs-tools, master branch from git...
$ git -C /opt/zram/overlayfs-tools fetch origin
$ git -C /opt/zram/overlayfs-tools fetch --tags --force --prune
$ git -C /opt/zram/overlayfs-tools reset --hard origin/master
HEAD is now at 77bf3f7 Merge pull request #11 from amir73il/deref-cmd
$ git -C /opt/zram/overlayfs-tools clean --force -x -d
Removing logic.o
Removing main.o
Removing overlay
Removing sh.o
$ git -C /opt/zram/overlayfs-tools checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
OK
$ update_git_repo /opt/zram/openhabian-zram master
2020-10-20_10:12:32_CEST [openHABian] Updating openhabian-zram, master branch from git...
$ git -C /opt/zram/openhabian-zram fetch origin
$ git -C /opt/zram/openhabian-zram fetch --tags --force --prune
$ git -C /opt/zram/openhabian-zram reset --hard origin/master
HEAD is now at 2f51a14 parametrize storage dir in zramsync.service
$ git -C /opt/zram/openhabian-zram clean --force -x -d
$ git -C /opt/zram/openhabian-zram checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
OK
OK
2020-10-20_10:12:34_CEST [openHABian] Setting up OverlayFS...
$ make --always-make --directory=/opt/zram/overlayfs-tools
make: Entering directory '/opt/zram/overlayfs-tools'
gcc -Wall -std=c99 -c main.c
gcc -Wall -std=c99 -c logic.c
gcc -Wall -std=c99 -c sh.c
gcc -lm main.o logic.o sh.o -o overlay
make: Leaving directory '/opt/zram/overlayfs-tools'
$ mkdir -p /usr/local/lib/zram-config/
$ install -m 755 /opt/zram/overlayfs-tools/overlay /usr/local/lib/zram-config/overlay
OK
2020-10-20_10:12:36_CEST [openHABian] Setting up ZRAM...
$ install -m 755 /opt/zram/openhabian-zram/zram-config /usr/local/sbin
$ install -m 755 /opt/zram/openhabian-zram/zramsync /usr/local/sbin
$ install -m 644 /opt/openhabian/includes/ztab /etc/ztab
$ mkdir -p /usr/local/share/zram-config/log
$ install -m 644 /opt/zram/openhabian-zram/zram-config.logrotate /etc/logrotate.d/zram-config
OK
2020-10-20_10:12:36_CEST [openHABian] Setting up ZRAM service...
$ install -m 644 /opt/openhabian/includes/sysctl-zram.conf /etc/sysctl.d/zram.conf
$ sysctl -q -p /etc/sysctl.d/zram.conf
$ systemctl mask unattended-upgrades.service
Created symlink /etc/systemd/system/unattended-upgrades.service → /dev/null.
$ systemctl enable --now zram-config.service zramsync.service
Created symlink /etc/systemd/system/basic.target.wants/zram-config.service → /etc/systemd/system/zram-config.service.
Created symlink /etc/systemd/system/basic.target.wants/zramsync.service → /etc/systemd/system/zramsync.service.
OK
2020-10-20_10:12:50_CEST [openHABian] Checking for default openHABian username:password combination... OK
2020-10-20_10:12:50_CEST [openHABian] We hope you got what you came for! See you again soon ;)
I got that on openhabian image for raspi on my first time logging in from ssh.
Thank you for providing a new version of openhabian. Great to see the new features!
Please can you give some more details on the new auto-backup functionality. Maybe it makes also sense to add those to the documentation.
openHABian will create partitions 1 and 2 to be mirrors of your internal card and will assign the remaining space to a storage partition. Full mirroring will take place semiannually and changes will be synced once a week.
Does that mean both partitions are mirrors, but partition 1 is updated semiannually and partition 2 weekly? Or is the same partition used, but different backup options are used?
Partition 1: dd (plus some more as mentioned in a post above), semiannually
Partition 2: rsync weekly
Use menu option 54 to copy your active backup card back to the new one
If the backup SD has two partitions, how does the restore mechanism work? Can the user decide which backup (half-year/weekly) to restore on the new SD? Or is this dependent on which partition of the backup SD is booted?
Additionally I would like to understand if the following assumption is correct:
Menu option 53 (mirroring) is automating the menu options 54 + 55.
Thanks in advance!
You’re overcomplicating things.
openHABian consists of TWO active partitions, the boot vfat one and the Linux root one.
Both are mirrored. Only the second one is rsync’ed (as only that will change in operations).
54+55 are to manually run once.
53 will setup timers to execute 54+55 at regular intervals.
I see Im over complicating it.
The second card needs to have at least twice the size of your internal card.
Based on the above I thought the backup is stored twice on the backup SD. Now I know this is not the case. However please could you explain (just high level) why the backup SD needs to have twice the size or the internal one?
to have Amanda fit on partition #3 and to avoid “destination too small” issues when people use different SD models
1 Like
I have been working on installing openHABian on a RPI4 2GB so that I can migrate off of my Pine64. The openHABian basic install went very well. Thank you for making such a hassle-free openHAB setup.
Since I was going to a new system, I thought it was a perfect time to also implement features I have not previously used. One of those is graphing of temperatures over time. I used the the openHABian configuration tool item to install optional component #24 for InfuxDB+Grafana. I was able to successfully create a dashboard in Grafana. Where I struggled was getting a Grafana graph to show in my sitemap but had no luck. After doing some research, my takeaway is that I need to install Grafana Image Renderer.
-
- Is this true, do I need Grafana Image Renderer to show charts from RPi4 in my sitemap?
-
- If so, is there a plan to make the renderer part of the openHABian configuration tool install optional components?
When I was trying to get Grafana working, I manually installed and edited some configuration files. My plan is to start fresh with another openHABian install in case I unintentionally messed something up. Ideally I’d like to import the working parts of my config. Where is the best documentation on installing openHABian, the optional components and moving configurations? The struggle I have is that I find great documentation or how-to videos but they are dated. If there is a most recent set of documents, I’d be happy to give feedback/edits on things I find which could benefit from updates.
Thank you!
I don’t know. For sure there’s means to graph without Grafana but that’s no openHABian question.
No.
The official docs are at openHABian | openHAB.
That’s actually a copy of the files in /opt/openhabian/docs of your box.
They are kept up to date.
The rest is up to you guys and girls. Figure out, take notes while you install and post your experience on this forum in the Tutorials section or (better) create a PR on https://github.com/openhab/openhabian.
Thank you for the reply.
Thank you. I’ll look into options other than Grafana since Grafana can no longer render images without the Grafana renderer plugin which is not currently suported on ARM.
Thank you!
I’m about to do this and buying a new Raspi. Should I but the best Raspi available? So Pi 4 8gb or is that to much and can I do with less?
So I should backup my config and load this in a new install of Openhab. Do you think I can just unplug my Z-wave stick and plug it in the new Raspi? Or are the some more things I should consider?
Thanks in advance
I attempted my first change request for the documentation. I noticed that the docs referred to the new install’s hostname as openhab instead of openhabiandevice. Please let me know if I should have done something different.
Oh come on this thread is on openHABian and no 1:1 consulting.
Read the docs (it says RPi 8GB is a bad idea) and open another thread on the forum if you want help.
1 Like
Excuse me for asking the wrong questions. You are right I should search and try my best first before asking here. I’m not looking for 1:1 consult it’s just that I’m still learning and trying.
First of all’ let me thank the providers of this handy openhabian image that is really helpful.
I wrote the image on an SD for my new Raspberry pi v4b v 1.2 4GB.
The possibility of editing openhabian.conf before first boot is very useful. I used the possibility to connect to Wi-Fi and to give a name to the host, in order to distinguish it from the production openhab instance running in my older Raspberry pi v3b.
Installation was smoot, (and fast) except for a couple of issues.
The name of the device in the network was not changed from the default after the first one or two reboot. The up address changed from one reboot to the other and it would have been difficult to find the Raspberry again given that the name changed. After one reboot, the Raspberry was not assigned an ip address: as I was directly looking at the screen output I was able to reboot. Looking into the logs I saw the dhcpcd service complaining some error. The dhcpcd setting file had a different default hostname written into it.
Is this possibly due to the fact that I was using only Wi-Fi? Or is there some change of network settings in Raspberry is? Possibly something related to randomly changing mac address for Wi-Fi adapters?
I would suggest adding the possibility to set a fixed ip in openhabian.conf.
As a workaround I’ve set the fixed ip at the router level (I have a fritzbox 7590 with fritzOS 7.20).
This may or may not work when I will redo installation from scratch (but I do not know how often the mac address of Wi-Fi change).
Thank you again for your hard work
Lionello
Changing anything about the IP setup is very tricky because we just ‘piggyback’ on Raspberry Pi OS so whenever anything changes there we’re quickly in trouble (incompatibilities).
Did you try the new 1.6.1 image?
There have been some changes to the WiFi connectivity code and it contains a hotspot that fires up when the inet is not reachable so you can get along without editing openhabian.conf.
But testing efforts on every piece of this part are huge (and probably nonetheless insufficient).
Just like any user, I have to flash,boot, analyze and fix stuff in an everlasting cycle. No automation 
And as my test box is located 2 stairs down in the basement, the last weeks with hotspot development have become a sports events to me. Now I’m tired of running the stairs so sorry but there’s no plans for further changes.
PS: I, too use a Fritzbox. There’s an option on every network component to “always assign this IP to this MAC” or the like which I enabled for most of my boxes. Little trouble with DHCP since.
Thank you, this is exactly what I ended up doing. Next time I will test the hot-spot feature.
Lionello
WireGuard VPN setup run and completed ok.
The client conf file generated seems to have a parsing error (space char) as reported by the QR scanner in the allowed IPs tag. It is missing an “,”
instead of:
AllowedIPs = 0.0.0.0 ::/0
it should be:
AllowedIPs = 0.0.0.0,::/0
Can I install OH 2.5 on OpenHabion 1.6.2 image