I don’t see anything obviously wrong and you are correct in that it appears to be happening in the time.toZDT call.
Do some experiments in -Scratchpad- and see if you can generate some Strings that time.toZDT fails to parse and file an issue.
I myself have recently encountered a weird case where “08:00” is failing but only some of the time and I get a different error so I can’t say if it’s the same issue as you are having.
But since you are using OHRT, why not use a looping timer for this? That kind of what it’s there for. That will make the whole rule a lot simpler. TimerMgr is really meant for cases where you have one rule triggered by lots of different Items and you need to manage one separate timer per each Item. Using TimerMgr to handle just one single timer, as is done here, is awkward.
I also don’t understand the whole “Processor” code at all. Why not use the cache for the count and hard code the key?
var { LoopingTiemr } = require('openhab_rules_tools');
var lt = cache.private.get('LoopingTimer'); // you are using the private cache so there's no chance of naming conflict with another rule
var interval = 'PT3S';
console.warn('0');
// Reschedule if LT already exists
if(lt !== null) lt.timer.?cancel();
// Create the looping timer
lt = LoopingTimer();
// Add the timer to the cache
cache.private.put('LoopingTimer', lt);
// Start the timer looping
var loopCount = 0;
lt.loop( () => {
loopCount++;
if(loopCount >= 10) return null; // stop looping
console.warn('1:'+loopCount+' '+interval);
const parsed = time.toZDT(interval);
console.warn('2:'+loopCount+' '+parsed);
return parsed; // will run the loop again at interval
}, interval);
There’s nothing special you need to do to store loopCount, it’s saved in the context in the timer function. But if you did need to save it outside of that, use the cache, not this to store it.
The looping timer reschedules itself based on what the timer function returns. If it return null the loop stops. If it returns something that time.toZDT() can handle it reschedules the next run for that time.
First of all, thanks a lot for the tip to use LoopingTimer. It is the particular thing I need.
But I am worrying about the problem in calling time.toZDT. It is failing with any string interval (PT3s, PT10s, PT5s), but only if it is called in function called by timer which started in function called by timer (look at the log, the first call was succeed, but the second call failed). It looks like a bug inside the engine and it may appear in other cases.
There is a lot of awkwardness in how the code is written which could be getting in the way here too so I can’t really draw any conclusions about what is causing the problem. I do know that I use a couple hundred timers in my rules and I use the ISO8601 duration strings for all of them.
You will notice though that the LoopingTimer example I posted also parses the duration String inside the Timer’s function. If parsing really is a problem because it’s inside a timer function, the same error will occur there too.
The advantage is there won’t be all that extra stuff getting in the way like the reimportation of time, trying to store variables between runs in this, the odd way to define the function within a function, etc.
