GPIO binding: Switch to pi4j

[ThomDietrich]

I'd like to suggest extending the GPIO binding to support pigpio as an easier way to use GPIOs on the Raspberry Pi. The GPIO binding creates a lot of problems for users as it needs system settings modifications, which differ from system to system, resulting in numerous forum discussions. pigpio is a small daemon providing GPIO functionality without elevated permissions of any kind. At first sight this sounds like a great deal.

What do the previous authors think? @danielbarron42 @9037568 @Speederc @dpslavov

[watou]

I would be curious to see how pigpio compares to pi4j in terms of range of supported systems, functionality possible without needing elevated privileges, etc.

[ThomDietrich]

I have no experience with one or the other. pi4j also looks promising. Whatever works, right ;) However: for me the most important requirement would be to make usage easier, meaning lifting the permissions problem... http://pi4j.com/faq.html#permissions

[watou]

Absolutely agree that not having to run as root is very important for usability. That seems to have been remedied (see here).

[ThomDietrich]

I actually know about this enhancement. It's less related to pi4j and more to Raspbian - and that's the problem. It seems like the base I'm using for openHABian does not create a gpio group. However I didn't take the time to investigate myself yet and am sure this can be solved, I just will have to look into that. Using pigpio would have been one solution.

I have to admit, that pi4j offers some nice features. The important question now: Do you see yourself looking into that?

[watou]

It would be a fun project to make an openHAB 2/ESH binding against Pi4j. The things/channels would be pretty obvious. I will think about that!

Meanwhile, here is a related issue: #4583

It seems like the base I'm using for openHABian does not create a gpio group.

That sounds like a possibly temporary problem, it has a hopefully temporary workaround to run as root, and of course doesn't apply to users on Raspbian and maybe other distros. If the common solution is to use the gpio group or some other distro-specific solution, then the binding should not be written to be constrained by it (my opinion anyway).

[ThomDietrich]

You totally made your point plus pi4j seems like a great base for that binding. As I said, I'll have to look into the problem from openHABian's side. I've renamed the issue. Would be great to hear news soon ;)

[watou]

@ThomDietrich would it be OK if you close this issue and open a new one in openhab2-addons requesting a new OH2 binding that expresses functional requirements like these:

• Event-driven GPIO changes (no polling)
• Logical pin numbering system that does not require any openHAB reconfiguration when moved to new hardware
• Package any required native libraries in the binding using the OSGi Bundle-NativeCode directive so no prior native installation is required
• Functions by having added any needed privileges to openhab user account instead of requiring openHAB to be run as root (whenever possible)
• Support multiple common platforms where GPIO access is possible, with ability to add future platform support when available
• Clear, usable, sensible Things and Channels

I think the OH1 GPIO binding should be left in its current state and a new OH2 binding written that meets the above requirements.

[ThomDietrich]

I fully agree this should be moved over as this will effectively be a new binding anyhow. I'll close this one, you could create the new one, leading with your list of requirements ;) Thanks for looking into that topic!