Problem with 3.1.0 Deprecation of System started

Setup, Configuration and Use Migration
,
1

UPDATE: Not deprecated. See below. Cache purge fixed the problem.

I received the 3.1.0 update of openHAB last Monday (Raspbian) and I noticed the System started rule trigger has been deprecated. I have seen multiple threads discussing this. I thought I would start a new thread to hopefully bring back this key (for me) rule trigger.

I live in a hot, dry, windy area susceptible to wildfires. My power utility will cut my power multiple times per year based on their own reasoning, and we’re approaching the time of year where it could be cut multiple times per month. I have UPSs in place and I initiate bash scripts that issue graceful shutdowns to the boxes prior to the UPS battery depleting. As part of the shutdown, I have openHAB turn OFF smart switches that are connected to the boxes and other equipment. The thinking here is that I’d much rather cause damage to a smart switch in the case of a power restoration surge, as opposed to damaging the computers. You can tell me that UPSs are designed to protect the equipment from a surge but I can tell you that is simply not the case in lower end UPSs.

I run openHAB on a RPi and it is not connected to a smart switch. Again, more cost effective to replace a RPi than my other equipment.

Now power is restored and the RPi boots on its own and begins to restore my internal environment. That is unfortunately no longer the case because of the System started deprecation. I need remote access to my home internal network as I travel for work. Hopefully you can see how problematic this is for this scenario. I’m assuming the thought process was to go with Persistence on startup but that is counter intuitive for me.

Yes, I can schedule health checks in the rules but there are also times when I want a device to be off and there’s no programmatic way to convey that easily in the rules.

Hopefully I’ve made a strong case to bring this feature back otherwise I have to move away from openHAB.

2

You can always use HABApp and write your rules in python (3).
The equivalent of System started is still working there.

2 Likes
3

So if I’m going to rewrite all of my rules, I may as well switch to something else. Your wording doesn’t sound confident that System started will continue to be supported in Python either. I’d want to hear this from a maintainer/dev.

I guess at this point, I’m looking to find out if the maintainers are willing to put support back, or if this decision is final and I have to live it. If they are firm on keeping it as-is, then I know what my next steps will be.

I will have to read up on HABApp as I’m not familiar with it. I code my own rules using an IDE and not sure how HABApp differs. Thanks for your suggestion.

4

Am I missing something?

I am using a rule with this trigger:

:
  - id: "1"
    configuration:
      startlevel: 80
    type: core.SystemStartlevelTrigger

I my words it would be a system started trigger!

5

according to Rules | openHAB

Startlevels (logically only if startlevel >= 40) are only available in UI-Rules, not in DSL-Rules with textual configuration.

and

System started is triggered upon openHAB startup. In openHAB version 2, System started is also triggered after the rule file containing the System started trigger is modified, or after item(s) are modified in a .items file.

So the OP seems to use DSL based .rules files.

1 Like
6

Correct. I am using DSL/Xtend rules. That was the only option when I installed and configured openHAB years ago. I have a vast rule set right now and it was be a significant effort to rewrite them all.

Again, System started was deprecated in DSL and there’s no indication that it will persist with Python-based rules or any other rules mechanism. Because it works now does not mean that is the case forever, especially considering what happened to DSL based rules. If I’m going to invest massive effort to adapt my rules to Python, I’d like some guarantee that I won’t have to go through this again. Of course, the ideal situation is to support System started in DSL rules.

7

Why telling it is deprecated?
It is still there in 3.1 and working. I see no reason to suppress it.

PS: using DSL rules

8

From the documentation that @Wolfgang_S linked to I understand that system started still exists in any type of DSL rules (file or UI), but that the specific startup level options are only available via the UI.

9

In DSL file, just use the same trigger syntax as in OH 2.x.

10

OK I see a problem. It works intermittently, and usually not. I issue multiple systemctl restart openhab.service and the System started rules seem to work less than 50% of the time. When it does not work, I see Rule engine started. in the openhab.log and it is quiet after that. When it does work, I see my startup rule processed as expected.

Is there some cache I can purge somewhere to make this more reliable?

11

Here is my rule:

rule "Démarrage"
when
	System started
then
	logInfo("Rule","Démarrage début")
	lastDesarmTime = now.minusDays(1)
	lastMinimoteTime = now
	logInfo("Rule","Démarrage fin")
end

And what I got the last time I started OH:

2021-07-04 22:28:25.639 [INFO ] [org.openhab.core.model.script.Rule  ] - Démarrage début
2021-07-04 22:28:25.681 [INFO ] [org.openhab.core.model.script.Rule  ] - Démarrage fin
2021-07-04 22:28:25.745 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
12

I have a very similar rule and mine works only sometimes.

var String ruleFile = "systemStartup.rules"

rule "Test"
    when
        System started
    then
        logInfo( ruleFile, "test: rule fired" )
end
13

I believe mine is always working.

14

What is sure is that there is no deprecation :wink:

1 Like
15

I will not argue that however it is not reliable in this current stable release.

16

You are coming form 3.0 ? Because I don’t think there was any change between 3.0 and 3.1 regarding this trigger.

17

Yes, I was coming from 3.0 stable.

So this appears to be a cache issue. I purged the openHAB cache and it is working fine now. After purging the cache, I did 3 consecutive restarts that successfully executed my startup rule.

Thanks everyone for the suggestions. You put me on the right track. I also updated my original post to indicate the issue was cache related.

Perhaps it might be a good idea to purge cache as part of the upgrade process (stable release upgrades).

2 Likes
18

I wouldn’t go quite that far, as it’s not always necessary to clear the cache. Better just to note it as a troubleshooting step if users have issues when upgrading.

Saying that, I haven’t upgraded to 3.1 yet. :wink:

1 Like
19

Just on a sidenote, do you use openHABian ? Your situation is a perfect match for its design philosophy. I’ve added the zram and SD mirror features, these greatly raise MTBF and reduce MTTR.
My own production RPi actually has an(other) UPS builtin. It actually happened to me twice that the main UPS had a problem. If that kills your RPi while that is busy bringing your equipment to a safe state in a coordinated manner that’s really among the worst things that can happen.

20

Just a note - all upgrade procedures should do this for you already. ${OPENHAB_USERDATA}/cache, ${OPENHAB_USERDATA}/tmp, and ${OPENHAB_USERDATA}/kar do not exist (tmp exists but is empty) before an upgraded instance starts for the first time.

1 Like