Error with timer (Cannot assign a value in null context)

[David]

Hi,

I have a floor heating system with an electric pump to distribute the hot water. I placed a 1-wire temp sensor (DS18B20) to measure the temp. of the incoming water. So far so good.
Now I'm trying to switch the pump on and off depending on the temperature of the water. I keep getting error messages when creating the timer.

00:56:58.028 INFO  o.o.model.script.SideKitchen[:73]- --> Temp is > 27
00:56:58.402 INFO  o.o.model.script.SideKitchen[:73]- swSocketBijkeuken1.state = ON
00:56:59.964 ERROR o.o.c.s.ScriptExecutionThread[:70]- Error during the execution of rule 'React 2 temp changes': Cannot assign a value in null context.

This is the rules files

var Timer tHeatPump = null
var DateTime lastHighTemp = now()

rule "React 2 temp changes"
when
    Item nBijkeuken changed
then

    if(nSideKitchen.state>27) {
        logInfo("SideKitchen","--> Temp is > 27")
        logInfo("SideKitchen","swSocketBijkeuken1.state = " + swSocketBijkeuken1.state)
        if ((swSocketBijkeuken1.state==OFF)||(swSocketBijkeuken1.state==Undefined)||(swSocketBijkeuken1.state==Uninitialized)) {
            logInfo("HeatPump","Switch pump ON")
            sendCommand(swSocketBijkeuken1, ON)
        }
        lastHighTemp = now()
        if (tHeatPump!=null) {
            logInfo("HeatPump","Cancel timer")
            tHeatPump.cancel
            //tHeatPump = null
        }
    } else {
        if (swSocketBijkeuken1.state==ON) {
            logInfo("SideKitchen","--> Temp is < 30 and switch is ON")
            // Check if timer exists
            if (tHeatPump==null) {
                logInfo("HeatPump","Timer tHeatPump bestaat nog niet")
                tHeatPump = createTimer(lastHighTemp.plusMinutes(30)) [|
                    logInfo("HeatPump","Timer tHeatPump executed, switch pump off")
                    sendCommand(swSocketBijkeuken1, OFF)
                ]
            } else {
                // Reschedule timer
                logInfo("HeatPump","Waiting for timer to end.")
                // TODO
            }
       
        }
    }
   
end

The temperature is not a steady line. It goes up and down during a heat cycle (see rrd image). Therefor I'm polling the lastHighTemp. With this parameter I'm trying to create a timer, that switches the pump off, after a while (in this case 30 minutes)
I noticed that Ben also had a similar issue. Maybe I'm missing something. I tried to place the rule in a different file, but that didn't help.
Anybody got an idea?

Regards,
David

[Ben Jones]

Sorry mate - wish I knew the answer! I think I have managed to fix my rules but I really don't know what I did that changed things. I thought it might be something to do with having a timer nested within another timer. I have removed that and my rules no longer give that error. But I don't think that is applicable to you.

Would really like to know what causes this exception to be thrown but it is deep within the scripting engine, well beyond my area of expertise.

[David]

I noticed a typo when translating the rule.
The rule is:

rule "React 2 temp changes"
when

    Item nSideKitchen changed
then
....
But this typo is not in the original rule.

I'm using 1.3.1.
This is the item:
Number     nSideKitchen              "Vloerverwarming temp. [%.1f °C]"         <temperature>   (gSidekitchen_Chart, gSidekitchen, gRrd)      { onewire="28.54395D040000#temperature" }

If this error is reproducable, I can enter an issue for it.

Cheers,
David

Op zondag 22 september 2013 01:22:00 UTC+2 schreef David:

[David]

Ok, it seems to work now.
I think the error came from the var DateTime lastHighTemp = now()

Now I store the last time the pump is switched on, in a DateTime item (dtPumpSwitch).

lastHighTemp = parse(dtPumpSwitch.state.toString)
 logInfo("HeatPump","Temperature is < " + iSwitchLevel.toString + ", create Timer to switch off pump. Execution time: " + lastHighTemp.plusMinutes(30).toString)
tHeatPump = createTimer(lastHighTemp.plusMinutes(30)) [|   
      callScript("heatpump-off")
]

Not quite sure what caused the error, but it is working now.

-David


Op zondag 22 september 2013 09:09:29 UTC+2 schreef David:

[Ben Jones]

I am still getting this exception - for some rules. As an example I have a lot of these types of rules (see below). When something trips a 'presence detector', i.e. a door opening, a PIR is tripped, or a camera detects motion, I update a presence variable to ON. I then have these rules to reset the variable after 5 mins. The idea is that as people move around the house they will keep triping these detectors fairly regularly and hence these presence variables should be continuously reset and I should get reasonably accurate presence detection. 

So the rules are quite simple, and the strange thing is some of them execute just fine, and others get the null context error. I can't for the life of me figure out why or what the difference is! I have tried different timer lengths, rearranging the order in the .rules file, copy and pasting existing rules (that work) to ensure there are no funny characters, but it just seems random. Once a rule fails and exhibits this error, it consistently does so, even if I restart openHAB. Then sometimes after making changes to the rules file it will miraculously start working again.

I am convinced it is something to do with the 'now' call in the createTimer() method. But I don't understand why it works sometimes and not others.

BTW - the rules all execute with no issues - i.e. the timers fire for every rule when they are supposed to - it is just that some report this null context error in the openHAB logs.

rule "Entry presence - EXECUTES OK"

when

    Item Presence_Entry received update ON

then

    if (presenceEntryTimer != null)

        presenceEntryTimer.cancel()

    presenceEntryTimer = createTimer(now.plusSeconds(300)) [|

        postUpdate(Presence_Entry, OFF)

    ]

end

rule "Garage presence - THROWS NULL CONTEXT ERROR"

when

    Item Presence_Garage received update ON

then

    if (presenceGarageTimer != null)

        presenceGarageTimer.cancel()

    presenceGarageTimer = createTimer(now.plusSeconds(300)) [|

        postUpdate(Presence_Garage, OFF)

    ]

end

[David]

Hi Ben,

Same here. I thought my errors where gone, but after some modifications in the rules file, they returned.
Unfortunately after this error the rest of the rules file is not executed. After I set the timer, I have some other statements, but these are never executed. If I place these statements before the createtimer, there is no issue. In your code I see the createTimer is the last statement, so it seems to run ok.
Still working on this. This morning I noticed, that none of my logInfo statements reached the log file. But the commands were executed. So there is some work to be done.

Regards,
David

Op maandag 7 oktober 2013 06:37:46 UTC+2 schreef Ben Jones:

[Ben Jones]

Yeah you might be onto something there. I have about 5-6 of these simple rules with timers (for detecting presence). They are all at the bottom of a rules file. And I am noticing it only seems to be the last rule, and sometimes the last two rules, in the file that exhibit this error.

Note: if the second to last rule gives the error, the last rule is still running ok, so this appears a little different to what you are seeing. 

But I am pretty confident it is nothing to do with the rules themselves - since they sometimes work fine. V

Very very puzzling...

[Ben Jones]

Scratch that - now the last 3 rules are doing it. But it does only seem to be the rules at the end of the file that cause this.

[Cyril Jaquier]

Hi all,

I remember that I also had this "Cannot assign a value in null context" error when writing my sun protection rules. I had more or less the same rule defined in two different rule files with variables having the same names. The rules where triggered by the same event (and thus run in parallel, I think from different threads). I noticed that the variables get wrong values in such case. I opened an issue here:

http://code.google.com/p/openhab/issues/detail?id=487

So I think that we have some concurrency issues when triggering rules at the same time. In my case, I saw this "Cannot assign a value in null context" without having any timers in any of my rules.

Do you have such rules that are triggered by the same event? Or maybe rules that trigger other rules?

Cheers,
Cyril

[Ben Jones]

Ok - tried something else - moved all the presence detection rules (with timers) to the middle of my rules file. However I still get one of the Entry/Garage/Living Room presence rules throwing this error. It varies which rule it is after I restart openHAB - but so far it is only these 3 that throw the error. 

One time during a restart I got the error below (which I have never seen before). I don't know if it is related but thought I better log it here in case it helps.

2013-10-09 21:51:46 ERROR o.e.x.x.s.XbaseScopeProvider[:189]- error during scoping

java.lang.NullPointerException: null

        at org.eclipse.emf.ecore.util.EcoreUtil.getAdapter(EcoreUtil.java:148)

        at org.eclipse.xtext.util.OnChangeEvictingCache.getOrCreate(OnChangeEvictingCache.java:107)

        at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:72)

        at org.eclipse.xtext.resource.impl.DefaultResourceDescriptionManager.getResourceDescription(DefaultResourceDescriptionManager.java:58)

        at org.eclipse.xtext.resource.impl.ResourceSetBasedResourceDescriptions.getResourceDescription(ResourceSetBasedResourceDescriptions.java:97)

        at org.eclipse.xtext.resource.impl.ResourceSetBasedResourceDescriptions$1$1.computeNext(ResourceSetBasedResourceDescriptions.java:61)

2013-10-09 21:51:46 ERROR o.e.x.l.l.LazyLinkingResource[:214]- resolution of uriFragment 'xtextLink_::0.2.10.2.0.1::0::/1' failed.

java.lang.NullPointerException: null

        at org.eclipse.emf.ecore.util.EcoreUtil.getAdapter(EcoreUtil.java:148)

        at org.eclipse.xtext.util.OnChangeEvictingCache.getOrCreate(OnChangeEvictingCache.java:107)

        at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:72)

        at org.eclipse.xtext.resource.impl.DefaultResourceDescriptionManager.getResourceDescription(DefaultResourceDescriptionManager.java:58)

        at org.eclipse.xtext.resource.impl.ResourceSetBasedResourceDescriptions.getResourceDescription(ResourceSetBasedResourceDescriptions.java:97)

        at org.eclipse.xtext.resource.impl.ResourceSetBasedResourceDescriptions$1$1.computeNext(ResourceSetBasedResourceDescriptions.java:61)

[Ben Jones]

Cyril - yes I do - this is my rule structure;

// a rule to detect a PIR being tripped - this sets two items to indicate what and where this event occured

// I have similar rules on the garage door - which will update the Presence_Garage and Presence_Door items

rule "Garage PIR tripped"

when

    Item PIR_Garage changed to OPEN

then

    postUpdate(Presence_PIR, ON)

    postUpdate(Presence_Garage, ON)

end

// the presence items are then left on for 5 mins to indicate presence and then switched off

// if something else trips these variables in the meantime they will reset the 5 min counter

rule "PIR presence"

when

    Item Presence_PIR received update ON

then

    if (presencePIRTimer != null)

        presencePIRTimer.cancel()

    presencePIRTimer = createTimer(now.plusSeconds(300)) [|

        postUpdate(Presence_PIR, OFF)

    ]

end

rule "Garage presence"

when

    Item Presence_Garage received update ON

then

    if (presenceGarageTimer != null)

        presenceGarageTimer.cancel()

    presenceGarageTimer = createTimer(now.plusSeconds(304)) [|

        postUpdate(Presence_Garage, OFF)

    ]

end

Do you think this parallel creation of timers could be the cause?

[Ben Jones]

The slightly odd thing is I have never seen the 'PIR presence' rule throw the error...I have even tried changing the order of execution in the 'Garage PIR tripped' rule.

[Ben Jones]

Bingo - the lightbulb went off!! I have found the connection - and it is based on the issue Cyril found I think. I am only seeing the null context error for rules that are triggered on items which are used as triggers in other rule files.

E.g. in my lights.rules file I have;

rule "Garage presence lighting"

when

    Item Presence_Garage received update

then

    if (Presence_Garage.state == ON) {

        if (DayIndoor.state == OFF || Door_GarageDoor.state == CLOSED) {

           sendCommand(Light_Garage, ON)

        }

        if (DayOutdoor.state == OFF && Door_GarageDoor.state == OPEN) {

           sendCommand(Light_Driveway, ON)

       }

    } else {

        sendCommand(Light_Garage, OFF)

        sendCommand(Light_Driveway, OFF)

    }

end

And in my presence.rules file I have;

rule "Garage presence"

when

    Item Presence_Garage received update ON

then

    if (presenceGarageTimer != null)

        presenceGarageTimer.cancel()

    presenceGarageTimer = createTimer(now.plusSeconds(304)) [|

        postUpdate(Presence_Garage, OFF)

    ]

end

So there are two rules with the same trigger and obviously the context is being shared between them somehow, as described by Cyril. 

Thank god I can at least now explain why this is happening!! It was beginning to drive me crazy!

I have no idea how or what to fix but at least it explains what is causing it.

[Ben Jones]

And just to confirm - I merged the two problematic rules (with the same triggers) into one and now I am not seeing any errors. Hopefully Kai/Thomas will be able to track this down at some stage. I can see if causing more headaches as people write more complex configs.

[Cyril Jaquier]

Hi Ben,

Great! I also had an hard time debugging my sun protection rules where I hit Issue 487 and this context null problems. I had no time to investigate them further and preferred to find an alternate, working solution (tons of other things to do in our new house at the moment). So I still have no time to look at this issue :-( But at least I think the problem has been more or less localized.

Cheers,
Cyril

[Kai Kreuzer]

Hi guys,

Great, thanks for nailing down this very tricky bug!

I will try to find the time to investigate the rule engine / Xbase internals to find out the root cause. As an Xtext upgrade to a newer version is due since a few months now already, I will probably first do the upgrade and then check if the issue remains - as there is a slight chance that the behaviour will change after this upgrade.

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

[Ralph Borchers]

Hi Kai,

is this problem with rules in two different .rules files triggered by the same event fixed? If so, since when, cause I still see it with a current cloudbees build (643).

Regards,
Ralph

[Kai Kreuzer]

Hi Ralph,

As you can see in https://bugs.eclipse.org/bugs/show_bug.cgi?id=423532, this has been fixed in Eclipse SmartHome - so for the upcoming openHAB 2.0, this problem will be gone, while it still remains in openHAB 1.x (but is not considered too critical).

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

For more options, visit https://groups.google.com/d/optout.

[Ben Jones]

This might have now been resolved - https://github.com/openhab/openhab/pull/2363