Bad indentation with method.invoke
When I create an MQTT thing with the file i.things (below), the file automation/lib/java/helper/generated/mqtt/MQTTActions.java contains:
Method method = thingActionClass.getMethod("publishMQTT", String.class, byte[].class);
method.invoke(thingActions, p1, p2);
There is no indentation on the second line.
ON from the default preset is missing; no erros logged when transformationPattern= cannot be compiled
I have installed OpenHAB 5.1.0 build 4828, which includes Details error message in log when, in an UI transformation, a script is the error cause. by dalgwen · Pull Request #5028 · openhab/openhab-core · GitHub. I create things/i.things
mqtt:broker:b "Q" [host="127.0.0.1", password="1", username="a", clientID="oh5"]
Thing mqtt:topic:i "I" (mqtt:broker:b) {
Channels:
Type switch : a "A" [stateTopic="i1/s", transformationPattern="DSL:|return ON;"]
}
and items/a.items:
Switch always_on {channel="mqtt:topic:i:a"}
This works as expected. Now I change "DSL:|return ON;" to "JAVA:|return OFF;". The value of the item does not change. I have to write instead "JAVA:|return OnOffType.OFF;". But according to JSR223 Scripting | openHAB the value OFF is part of the default preset. I assume ScriptEngineFactory.scopeValues() has to be overriden to get everything from the default preset.
The other problem is that no error appears in openhab.log, even if transformationPattern="JAVA:|return OFF;" cannot be compiled.
Removing the MQTT broker and things leaves generated/mqtt/MQTTActions.java
Now I remove things/i.things. openhab.log contains:
2025-09-17 12:40:13.724 [DEBUG] [.internal.Java223ScriptEngineFactory] - Added/updated thing: Thing 'mqtt:topic:i' has been removed.
2025-09-17 12:40:13.726 [DEBUG] [ernal.codegeneration.SourceGenerator] - Scheduling Things generation in 10000 ms
2025-09-17 12:40:13.728 [DEBUG] [ernal.codegeneration.SourceGenerator] - Scheduling Actions generation in 10000 ms
2025-09-17 12:40:23.728 [DEBUG] [ernal.codegeneration.SourceGenerator] - Generating things
2025-09-17 12:40:23.729 [DEBUG] [ernal.codegeneration.SourceGenerator] - Generating actions
2025-09-17 12:40:23.742 [DEBUG] [internal.codegeneration.SourceWriter] - Wrote generated class: /etc/openhab/automation/lib/java/helper/generated/Things.java
2025-09-17 12:40:23.766 [DEBUG] [internal.codegeneration.SourceWriter] - Wrote generated class: /etc/openhab/automation/lib/java/helper/generated/Actions.java
but generated/mqtt/MQTTActions.java is still present. Just Actions.java is changed with(out) import helper.generated.mqtt.MQTTActions; … public MQTTActions getMqtt_MQTTActions(String thingUID) {return new MQTTActions(actions, thingUID);}. Similarly for Things.java. I think if the generated/ code does not make use of MQTT, because the system has no MQTT brokers and things, the directory generated/mqtt/ should be deleted.
instanceReuse
After reading README for me it is unclear how instanceReuse works. Is it applicable to inline transformations, like "JAVA:|return \"A\";"? Or is it applicable to all kinds of .java scripts, including transformations, but excluding automation/jsr223/*.java files? Also what means “Take note that it uses the compilation cache, managed by openHAB on best effort. So instance reuse is not guaranteed.”? As the caffeine cache is gone, what means “best effort”? Is the seconds sentance (not guaranteed) still relevant? How can I intentionally create a concurrent problem with instanceReuse?
[TRACE] [ation.java223.common.BindingInjector] - Cannot find an element with the key logger
It’s not an issue, merely a deep debug log (this is why I used the trace log level).
The bundle tries to inject openHAB binding value in the script class, and for doing so, checks all class members (by their name). As the name (here, “logger”), doesn’t correspond to anything in the available openHAB bindings values, it logs a trace.
I do not think it is a good idea to log information for irreparable things. Logging should be used for debugging or removing problems, but here something is just logged - causing distraction - and there is nothing useful, which can be done with the information.
null checks in generated/Items.java
When will itemRegistry be null?
It could be null if the user doesn’t use the generated class “Items” as expected (for example, the user instantiate the Items class by himself instead of using the automatic injection provided by the bundle).
How can the user instantiate the Items class by himself?
), and if someone make a good PR with a system like this, I’m not opposed to merge it. But it’s a many hours trip.
