GPIO Variables

Stream Deck & Companion Clear-Com REST Module
1

First off, big thanks for the work that’s gone into this module. I’ve been using a POE powered contact closure device to accomplish my desired workflow, and this will allow me to cut down on some setup time on gigs.

Working through the existing functionality, I noticed the GPIO Trigger variables are giving a value based on the Trigger GPI action. Looking through the log, I see that we have [GpiUpdated] and [GpoUpdated] coming to us from the station but currently tagged as unhandled.

Are there any plans on a roadmap to integrate this information coming to the module as a variable?

The advantage would be having a variable that reflects the current state of the GPI if it was triggered by this module, ccm, or the physical GPIO ports.

Current rig:

Companion - v4.3.4

Arcadia Station - 4.1.83.41

2

Hello;

I did add some GPI functionality, are you using the latest from this site, I think 0.4.7 might be the version?

If you are, and you still aren’t seeing the selection of GPI status in the local variables, please let me know and I can look into adding that when I return. Just away on an out of town gig.
If you don’t hear back in a couple of weeks, please feel free to give me a nudge!

3

Hey Andy,

I am using 0.4.7 from a direct download from here.

I do see “[NEP] GPI Triggered” as a local variable and it does change state based on the “[NEP] Trigger GPI” action.

What it doesn’t do is change state when forcing the GPIOs on or off from CCM.

What I’m seeing is the variable can be left in an incorrect state if the GPIO is forced on or off in CCM rather than using the “[NEP] Trigger GPI” action.

100% no rush for little ole me. I’d even be happy to hop in and contribute with the little bit of free time that exists. I’m also currently hopping around on out of town gigs.

4

Understood. If the basestation reports the status, that’s where the variable’s value SHOULD come from, and then it would be correct regardless of the source. If it’s not working that way (which it sounds like it’s not) then that should be fixed.
Thank you for letting me know!

5

If you get a chance, can you send me a module log showing the messages?
Set the module to “dev” mode, open the module log, clear it, operate a GPI via CCM and also by contact closure (or whatever is connected to the GPI) and export that log and fire it off to me.

6

Absolutely!

After playing with it some more, I see the “[NEP] Trigger GPI” action is using force on and force off.

Could the force off command be changed to turning “force on” off? Like you would do when clicking “force on” a second time in CCM.

When “force off” is active, it prevents the physical GPI pins from triggering the logic.

7

I should have some time to export a log later today actually.

8

I can investigate that. I expect the module is just mimicking how the CCM manually operates (tests?) the GPIs.

9

This arcadia currently has lot going on, so the log fills up fast. Here’s the purganent parts.

Physical GPI 2 being triggered on-off-on-off

image
image1645×113 25.5 KB

CCM GPI 2 force on - force off - force on - force off

image
image1554×112 24.8 KB

CCM GPI 2 force on - force on turned off - force on - force on turned off

image
image1552×109 25.2 KB

10

Companion “[NEP] Trigger GPI” action on-off

image
image1586×163 27.2 KB

11

Ty, could you export it for me please? There’s an export button at the top of the page. You can DM it if you don’t want to post it here.

12

Fresh log DMed to you.

1 Like
13

Edited and replied. LMK if it makes things better or worse!
The force thing will require me to diagnose with my Arcadia to determine what the CCM actually sends to enable and disable the forced status of the GPI.

14

The GPI variable is now correct polarity (even though the true/false is reversed in the log), but I’m not really sure if there’s a way to NOT “force” the operation.