Hi
I will try to make a new rule file.
This is my own file, it has been working earlier in openhab 2.5 
Thanks Mads
Don’t care, totally new rules management in OH3
Hi
This is how the same rule looks from MainUI rule “reader”
The start level is only 20, which is way to early, it should be 60 or so
// Triggers:
// - When the system has reached start level 20
// context: systemstarted-1
logInfo("bootup", "System startet, regle genstartet.")
//Hvis SystemKLAR er null, så er det første start. (skal kun køres ved første start)
Thanks Mads
HI
Ok, i think that in openhab 3.1 release, the “System started” trigger in DSL rules in broken, because.
This DSL rule
Ended up look like this in MainUI “rule reader”
When looking at startup levels, its my understanding that rules below level 50 will not be executed because the rule engine is not running ?
So unless there’s away to change “System started” trigger in DSL rules to a higher startup level its broken.
Thanks Mads
Maybe. Maybe they get queued. Maybe the start levels isn’t properly implemented in OH3.1 at all, and any/all ‘levels’ actually get triggered later.
The Big Question you haven’t answered … does that test rule work?
Hi
Sorry, No the test rule does not work.
Thanks Mads
it’s not necessary still repeat same questions,
We’ve been discussing it since OH3 and I’m pretty sure ticket was filled in back then.
System started trigger simply does not work in 3.1. And whatever that runlevel 20 is, it’s not triggering that trigger at all, neither for me and for many others. Neither from UI rule definiton (for into)
Personally I don’t care so much about this trigger, better to have different approach, but yes, in some cases it might be handy.
1 Like
There’s a whole bunch of reasons any given rule might not do what is expected; always worth identifying actual causes.
Fairly extensive exploration at -
I do wonder why the OP didn’t change to a MainUI created rule using the DSL syntax. The use of the trigger “When the system has reached start level 50” is working ( at least for me).
After looking that often onto the MainUI rules Editor such a step shouldn’t be that hard ( copy &paste of the old rule body is possible)!
Not entirely sure why you think that the “system started” trigger for DSL rules doesn’t work, for me it does.
There can be several reasons why DSL rules need to be used, for example if global variables are involved.
Hi Opus
I only have text based rules at the moment, but at some point i will have to start using the “new” MainUI.
i first started to look into MainUI while investigation this problem.
Thanks Mads
Just to summerize:
- startup triggers work in all UI rules
- startup triggers work in non-Rules DSL languages (and there are other mechanisms too)
- startup triggers sometimes work with file based Rules DSL
It is not clear why they do not work all the time.
Work arounds for now include:
-
move the rule to a format that is supported
-
after a restart manually run the rule
2 Likes
Hi
Sometimes is not the case for me, more like never 
I just upgrade to openhab 3.2m5, now my old rule and the new test rule works as intended, of cause with very limited testing a the moment.
Thank Mads
@Mads_Bloch Can you please share your DSL (system startup) rule please?
Mine is still not working after upgrading from the OH3.1 to the OH3.2 release.
rule "actions at system start"
when
System started
then
// send startup mail + send status to MQTT
end
How can you tell, that rule doesn’t do anything? So of course the comment substitutes for some secret code, but what stands out to me is that the code may rely on Actions provide by bindings that may simply not be ready for use at this time.
Just slip in a logInfo() to be sure of rule execution.
1 Like
Indeed, by adding the loginfo() I noticed that it get triggered.
but the other lines don’t get executed.
2021-12-23 08:15:38.625 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘RULE-6’ failed: ‘sendMail’ is not a member of ‘org.openhab.core.thing.binding.ThingActions’; line 122, column 3, length 70 in RULE
Do I need to include an extra delay?
Assuming the syntax of your still-secret code is correct, then yep the mail Action is not ready yet. Try again later.
Yes the “MI-6” code 
is correct, it is working in other rules.
What do you mean with “try again later”?
Is there a way to detect if a rule is not fully executed and the try to repeat the rule execution?
Or do I need to implement a delay via a timer?
Your mysterious rule I’m guessing includes code to fetch Actions from a binding Thing.
It does that when you tell it to do that - here that will be when the rule runs. At system startup.
The bindings are getting started at that time as well, not everything is operational before the rule runs.
If the binding is not ready at that instant, then a functional Action will not be returned.
If you try to use a broken Action, your rule will fail with an error.
If you fetch the same Action from the same binding later on, maybe it will be ready then.
There are more or less elaborate techniques to do that, but what you’re really interested in is “did I get a valid Action?”
Related discussion -
I think that the bindings are not ready yet. I use the same “code” parts in others rules and those work fine.
Here is the “secret” rule: (parts in capitals are stil secret )
rule "actions at system start"
when
System started
then
logInfo("System started", "OH 3.x STARTED ------------------")
// send startup mail
val mailActions = getActions("mail","mail:smtp:OpenHabMail")
mailActions.sendMail("<MAIL_ADDRESS>", "Openhab 3.x startup", "")
// request multiroom audio device status
val mqttActions = getActions("mqtt","mqtt:broker:MQTTbroker")
mqttActions.publishMQTT("<TOPIC>","<PAYLOAD>")
end
So the loginfo is present in the logs but the mail and the MQTT message are not send.
Should I add a “delay” in this rule?