Cleaning up the startup process / renaming rules (windows possible)

The rules renaming works fine if you implement it correctly. It’s also already built into openHABian.

FWIW, I suggested adding that to openhab-core but Kai refused. OSGi start levels according to him cause all sorts of problems.

What do you mean be with built into OpenHABian? I found the 44 command “Delay rules load”. What is it doing compared to the suggested option in this threat? I activated it but my rules where activated very fast just after items and things.

Attached the loading order and times when using the openhabian 44 option and no additional modification:

2020-05-17 18:14:47.507 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘general.items’

2020-05-17 18:14:47.596 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘anwesenheit.items’

2020-05-17 18:14:47.677 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘systeminfo.items’

2020-05-17 18:14:47.756 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘hue.items’

2020-05-17 18:14:48.003 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘zigbee2mqtt.items’

2020-05-17 18:14:48.293 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘schlafen.items’

2020-05-17 18:14:48.355 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘chromecast.items’

2020-05-17 18:14:48.478 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘tueren_fenster.items’

2020-05-17 18:14:48.494 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘nerdstuff.items’

2020-05-17 18:14:48.502 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘tasker.items’

2020-05-17 18:14:48.513 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘warnings.items’

2020-05-17 18:14:48.520 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘test.items’

2020-05-17 18:14:48.534 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘speedtest.items’

2020-05-17 18:14:48.559 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘shelly.items’

2020-05-17 18:14:48.615 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘kodi.items’

2020-05-17 18:14:48.646 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘timeoftheday.items’

2020-05-17 18:14:48.663 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘szenen.items’

2020-05-17 18:14:48.715 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘network.items’

2020-05-17 18:14:48.805 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘ui.items’

2020-05-17 18:14:48.882 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonos.items’

2020-05-17 18:14:49.100 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonoff.items’

2020-05-17 18:14:49.160 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘roborock.items’

2020-05-17 18:14:49.241 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘astro.items’

2020-05-17 18:14:49.591 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘influxdb.persist’

2020-05-17 18:14:50.166 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘default.sitemap’

2020-05-17 18:14:50.621 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘hue.things’

2020-05-17 18:14:50.632 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘mqtt.things’

2020-05-17 18:14:50.653 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘network.things’

2020-05-17 18:14:50.667 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘mail.things’

2020-05-17 18:14:50.693 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘nodemcu.things’

2020-05-17 18:14:50.715 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonos.things’

2020-05-17 18:14:50.731 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonoff.things’

2020-05-17 18:14:50.755 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘shelly.things’

2020-05-17 18:14:50.772 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘roborock.things’

2020-05-17 18:14:50.814 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘zigbee2mqtt.things’

2020-05-17 18:14:50.848 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘systeminfo.things’

2020-05-17 18:14:50.856 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘astro.things’

2020-05-17 18:14:54.871 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonoff.rules’

2020-05-17 18:15:03.628 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘licht.rules’

2020-05-17 18:15:07.170 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘motionsensor.rules’

2020-05-17 18:15:11.226 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘warnings_luftfeuchtigkeit.rules’

2020-05-17 18:15:11.621 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘weihnachtsbeleuchtung.rules’

2020-05-17 18:15:19.137 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘schlafen.rules’

2020-05-17 18:15:19.930 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘warnung.rules’

2020-05-17 18:15:20.957 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘timeoftheday.rules’

2020-05-17 18:15:22.708 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘tueren_fenster.rules’

2020-05-17 18:15:34.692 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘sonos.rules’

2020-05-17 18:15:36.437 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘warning_systeminfo.rules’

2020-05-17 18:15:39.820 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘warnings_temperatur.rules’

2020-05-17 18:15:40.440 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘roborock_szenen.rules’

2020-05-17 18:15:42.255 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘speedtest.rules’

2020-05-17 18:15:48.361 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘zigbee.rules’

2020-05-17 18:15:48.701 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘networkhealt.rules’

2020-05-17 18:15:50.279 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘ui.rules’

2020-05-17 18:15:54.277 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘hue.rules’

2020-05-17 18:16:00.948 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘roborock.rules’

2020-05-17 18:16:01.526 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘vacation.rules’

2020-05-17 18:16:07.672 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘statistik.rules’

2020-05-17 18:16:13.005 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘anwesenheit.rules’

2020-05-17 18:16:14.076 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘googlehome.rules’

2020-05-17 18:16:19.132 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘szenen.rules’

2020-05-17 18:16:23.315 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘rollo_szenen.rules’

2020-05-17 18:16:23.599 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘rollo_automatik.rules’

2020-05-17 18:16:26.571 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘schalter.rules’

2020-05-17 18:16:33.904 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘rollo_shelly.rules’

It implements the solution this thread was about in the first place (move rules away and back after 2 mins). If it does so after items that’s all you need.

I tried to change to the following commands:

[Service]
ExecStartPre=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exec /usr/bin/rename.ul .rules .rules_away {} \;’
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.script” -exec /usr/bin/rename.ul .script .script_away {} \;’
ExecStartPost=/bin/sleep 240
ExecStartPost=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.script_away" -exec /usr/bin/rename.ul .script_away .script {} \;’
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.rules_away” -exec /usr/bin/rename.ul .rules_away .rules {} \;’
TimeoutStartSec=360

Watching the filenames on the raspberry I could not see any renaming happening. In addition I observed that watching the log during boot is active much later. Any explanation? I run openhabian 2.5.4 on RP 4.

Thanks and best
Matthias

where

why

Your file is wrong. You need a * in front of .rules.
And you must not duplicate lines.
You also said you enabled openHABian delayed rules option, but your file (which ?) would not look like that if it did originate from openHABian.

I was following the original threat.

I used the command as follows as I am on stretch-based Linux using openhabian 2.5.4

sudo systemctl edit openhab2.service
and modified from

ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exec$
ExecStartPost=-/bin/sleep 120
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.x” -exec /u$
TimeoutStartSec=240

to

#[Service]
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exe$
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.script” -ex$
ExecStartPost=/bin/sleep 240
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name ".script_awa$
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.rules_away$
TimeoutStartSec=360

as mentioned here.

Why: Because my rules are loaded immediately, especially before things are initialized and before values are restored by persistance. This causes several rule failures as well as multiple load of rules.

The following file does not exist or has been generated as I expect the steps above are correct for my OS:

/etc/systemd/system/openhab2.service.d/override.conf

EDIT:
I just checked my version and it seems to be buster:

cat /etc/os-release
PRETTY_NAME=“Raspbian GNU/Linux 10 (buster)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“10”
VERSION=“10 (buster)”
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL=“http://www.raspbian.org/
SUPPORT_URL=“http://www.raspbian.org/RaspbianForums
BUG_REPORT_URL=“http://www.raspbian.org/RaspbianBugs

You have not been careful in reading.
If you literally entered what you cited that cannot work.
Your lines are incomplete. And a # before [Section] is no good idea.

And there was no need for that change, the previous version was mostly fine (except that your lines are cutoff there, too).

There has been more commented lines and a non-commented [Service] at the top.

Interestingly I just checked the file after rebooting and it was empty - so maybe something was wrong anyhow.

The current full (!) file looks like this:

[Service]
ExecStartPre=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exec /usr/bin/rename.ul .rules .rules_away {} \;’
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.script” -exec /usr/bin/rename.ul .script .script_away {} \;’
ExecStartPost=/bin/sleep 240
ExecStartPost=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.script_away" -exec /usr/bin/rename.ul .script_away .script {} \;’
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.rules_away” -exec /usr/bin/rename.ul .rules_away .rules {} \;’
TimeoutStartSec=360

Same problems:

  • Rules are loaded very early
  • Log output is quite late
  • Rules are fired several times
  • Watching the files I can not observe any renaming happening

Obviously I am still doing something wrong.

Can be anything like an unspotted typo or file permissions or whatever.
I don’t understand anyway why you do not use the delayed rules option since you’re on openHABian.
It’s right there to save you from this trouble.

I am fine with the delayed rules option with openhabian and already activated it several times with no effect. What should I observe? What is changed?

I believe you must somehow have messed up your system because it works on a default oepnHABian installation.

Actually multiple rule firings at the startup seems to be a known issue - that’s why I ended up trying to clean this behavior with this threat.
Does anybody know what the built in delay rules of openhabian is doing?

I did an upgrade to openhabian 2.5.5.-1:

  • After the update the file sudo systemctl edit openhab2.service was empty.
  • Logs during booting are shown as expected (starting with timezone etc.).

I played with openhabian-config:

  • Option Default order Reset config load order to default (random) empties whatever has been modified via sudo systemctl edit openhab2.service
  • Option 44 | Delay rules load Delay loading rules to speed up overall startup adds the following to sudo systemctl edit openhab2.service:

[Service]
ExecStartPre=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exec /usr/bin/rename.ul .rules .x {} \;’
ExecStartPost=-/bin/sleep 120
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.x” -exec /usr/bin/rename.ul .x .rules {} \;’
TimeoutStartSec=240

This shows what the built-in openhabian option is doing. Nevertheless applying this optimization results in delayed log-output and no observed renaming.

I thought about removing the second renaming to just see the script works:

[Service]
ExecStartPre=-/bin/bash -c ‘/usr/bin/find ${OPENHAB_CONF} -name “.rules" -exec /usr/bin/rename.ul .rules .x {} \;’
ExecStartPost=-/bin/sleep 120
#ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "
.x” -exec /usr/bin/rename.ul .x .rules {} \;’
TimeoutStartSec=240

Interestingly the rules still are named rules instead of x.
So again: Something is wrong here!?

That won’t replace any (possibly bad) part of your system. I’d reinstall from scratch to have a known starting point.

I can not follow your recommendation: I clearly stated what I was and am doing. Maybe there is a change for somebody to validate what happens on their system?

It works on standard openHABian. It does not work on your system
=> something was changed on your system but we don’t know what that is. Only you yourself can know.
=> reset the system to a known starting point or keep searching on your own.
No worries it’s fairly simple if you backup/reimport your OH config.

Thanks @glhopital Seems to work to drive down the startup errors for me!

I’m on a Windows 10 Box running 2.5.7-Snapshot Build #179 and have placed the “bundle:start-level” lines in “C:\Users\natha\Downloads\openHAB2\userdata\etc\scripts\custom.script”. On startup of OH2 I get an error in Karaf

Error in initialization script: C:\Users\natha\Downloads\openHAB2\userdata\etc\scripts\custom.script: Command not found: bundle:start-level

When I check each command (without the values) they are not set, but if I execute your values in Karaf they work fine, and oddly seem to be persistent between restarts of Karaf (I’ve not tried a reboot of the PC at this point).

Any suggestions on why the initialisation script errors out?

Thanks
Nathan

I’m not sure if I’m doing it too much or not. I definitely want to avoid sending old status messages or commands after startup. Therefore I do the following:

sudo systemctl stop mosquitto.service
# Löschen der mosquitto.db die alle gespeicherten Nachrichtendaten der Persistenz enthält. Befindet sich standardmäßig in /var/lib/mosquitto/mosquitto.db
sudo rm /var/lib/mosquitto/mosquitto.db

# Neustarten des Mosquitto MQTT-Brokers
sudo systemctl start mosquitto.service
sudo systemctl restart mosquitto.service

sudo systemctl stop openhab2.service
sudo rm -rf /var/lib/openhab2/cache/*
sudo rm -rf /var/lib/openhab2/tmp/*
sudo systemctl start openhab2.service

So after starting openHAB all models (.rules, .sitemaps, .items, etc.) have to be loaded, which I sort of do as follows:

sudo systemctl edit openhab2.service
[Service]
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.items" -exec /usr/bin/rename.ul .items .items_away {} \\;'
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.sitemap" -exec /usr/bin/rename.ul .sitemap .sitemap_away {} \\;'
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.things" -exec /usr/bin/rename.ul .things .things_away {} \\;'
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.rules" -exec /usr/bin/rename.ul .rules .rules_away {} \\;'
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.script" -exec /usr/bin/rename.ul .script .script_away {} \\;'
ExecStartPost=/bin/sleep 240
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.items_away" -exec /usr/bin/rename.ul .items_away .items {} \\;'
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.sitemap_away" -exec /usr/bin/rename.ul .sitemap_away .sitemap {} \\;'
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.things_away" -exec /usr/bin/rename.ul .things_away .things {} \\;'
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.script_away" -exec /usr/bin/rename.ul .script_away .script {} \\;'
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.rules_away" -exec /usr/bin/rename.ul .rules_away .rules {} \\;'
TimeoutStartSec=360

So I’ve expanded it a little bit.

What it is stuck on now is that it has to reinstall the addons.

This also works only through

sudo systemctl restart openhab2.service

Means, if I start twice or restart after one start, it loads all models and addons. Then I would not need the override at all.

Now to the question or the difference. Would I not need the following at all?

sudo rm -rf /var/lib/openhab2/cache/*
sudo rm -rf /var/lib/openhab2/tmp/*

So would a move or a rename already mean that it does not send out a command again? Or would my approach still be the more clever one and I wouldn’t need the override at all?

The fact is, if I don’t start again, it loads the models, but because the addons are missing, exceptions would be thrown. I actually hoped that I could have saved the restarts and the whole mechanism would be faster.

I am very much not keen on taking preventative measures to fix things that might be a problem. Have you actually experienced problems for which doing the above on every start of openHAB solves?

If your goal is to “avoid sending old status messages or commands after startup” I don’t see how anything you are doing in the openhab2.service file does anything for that.

Furthermore, unless you’ve actually coded some rules to send these old status messages or commands, won’t be sent. So I’d suggest coding your rules so they are not sent rather than going through the trouble of shutting down the MQTT broker, which can itself disrupt any of your MQTT devices causing them brief problems and causing them to use up more energy than normal as they try to reconnect.

The only files that I would move and then move back after a time are .rules. Doing this has absolutely no benefit for any of the other file types.

Only “clear the cache” when you hare experiencing a specific class of problems, namely the inability to install an addon or an addon appears to be corrupted. Doing it on every reboot of OH is almost certainly going to lead to far more problems than it actually solves.

And clearing the cache every time is going to add a long time to every boot, not make it faster.

1 Like

A post was split to a new topic: Startup issues