Does someone know how I can use the new “start level reached” trigger in a rule file? There doesn’t seem to be any documentation about that, just for the “old” system-started trigger and UI-based rules but I don’t think there is a way to transform that to a text-based rule so I can look up the correct name?
hi Flole,
try this:
- edit or create a rule
- add a ‘When’ trigger
- select: System Event
then you can define the ‘Start Level’
I’m aware of that, but how do I figure out the name of the trigger from that so I can use it in a rule file?
for testing I sometimes use the following ECMAScript lines:
// ECMASCRIPT: cron-triggered oder item-triggered ??
if (this.event === undefined) {
//or:
//if ( (typeof event) == 'undefined' ) { ...
// ..., if rule was for example: cron-triggered
logger.info("!!!");
logger.info("!!! trigger is NOT an event ...! may be CRON ?..");
logger.info("!!!");
} else {
// https://openhab-scripters.github.io/openhab-helper-libraries/Guides/But%20How%20Do%20I.html
logger.info("-- this.events: {}", this.events);
logger.info("-- this.event: {}", this.event);
// Get the triggering Item
//logger.info("-- the triggering Item: {}", ir.getItem(event.itemName));
// Get the triggering Item’s name
logger.info("-- get the triggering Item’s name: {}", event.itemName);
// Get the triggering Item’s state
logger.info("-- get the triggering Item’s state: {}", event.itemState);
// Get the triggeringItem’s previous state
logger.info("-- get the triggeringItem’s previous state: {}", event.oldItemState);
// Get the received command
logger.info("-- get the the received command: {}", event.itemCommand);
}
Presumably what the OP wants doesn’t manifest as a trigger from an Item, so this script would just return trigger is NOT an event? Or are the start conditions specific events?
You would need a generic event trigger (look for the event classes in triggers.py or triggers.jsin my Helper Libraries). You will also need to know the event name so you can filter for it. I suggest filtering for all system events and log the event path, similar to the example above.
But how does all of that give me the correct syntax to write a start level trigger in a DSL Rule file? Normally that should be mentioned in the documentation but all the examples use the old “system started” trigger which internally gets translated then.
in my example: yes
in some cases I use the if branch for value assignments
yes (cron triggered / system start level / manually triggered)
I learned that event is only populated when the rule is triggered by an Item. Not when it is manually triggered nor when it is triggered by a time event. I can use it to handle my cases.
I think it’s safe to assume this just isn’t available to files-based DSL. Feel free to suggest an enhancement, maybe with a use case. What did you need this for?
Unfortunately I am seeing rules being triggered when the item state has not been restored yet so I wanted to change it from 20 (which system started is internally translated to) to something later like 80.
I thought DSL and “webinterface based” rules are supposed to have the same features? As it’s a major change which was done by experienced openHAB developers this probably wasn’t just a simple “we forgot about it”, so if it really isn’t there I think there’s a good reason for that.
That might be because you’re using a “slower to start” persistence service for this purpose?.
I’ll bet it doesn’t actually fire then, but more like “as soon as rules are ready”.
Nevertheless,if there is benefit in changing that,maybe that is a benefit that all should share and the system needs amending here.
Really? There’s no direct equivalent of files ‘globals’ in UI rules for example.
I am using MapDB for this purpose as I think that’s the most lightweight persistence service possible.
Yes it does fire after the rules are loaded (for obvious reasons, rules which aren’t loaded can’t get executed). And as I understood that should always happen after item states are restored, but for some reason that’s not the case. It works to some extend but sometimes I need a few restarts to get everything working.
Yep, should be. Curious why you have that issue.
Shouldn’t make any difference apart from randomness, unless the cache is cleared e.g. by upgrade.
The cache also goes stale, should you run a dev system that only gets run up once in a while.
Not sure if this helps, but:
- I have the same problem; that some scripts begin to execute before their dependencies are ready
- In my case, this includes other scripts!
I have opened a PR which:
- Moves the default start level for script processing to 40 (but keeps the machinery that detects/submits it at 20)
- Allows scripts to override their desired start-level, per script.
(If you want to try it out, feel free to use my docker image)
It doesn’t, you never said what language you were writing rules in before this sentence.
I can’t say for sure, but I think it’s because the concept of start levels is a very new one. My guess is that once the language has the start level trigger added, the documentation will be updated. Start level 20 I believe approximates the behaviour of the old system started trigger, so the change should be largely transparent.
If you are interested in looking into it more, I can provide the rule that will log event info.
Probably because of the amount of items I have 
Seems like this is indeed not supported at the moment. This needs a small addition in the DSLRuleProvider.java file and the Rules.xtext file.
This is all feeling like grabbing for bandages that were used with OH2 load asynchronous problems. Some effort was put into improving all this in OH3.
Having MapDB restoring all Items before rules get rolling doesn’t really seem like a difficult target to meet. I’d like to know more about the root problem really - are you sure you’re actually set up for MapDB restore? Is something else coming along and undoing its work, even? How do you identify there is this problem at all? It’s all a bit sketchy and unexamined here.
Yes I am sure the MapDB is setup properly, it is restoring the items perfectly fine. I notice this as some rules complain about NULL-values for some items then. Actually I’m not sure if the items are not loaded at that point or if the state is NULL, I need to check that again.
Apart from that I think it would still be a useful feature to add the start level trigger from the Webinterface to the rules files.
That would be helpful. Note also that a binding could come along and update stuff to UNDEF before it gets rolling properly. We need to be careful not to muddle the cases here.
There are sporadic reports of “Mapdb not working” so there might be something to be nailed down here.
I’m starting to think that there’s a race condition here. I’ve seen numerous occurrences where some rules complain about items being NULL, yet those items are defined with restoreOnStartup using mapdb. In my case, I have 1432 items set to restore on startup.
I haven’t had much time to dig into this yet, but it certainly seems plausible that the rules are running before all the item states have been restored from the mapdb.