Perfom "reboot" command by openhab

Hey guys,

I need some help again.
I want to perfom a “sudo reboot” command directly from openhab. Either per rule or per button in my sidemap. I already found some tutorials to perfrom linux commands but I’m really not a Linux / Raspberry expert… so unfortunately it isn’t working. Because of limited knowledge I’m not really able to get it running :frowning:

I think I also have to make some changes in the “configuration” but I dont know espscially what I have to do.

rule "Automatischer Neustart"

Time cron “0 0 2 ? * MON *”
executeCommandLine(’“sudo” “reboot”’, 5000)

In case you want to know the reason why I want to do this… please check my old thread All timed rules stopped working.... no idea why I have some issues with rules after longer runtimes and I tried everything which was suggested in that thread but problem is still up. So I try to fix it in that way… I know it’s not the best way to do so… but at least it is a fix.

FYI: when you login with e.g. putty, you are running as user openhabian. OH runs the exec commands with opnhab. Has security reason. However if you want to test your commands when you are e.g. logged in with openhabian in putty, simply put in front of you command to test sudo -u openhab COMMAND

Note that my guide doesn’t work with recent openHABian builds unless you generate SSH keys. There’s a discussion in the comments, but I never got around to implementing it as I rarely need to reboot openHAB these days.

The solution in that thread was to upgrade your system so that you would have more time-based threads. If you’re running more than 10 time-based rules (which I assume to be the case), then it’s not a problem with the system; it’s a problem with your approach. Instead of asking openHAB to do more than it’s capable of doing, let’s rethink how your rules work.

So the question is, how do you reduce the number of time-based rules you need? Something that many of us do is use the Astro binding to identify time of day (sunrise, sunset, etc.) and trigger rules on those changes. That enables things like lights and rollershutters to adjust with the seasons, which I personally find to be preferable over “always do this at 7:00AM”.

If you’re committed to things happening at specific times, then you could set up a time-based rule that updates a proxy item, and trigger all of your other rules based on the proxy item changing. Then you’d only need one time-based rule. Or have a few different rules/proxies if you want to group things together. Just don’t go over 10 and you should be fine.

Yes thats exactly the problem
I get rid of all “time cron” rules that I could do differently. But especially my heating automation is based on timed rules and I have no other idea on how to handle it differntly.

Are timers limited to 10 too?
So I could create my own “watch”.
Lots of switches for the different hours of the day. One “time cron” rules which starts at 0:00. And creates a timer for 5 hours. Now it switches “5 o clock” item to on and also starts a new timer which switches next “x o clock” item to on. Last timer of the day switches all clock items at 23:59 back to off.

Would this work or would I have the similiar issue because the big amount of timers?

I suggest trying to fix the underlying issue (rules) instead of covering up the symptom (reboot).
There is probably something wrong with your rules or it really is a problem with the rule engine.
Nonetheless I’d search there. You can also always try HABApp, there is no limit for timers and such.

Yes thats what I said in my post above :wink:
I tried my best so far but unfortunately in my current scenarios I need the timed rules. What I requested in my post above was if creating a lot of timers would result in the same issue.

Of course I would create the rules in the way that not all timers are running at the same time.

Maybe @rpwong can answer that or I know that @rlkoshak has a lot of knowledge about these things

Did you manage to update to OH 2.5? If not, you can manually increase the threadpool used by the scheduler. Performing a reboot is equivalent to using a sledgehammer to wash your dishes. BTW, the new rule engine does not have this limitation…

1 Like

The key isn’t how many rules you have that are cron triggered. The key is how many are running at the same time. To make sure that you have the minimum number running at a time you need to make sure your rules run fast. No sleeps, no whiles, limit calls to executeCommandLine and sendHttp*Request calls.

It’s not a problem with the number of cron triggered rules or timers, it’s a problem where they are running at the same time. You can have a million timers and cron triggered rules as long as fewer than ten are running at the same time (for earlier versions of OH that number is 2).

NOTE: both cron triggered rules and timers execute out of the same thread pool.

Also avoid the typical mistake to start most stuff at the same time (full hour etc). Randomize start times a little.
And you might want to investigate if you can re-do rules a different way.
Starting via cron often means you just have not found the right event to trigger upon yet.

I’m running 2.5.1-2

@rlkoshak and @mstormi
I tried my best to get rid of most of time based rules. But still have a lots of them. Markus Storm you are absolute right for some things I didn’t found another trigger yet. I guess my main problem comes from my heating. I regulate the temperatur based on type of day (weekday, weekend, holidy, gone, etc) and time. To trigger for example the rule to heat up the livingroom an hour before my working day ends is difficult to trigger without the time.

So maybe my workaround (till i found maybe I find some better triggers) isn’t that bad. I created 24 for items (switches) one item per full hour. The first item of the day is triggerd with time cron the other ones checking the status of the previous item.

rule "Start Zeitgeber"


    Time cron "0 0 0 * * ?"


    sendCommand(Uhrzeit_0, ON)

    sendCommand(Uhrzeit_23, OFF)


rule "Uhrzeitermittlung 1"


    Item Uhrzeit_0 changed to ON


    createTimer(now.plusHours(1)) [|

    sendCommand(Uhrzeit_1, ON)

    sendCommand(Uhrzeit_0, OFF)



rule "Uhrzeitermittlung 2"


    Item Uhrzeit_1 changed to ON


    createTimer(now.plusHours(1)) [|

    sendCommand(Uhrzeit_2, ON)

    sendCommand(Uhrzeit_1, OFF)



rule "Uhrzeitermittlung 3"


    Item Uhrzeit_2 changed to ON


    createTimer(now.plusHours(1)) [|

    sendCommand(Uhrzeit_3, ON)

    sendCommand(Uhrzeit_2, OFF)



So I created my own timer and can delete all my time cron rules and just check the change of the switches. What do you think?

@5iver, this sentence made my day.


To answer your question, I think the command in OpenHAB would be:
executeCommandLine(’“sudo /sbin/reboot”’, 5000)

I’m not a linux expert either, but the command will be run in the context of a certain user, likely the user: “openhab”

It’s most likely that the openhab user does not have the permissions to run the reboot command, and so, you’d need to likely modify the /etc/sudoers file via the ‘visudo’ command and add something like:

openhab ALL=NOPASSWD: /sbin/reboot

You can do ‘man sudoers’ for the gory details. I believe, once you’ve made the appropriate modifications to /etc/sudoers, the command would only need to be:
executeCommandLine(’“/sbin/reboot”’, 5000)

I’m not an OpenHAB expert, so I can’t contibute to that part of the conversation. I hope that you find this helpful.



i used this german blogpost to create a button to reboot OH2.
I hope this helps for the rule.

Important is the hint in the comments:
Das exec Binding war unsicher und daher müssen die Kommandos nun in eine whitelist. Trage die Befehle hier ein
sudo %2$s
sudo /bin/systemctl %2$s openhab2.service

Bye Florian

Hi @floriandd2ba,

its looks like this manual don’t really work…
No reboot of OH or Raspi services, only following log entries:

2020-08-20 21:24:09.705 [ome.event.ItemCommandEvent] - Item ‘OH2_Service’ received command restart
2020-08-20 21:24:09.708 [nt.ItemStatePredictedEvent] - OH2_Service predicted to become restart
2020-08-20 21:24:21.874 [ome.event.ItemCommandEvent] - Item ‘PI_Service’ received command reboot
2020-08-20 21:24:21.879 [nt.ItemStatePredictedEvent] - PI_Service predicted to become reboot


I use this manual last week with Openhabian OH 2.5.7 and it works directly.

2 Ideas from my side:

  1. sudo visudo -f /etc/sudoers.d/010_pi-nopasswd
  • I changed the line “pi” with “openhab”, don’t add a line.
  • I made a reboot after change this file.
  1. exec.whitelist
    This is my misc/exec.whitelist:
    sudo %2$s
    sudo /bin/systemctl %2$s openhab2.service
    sudo /bin/systemctl %2$s knxd.service
    sudo reboot

Bye Florian

1 Like

Hi @floriandd2ba,
reboot was a great idea :wink: :crazy_face:

Thanks & Regards,