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.
Item Zigbee_motion_technikraum_aqara_Occupancy changed to ON
Item Zigbee_motion_werkstatt_aqara_Occupancy changed to ON
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.
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
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?
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.
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.
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.