I’ve tried both OH5 milestones and the latest snapshots, and all have problems with rules which contain rulesDSL code (Yes, I should migrate this code to something else, but what I have works with OH 4.x)
The error is:
2025-05-15 18:53:44.111 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'af4c760780': Failed to execute action: 7(Cannot invoke "com.google.inject.Injector.getInstance(java.lang.Class)" because the return value of "org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()" is null) ```
Action: 7 code is:
actions:
inputs: {}
id: “7”
configuration:
type: application/vnd.openhab.dsl.rule
script: >
var Number requiredSolar = ((TeslaPowerwall_InstanteousHomePower.state
as Number)+(1 - (TeslaPowerwall_BatterySOE.state as
Number))20000)/5000100;
if (requiredSolar > 100) requiredSolar = 100;
if (EVChargingGroup.state == ON) requiredSolar = 100;
if (NegativeFIT.state == OFF) requiredSolar = 100;
if (NegativeGrid.state == ON) requiredSolar = 1;
logInfo("curtailSolar", "required solar percent = {}, Current Inverter
limit = {}", requiredSolar.intValue,
SolarEdge__Modbus_Data__Active_Power_Limit__61441_Value_as_Number.state);
if
((SolarEdge__Modbus_Data__Active_Power_Limit__61441_Value_as_Number.state
as Number) != requiredSolar.intValue) {
SolarEdge__Modbus_Data__Advanced_Power_Enable__61762_Value_as_Number.sendCommand(1);
if ((TeslaPowerwall_BatterySOE.state as Number) > 0.97) {
logInfo("curtailSolar", "current PW2 charge ({}) > 97%, curtail output",(TeslaPowerwall_BatterySOE.state));
SolarEdge__Modbus_Data__Active_Power_Limit__61441_Value_as_Number.sendCommand(requiredSolar.intValue);
DaikinAirbaseACUnit_Zone4.sendCommand(ON);
} else {
logInfo("curtailSolar", "current PW2 charge ({}) < 97%, set full rate production",(TeslaPowerwall_BatterySOE.state));
SolarEdge__Modbus_Data__Active_Power_Limit__61441_Value_as_Number.sendCommand(100);
}
SolarEdge__Modbus_Data__Commit_Power_Control__61696_Value_as_Number.sendCommand(1);
} else {
logInfo("curtailSolar", "required solar matches current inverter limit, no change required.");
}
type: script.ScriptAction
Any ideas what the error is telling me and what has changed between OH4 and OH5 to trigger this?
All I can say is I’m having the same issue (5.0.0.M2)
As my script was only simple I could re-write it in blocky (or ECMA probably would have worked too).
I had the same problem with DSL-Scripts which I wanted to run in the OH-UI.
Closing the browser tab, opening a new one , browsing to the script and hitting Strg-R again helped???
Luckily, the workaround of disabling and enabling the rule works.
However, this lasts only until the next restart of openhab. This means I currently need to disable and endable all rules manually after each restart of openhab. Even with Openhab 5.1.3.
Is there a fix planed for DSL rules or do you recommend to migrate them?
[ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'config:dsl:get_location_from_sim7600_position' in link 'Sim7600_GPS_Position_Location -> mqtt:topic:fa97435618:053380b097:gps_position': Script type 'dsl' is not supported by any available script engine.
Could it be that the DSL engine is loaded to late and this “disables” the dsl rules? Was there a change in the last versions?
I’m in no way sure what’s happening here, but I definitely think that it might be a startup order problem. Was the DSL in question here part of a managed rule or from a DSL file?
I looked at this a bit yesterday, because I had some “somewhat related” issues in my dev environment, and the ScriptStandaloneSetup injector is configured when the rule engine starts. I’m wondering if the introduction of precompilation of scripts might have to do with it, because if the rule is compiled before the rule engine is started, the reference will be invalid. If the rule engine then later tries to execute the compiled script, it might still point to the previously uninitialized injector. I don’t know exactly how precompilation works, but that would explain why resaving the rules “help”, because that causes them to be recompiled.
I think the whole initialization of ScriptStandaloneSetup is a bit dodgy, I’m not sure exactly why it is like it is.
I don’t know if that is the issue at all, it’s just that precompilation complicates things, and there are times when I wished that it was possible to try without it so eliminate potential issues. Whether it’s worth a PR I don’t know.
I don’t know how easy that would be, but if you set org.openhab.core.automation to TRACE, you should get a lot of information - but I don’t know if you’ll get what you need to figure out the order.
(5.0.0.M2)