PM on your way, but that didn’t return me any output
edit: I’ll post it here has I need to wait 16hours before I can submit a new PM
[20:18:54] openhabian@openHABianPi:/$ fgrep -r gpio /etc/udev
[00:20:15] openhabian@openHABianPi:/$
nothing returned, I’ve also try with root - still no go
I’m also still struggling with this whole safety access things…
I believe a tutorial/example of how to safely use exec binding with scripts would be a great addition here in the forum or the documentation. @ThomDietrich for the rescue?
Hmmm, strange. Without knowing what’s setting the permissions on your devices, it’s sort of hard to figure out how to get them set to the more standard approach of restricted owner (root, typically) and providing group access to processes that need it.
I had try a new and clean installation on my PI2 and still no go
I’m actually running out of idea to have a simple 433hz command to work 
Are you using Exec Binding 1.1 or 2.0? The structure differs between the two and I think your structure is suited to the 1.1 version.
This issue with SUDO permissions has made me confirm my plans for the future. I’ll be moving away from the Pi and use MQTT to a ESP01 with the 433Mhz transmitter connected as this seems like a more secure approach.
this is the version on my exec:
binding-exec - 2.0.0
and I agree about mqtt with an ESP01 - I’m just awaiting the mail to show up but until now I wanted to give a try,
still no luck even using thing, my items looks like this now:
Switch lamp “Standing Lamp” { channel=“exec:command:cc1e0198:run” }
but still no go
I’m using the 1.1 binding at the moment so can’t help much other than point you towards this documentation:
I came accross another issue using the ESP8266, maybe this is not for me lol very frustating to not be able to control that outlet!
so here we go, I have found back on my desk an ADAFRUIT ESP8266, following this instruction:
I’m able to see connection from the ESP8266 to the Openhab mosquitto mqtt, therefore when I’m pushing the remote control from the outlet to gather the code using the small RX chip, I can’t see anything, screenshot below:
it might be my wirering issue, looking at the datasheet of the ESP8266 ( https://learn.adafruit.com/assets/24745 )
I have determinate this on the User_Config.h:
#ifdef ESP8266
#define IR_EMITTER_PIN 14 // 14 = D5 on nodemcu #define only usefull for ESP8266
//RF PIN definition
#define RF_RECEIVER_PIN 6 // 5 = D1 on nodemcu
PIN 6 = #0 on the board If I read this right
right now its connected and I can see the GPIO LED blinking a lot, but nothing appear on the console
if I connect the RX to pin #4 from the board, I can then see this type of traffic:
home/sensors/ir 171832605
home/sensors/ir 2152765278
home/sensors/ir 4094388610
home/sensors/ir 3834259140
home/sensors/ir 919255103
home/sensors/ir 1463816273
home/sensors/ir 4109716517
home/sensors/ir 1160727496
home/sensors/ir 3168146175
home/sensors/ir 417090275
home/sensors/ir 3654779680
home/sensors/ir 441054874
home/sensors/ir 1243567641
if I read this right, it’s look like the system see the chip as IR rather then RF?
any idea guys?
Jeffsf,
I’m a little bit confused, and totally not an expert.
This is not mentioned as comment but as a suggestion.
A stupid question is it not better in this case to use the advantage SUID, SGID and sticky bit, to give not owners, member of groups, not others the same permission, make it executable.
http://thegeekdiary.com/what-is-suid-sgid-and-sticky-bit/
Is this not a safer way of working instead of trying to do it as root?
setuid programs and the associated sticky bit can be a good way to provide very limited access to elevated privilege. The mechanism isn’t designed to restrict who can do something, but what – for example changing one’s own login password, but not being able to touch anyone else’s. Setuid programs are virtually all written in “hard code” and not in scripting languages and are pretty rare.
User and group membership are the standard way of managing access to resources under POSIX systems. That includes setuid programs as well. (Yes, there are security contexts that go beyond user and group access, but that still falls into “advanced topics” for most non-professionals).
The way it should be done is that /dev/gpiomem has ownership that allows “normal” POSIX group-membership access.
I just checked a completely different RPi that I have and it, as well, has root:gpio ownership of /dev/gpiomem
That openHABian or something else has changed the ownership of your /dev/gpiomem really has to be resolved to provide robust access to your GPIO pins.
