When the minutes are greater than 60, an error appears in the LOG.
Only if I use function:
I tested with the following Rule
Log Viewer
Error Detail only when minute is > 60
Script execution of rule with UID ‘e70053bcbc’ failed: TypeError: null has no such function “until” in @openhab-globals.js at line number 2 at column number 79926
I don’t think the error has anything to do with persistence. It’s coming from the helper library before your rule even runs.
Do you have more than two options under Settings → JS Scripting for “Variable injection”? If so, try changing that option (e.g to “Auto injection for UI based rules and transformations”), and then open and save the rule generating the error. Does that seem to help?
If you only have two options there I’m not sure what else to try. Maybe just saving the rule to regenerate it will help?
Hi Rick!
Thank you for your reply.
The error only occurs when the number of minutes is greater than 60.
There are 2 calculations for “minutes between” the one that fails is from the Persistence block.
As you can see every minute appears twice one for each option.
The one from Item block keeps running after 60, 70, 120 minutes, etc.
But the block from Persistence stops and gives me an error as soon as the number of minutes is above 60.
There is no error from 0 to 60 minutes.
Regards.
Hi Rick!
This is what I have under Settings → Add-On Settings → JS
The error only happens when number of minutes is Greater than 60!
All counts from 0 to 60 have no errors.
Click on the code tab and post the JS code.
Use code fences.
```
code goes here
```
console.info(('#1 ==> ' + String(time.ChronoUnit.MINUTES.between(items.getItem('RX_433_Porta_Sala_Status').lastStateChangeTimestamp,(time.ZonedDateTime.now())))));
console.info(('#2 ==> ' + String(time.ChronoUnit.MINUTES.between((items.getItem('RX_433_Porta_Sala_Status').persistence.previousState(true, 'rrd4j')?.timestamp),(time.ZonedDateTime.now())))));
console.info(('#3 ==> ' + String(String(parseFloat(String(time.ChronoUnit.MINUTES.between(items.getItem('RX_433_Porta_Sala_Status').persistence.lastChange(),(time.ZonedDateTime.now()))))))));
As soon as the value is above 60 (minutes in this case) there is an error.
Only the first part of the code (#1 ==>) keeps running after 60 minutes.
Please avoid posting screen shots unless absolutely necessary. They are impossible to read on a small screen, cannot be searched or copied from, and often they cut off important information. Text is always better. When posting a rule, click on the code tab. The log reader has a “show logs as plain text” button a the bottom.
Use code fences like you did with the JS.
Anyway, I suspect the problem is with the call to previousState. If the current state of the Item is different from the most recent entry in the database, persistence returns null because it can’t actually know what the previous state was and more importantly when the previous state occurred. That means the code is trying to find the minutes between null and now and that’s throwing an error. The fact that it happens at 60 minutes I suspect might be a fluke of the timing. What’s triggering this rule?
The good news is you don’t need persistence for this anyway. The Item keeps track of the last change and last update itself without needing persistence. Use the get [name] of item block and select “last state change” which will be the timestamp from when the Item last changed states.
The rule runs every minute to check for how long doors are open.
Yes using Item get last state change is the only option that works for a time between minutes greater than 60.
When using persistence previousState from Blockly it only works if minutes between is <= 60.
At first I thought it might be a bug in the Blockly function as it works up to 60 minutes only.
I’m not seeing any error when I query rrd4j for a change more than 60 minutes away. I can’t reproduce the error.
It’s working without problems for me too, as long as I use the example above.
I have already changed my code to only use this option.
My question remains: why, among 3 options for calculating the time between minutes, only one of them works after the counter reaches more than 60 minutes?
In any case, we managed to discover an option that always works and this is very important.
Thank you for your help and guidance.
