openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)
openHAB version: openHAB 5.1.3
Issue of the topic: Adding new items to new channels triggers partial and related rule reload; also happens when adding these new items to a new group.
Please post configurations (if applicable):
Items configuration related to the issue
Sitemap configuration related to the issue
Rules code related to the issue
Services configuration related to the issue
If logs where generated please post these here using code fences:
Hmm, this is weird… when I add a new thing to a channel, a few rules restart; why it that?
This shouldn’t be the case. This means I can’t edit / add items, without the risk of restarting rules… which causes havoc with longer running and cascading rules.
2026-03-25 07:38:48.190 [INFO ] [openhab.core.model.script.Astro.1.02] - ToD rule triggered at...: 2026-03-25T07:38:48
2026-03-25 07:42:27.611 [INFO ] [aml.internal.YamlModelRepositoryImpl] - Adding YAML model ___tmp_model_1.yaml
2026-03-25 07:42:27.631 [INFO ] [aml.internal.YamlModelRepositoryImpl] - Removing YAML model ___tmp_model_1.yaml
2026-03-25 07:46:17.648 [INFO ] [b.core.model.script.Irrigation1.0.00] - System start or rule file reload for Irrigation1.0
2026-03-25 07:46:18.227 [INFO ] [nhab.core.model.script.PACE_BMS.0.00] - System start or rule file reload for PACE_BMS.
2026-03-25 07:46:19.313 [INFO ] [b.core.model.script.Irrigation2.0.00] - System start or rule file reload for Irrigation2.0
2026-03-25 07:46:19.938 [INFO ] [openhab.core.model.script.Astro.1.02] - ToD rule triggered at...: 2026-03-25T07:46:19
2026-03-25 07:47:58.024 [INFO ] [b.core.model.script.Irrigation1.0.00] - System start or rule file reload for Irrigation1.0
2026-03-25 07:47:58.722 [INFO ] [nhab.core.model.script.PACE_BMS.0.00] - System start or rule file reload for PACE_BMS.
2026-03-25 07:47:59.480 [INFO ] [b.core.model.script.Irrigation2.0.00] - System start or rule file reload for Irrigation2.0
2026-03-25 07:47:59.679 [INFO ] [openhab.core.model.script.Astro.1.02] - ToD rule triggered at...: 2026-03-25T07:47:59
2026-03-25 07:48:43.658 [INFO ] [b.core.model.script.Irrigation1.0.00] - System start or rule file reload for Irrigation1.0
2026-03-25 07:48:44.392 [INFO ] [nhab.core.model.script.PACE_BMS.0.00] - System start or rule file reload for PACE_BMS.
2026-03-25 07:48:45.251 [INFO ] [b.core.model.script.Irrigation2.0.00] - System start or rule file reload for Irrigation2.0
2026-03-25 07:48:45.625 [INFO ] [openhab.core.model.script.Astro.1.02] - ToD rule triggered at...: 2026-03-25T07:48:45
Steps:
Create MQTT Thing
add channels
add new items to channels
saving after each added item triggers unrelated rule reload.
Any hints appreciated.
I enabled DEBUG for core:
2026-03-25 08:11:57.787 [INFO ] [openhab.core.model.script.Astro.1.02] - ToD rule triggered at...: 2026-03-25T08:11:57
2026-03-25 08:32:59.047 [DEBUG] [e.model.rule.jvmmodel.RulesRefresher] - Item "Sensor_Temp_Humi_04_LAst_Updated" added => rules are going to be refreshed
2026-03-25 08:33:20.808 [DEBUG] [e.model.rule.jvmmodel.RulesRefresher] - Item "Sensor_Temp_Humi_04_LAst_Updated" removed => rules are going to be refreshed
2026-03-25 08:33:51.437 [INFO ] [b.core.model.script.Irrigation1.0.00] - System start or rule file reload for Irrigation1.0
2026-03-25 08:33:51.912 [INFO ] [nhab.core.model.script.PACE_BMS.0.00] - System start or rule file reload for PACE_BMS.
… and it seems this is by design; but why?! I get it if I modify an item that forms part of a rule; but not willy-nilly restarting unrelated rules!
Must likely not. I’m not seeing this behavior at least.
All rules in one fine are loaded and unloaded as a unit. So if there’s a reason to release just one role in a file of 20 rules, all 20 will get unloaded and recreated.
But if this is a new Thing linked to new Items, there shouldn’t be a need to reload any rules, unless it’s still the case that all rules are reloaded for any Item change.
I permanently have openhab.log open (24x7) as it is the quickest indicator if something goes pear-shaped. Hence, when I add items, as I did, I can see this log ticking over; and in this case, giving me the messages as listed.
Given these were new items, they are not part of any rule, no other rule should be triggered. If it does, as it did, then “System started” has become useless. Instead of guarding for NULL, I create new System started rules that preset values and guard for NULL or UNDEF. Reason being, initialisation should not happen on rule save… and only rules affected should reload when an item changes, not unrelated ones.
So, there is clearly something wrong, and if it is considered correct behaviour than the design is wrong. I mean, a reload kills running timers; cron jobs do not get triggered past their time, etc. There “system started” no longer happens at system start; meaning this trigger has become useless, because the system has not restarted; only a rule was saved.
… and I haven’t found a solution… I need something to check that only exist on system started…
any ideas how I can detect a true system started to guard against initialisation on rule save? Ot simply do not initialise values, but rely on restoreOnStartup?? I would have to think about the implications.
What matters is the file. And Group membership could make them being used by a rule without their being mentioned by name.
System started rules always trigger when the rule is loaded and that start level has passed. So if a rule’s file is reloaded, the system started rules will trigger. This is the designed behavior.
And again, reloading is always file based. If one rule in a file needs to be reloaded, OH has to reload the whole file. It can’t reload individual rules from a file. So if one needs to be reloaded, they all are.
That remains to be seen. If there truly are no rules impacted by these items, there might be something wrong. But if they are, even tangentially through Group membership or something like that (including global variables) the behavior is the designed behavior. That’s what I’m trying to figure out.
It’s always been this way. There are technical limitations as well as legitimate use cases. You can open a new issue and try to relitugate the issue but it’s been argued about more than once.
You could try calling systeminfo API and parsing out uptime if it is less then some value you define as a valid restart then it may be possible to restore whatever values you had in your sequence of the concerned workflow
Again, not going to stop the reload of rules as has been pointed out but may help keeping your workflow sanity intact
It’s always been this way. There are technical limitations as well as legitimate use cases. You can open a new issue and try to relitugate the issue but it’s been argued about more than once.