This was my key to success:
1 Like
Thanks @sihui! I’ll try it out this weekend. I rarely need to reboot these days, but the shutdown command is nice to have on occasion. Mostly, I’d like to update the guide so that it works for others.
for this I added following rule
rule “piStartup_systemstatus”
when System started or
Time cron "0/15 * * * * ?"then
postUpdate(Flag_System, NULL)end
Did you ever get this figured out? Sorry, I’ve been away from the forums for a long time, and I’m just getting caught up.
On my installation, it was not enough to use
openhab ALL=(ALL) NOPASSWD: /sbin/systemctl
For some reason I had to use
openhab ALL=(ALL) NOPASSWD: ALL
to allow a rule to call ‘sudo -S systemctl restart openhab2.service’. No idea why allowing only systemctl is not enough.
Hello, your example works great for a long time on OH2.5 … But on OH3 I’m having an error:
2021-01-27 13: 36: 19.614 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘system-1’ failed: An error occurred during the script execution: array element type mismatch in system
I would know how to help me solve it, I miss “restart” in the UI.
Thanks!
That’s because executeCommandLine has changed in OH3. So instead of:
executeCommandLine("sudo@@poweroff")
It’s now:
executeCommandLine("sudo", "poweroff")
Every phrase is now put into quotations, and the @@ for spaces no longer works.
4 Likes
Hi @rpwong
Thanks for jumping in on that one! Ive not gone to OH3 yet, so you’ve saved hunting down a problem when I do! 
I’ve put a link into your post on my post further up, so hopefully people will find the change.
Thanks!
Man, thank you very much!
Sorry my noob
It worked perfect!
executeCommandLine is the only thing that doesn’t hold up if someone transfers their existing config files to OH3. Rather than updating this tutorial, I’ll probably write an OH3-specific version and reference this one.
EDIT: I changed my mind and just updated the rules with OH3-specific versions of executeCommandLine.
2 Likes
The same with me. Anybody have an idea?
No idea. I replicated this when I built a new OH3 system on openHABian, and everything above worked just fine.
Hello,
i have started the migration from my OH2.5 to OH3 and have also implemented the reboot/shutdown switch and it’s working fine.Now i also want to replace the sitemap by a page but have not found a way how to setup a page especilly for
Switch item=Restart_Shutdown mappings=["1"="Restart", "2"="Shutdown"]
Switch item=Restart_confirm mappings=["ON"="Yes","OFF"="No"] visibility=[Restart_Shutdown=="1"]
Switch item=Shutdown_confirm mappings=["ON"="Yes","OFF"="No"] visibility=[Restart_Shutdown=="2"]
Any hints what widget should be used and how to get e.g. the mappings into a page are welcome.
I found a solution when searching for somthing else.
In the item defintion you need to add Metadata | State Description and here in the field Options put
"ERROR"="ERROR"
"WARN"="WARN"
"INFO"="INFO"
"DEBUG"="DEBUG"
"TRACE"="TRACE"
In a PAGE you can add a LIST CARD and in the LIST CARD you should use LABEL LIST ITEM for each log swich item.
When you display the page, klick on the Item Label displayed in the page and you get the list from the Option field for your selection
how can i add a delay?
thnx,i meant a delay to reboot after 2 minutes or so…
i used :
executeCommandLine("sudo","shutdown","-r 2")
or
executeCommandLine("sudo","shutdown -r 2")
but did not work…
Did you try:
executeCommandLine("sudo","shutdown", "-r", "2")
In my experience, every device containing software needs periodic rebooting, because all software contains bugs, including resource leaks. This applies to your router, your phone, and of course openHab.
I agree that we should try to resolve any resource leaks that are under our control, but not all of them are. My openHab is periodically soft-rebooted (the openHab service), but the other day the Z-Wave stick stopped communicating with Z-Wave devices, no doubt because weeks had passed since hard-rebooting the RPi. A hard reboot resolved it. I don’t see any practical alternative to periodic power-cycling.
1 Like
It may have avoided symptoms to show up but it is not a cure so it didn’t resolve any problem, that persists. You cannot even be sure you won’t have the same symptoms reappear in the coming minutes or right the day you leave on vacation.
Yes debugging is the tough route many are unwilling to take (and the harder to take the less experience you have). It’s time-consuming and annoying but unlike reboots it is practical, and in fact the only sustainable solution.
Thing is, when you reboot you cannot analyse the system in its broken state which is what you need to do when you don’t know the origin/genesis of your issue. (Auto-)reboots will also destroy many traces and data you would need to identify a root cause. They’re no “solution”, just a strategy to avoid tackling the real problem behind.
Reboots require manual interaction and supervision to ensure everything comes back up working. That you will have to keep doing over and over, for the rest of your (openHAB) life.
Don’t forget reboots also cut service and deteriorate quality (e.g. the zwave network is reinitialized, data collection interrupted etc). Plus, several rules implementations aren’t built to be robust enough against such impact. Not quite uncommon that you start having problems because of a reboot you would not have had without.
openHAB is designed to run 24/7 and many people successfully run it without OH restarts and even more so without system reboots (Linux all by itself - i.e. all the software beyond OH - is pretty reliable and does not require you to). So it can be done. It’s just sometimes tedious work to get there.
Finally, if restarting was an acceptable or (in the long run) less work intensive (read: better, cheaper) means of mitigating issues, people to professionally operate other’s systems (i.e. all of the IT outsourcing business where it’s all about the work=money the operator has to spend) would be doing this all over, all day. They don’t because it just isn’t.