the official openhab guide says for the “system started” rule trigger
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.
Is there any chance to get system started trigger to only use if the system really started. I want to use it for some minor rules for the very spezific and rare case of a system start or reboot of my PI. But I don’t want to have these rules fired everytime a change some items.
No, it’s been like that ever and a change would annoy many people.
It only happens with text items, so why don’t you move to UI.
You can also try to separate your “system started” rule into a separate file, AFAIK it’ll only trigger if items are used in the same file.
so it only happens if I change items which are used in the same rule file as the system restart trigger is used? or am I getting this wrong?
so in theroy I could create a rule file which uses the system restard trigger and create my on trigger in form of a item. and do nothing else inside this rule file.
@mstormi, does the System started trigger work at all in OH 3 still in .rules files? They do not exist any more in UI created rules. Instead OH 3 introduced the concept of start levels and now you can trigger a rule based on the OH start level.
Not that these are system start levels so they behave much closer to what you are asking for @c0rtez. Once OH reaches start level 100 it remains there. So if you change your rules, even the start level reached triggered rule, it won’t trigger again until OH itself is restarted.
There is talk on gitHub about adding a Rule loaded trigger which will trigger the rule more like the old System started trigger but there are some technical challenges to make it work and some discussion on when the trigger should actually trigger the rule. So to cause the rule to trigger when it is reloaded the current recommended approach is to manually run the rule in the UI by pressing the play button for the rule when you know you’ve reloaded it.
Yes although I believe it is unreliable in doing so. There was or still is some open issue on that.
Yes it does. And as far as I can see in my logs it does it reliable (OH3.0.1, all rules still in files):
2021-03-08 18:31:43.836 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'heizung.rules'
2021-03-08 18:31:51.362 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'wasser.rules'
2021-03-08 18:31:51.646 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'rolladen.rules'
2021-03-08 18:31:54.063 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2021-03-08 18:31:57.536 [INFO ] [org.openhab.ui.internal.UIService ] - Started UI on port 8080
2021-03-08 18:31:58.463 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
2021-03-08 18:32:01.499 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = xxxxxx, base URL = http://localhost:8080)
2021-03-08 18:32:05.739 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2021-03-08 18:32:06.899 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2021-03-08 18:32:12.135 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2021-03-08 18:32:12.136 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2021-03-08 18:32:15.200 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2021-03-08 18:32:15.202 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xa)
2021-03-08 18:32:15.203 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 29: Not initialized (ie node unknown), ignoring message.
2021-03-08 18:32:15.205 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 30: Not initialized (ie node unknown), ignoring message.
2021-03-08 18:32:28.238 [INFO ] [rg.openhab.core.model.script.default] - ##### Initialize system on startup starts
2021-03-08 18:32:28.325 [INFO ] [rg.openhab.core.model.script.default] - ##### Initialize system on startup ends
2021-03-08 18:32:28.328 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
what you show is logging content.
That what was meant by rlkoshak is if rules can make use of the current ‘running state/level’ to detect it and execute something depending on the state.
That is a good question. Does anyone have any insights in this?
Besides this, I also can confirm that the “normal” system start trigger is very reliable in OH3, but it would be nice to also be able to use the new start levels in .rules files.
There are two concepts, which can be used:
- The old one with the trigger “when system started then…”. This one still exists in OH3, but it can only be used in rules files, the GUI does not offer a way to define rules based on this trigger as far as I have seen. This is the concept I confirmed still works, which was rikoshaks question.
- The “new one”, which is exclusively offered by the GUI with the level definition you referred to. It cannot be used in (EDIT: DSL-) rules files.
I did not experiment if a mix of both are possible. Most likely it will work as I do not see technical restrictions that the two interfere with each other from a triggering p.o.v. If one tries to define actions by rules based on both concepts that relate to the same items it might lead to “interesting” results, though
I doubt that the start level triggers are impossible in .rules files. I think we just don’t know how to use them.
I agree it might be possible, from a technical p.o.v. But as long as it is not documented how it can be done, we cannot use it. That’s what I meant.
I’m not a native english speaker, so it is sometimes difficult for me to express exactly what I mean. Sorry for that.