Js script file: actions.Things null in OH 5.1M1 → Fixed with require('openhab').actions.Things

BigGeorgeTx · October 20, 2025, 4:37pm

While this is probably obvious to experienced js programmers, it took me a while to figure out what was needed so I thought I would share it.

actions.Things null in OH 5.1M1 → Fixed with require(‘openhab’).actions.Things

Problem: In OH 5.0.1, my script worked with:

javascript

let actions = require('@runtime').actions;

let thingStatusInfo = actions.Things.getThingStatusInfo(thingUID);

OH 5.1M1: actions.Things was null:

text

actions properties: ["dispose","get"]

actions.Things is null

Solution:

javascript

const Things = require('openhab').actions.Things;

let thingStatusInfo = Things.getThingStatusInfo(thingUID);

Tested: Amazon Echo (amazonechocontrol:…) and Tuya (tuya:tuyaDevice:…) bindings Logs:

text

Successfully loaded Things from openhab.actions.Things: ["getThingStatusInfo","getActions","class"]

Thing status for MasterLightSwitch_PowerState (...): ONLINE

Setup: OH 5.1M1, org.openhab.automation.jsscripting 5.1.0.M1, “Use Built-in variables for file scripts” enabled

Why this works: require(‘openhab’).actions.Things directly accesses the Java Things API, bypassing the actions.Things null issue.

Before:

javascript

let actions = require('@runtime').actions;

thingStatusInfo = actions.Things.getThingStatusInfo(thingUID); // null

After:

javascript

const Things = require('openhab').actions.Things;

thingStatusInfo = Things.getThingStatusInfo(thingUID); // ONLINE

rlkoshak · October 20, 2025, 7:31pm

tl;dr: This is not supposed to be required. Try changing the variable injection settings for the JS Scripting add-on and restart OH.

There are some exciting changes to JS Scripting that are basically mostly done in OH 5.1 M1.

Changes are being made so we can use proper const, let, and return in UI rules and the event Object in UI rules will not match the wrapped and enhanced event Object that file based JS rules get.

Both of these are separately enabled or disabled in addition to enabling automatic injection of the helper library variables (e.g. actions) in the add-on settings. Here is what the new settings looks like.

Now when I upgraded to OH 5.1 M1 this didn’t go super smoothly. I was seeing errors similar to what you report indicating that the helper library variables were not being injected for some rules. What I did was toggle “Auto injection for UI-based scripts and transformations”, save and restart OH. Sometime later I toggled it back to first option. That seemed to fix it but I don’t know for sure if that was a fluke or not nor am I absolutely certain what I saw was an error (yours is only the second after my experience that seems similar).

But in short, if any of the first three injection options is selected, actions should be there without importing it with a require.

When “Wrap UI-based scripts in Self-Executing Function” is enabled, you can use let, const and most importantly return in your scripts (note changes in OH 5.1 M2 should enable the wrapper for all JS Script Conditions and this toggle will only impact JS Script Actions.

When “Convert Event from Java to JavaScript type in UI-based scripts” is enabled, instead of the raw Java event Object with all the pain that is (a Java String is not a JS String), the same JS event Object file based JS users have enjoyed all this time will be used. The old property names are still there, but a deprecation warning will be shown in the logs. See JavaScript Scripting - Automation | openHAB for details.

sihui · October 20, 2025, 7:50pm

There is at least one more:

BigGeorgeTx · October 20, 2025, 9:23pm

Thanks for your comments.

Since what I have is working, is it OK to just leave it? Or would it be better in the long run to try and go back to what worked in 5.0?

Based on the ALERT on line 182 in the 5.1M1 release, when it didn’t work initially I switched to the second options on the JS Scripting options page, Auto injection for UI …

github.com/florian-h05/openhab-distro

distributions/openhab/src/main/resources/bin/update.lst

main


      
          ALERT;MQTT Binding (Home Assistant): Devices that use custom payloads or states now have that abstracted, so users should only use the default payloads. Rules and UIs may need to be updated for some devices.
          ALERT;Shelly Binding: Thing type shellypro2-relay was renamed to shellypro2. Delete the existing thing and re-discover the device.
          ALERT;Teslascope Binding: The Teslascope binding was refactored in order to support discovery. You now need a bridge device for the Teslascope binding to work.
          ALERT;Tibber Binding: All channels have been renamed and restructured into groups. All items will need to be relinked to the new channel IDs.
          
          [5.1.0]
          ALERT;Automower Binding: Implementation of Automower WebSocket API causes several channels to be removed, changed or added. New channels will need to be linked, existing items need to be adjusted.
          ALERT;evcc Binding: Restructured to modular things with auto-discovery of datapoints. You must reconfigure settings, recreate Things, and adjust Items as previous configurations are incompatible.
          ALERT;Freebox Binding: The binding has been removed from the distribution. You should consider migrating to the FreeboxOS binding.
          ALERT;JavaScript Automation: The event object in UI-based environments has been aligned with the file-based event object. Properties are now pure JavaScript types and property names have changed. Blockly users need to resave their scripts.
          ALERT;JavaScript Automation: Automatic injection of the openHAB JavaScript library now allows for more fine-grained control. It is recommended to manually import required namespaces from the openhab library in file-based scripts and transformations and disable automatic injection for file-based scripts and transformations.
          
          [[PRE]]
          [2.2.0]
          DEFAULT;$OPENHAB_USERDATA/etc/org.ops4j.pax.logging.cfg
          
          [3.0.0]
          DEFAULT;$OPENHAB_USERDATA/etc/log4j2.xml
          DEFAULT;$OPENHAB_USERDATA/etc/org.ops4j.pax.logging.cfg
          
          [3.1.0]

All of this is well over my head, so happy to have it working.

rlkoshak · October 21, 2025, 3:42am

There nothing wrong with importing it. But be careful. Future you may not remember why you did it. I usually try to be nice to future me and be consistent everywhere. That works means reverting, or chasing the setting and explicitly importing everything.