ok, I’ll clean tmp and cache and restart
… no change 
I’ve fired up the VM again and created a new rule:
rule "Context Test" uid="context-test"
when
Time cron "0 0/1 * * * ? *"
then
logError("Test ctx", "ctx: {}", ctx)
logError("Test inputs", "inputs: {}", inputs)
logError("Test eventObject", "eventObject: {}", eventObject)
end
Triggering the rule manually produces:
21:53:33.111[ERROR] [org.openhab.core.model.script.Test ctx] - ctx: {event=Execution triggered by manual, ruleUID=context-test}
21:53:33.111[ERROR] [org.openhab.core.model.script.Test inputs] - inputs: {}
21:53:33.111[ERROR] [org.openhab.core.model.script.Test eventObject] - eventObject: Execution triggered by manual
Letting it trigger produces:
22:06:00.543[ERROR] [org.openhab.core.model.script.Test ctx] - ctx: {0.event=Timer 0 triggered., ruleUID=context-test}
22:06:00.543[ERROR] [org.openhab.core.model.script.Test inputs] - inputs: {0={event=Timer 0 triggered.}}
22:06:00.543[ERROR] [org.openhab.core.model.script.Test eventObject] - eventObject: Timer 0 triggered.
openhab> bundle:list -s | grep -i core.model.script
210 x Active x 80 x 5.2.1 x org.openhab.core.model.script
211 x Active x 80 x 5.2.1 x org.openhab.core.model.script.ide
212 x Active x 80 x 5.2.1 x org.openhab.core.model.script.runtime
Hi Nadar,
for some strange reason those implicit variables cannot be resolved on my system. I double checked my setup which seems perfectly fine and looks like yours:
openhab> bundle:list -s | grep -i core.model.script
210 │ Active │ 80 │ 5.2.1 │ org.openhab.core.model.script
211 │ Active │ 80 │ 5.2.1 │ org.openhab.core.model.script.ide
212 │ Active │ 80 │ 5.2.1 │ org.openhab.core.model.script.runtime
What could prevent resolving the implicit variables? I c&p’ed your rule into my DSL rule file and get:
2026-08-15 16:02:00.780 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'context-test' failed: The name 'ctx' cannot be resolved to an item or type; line 28, column 34, length 3 in timer
Thanks!
I really have no idea. I didn’t just do this on my development system, I pulled a completely standard Docker image where I tested it - so I have no idea. Just to eliminate some really freak circumstances, I don’t think I’ve tested it using a .rules file (too much hassle to edit files on a remote VM running inside Docker, I access it with SSH), so what I’ve done is use the “Code” tab in the UI and paste the rule code (you must change/remove the UID). Just to be absolutely sure, can you try to do the same with a test rule?
That’s it. For some reason, these aren’t injected when you use .rules files:
18:10:00.286[ERROR] [org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'context-file-test' failed: The name 'ctx' cannot be resolved to an item or type; line 5, column 34, length 3 in ctxtest
That’s definitely a bug, and it’s no wonder why you can’t make it work. Make the rule in the UI until the bug has been fixed…
edit: All you have to do to “import” the rule is to open the existing, file based rule in the UI, scroll to the bottom, and click “Duplicate”. That will make a copy that is stored in the JSONDB.
Yes, $ctx is a UI rule thing to carry the rule execution “inputs” data. For file-based rules (SimpleRule) it’s provided via the inputs argument to execute. See SimpleRuleActionHandler (openHAB Core 5.3.0-SNAPSHOT API)
Unlike the helper library assisted creation in other languages, DSL doesn’t use SimpleRule. It always creates a “full” rule, although the shared context is “hacked in” by putting a comment in the code that references the ID of the context. As such, there should be no difference between file-based on JSONDB based rules, and there must be some form of bug AFAICU.
I found the problem, and it’s all my fault 
I’ve made a fix, but I don’t know when or if it will get merged: