Rule fails only sometimes

Setup, Configuration and Use Scripts & Rules
1

I wrote a rule that informs me when the doorbell is used. Most times the rule works fine. But sometimes I get an error in the logfile and the notification fails to appear.

2017-10-31 11:11:58.052 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 14: Originating Command Class ALARM (0x71) was on the root node.
2017-10-31 11:11:58.120 [INFO ] [eclipse.smarthome.model.script.Rules] - Item doorbell changed from 'CLOSED' to 'OPEN'
2017-10-31 11:11:58.140 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Es hat geklingelt': An error occurred during the script execution: The name '<XFeatureCallImplCustom> && <XBinaryOperationImplCustom> ' cannot be resolved to an item or type.

The code of the rule is:

rule "Es hat geklingelt"
when Item doorbell changed
then
     logInfo("Rules", "Item doorbell changed from '" + previousState + "' to '" + doorbell.state + "'")

     // Avoid triggering on system start:
     if ( doorbell.state == CLOSED && previousState == OPEN || doorbell.state = OPEN && previousState == CLOSED ) {

         var SimpleDateFormat df = new SimpleDateFormat( "dd.MM.YYYY HH:mm:ss" )
         var String Timestamp = df.format( new Date() )

         logInfo("Rules", "Es hat geklingelt (" + Timestamp + ")")
[...]
    }
end

As you can see, the error must happen between the first and the second log - otherwise the second log would appear in the logfile.

Due to “XBinaryOperationImplCustom” in the error message, I assume that something goes wrong in the “if”-clause. The strange thing is that most time the rule works fine. Only sometimes this error appears.

Does anyone has a clue about what is going wrong here?

When the rule works fine, the following output is logged:

2017-10-31 11:12:18.755 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 14: Originating Command Class ALARM (0x71) was on the root node.
2017-10-31 11:12:18.811 [INFO ] [eclipse.smarthome.model.script.Rules] - Item doorbell changed from 'OPEN' to 'CLOSED'
2017-10-31 11:12:18.866 [INFO ] [eclipse.smarthome.model.script.Rules] - Es hat geklingelt (31.10.2017 11:12:18)
2017-10-31 11:12:19.178 [INFO ] [eclipse.smarthome.model.script.Rules] - Telegram sent
2017-10-31 11:12:19.583 [INFO ] [eclipse.smarthome.model.script.Rules] - Telegram with Picture sent.

So I believe that the warning “NODE 14: Originating Command Class ALARM (0x71) was on the root node.” has nothing to do with the error (even if the same node is affected).

  • Platform information:
    • Hardware: RaspberryPi 3
    • OS: openhabian
    • Java Runtime Environment: openjdk version “1.8.0_121”
    • openHAB version: openHAB 2.2.0~20171024193001-1 (Build #1069)
2

I don’t really know what could be wrong but you can eliminate that if statement if you use

Item doorbell changed from OPEN to CLOSED or
Item doorbell changed from CLOSED to OPEN
3

If this isn’t a copy/paste error, you probably need to change this to say doorbell.state == OPEN

4

I have such errors often occur when rebooting OpenHAB. Not always, but there are. It sometimes swears on one rule, and it happens by ten. I’m sure that the error is not in the rules, I assume that when loading OpenHAB, something else did not load and caused an error in the rule. In the process of work, I did not notice such mistakes, I’ll observe further.
And you have in the process of work or also at the start of OpenHAB?

5

Thank you for your quick answers!!!

@Olymp: the problem not only appears after (re-)starting openHAB, thus also in the process of work.

@namraccr: thank you for this! A real rookie mistake :frowning:

@rlkoshak: I will try this too. Thanks for this!

Thank you again. I will check your proposals and keep you updated!

Best regards, Nico

6

Yes, that’s right! I watched, indeed during the work such errors also appear, and not only after a reboot.

7

Hi @nbar,

Funny: I’ve exactly the same usecase like you. Have a Fibaro DoorSensor connected to my doorbell.

Unfortunatly I got the same problem like you. My rule fires only sometimes. Most time it don’t. And I’ve got the same warnings in my log-file.

2018-01-03 15:34:55.875 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class ALARM (0x71) was on the root node.
2018-01-03 15:34:56.204 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:34:56.296 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:34:56.385 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class ALARM (0x71) was on the root node.
2018-01-03 15:34:56.700 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:35:04.305 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class ALARM (0x71) was on the root node.
2018-01-03 15:35:04.624 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:35:04.706 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:35:04.795 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class ALARM (0x71) was on the root node.
2018-01-03 15:35:05.114 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.
2018-01-03 15:35:05.214 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 40: Originating Command Class BASIC (0x20) was on the root node.

Have you been able to solve this problem meanwhile?

Edit: Excluded and then reincluded the device. Nothing changed.