Rules stop firing after a short while, stack trace in logs

Hi,
I am new to openhab and I’m trying to use it to simulate dusk and dawn for my birds so they get a nice sunrise and a nice sunset.

Unfortunately this only works for a couple hours, then the rule fires but the script generates stack traces.

I am running on a Raspberry Pi 1, and I have limited the openhab 2.1 installation to a maximum of 384 MB of RAM so it doesn’t run into allocation errors (default Xmx is 512M, which is a tad too much). The package version is openhab2-2.1.0-1 which I installed from the official repo.

My ruleset and the corresponding scripts are at https://gist.github.com/oliof/2f784ab68a529437d19fa25886859178, the openhab2.log with stack traces is on https://gist.github.com/oliof/467f321923631ddfc7f1d1d11dadbb13

As you can see, dimming down works fine, but dimming up doesn’t (but I omitted the end of the logs where the night-dimming also fails with the same stack trace, i.e., the failure happens after about ten to fifteen sendCommand invocations, and not just during dimming up).

The lamps I am controlling are IKEA Tradfris with the Tradfri Gateway. Using a dimmer item to control the lamps works fine.

Any pointers how to make this more reliable are very welcome! I am considering to buy a newer Raspberry Pi, but am holding off in case this is a configuration issue on my side.

Limiting the amount of RAM is going to make it more likely that you run into allocation errors, not less likely.

OH is memory hungry and the default is set to 512M for a reason.

But having said that, running OH on an RPi 1 is never going to give you adequate performance or a trouble-free install. It is simply too constrained. RPi 2s or better are really needed. So I would recommend getting that newer Pi (avoid the Pi Zeros as they are roughly the same specs as an RPi 1.

OK, looking at the stack trace I’ve no idea what is going on. I’ve never seen those errors before.

Looking at your rules I see some red flags.

  • 30 second Thread::sleeps are a huge red flag. Any sleep longer than 300 msec is to be avoided. The two minute sleeps are bound to cause you some trouble.
  • why are you using scripts for these? It isn’t like you will be reusing the script across multiple Rules. Using a script here is only going to cause OH to require more resources and add one more layer of redirection to get to and understand the code

Given the really long sleeps, I’m going to guess that the thread pool on your RPi 1 that is able to run Rules is really low and the long timers is causing it to run out. In fact, this would probably be a problem on ANY install, not just a RPi 1.

So I recommend:

  • instead of long sleeps use Timers
  • instead of scripts, put the code inline in your rules

Something like the following which uses the Expire binding to run your Timers:

New Item:

Switch Sonnenuntergang_Timer { expire="2m,command=OFF" }
rule "Voliere Sonnenuntergang"
when
    Time cron "0 15 21 1/1 * ? *"
then
    logInfo("Volierendimmer","Volierendimmer: Sonnenuntergang")
    Sonnenuntergang_Timer.sendCommand(OFF)
end

rule "Voliere Sonnenuntergang Timer"
when
    Item Sonnenuntergang_Timer received command OFF
then
    // calculate the new dimmer value
    var newDimmerValue = Volierendimmer.state as Number - 10
    if(newDimmerValue < 0) newDimmerValue = 0

    // log the value and send it to the light
    logInfo("Volierendimmer", "Volierendimmer Sonnenunterganng: " + FadeOutDimmer)
    Volierendimmer.sendCommand(newDimmerValue)

    // if the light is not yet at zero, reschedule the Timer
    if(newDimmerValue != 0) Sonnenuntergang_Timer.sendCommand(ON)
end

Implementing the other four is an exercise left to the student. I might recommend Reusable Functions: A simple lambda example with copious notes as a good place to start.

Hi Rich,
thanks a lot for your detailed answer! I mostly split out the rules and the scripts because I followed an example I found on this forum. Your code looks much saner – I’ll give it a whirl later and will report back whether it helps.

Thanks,
Harald

Hi Rich,
I have adopted your example to my use case and the code is much cleaner, thanks for that!

Unfortunately, I still get stack traces (https://gist.github.com/oliof/14a8bf635fd2e720f892b9cc77db99f2).

I get maybe 25 rather than 16 state changes now before the stack traces turn up, but it’s also evident that openhab2 believes the lamp’s state changed (i.e., it does think the state is 20, and then 10), but the lamp is steady at 30% according to the Tradfri app (and visual inspection)) … next stop for me is either a newer Raspi or a test run with a newer-than-2.1 release.

I really can’t fully explain the error but it is definitely related to resources. I would try on a newer Pi. I’m not so sure that a 2.2 version of OH will change things but it is certainly something to try while you are waiting on shipping for the new Pi. :slight_smile: