Stopped sending codes; help needed

[jdtsmith]

So this was working fine for me for many weeks, but has recently stopped working once I started using other GPIO pins on input with a plugin that uses SysFS to interact with the GPIOs (homebridge-gpio-wpi2). It had been working fine using WPI2 for other GPIO outputs, but now the codes do not apparently get sent. I can send the same code successfully using 433Utils codeSend so I know the transmitter unit is working. Any debugging advice? No pin has changed. Any negative interaction between GPIOMEM output and SysFS input?

[n8henrie]

As I replied in https://github.com/n8henrie/node-rcswitch-gpiomem/issues/5 -- I'll mess around and see what I can figure out. This might be above my head. I'll either close this issue or the other one once I figure out what library is more relevant (I think it will be node-rcswitch-gpiomem, but we'll see).

[jdtsmith]

I think what's happening is this: if you have two active homebridge plugins both using WiringPi and GPIO's, they stomp all over each other in terms of calling different flavors of wiringPiSetup, wiringPiSetupSys, or wiringPiSetupGpio which sets global WPi variables: see here. In addition to accessing the GPIO's through different system, these various setup flavors utilize different underlying pin numbering (WPi, BCM, BCM). And since different plugins run the wiringPiSetup* commands at various times (some every time you toggle a switch), this randomly breaks the behavior of other plugins. I think that is the entire issue. That is, if you have compatible pin numbering among all WPi-GPIO-interacting plugins, can you switch freely between gpiomem, the normal (old-style) memory based GPIO fiddling, and SysFS. But only one such system will be active at a given time.

What I've found works is patching other tools to give an option to all use the same WPi system (so far I'm using Gpio, which uses BCM numbers and gpiomem). I haven't tested that with your plugin, since in the meantime I switched to homebridge-platform-rcswitch. The latter uses the SysFS method, which just doesn't work for RC transmitters (probably not fast enough), so it has to yield. If I patch it to use Gpio instead, works great. So, bottom line is, if everybody used the new gpiomem version with the same PIN number conventions, I believe there would be no problems.

Note that Sys is now deprecated by WiringPI (from a related CPAN module):

setup_sys() Maps to int wiringPiSetupSys()

DEPRECATED.

This function is here for legacy purposes only, to provide non-root user access to the GPIO. It required exporting the pins manually before use. wiringPi now uses /dev/gpiomem by default, which does not require root level access.

gpiomem, like SysFS, doesn't require root access, and is much faster. SysFS does allow easy manipulation of the same pins from external tools, but they can do so anyway.

@jamesblanksby @rsg98 @kraigm @FWeinb @rainlake

[n8henrie]

@jdtsmith -- what a great follow up post. Thanks for being so thorough in explaining the issue. I had not seen the other project you switched to, thanks for pointing it out.

So from my end, it seems like the most important next step may just be adding an FAQ / Troubleshooting point that addresses this incompatibility. Did you have other thoughts? Perhaps doing a lookup on those other globals and issuing a warning if it seems like SysFS is being used simultaneously?

[jdtsmith]

A FAQ would certainly be helpful in case people are using multiple WPi plugins. I think issuing a warning is also a good idea. I suspect most people will naturally migrate to GPIOMEM (unless e.g. you want to use shell scripting to toggle GPIO's as well), so then the issue comes down to ensuring compatible pin numbering conventions are used, or at least enforcing your plugin's convention before every pin address. Essentially code defensively. That might be enough all by itself (i.e. I'm not familiar enough with WPi to know whether you can simultaneously use say GPIOMEM and SysFS on different pins).

[rsg98]

From the wiringPi version 2.36 diff:

+// It's actually a fatal error to call any of the wiringPiSetup routines more than once,
+//     (you run out of file handles!) but I'm fed-up with the useless t***s who email
+//     me bleating that there is a bug in my code, so screw-em.

My understanding of C is very limited... as is my knowledge of the inner workings of node addons. The version I cobbled together for node-wiring-pi (which is just a NAN'ified version of WiringPi-Node) doesn't have any libuv or asyncworker patterns in it - which I think means everything runs in the main Node event loop. Assuming other plugins operate in the same manner, I think this means they all share the same process and could therefore run into problems as described.

We could add some "already called setup" detection function to the WiringPi node bindings module (I could add to node-wiring-pi, but we would need a PR for WiringPi-Node and any other bindings people use) - actually, should add a "WiringPiSetupXXXSafe()" function that doesn't do anything if it's already called.

First step is probably to add some tests to node-wiring-pi to check out all the stuff @jdtsmith has figured out and ensure we're trying to fix the right problem! (It will also involve restoring all the gpiomem stuff I removed from the bindings as it didn't work for me in earlier wiringPi versions...)

[rainlake]

I have not update my code for a long time since pi is not good at doing real time operations. There is no feedback from the plug either. On Mon, Jun 5, 2017 at 2:59 PM Richard Grime notifications@github.com wrote:

From the wiringPi version 2.36 diff https://git.drogon.net/?p=wiringPi;a=blobdiff;f=wiringPi/wiringPi.c;h=5adfe691400bada4da222a4503ae636276d7fa0a;hp=dfd5de484297b293f6c95978c7eba95b4d53628e;hb=b1dfc186efe327aa1d59de43ef631a2fa24e7c95;hpb=b0a60c3302973ca1878d149d61f2f612c8f27fac :

+// It's actually a fatal error to call any of the wiringPiSetup routines more than once, +// (you run out of file handles!) but I'm fed-up with the useless t***s who email +// me bleating that there is a bug in my code, so screw-em.

My understanding of C is very limited... as is my knowledge of the inner workings of node addons. The version I cobbled together for node-wiring-pi https://github.com/rsg98/node-wiring-pi (which is just a NAN'ified version of WiringPi-Node https://github.com/WiringPi/WiringPi-Node) doesn't have any libuv or asyncworker patterns in it - which I think means everything runs in the main Node event loop. Assuming other plugins operate in the same manner, I think this means they all share the same process and could therefore run into problems as described.

We could add some "already called setup" detection function to the WiringPi node bindings module (I could add to node-wiring-pi, but we would need a PR for WiringPi-Node and any other bindings people use) - actually, should add a "WiringPiSetupXXXSafe()" function that doesn't do anything if it's already called.

First step is probably to add some tests to node-wiring-pi to check out all the stuff @jdtsmith https://github.com/jdtsmith has figured out and ensure we're trying to fix the right problem! (It will also involve restoring all the gpiomem stuff I removed from the bindings as it didn't work for me in earlier wiringPi versions...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/n8henrie/homebridge-rcswitch-gpiomem/issues/11#issuecomment-306273965, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYg3a82MYQIx5PSo5lHoZW6fC_cGR28ks5sBFAWgaJpZM4NkjXb .

[n8henrie]

Added to the FAQ. Going to go ahead and close now -- I don't know if there is a way to check for SysFS having been set up, my guess is that there may not be. If anybody finds one or has a concrete suggestion on how to add the warning, feel free to re-open.

[jdtsmith]

I think the issue isn't in the use of other programs with a different convention, but other plugins in the same homebridge process, since the PIN numbering is presumably maintained globally within a process by WiringPi.