Error: "PT2M" is an unsupported type for conversion to time.ZonedDateTime

Strange bug maybe.

Whenever I restart my Pi, I get error messages for some timers in the logs that say:

“PT2M” is an unsupported type for conversion to time.ZonedDateTime
at toZDT (/openhab/conf/automation/js/node_modules/openhab/time.js:281)
at check (/openhab/conf/automation/js/node_modules/openhab_rules_tools/timerMgr.js:46)
at execute (heating_OpenWindowSensing.js:111)
at execute (@openhab-globals.js:2))

If I edit the rule and make any change, even just adding an empty line, and save it, it will work again as expected.

Anyone else see this behaviour?

On OpenHAB 4.0.0M3

Are you using the built in helper library or have you installed the helper library manually using npm.

Which version of the helper library and openhab_rules_tools library? You should be able to tell by looking at the package.json file or, if both are recent enough you can get both printed to the log using:

var {helpers} = require('openhab_rules_tools');;;

If that doesn’t work, you are running rather old versions of one or both. I believe the latest version of the helper library is 4.4.0 and the latest version of OHRT is 2.0.2.

Every time you restart or only sometimes?

How are these rules triggered?

File based or UI based rules?

Ultimately the problem is that it’s not recognizing the string “PT2M” as a standard ISO8601 duration string. It is valid so something weird is going on (this has been supported basically since time.toZDT() was written.

One good thing to try is to make sure you are running with the latest of both libraries to see if the problem persists. If you are using an older version of the helper library installed through npm you can change the settings of the JS Scripting addon to use the built in version instead as that one should be relatively recent (4.2.0 I think for M3).

It would also be informative to know if this is also a problem in OH 4.0 M4.


I am using the built in helper library. I did experiment with the npm install some time ago, but I believe my settings are correct now.

My JS Version seems to be 4.5.0.
I got an error from the second line though:

ReferenceError: "OHRT_VERSION" is not defined

I think it happens every restart. Can’t be 100% sure though.

Rules are usually triggered my a motion or contact sensor in the cases I’m seeing errors in the log.

They are file based JavaScript rules.

I upgraded to M5 yesterday, but the problem was happening on M4 too

OK, that means your openhab_rules_tools library is out of date. You’ll need to upgrade it using npm, or remove it and reinstall it.

If you are running openHABian there’s an option in openhabian-config to do this.

FolIow this Updating packages downloaded from the registry | npm Docs , I tried

npm update

from the /conf/automation/js/node_modules/openhab_rules_tools folder. It looked like something was successful, but I still get the same error when checking the OHRT version.

Am I doing it wrong?

What’s in your automation/js/packages.json file?

Run the update from the automation/js folder, not that deep in the folders.

I ran npm update from the folder you said, and a few more things seemed to be successful. But stil no OHRT version in the log.

my package.json file has:

  "dependencies": {
    "custom_npm": "file:../custom_npm/custom_npm-1.0.0.tgz",
    "openhab": "github:openhab/openhab-js",
    "openhab_rules_tools": "^1.2.0",
    "suncalc": "^1.9.0"

On a side note, how can I remove this openhab-js now that I am using the included libraries again?

npm is such a pain sometimes. The latest version is 2.0.2 of OHRT. But npm won’t automatically upgrade major version numbers like that.

It might work to change the version number in package.json to “^2.0.2” and then run the upgrade. If that doesn’t work, use npm uninstall openhab_rules_tools, double check that the line is removed from package.json, then reinstall.

That last bit should also tell you how to remove openhab-js.


I’m convinced I have 2.0.2 installed now, but still the same log error: ReferenceError: “OHRT_VERSION” is not defined

Doh, typo.;

You still needed to update because there are changes in openhab-js and OH itself that impacted openhab_rules_tools.

Yep, that did it. Up to date now.

Hopefully that’ll be an end to that problem now.

Thanks again

hmm… It’s happening again

Error: "PT15M0.000178329S" is an unsupported type for conversion to time.ZonedDateTime
    at toZDT (/node_modules/openhab.js:2)
	at check (/openhab/conf/automation/js/node_modules/openhab_rules_tools/timerMgr.js:46)
	at execute (lights_sensorDetection.js:170)
	at doExecute (@openhab-globals.js:2)

And now I can’t fix it by resaving the rule file.

A fix seems to be to add .toString()


Hmmm, it should work with a time.Duration class too. Post your full code around the call to check() on timer manager. I tried the following code and it works for me.

var {helpers, timerMgr} = require('openhab_rules_tools');'Running scratchpad.');'openhab-js version: ' + utils.OPENHAB_JS_VERSION);'OHRT version: ' + helpers.OHRT_VERSION);

var tm = new timerMgr.TimerMgr();
var dur = time.Duration.ofMinutes(1);
tm.check('scratchpad', dur, () => {'Timer'); });
2023-07-20 14:15:43.569 [INFO ] [nhab.automation.script.ui.scratchpad] - Running scratchpad.
2023-07-20 14:15:43.570 [INFO ] [nhab.automation.script.ui.scratchpad] - openhab-js version: 4.5.0
2023-07-20 14:15:43.571 [INFO ] [nhab.automation.script.ui.scratchpad] - OHRT version: 2.0.2
2023-07-20 14:16:43.576 [INFO ] [nhab.automation.script.ui.scratchpad] - Timer

Of course this could be tested with a simple


as that also hits the code that seems to be causing problems.

var { timerMgr } = require('openhab_rules_tools');
let manager = cache.private.get('openWindowsTimerMgr', () => new timerMgr.TimerMgr());

let radiatorName = event.itemName.replace('_Radiator_AssociatedContactSensors', '')
let deBounce = 'deBounce_' + radiatorName;
const Heating_Debounce = items.Heating_Debounce // a number item
const deBounceDuration = time.Duration.ofMinutes(Heating_Debounce.numericState).toString() // the toString() is the bit that makes it work for me

manager.check(deBounce, deBounceDuration, checkOpenings, true)

It doesn’t address the root problem, but there is a Debounce rule template. You may not need this rule at all.

It’s really weird that the Duration is resolving to PT15M0.000178329S. What state is Heating_Debounce? I’d expect it to be an integer, not a float. In particular, when the error occurs what’s the state of that Item and what does the error message say the Duration became?