Out of memory exception due to expire binding

Add-ons Bindings
1

Hi community,

For some weeks I had every 2 days an out of memory exception in openhab. I have investigated the problem and figured out that it has to be the expire binding which I use in combination with an aqara motion detector and a physical switch with a Shelly 1. As soon as I deactivated the expire binding the out of memory problem disappeared.

I guess that there is a problem when the item with the expire binding will be switched off manually over the physical switch.
In my case I use this setup on my rooms in the basement. Most of the time the lights turn on with the motion detector and when I leave the room I turn it off manually over the regular switch. But sometimes we forget turning the lights off and therefore I used the expire binding.

Now I switched my setup and use zigbee2mqtt with the aqara motion sensor. With zigbee2mqtt I also get an off signal for the motion and therefore I don’t need the expire binding anymore.

Maybe there are more people with this problem and maybe there is an explanation in the expire binding about the out of memory exception. But maybe there is a bug in the binding.

Just want to share my results with you.

Sebastian

1 Like
2

Thanks for sharing this, @SebastianG! I’ve added categories to your post.

Personally, I use timers instead of the expire binding, for no reason other than personal preference. So if you need to do something similar in the future, that’s an option to consider.

3

It’s bit unlikely that you would be the first to find a bug in the expire binding after some 5 years.
It may be more to do with how you use it.

4

This are my items

Switch Shelly1_light_werkstatt_10_Relay_Power "Werkstatt" (gLights) { expire="5m,command=OFF" }
Switch Shelly1_light_technikraum_25_Relay_Power "Technikraum" (gLights) { expire="5m,command=OFF" }
Switch Zigbee_motion_werkstatt_aqara_Occupancy "Werstatt Occupancy"
Switch Zigbee_motion_technikraum_aqara_Occupancy  "Technikraum Occupancy"

And this is the rule

rule technik_motion
when
	Item Zigbee_motion_technikraum_aqara_Occupancy changed to ON
then
	Zigbee_motion_technikraum_aqara_Occupancy.sendCommand(OFF)
	Thread::sleep(1000)
        Shelly1_light_technikraum_25_Relay_Power.sendCommand(ON) 	
end

rule werkstatt_motion
when
	Item Zigbee_motion_werkstatt_aqara_Occupancy changed to ON
then
	Zigbee_motion_werkstatt_aqara_Occupancy.sendCommand(OFF)
	Thread::sleep(1000)
       	Shelly1_light_werkstatt_10_Relay_Power.sendCommand(ON)
end
5

Nothing particularly alarming there.
Sleeps over a few hundred milliseconds are not advisable, but will not cause disaster on their own …

… unless you repeatedly call the rule quicker than the sleep duration (which would pile up multiple starts of the rule, all at different points in their sleep).

However, I wouldn’t expect that to cause an out-of-memory either. It would generally just stop any further rules from starting, once thread pool used up.
Sometimes people set large thread pools when they’ve been having rule delay issues, so I suppose it is possible.

Missing background here is what/when sets these xxx_Occupancy Items to ON.
Because the rule immediately sets it OFF again, it is possible that the mystery setter-of-ON could repeatedly act at a fast rate.
Your events.log would reveal if anything like that was going on.
Simply moving the OFF action to after the time delay might alleviate that.

6

The xxx_Occupancy items is set to ON from a motion detector. Detector sends only a motion every minute after it detected a motion. So the rule is running every minute, therfore I didn’t care about the 1s sleep. Should not be a problem at all.
I immediately turn it off, because I know that there won’t be any new turn ON in the next minute.
I didn’t find anything wrong in the events.log

7

Thanks for the hint with the timers. Next time I try it with timers. But to be honest the expire binding is super easy to use for such simple topics.

8

I’d agree from your description. Your events.log will tell you the truth.

Yes, many people use it and it hasn’t changed for years, which is why I am skeptical about it causing your problem.

9

For sure. Like I said, it’s just preference. Whether you build an expire into an item or build a timer into a rule, the end result is pretty much the same.

Saying that, I would recommend createTimer instead of Thread::sleep, per @rossko57’s comment that it’s not advisable to sleep for too long. I got that advice early on, so I just decided to avoid Thread::sleep altogether.

Out of curiousity, why are you using Thread::sleep to delay your switch by one second instead of just having the Shelly turn on immediately?

10

There is often the situation that I switch the light on with the physical switch. Most of the time the motion detector and the rule is faster than my hand and instead of turning the light on with my hand, I turn the light off. The result is a dark room before and after I pushed the switch.
Therefore I need a waiting time in openhab.
I have not found a better solution for it so far.

11

Not sure how many rules you have, when they run, or if it’s related to the memory issue but for the number of threads can be checked.

From the console use openhab> shell:threads --list |grep -i “ruleEngine” and see how many threads are being use during motion detection.

Also, from the console what is the output of:
openhab> config:list "(service.pid=org.eclipse.smarthome.threadpool)"

If you suspect a possible thread issue try changing the thread pool by setting org.eclipse.smarthome.threadpool:ruleEngine=20 in /etc/openhab2/services/runtime.cfg restart OH and see if that makes a difference.

12

I have disabled all the rules to really find out the problem. So I have only the posted rule and the expire binding which caused the out of memory issue.
I can try your command and post the result. But first I have to reconfigure the item and install the expire binding again and then wait a day.

13 
openhab> shell:threads --list |grep -i “ruleEngine”
221488 x pipe-grep -i “ruleEngine”                                                                     x RUNNABLE      x 501      x 410
openhab> config:list "(service.pid=org.eclipse.smarthome.threadpool)"
----------------------------------------------------------------
Pid:            org.eclipse.smarthome.threadpool
BundleLocation: null
Properties:
   discovery = 5
   safeCall = 10
   service.pid = org.eclipse.smarthome.threadpool
   thingHandler = 5

this is the result right after I reconfigured and ran the rule for 4 times.

Let’s see what happens after 1 or 2 days

14

Now it works for 10 days without any issues. Looks like the reinstall of the expire binding has fixed the issue.
Very hard now to exactly find out the reason.
Thanks for your help

1 Like
15

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.