I would like to disable a rule when the OpenHab service shuts down. I use this rule to check the online state of an MQTT thing and send a message if it goes offline. The problem is that when OpenHab shuts down this rule is also triggered because the bindings are stopped.
In older versions of OpenHab there was a “System shuts down”, but this trigger has been removed. Is there any other way to disable a rule when the service is stopping? I already checked the “But only if” condition of OpenHab 3.0, but there is no such condition.
Not that I know of. The System shutdown trigger in OH 2.5 never did work reliably so it’s no surprise that they removed it. The way startup and shutdown is handled also may have made such a trigger impossible.
You might be able to trigger a rule for when the Thing changes to UNINITIALIZED (HANDLER_MISSING_ERROR).
There are cases where it would be very helpful, to be able to set an item to a certain state, when OpenHab shuts down. For example, I would like to control a freezer, based on the actual PV power level, so that it is only in cooling mode as long as the sun is shining (with a few additional safety measures not mentioned here). If Openhab is switched off, the state of the freezer should go to “always on”, otherwise you will get extreme trouble with the boss of the kitchen.
As the shutdown trigger is no longer available (and has obviously never worked reliable), is there any other possibility to accomplish this?
If you use Python/JavaScript/Groovy rules in text files (not through the UI) you can define a scriotUnloaded function that gets called when that done becomes unloaded by OH, which happens as part of shutdown.
However, even with a System shutdown trigger, assuming it worked, you’d have no guarantee that the Item is still loaded when that code runs but do you have any guarantee that the Thing is still loaded and operational when that code runs.
Therefore you probably need a be watchdog outside of OH to take action when OH goes down, turning on the device itself, alerting, something like that.
For that sort of purpose, you really need an autonomous watchdog that keeps trying to set the freezer to failsafe mode, unless it’s told not to regularly.
That gives you protection against loss of network, host catching fire, etc., all the other ways it can go wrong that would not give a tidy controlled shutdown anyway.
Maybe… It depends on how you shutdown openHAB. If you stop it in the shell (e.g. sudo service openHAB(2) stop) probably not.
However I do have an item which triggers an openHAB restart. If the item receives a command it triggers a rule which will restart openHAB with executeCommandLine. Just before that I can execute whatever I wand. In my case I add an annotation to a grafana dashboard.
rule "Reboot OpenHAB oder FritzBox"
when
Item System_OpenHABNeustartTrigger received command
then
var panels = newArrayList()
logInfo("Rule triggered", Dateiname + ": \"Reboot OpenHAB oder FritzBox\": OpenHAB")
service = "OpenHAB Neustart"
panels = newArrayList('18', '22', '23', '24', '25', '28', '29')
e executeCommandLineetc/openhab2/scripts/RPi4/OpenhabRestart.sh")
panels.forEach[panel |
var String json_message = '{
"panelId":' + panel + ',
"dashboardId":2,
"time":' + Long::toString(now.millis) + ',
"text":\"' + service + '\"
}'
sendHttpPostRequest(url, "application/json", json_message)
]
end
thank you for your proposals. I’m surprised that there seems to be no big need in the community for a user-friendly implementation of a shutdown rule feature. I’m only using straight DSL rules and reluctant to learn how to set up additional watchdogs or Python Unload Scripts. My freezer is controlled by a ZigBee2MQTT Wall Plug. The MQTT daemon is running on a separate Synology station, so this is independent from Openhab which runs on Raspi. So the simplest way to make the system more reliable in this special case for me is to set up a cron job on the Synology which sends a mosquitto_pub command once a day.
Ok think the point that rosdko57 and I were trying to make is that it’s not a matter of need. It’s simply not technically feasible. At best all OH could offer is a partial solution that only works when OH it’s shut down nicely. That won’t handle cases where OH crashes or the machine loses power or what ever. And we don’t have a best case given how OH works and is archtected. At best all it can offer is sometimes a command issued to an item at system shutdown will make it to the device, but only if OH is shutdown nicely.
It’s far better to not offer any solution at all than a solution that can’t be relied upon. And since the only way to provide a reliable solution is outside of OH, whether or not it’s too complicated for many users, is there best that can be offered.
Note, what you’ve set up is in fact a watch dog. It didn’t have to be any more complicated than a cron job.
