Include module in 3.x builds

[mark-epstein]

Please consider a module to allow Companion to talk directly to the IO of the host computer,

My vision of what this module would do is pretty basic: It would simply include commands to turn a specific output pin on or off; or read the state of a specified input pin.

Use cases: My immediate goal is to use low voltage to control an AC circuit, so that Companion can reliably turn my equipment on and off unattended. I know there are third-party devices that can manage such circuits but they add a lot of complexity/points of failure to the system, not to mention that electrical code regulations suggest I cannot just split a hard-wired circuit and plug it into a controllable outlet. (It's perfectly legal, on the other hand, to insert a certified relay.)

Also a low-voltage control such as is already built-in to the Pi would let me connect to all manner of previously-built electronic circuits and legacy devices that are otherwise unfriendly to remote control. For example, I have an amplifier that has a set of low-voltage contacts to temporarily mute its output. I'd like Companion to be able to control that, as the amplifier has no other control options.

I can (probably, haven't yet tried to) accomplish this with some minimal coding on the RPi and the generic http module. But the generic modules even admonish me to ask for a real module when the device is one that more users than myself are using. I think this fits.

[istnv]

A raspberry GPIO module exists: https://github.com/bitfocus/companion-module-raspberry-gpio

It does not get included in the automatic Companion builds since it is Pi specific.

[mark-epstein]

It does not get included in the automatic Companion builds since it is Pi specific. I don't see why this would matter. It's Pi specific, but every module is specific to the device it is written for. My Companion instance already includes modules for 475 devices I don't have, why would it matter if there were one (or twenty) more?

Sure, I understand that in this case the Pi is the OS as well as the controlled device, but I can't see the logic in using that as a deciding factor whether to include the module. Microsoft OSes run Teams. Should the Teams module be excluded because Companion might run on the same hardware as Teams? (maybe a weak example but not a completely inert one)

Regardless, in the thread https://github.com/bitfocus/companion-pi/issues/26, https://github.com/Julusian says "I know it needs some work before it can be included in the official builds, as part of it is picky about where it is compiled." Then, in that thread the OP mentions what he has to do to get it to compile, which include some liberal handing out of permissions. I know how to do that, but I don't know what I'm risking by doing so.

[istnv]

QLab and most other modules work great from a Pi even though the apps being controlled are not running on the Pi.

The GPIO module is a low level hardware interface that does not behave well when included in other OS builds.

Actual hardware access on any unix requires permission. To use the GPIO module, the companion 'user' needs permission/access to the pins.

FWIW I have used the GPIO module on a Pi and ended up using other options.

Network relay modules work well (TCP -> Relay ON/OFF). (https://a.co/d/e94BDJy)

I have also built Arduino interfaces that take ethernet commands to trigger relays.

[mark-epstein]

ok, that's a fair explanation that doesn't go over my head. I do really appreciate that, particularly the not-going-over-my-head part. Still, it feels (intuitively, not empirically) that adding outboard devices, whether the device you linked or and arduino, adds complexity and points of failure.

not to beat a dead horse, but what if there were a separate app running on the Pi, something akin to midi-relay, that would act as a conduit between Companion and the Pi hardware. Of course that app's user would still have to have the permissions, but does that provide the separation from Companion that you'd think was appropriate? Or am I still not getting it?

[istnv]

Your questions are not that bad. I have had to deal with way worse over the years :) One advantage of the stand-alone modules (or Arduino) is there is no OS to 'hack' Most pi installations are not online all the time anyway so it is usually not that much of an issue.

For the go-between software, there is a module written in python that you can awkwardly talk to from companion shell commands. You need to give that app permissions, too.

The companion module is much easier to use. The updates needed for the user permissions are minimal and specific to the IO pins.

Anytime you type sudo in your pi ssh session you are giving yourself extra permissions, which are way more than necessary to use the GPIO functions. sudo is mainly there to make you think twice about running certain commands.

[mark-epstein]

also, what is this? [ETA: I mean, I can see what it is, can you share a particular part number or source?]

[istnv]

Ethernet panel jack: https://a.co/d/aYX3y2V

This one takes up less space in the box: https://a.co/d/gc9SlNA

The internal ethernet jumper: https://a.co/d/6rYyRDE

The relay 'output' is a headphone jack underneath the wires in the middle.

[Julusian]

Prior to 3.0 we were loading all modules into memory even if they werent used, which could cause issues if some werent suitable to run on the current platform. In 3.0 that changed, so that we only load the manifest.json into memory, and load the code only when the module is used. And they get loaded into their own processes, so don't risk crashing companion.

So having platform specific modules carries no real risk anymore. The only reason I haven't included rpi-gpio in the builds is the build issues I mentioned in that other thread. I started working on that, but haven't gotten around to testing my changes so haven't been ready to merge them. But it will happen one day.

Im going to transfer this to the rpi-gpio module, as I think that once that module is updated and included then this will be resolved

[istnv]

@Julusian Invite me to this repo. I have an update for this ready but need to finish setting up my pi dev system set up to work on a couple of issues that need deeper debugging.

[Julusian]

done.

The work I haven't finished was rewriting/reworking the underlying epoll library to node-api and making sure we don't need to compile it. So there shouldn't be any conflicts

[istnv]

gotcha. I have a fix for a hard lockup if you enable a pin that is being used by the system and restart the module: ENOACCESS -> retry ->ENOACCESS -> retry ad nauseum. Config tab never completes to disable the pin. I may scan first to offer only the pins which could be accessed.

I'm having trouble on the config tab with some isVisible functions that always seem to return false.

The module works fine after aborting the restart cycle for a bad pin.

[istnv]

@Julusian I was able to run this on a non-pi Ubuntu system. Properly shows GPIO is not accessible error. Won't work on a non-pi, but does not crash, either