I’ve been working on flash rule for a Leviton DZPA1 switch module. The following rule results in the runtime error below. Not stating the rule is correct, just that the error results. (Rule operates without the repeat.)
Also, formatting is a bit messed up when editing the repeat:
I wonder if this error might not be caused by too many instances of the rule running at the same time…?
There doesn’t seem to be anything stopping the repeat action - this will end-up becoming a problem…
Try deleting the rule completely and starting from scratch. Make sure you aren't using the browser navigation or just leaving the page. Only use the navigation buttons in the page to leave (clicking 'done' until you're back at the main app page). I've caused some RM errors in the past by starting to create something (trigger, action, etc.) and navigating away without finishing it.
Both the issues that @Sebastien has indicated result from the same flaw with this rule:
There is no condition that stops the repeat.
Without fixing that issue, you will have multiple iterations of this rule run into each other - causing havoc; ultimately, this will slow your hub down to a crawl.
Notice buttons missing in the formatting image in original post. Using Firefox and if I zoom out, the buttons appear and formatting is correct:
I’ve rewritten the rule numerous times and experimented with while-repeat. Whenever the formatting was incorrect, the “Cannot cast object '' with class 'java.lang.String' to class 'double' on line 8564” error resulted. The following operates correctly – not stating cause and effect, but something is amiss with the Firefox/HE/formatting:
When I first created the rule, I included while-repeat. It didn’t work whatsoever, so I removed the code to include what I thought was causing the problem for posting. If the rule had been looping, I think it would have done so after working the first iteration.
“Cannot cast object” is probably a bounds or instance error.
Regardless, my goal is to create a rule that will turn a switch on/off ("flash") when HSM is armed and a contact sensor is open before or opened after the arming. This rule accomplishes that (maybe there’s a better method):
This throws the same error as above. Only difference is a method to aggregate the contact sensors into a virtual switch using another rule. It should work, but it doesn’t…
I just mocked up your rule. The only exception is that I'm not using HSM and it worked flawlessly. Have you tried swapping the HSM parts out for a virtual switch and testing?
Do you have logging enabled for this rule? If so, what action (or maybe trigger) happens right before or around the error? That may assist with troubleshooting. My guess is also re-entrant execution, but that's a guess without knowing more.