Sometimes it can take hours for the system load average to drop low enough for the openhabloader.sh script to copy the rules to /etc/openhab2/rules. Perhaps it never quiets down enough, I’ve given up too many times.
I’ve attempted to change the test in openhabloader.sh in /home/pi/scripts to 1.5 but it doesn’t seem to be taking effect. When I do a ps, I can’t find openhabloader.sh running but I can clearly see that it is running in boot.log (Too busy printed over and over every 20 seconds).
It looks like I need to learn more about how the scripts work.
Edit: I’ve even gone as far as killing openhab and mosquitto and a few other daemons that appear to be using resources that don’t appear to be needed and the load average never drops below 1.10.
openhabloader.sh is not used anymore. Apologies for the confusion. I have updated the wiki. /home/pi/scripts/kiosk-xinit.sh is used now called from: /etc/rc.local
from this line: su -l pi -c 'sudo xinit /home/pi/scripts/kiosk-xinit.sh'
Regarding the load, that doesn’t seem the case for a freshly imaged card on me on a Pi Zero. Hmmm…
Load may take up to 25 minutes after the reboot but it does go down to reasonable numbers below 0.5.
Further testing shows that if you have PaperUI or BasicUI open and connected or trying to connect while there is a reboot happening, the load will never get below 1.0. I had to hunt around until I found a VM I had with BasicUI opened. Once I closed it the load eventually dropped enough for it to transition and copy the rules file.
This further makes me wonder if it wouldn’t be more appropriate to put the hiding and restoring of the rules file into openhab2.service instead of this boot script. That’s how openHABian does it and it will work when restarting just openHAB and not just the whole machine. It also works quite well. But I clearly don’t understand the interconnections between all of these scripts. With the restoreOnStartup stuff working, I think several of them are no longer necessary.
Anyway, now that I’m looking at this script I have some questions.
Do you really need to reboot the whole machine after restoring the backup? It would take much less time to just restart the openHAB service. Since you are only restoring OH configs it’s the only thing that needs to be restarted.
What is the 500 seconds before switching to loading (according to the LCD screen) based on? From watching htop and the logs it seems several minutes too long but there may be something I’m missing. And where is that 500 second delay implemented? It doesn’t appear to be in the kiosk script. Or does it actually wait that long or is it just like a UI progress bar, not necessarily telling the truth.
I’ve seen the rules file being loaded twice on a reboot. I think it’s caused by the copy and then the chmod/chown If you do a sudo -u openhab cp ... instead of the just sudo cp the permissions and ownership don’t need to be fixed and the file will only load once. That alone should cut five to ten minutes off the amount of time it takes for the RPi to settle down after the first boot.
One of my upcoming tasks I want to do is update the base OS to a DietPi which is based on Buster and which should free up a bunch of resources that a Raspbian Lite consumes that we don’t need. I’ve seen reports on the OH forums of drastically improved performance running that way. But I see a test in this script looking for Debian version 9 before calling ifconfig to populate the wlan variable. On Jessie, the debian_version appears to be 8 so I would expect Buster to be 10. Does that if need to be -gt 8 or is the difference really only for Stretch?
That’s all for now. Thanks for the info. I’m learning more every day!
No. It was the easiest way to avoid confusion for the user wondering if the restore has completed.
That is leftovers from the previous way the LCD UI was loaded (HABPanel). That same countdown was shown and near the end the browser was trying to load HABPanel on a hidden frame. If the frame loaded successfully it you load it over the countdown and hide the countdown afterwards for a smoother transition.
A more realistic countdown or a more efficient loading screen should be implemented instead
The commmand sbin/ifconfig wlan0 was reporting the IP in a different way so a different grep was needed as this script was still used by older versions too. Thats all. If Buster reports it with another syntax, another if/else should be added.
Here are my thoughts on going to DietPi:
I have used DietPi in the past for personal projects and I do like the very slim distro
I am worried on moving away from (although based on) the official Raspbian distros in terms long term support
Software that should need more care in a possible upgrade are:
Turnkey (the app for initial WiFi provisioning)
libwebsockets and custom built mosquitto with websockets
I think there needs to be a balance between how long it takes this little machine to boot and long term maintenance. 15-20 minutes or more to reach a usable state for a thermostat just feels unacceptable to me. I feel like it shouldn’t take that long but I don’t have enough experience yet to see how much we can cut off of it. That’s the main reason I’d try DietPi.
Given that you don’t really have a way to update the OS after it’s deployed (Mosquitto and openHAB will both upgrade to the latest version if you run apt upgrade it doesn’t really matter if there is LTS or not. Once deployed it has to remain static.
I don’t think that’s the right answer either really so maybe a Buster Lite with a script to strip out a bunch of stuff would be a better approach?
As of Mosquitto 1.5.4 it comes with websockets by default, no need to rebuild. The latest version of Mosquitto is 1.6.8.
I’ll have to look into Turnkey. Their github indicates they require Stretch. I’ll have to research whether there is a reason it can’t support Buster or their readme hasn’t been updated.
One concrete recommendation I’d make is to change the image so that openHAB and Mosquitto and anything else that needs to remain untouched get’s installed as a specific version (e.g. apt install openhab=2.4.0-1). That way running an apt upgrade won’t upgrade OH and those other apps too. Then we the user can get security and other OS updates without breaking anything.
If we had more RAM I’d push containers but there just isn’t enough RAM on the RPi 0 to consider that.
The documentation now contains a “Boot Sequence” section (4.2). The content was actually written a while ago, but wasn’t being included due to an error. It’s light, and it wouldn’t have conclusively said openhabloader.sh was not used, but it’s a start (for example, it did mention rc.local).
I think it would. The stated intent of this sleep/load avg checking is to ensure “that the backend […] finished loading” (Source: Boot sequence ONE · HestiaPi/hestia-touch-openhab Wiki · GitHub). The current doesn’t actually ensure that, it only ensures that the load average is down. It’s at least theoretically possible that it’d copy over the rules too early, and practically possible that it would do so far later than desired.
Using systemd should be able to actually ensure that the service is up before starting services which depend on it. If kweb were a service, systemd could also handle the “restart this process if it dies” part of the code. There are some things I don’t like about systemd, but being able to start services as quickly as possible but also ensuring they aren’t started too soon… that’s something it does very well (and to be fair, that’s the main problem that package is trying to solve, so it makes sense that it does it well).
I’ve definitely seen this in my experiments and development. I’d say at least several minutes are wasted waiting around for the load to drop to .5.
I don’t know as much about how kweb works so can’t comment on whether or how to make it load using systemd. But even if it doesn’t, I don’t think the intent of the script would be broken if we did this.
Given that openhabloader.sh isn’t used, why is it still there? Shouldn’t it be removed to eliminate confusion and dead code?
