Gpio modules don't work on Raspberry Pi

[pat-moore]

Expected behavior

The sensor modules should respond to gpio inputs and the switch modules should control gpio outputs.

Actual behavior

Neither IN nor OUT actually connects to the gpio pins. There are no error messages and I can see the program partly working as it changes the IN/OUT state of the correct pins as seen with gpio readall. I can also see the necessary exports in /sys/class/gpio and a file created for each pin. The program seems to be working correctly in every way except to actually read/write the pin values. For example, gpio readall shows the output levels unchanged when I click the switch on, off or toggle.

If I bypass homegenie, the gpio pins work correctly using both read and write to /sys/class/gpio/... They also work using the gpio CLI and a Python program I've written that uses gpiozero. This confirms I have the correct pin-out scheme. I assume the problem is in the c# gpioConnection implementation or Mono.

Steps to reproduce the problem starting from a fresh install

0. sudo apt-get install wiringpi
1. Download and enable the HG program "GPIO Modules".
2. By default it creates a number of OUT modules. Use gpio readall to confirm the OUT status for the configured pins is set when the program is enabled.
3. Add a few of the switch modules created by the program to a group and click the switch on/off. There's no need to check the gpio pins as the failure is visible using gpio readall. The output value fails to change as it should.

Specifications

• Version: Both beta_1.1.r526 and 1.3-stable.5 behave the same (I hoped the update might fix the problem)
• Operating System: Rasperrian 4.19.42+
• .Net/Mono runtime version: 4.0.30319.42000 (32-bit)
• Hardware configuration: Rasperry Pi model B1

Additional configuration notes

I have a mature HG installation with ~30 ZWave modules and numerous programs of my own all working fine. Other than gpio, where I'm trying to connect some pre-existing alarm PIRs, HG is wonderful!

/boot/config.txt is as follows:

For more options and information see

http://rpf.io/configtxt

Some settings may impact device functionality. See link above for details

uncomment if you get no picture on HDMI for a default "safe" mode

hdmi_safe=1

uncomment this if your display has a black border of unused pixels visible

and your display can output without overscan

disable_overscan=1

uncomment the following to adjust overscan. Use positive numbers if console

goes off screen, and negative if there is too much border

overscan_left=16

overscan_right=16

overscan_top=16

overscan_bottom=16

uncomment to force a console size. By default it will be display's size minus

overscan.

framebuffer_width=1280

framebuffer_height=720

uncomment if hdmi display is not detected and composite is being output

hdmi_force_hotplug=1

uncomment to force a specific HDMI mode (this will force VGA)

hdmi_group=1

hdmi_mode=1

uncomment to force a HDMI mode rather than DVI. This can make audio work in

DMT (computer monitor) modes

hdmi_drive=2

uncomment to increase signal to HDMI, if you have interference, blanking, or

no display

config_hdmi_boost=4

uncomment for composite PAL

sdtv_mode=2

uncomment to overclock the arm. 700 MHz is the default.

arm_freq=800

Uncomment some or all of these to enable the optional hardware interfaces

dtparam=i2c_arm=off

dtparam=i2s=on

dtparam=spi=off

Uncomment this to enable the lirc-rpi module

dtoverlay=lirc-rpi

Additional overlays and parameters are documented /boot/overlays/README

Enable audio (loads snd_bcm2835)

dtparam=audio=on

[homeautomate8]

You’ve given the kernel version but not the Raspbian version you are running.

As you’re running Mono 4x I’m guessing you’re running Raspbian Jessie.

You think it may be Mono related and you may be right. If you have an image of Raspbian Stretch I’d install that and point your sources list at the Mono project and install Mono 5.20 and pin that release.

I do remember some Raspberry Pi users experiencing problems with Mono 4x and the GPIO operations.

Might be worth investigating the HG log and see if that throws up any clues.

[pat-moore]

I originally installed Raspbian 2018-06-27. This worked fine for all my Z-Wave work so I stayed with it. I've recently started a new project to add gpio and when this failed I upgraded both Raspbian (using apt-get update and upgrade) and HG to 1.3-stable.5. No change in symptoms with any of this. HG logs show nothing.

I've tried installing Mono 5.20 according to https://raspberrypi.stackexchange.com/questions/79349/how-to-correctly-error-free-install-mono-5-on-raspberry-pi-3-raspbian-stretch, but the install doesn't complete. The system crashed on apt install mono-complete. The last message (at 99% complete) was Mono precompiling /usr/lib/mono/4.5/Microsoft.CodeAnalysis.CSharp.dll for arm (LLVM disabled due to missing SSE4.1)...

After this, apt list shows mono at 5.20. HG is working exactly as before with Z-Wave fine but gpio sill broken. However, I'm not sure the Mono installation is complete. apt now demands that I run "dpgk --configure -a", but when I do this the same system crash as above recurs, but only 30 mins or so after the same final message above and with mono taking >90% cpu for much of this time. At the time of the crash top showed "as" as the most active process.

I've still not run the final step "apt-get install --only-upgrade mono-complete" although it looks as though 99% of mono has gone in OK.

Any advice on how to recover the apt error so that I can do future upgrades? Any other ideas how to fix gpio?

Thx.

[homeautomate8]

It looks like the package manager is failing.

Ok you have all your dependencies installed. All you need to do is wget the HG manually, tar the zip into a folder of your choice and start HG using sudo mono HomeGenie.exe

You can autostart it with a service yourself.

[pat-moore]

The problem with dpkg was that the Mono 5 Roslyn compiler was depleting all my Pi's memory. I got round it by killing of Mono and HomeGenie to give more memory and after a very long time, and a lot of swapping, dpkg --configure -a ran to successful completion.

However, no change in the symptoms of HomeGenie GPIO. I can see the IN/OUT status changing with gpio readall when I enable/disable the program, but turning the switch module on fails to set the output to 1, either viewed with gpio readall or the voltage on the GPIO pin itself.

[homeautomate8]

Since your last post Mono 6 has been released.

Yes Roslyn was stumbling over compilation of Mono 5.20

I think the Mono developers pushed Mono 6 as a result but I haven’t had a chance to check.

I’m not sure if the HG developer has tested his latest version on Raspbian Buster.

Could you revert to Stretch until your GPIO pin issue is resolved assuming it was working ok there.

Alternatively you could go with Mono 6 and see if this helps with your issue.

[pat-moore]

HG GPIO has never worked on my Pi, and I've tried various versions of Raspbian, Mono and HG. I'm now giving up and reverting to a simple Python program using gpiozero. I'll have the Python handler use the HG web API to communicate the GPIO state into HG. What a pain.

[homeautomate8]

If GPIO is important to you I’d look at something like Home Assistant. Plenty of goodies there to get GPIO running smoothly and all completely integrated.

[pat-moore]

I've written a lot of software for HG, so I'm not going to switch now. Anyway I have a solution with gpiozero. It's a pity as otherwise HG is great.

[homeautomate8]

It’s features like this that are exactly what HG needs. Maybe put in a request for it. Pita having to off load this function to a secondary Pi

Back to your problem and may sound a little basic but do you have enough overhead on your power supply. I’ve seen issues like this occasionally with an underpowered or flaky power supply. Maybe nothing in it but just thought I’d mention it.

[pat-moore]

No need for a second Pi. I can run a separate Pyhon and HG on one.

[pat-moore]

Power supply is fine. I'm using a powered USB hub and went round that loop a few years back. GPIO works fine and HG works fine. They just don't work together.

[homeautomate8]

Of course you can run a separate server on the same RPI in a Python virtual environment. That’s the great thing about Python.

Have you produced much Python code for HG.

Hopefully the author will get around to your issue at some stage.