Error from forEach loop of group

Hi,

I have integrated my Verisure alarm into OpenHAB. It works well, but I want to reset the status of items if they are not updated and thus should not be trusted.

To do this, I created a rule

// Reset all values if too old (older than 15 mins)
rule "verisure_reset_if_lastupdate_too_old" when Time cron "0 0/1 * 1/1 * ? *" then
        val DateTimeType timenow = new DateTimeType(now.toString)
        val DateTimeType lastupdate = new DateTimeType(verisure_lastupdate.state.toString)
        val Number mdiff = (timenow.zonedDateTime.toInstant.toEpochMilli - lastupdate.zonedDateTime.toInstant.toEpochMilli) / 1000
        // If older than 15 mins
        if (mdiff > 900) {
                logInfo("Verisure", "Last update older than 15 mins, NULLing items")
                verisure.members.forEach[ i |
                      i.postUpdate(NULL)
                ]
        }
end

This does not work, I receive errors:
020-06-18 13:33:00.020 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule ‘verisure_reset_if_lastupdate_too_old’: String index out of range: 10

The verisure group contains all the verisure items, as well as some subgroups.

I tried to add logInfos into the forEach loop to find out why, but it seems it hits the error before looking into the loop.

What might be the problem?

So you’d be attempting to postUpdate a Group Item? Not allowed. Not sure if that is your error, though.

Thank you for your reply!

You are probably correct. However, I don’t understand how I can avoid iterating through the subgroups without removing the groups from the main group (verisure). I tried to reduce the forEach loop as much as possible to gain info on where it fails. However, it fails without producing output. My idea was to test if i is an item, not group, before proceeding. But that seems to be impossible if the error stops the iteration before the loop content is executed?

verisure.members.forEach[ i |
                        logInfo("VerisurePurge", i.toString)
                ]

2020-06-18 14:53:00.020 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule ‘verisure_reset_if_lastupdate_too_old’: String index out of range: 10

As a follow-up, I removed all the subgroups from the verisure group, but that has no result. It still fails. The items in the group are of String, DateTime, Switch, Contact and Number types.

Some basic tools here


You can test or filter for myItem.type ‘Group’ I believe

But as I said, not at al sure that is your error message, that’s something about strings.
You didn’t say if you see that logInfo() before the forEach … are you getting past the DateTime stuff successfully?

1 Like

Design Patterns: Generic Is Alive or just using the Expire binding might be a better overall approach.

You should use UNDEF as the state instead of NULL. NULL means not initialized. UNDEF means we don’t know what state the device is in. In this case, UNDEF is more appropriate.

I don’t see anything obviously wrong that would generate that error. Are you sure verisure_lastupdate doesn’t have a NULL or UNDEF state? I could see that error occurring if that were the case.

1 Like

Thank you for your replies rossko57 and Rich!

I was unaware of the Expire binding. I believe that is a much better solution than my tinkered rule, so I implemented that on the items instead. Until now it is working well.

Because of the above, I didn’t investigate the error further. The verisure_lastupdate will be NULL on startup (all verisure_ items are), but they are updated at least every 5th minute. The error occured even after update, so it is unclear to me what caused it. The logInfo was never executed in the loop, so I couldn’t investigate it easily further.

Thank you for your support, it is well appreciated!

In the future, when debugging problems like that, add additional log statements and log out all the relevant information (e.g. in this case the value of verisure_lastupdate.state, mdiff, etc. When code doesn’t work or stops working, it’s because what you think is happening differs from what is actually happening. Logging out the values of the variables will either confirm your assumptions or show where your assumptions are wrong and the solution usually becomes apparent.