Exec and 433hz script help

Hello Gents,

its been a good 5 days that I’m scratching my head without much luck - I just started using Openhab and I’m currently trying to power up my desk lampe using some 433hz plug,

I can run it without any issue from the shell using the send command, so proof of concept work fine,

I’m currently trying to get it working using the sitemaps,

  1. execbind is installed
  2. I have try to add a thing using the smarthome designer no luck
  3. I have added a thing using paper UI - and by having the output enable, I can see the log - I’m sure it’s a question of permission, even if my visudo looks good


Thing exec:command:Bureau [command="/etc/openhab2/scripts/bureauON.sh", interval=15, timeout=5]


Switch Bureau “Bureau” { channel=“exec:command:Bureau:run”}


Frame label="Bureau" {
Switch item=Bureau icon="light"


User privilege specification

openhabian ALL=(ALL) ALL
openhabian ALL=(ALL) NOPASSWD: ALL
openhabian ALL=NOPASSWD: /etc/openhab2/scripts/*
openhab ALL=(ALL:ALL) ALL
openhabian ALL=(ALL) ALL

(I have try different type so I might clean this a bit)

output from paperUI:

wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Permission denied. Try running with sudo? wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Permission denied.

my script that I’m currenttly trying to run:

for run in {1…5}
/etc/openhab2/sitemaps/rcswitch-pi/send 01111 4 1

and my permission on that script

[11:20:21] openhabian@openHABianPi:/etc/openhab2/scripts$ ls -l bureauON.sh
-rwxr-xr-x 1 openhabian openhab 88 Mar 25 10:46 bureauON.sh
[11:20:26] openhabian@openHABianPi:/etc/openhab2/scripts$

also in general, tail -f /var/log/openhab2/openhab.log isn’t give me much information, is there a way I can have a debug level on the log?

thanks for your help guys!

Really no expert with regards to the exec binding…but guessing from the error message provided shouldn’t your command be like:
command=“sudo /etc/openhab2/scripts/bureauON.sh”

I’ve try that already before, adding sudo and trying to run the script from the shell ask me everytime for the sudo password, so I guess its a no go

thanks for your input much appreciate :slight_smile:

again,just an educated guess here:
clean up your sudoers file. IIRC the entries are worked top to bottom and the last entry for a user counts.
You shoud have only one entry per user, like so (mighty guess here):
openhabian ALL = NOPASSWD: ALL

First off, no IoT app/user should ever be given root privilege!

There’s far too many good reasons to avoid that, many well beyond your own personal home automation’s security.



So, given that, the first thing is

wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Permission denied. Try running with sudo? 
wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Permission denied.

Giving access to /dev/mem is a huge security hole. Don’t do it!
No idea where that suggestion came from, but if it’s openHAB code, somebody should remove it and properly document how to access GPIO

At least /dev/gpiomem is a little more restrictive.

$ ls -l /dev/gpiomem 
crw-rw---- 1 root gpio 244, 0 Mar 14 19:17 /dev/gpiomem

You need to give your openhab user an effective group of gpio – and only for this script, not in general.

(Checking for a robust, limited way to do that now)


Thanks Oli, I have clean the sudoer file,

jeff, this is the issue I’m currently unsure how to give access

thanks both!

From https://github.com/r10r/rcswitch-pi

:thumbsup: 100% with you there. Didn’t really think that one through…

currently running the wiringPisetup, I’ll keep you posted Sir!

thanks :wink:

here is the result:

[17:08:53] openhabian@openHABianPi:/$ ls -l /dev/gpiomem
crw-rw---- 1 openhabian root 245, 0 Mar 20 01:17 /dev/gpiomem
[17:09:27] openhabian@openHABianPi:/$

I have also confirm wiringPisetup is working, as I can read the gpio header via “gpio readall”

but still same issue apparently

Two ways to do this, one is to give the openhab user blanket access to /dev/gpiomem (which sounds scary, at best). The other is a carefully crafted statement in /etc/sudoers or in a file in /etc/sudoers.d/ or wherever your particular distro sticks it.

You likely want openhab to only be able to access certain scripts, and probably scripts that don’t have any parameters (that way what then can do is locked down). Looks like you already do that in your script, rather than calling the send script directly.

Those scripts should have tight privileges; likely owned by root and writable only by owner, if at all. You want to provide group read and execute access to gpio so that openHAB can later “play as” gpio and get limited access to your low-level hardware and memory.

So the parameters of the sudoers restriction should be along the lines of

  • user: openhab
  • host: this host only
  • can’t change UID
  • can change GID to gpio
  • can only execute /full/path/to/script1, /full/path/to/script2 (or whatever)

I haven’t tried this before with sudoers on Linux but it might be something like

openhab   ALL = (:gpio) NOPASSWORD: /full/path/to/script1, /full/path/to/script2

and then passing -g gpio to sudo so that the group is changed, but not the user.

Edit: Yes, it says “ALL” there for hosts, but sudo config is often distributed over a large enterprise with LDAP and the like. ALL ends up meaning “the host this is installed on, whatever that might be”

Is openhabian UID 0?

Otherwise it looks like someone did something rather insecure when they customized the distro.

this is the output,

[17:24:04] openhabian@openHABianPi:/$ whoami
[17:24:05] openhabian@openHABianPi:/$ id openhabian
uid=1000(openhabian) gid=1000(openhabian) groups=1000(openhabian),5(tty),20(dialout),27(sudo),113(openhab)
[17:24:07] openhabian@openHABianPi:/$

my knowledge playing with group is limite with linux environement,

not sure what next

Hey, don’t undersell yourself!

That someone customized the distro to loosen up access to /dev/gpiomem is unfortunate, but will be a pain if you ever want to upgrade or move to another platform.

You certainly don’t want to give your openhab user access to the root group!
(I often call it wheel, being from a BSD background)

It’s a bit of a mess as they’ve set up the device privileges. You could use a stanza like I had above, but use (openhabian) instead of (:gpio) to change user (instead of changing just group)

openhab   ALL = (openhabian) NOPASSWORD: /full/path/to/script1, /full/path/to/script2

Definitely restrict access to the specific scripts, given that I’m guessing that openhabian has password-less access to sudo for anything.

I haven’t looked at Linux device generation in a long time, but if I were running openhabian, I’d either be looking at changing the device permissions, or getting off of it quickly, given the questionable security choice already seen. From a “standard” RPi distro:

$ fgrep -r gpio /etc/udev/
/etc/udev/rules.d/99-com.rules:SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"
/etc/udev/rules.d/99-com.rules:SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
/etc/udev/rules.d/99-com.rules:	chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
/etc/udev/rules.d/99-com.rules:	chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
/etc/udev/rules.d/99-com.rules:	chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\

so in your opinion, I might have to reinstall OH2 from scratch?

that a possibility I haven’t done it much yet - I’d rahter having a clean system from begining then pulling the air out of my head to get it working due to potential user issue I created trying to fix it

thanks for your intensive answer

I don’t know that installing OH2 from scratch is required

More that my personal choice would be to install a “standard” OS (Raspbian on RPi, Ubuntu on ODROID) and install OH2 from packages, or local build as to your own needs. For me that means a well-known platform to start with.

this is what I’ve done using the net install on my RPi

Not sure where the changes to the permissions from “stock” Raspbian came from. I’ve got to get some door handles and locks in, so it might be a while until I can look into the code at https://github.com/openhab/openhabian

I’d get it working with what you’ve got, and transitioning in the future should be pretty straightforward if you keep good notes.

thanks Jeff,

I might wait for some other idea as well - no idea why its so hard to have basic exec command runned and have a basic integration working :frowning:

Locks mainly in, but need to run to the hardware store to finish. When you get a chance, would you run

$ fgrep -r gpio /etc/udev

and PM me the result. It shouldn’t be sensitive, but still…