Until the migration to OH 4.x I had a rule in place that worked perfectly and sent out an email to inform all users, that the system has been restarted.
var Number counter
rule "Startup"
when
System started
then
counter = 0
val mailActions = getActions("mail", "mail:smtp:xxx")
val success = mailActions.sendMail("***")
logInfo("System start", success.toString())
end
Since OH 4.x this rule is also triggered when I’m working on .rules, .items. or .things (I tend to work with textual configuration in nearly every case) and save them.
I also tried to use
System reached start level 100 as a trigger but nothing changed.
What do I need to do in order to just trigger this rule when openHAB has REALLY been rebooted?
I guess a „system started“ trigger is too early for your script as the rule engine is up and running at systemlevel 50.
Did you check in the log if your system ever reaches level 100 (by creating a script which writes an entry into the log)? If just one of your things cannot be initialized your system might not reach level 100.
For your script check if startlevel 50 (Rules Engine active) or 80 (All things initialized) does the job.
Hey Oliver,
thanks for the fast answer. If my system would not reach start level 100, the rule would not start, right?
Because as I tried to explain, I am currently running the rule like that:
var Number counter
rule "Startup"
when
System reached start level 100
then
counter = 0
val mailActions = getActions("mail", "***")
val success = mailActions.sendMail("<MESSAGE>")
logInfo("System start", success.toString())
end
And still, the rule fires EVERYTIME I save one of my text config files
This also happens when I’m adding something new via the main UI.
It seems as if the start level will be re-set to 100 if something changes.
I recommend the following:
create rules triggered when startlevel reaches 50, 70,80 and 100 and just do a loginfo to see if your system ever reaches 100. Even if so, I would prefer startlevel 80 for your script.
That’s a great idea, but it does not really solve my problem
I don’t want to spam my whole family with countless mails whenever I’m configuring something new and still get the info, when the system did - for what reason ever - a reboot
Rich answered: When you change a .items file, that forces a reload of the rules because when a .items file is reloaded, all the the Items defined by file are destroyed and then created anew which causes a reload of the rule. Otherwise the rule would not pick up the new Items to use as triggers.
Thanks a lot for this update @April_Wexler
Then - at least from my point of view - the state of “System started” respectively “System reached start level xx” can be mis-interpreted.
Maybe there will be another information that can be used as a trigger in the future that makes it possible for us to distinguish between A RELOAD and A RESTART
This was a deliberate change in OH 4 and it’s discussed in the release notes and Trigger immediately when start level already reached by J-N-K · Pull Request #3278 · openhab/openhab-core · GitHub. This is actually a return to how it worked in OH 2.x and this return to the old behavior was implemented to handle the case where a rule doesn’t get loaded until the runlevel that triggers the rule has already passed (e.g. maybe the automation add-on took some time to download and install).
When you save a text config, that requires a reload of them all to pick up changes and a reload of a text file causes everything in that file to be destroyed and created anew, causing the system start level triggers to run again.
There was some work started (not sure where it is) to be able to detect which entities in a text file actually require a reload instead of reloading everything in the file. That should help as it will prevent the system started rule from rerunning unless the file it’s in actually changed. I’m not sure how feasible that is myself but there are some smart developers contributing to this project so who knows.
In the mean time this behavior is much less of a problem with managed configs because each entity is handed on it’s own so changes don’t have as big of an impact (i.e. if you change an Item, only that one Item gets updated, not every Item in the file where that Item is defined getting destroyed and recreated). If you moved this one rule (or all of them if you want) to be managed, you can set a flag in the cache the first time the rule runs during an OH start. Because it’s managed, I don’t think this rule gets reloaded on a file config change so that flag will persist. Then you can check that flag to see if this is the first time or if the rule is retriggered because of a config change.
There are other things that you could do, many that involve stuff outside of OH. In no particular order:
create a file in the OH start script and in your rule check the date time of that file and only send the email if it’s close to now
the LogReader add-on might be usable here to monitor openhab.log for a log statement that only occurs once during startup but happens after Things are loaded and configured (runlevel 80)
use an external system to monitor OH and send the email (I use Zabbix)
consider if your family really needs the email in the first place, that’s more of an admin thing than something end users really should be aware of or care about
trigger the rule based on a reliable (i.e. has no external dependencies to be ONLINE like Exec) Thing changing status to ONLINE (this Thing would have to be managed) instead of system started. If it’s reliable and managed, it should only ever change status during OH startup and remain ONLINE until OH is restarted.
Create a managed Item (not in .items files so do not get reloaded on a config change) that is excluded from restoreOnStartup. Set that Item with a state (ON, current date time, whatever). When your rule triggers, only send the email if the Item has state NULL and update the Item as appropriate after sending the email.
