RPi GPIO update for HG

This is a bug fix for HG on the RPi. Although the GPIO worked in HG already for RPi1 with early versions, it required some work by Wibo primarily to figure out what needed to be fixed to make the RPi2 work. At some point during Jessie’s development the OS changed the way the CPU was reported which broke GPIO in HG. Although this was the case for some time, it appears that there were no reports of this issue on github that prompted a fix. In June, Gene added some code to make the RPi4 work but stopped short of making all versions of the RPi work with HG.

I have submitted a pull request on Gene’s version of Raspberry-Sharp-System which fixes the GPIO issue. If Gene updates this code and incorporates it into the HG base code, this post will not be needed. However, due to the regularity of Gene’s updates, it may be some time before it’s incorporated. The attached library can be used with any version of HG on any RPi. However, I have found that RPi1 variants do not work with any of the recent releases of HG so keep that in mind.

You should only need the Raspberry.System.dll but some versions of HG also have the xml and pdb files included so it probably doesn’t hurt to replace them as well. I also included the Test.Board.exe file that will output what info your RPi is sending to HG if something goes wrong.

Raspberry.System.update.zip (13.9 KB)

A lot of work no doubt and here’s hoping your PR will acted upon sooner rather than later.

I imagine @enterprised will be interested in your findings and the resulting solution as he did encounter some problems with GPIO on the RPI3 if I recall. Nice work :+1:

It was a lot of work but hopefully it will help someone out. I hated the idea of tossing the RPi3 to the parts bin and buying a RPi4 because of some presumably small software bug. If I had the RPi4 already this might have been a different story. I guess being stubborn pays of once in a while!

Yes with the rate of production of new RPI model versions it probably would have gone unnoticed certainly as far as HG is concerned. Just proves that no software is ever a completed project.

If Gene wants other contributors, he should provide better documentation. Some of that would need to include a guide on a development environment. I was able to compile one library but not another. I would have modified the code of both if I could compile everything. As is, it works for now.

@bkenobi I’m new to playing with the GPIO. Thanks for this.
I picked up a DHT-22 to add to my pi Zero W at my off grid location sometime ago.
I decided to test it in the city on my Zero W board and 3B+ as I had never got around to playing with it until now.
The DHT-22 program is loaded and running in both the zero and 3B+
HG sees it on my Zero W and I can add to a group even though it is connected to the 3B+ However HG fails to see the DHT-22 to load to a group on my 3B+ :disappointed:

I can get the DHT-22 to report on my 3B+ using the python code, however the values are not correct (0.0 C and 1.0 % humid)
I figure the sensor is bad so I’ve ordered a couple more to play with

There are lots of examples of DHT code that work with Arduino and RPi. I cant comment on failure rate of these sensors, but if it responds then it’s not likely faulty. The response isnt a single value, it’s a formed phrase with temperature and humidity. As I recall a failed sensor would respond with a different message or no response at all. They can be out of calibration but I’d guess it’s a problem with the code before I assumed it was a sensor that’s been sitting in a desk drawer.

Yes, the same python program on the Zero W reports check wiring with no sensor connected.

I downloaded the HG program on my off grid setup but can’t switch(update) the files you create as I need to be on that network.
HG can’t add the DHT-22 module to a group there just like the pi 3B+ here, so I’m wondering if something needs to be added to the files for a 3B+

The update will make GPIO function on all versions of the RPi through 4 and through Buster. I don’t know what will change with the 400 or in the next version of the OS but it currently should get things back in order. The RPi4 should already work but any older boards will not unless you install Wheezy or older and use HG 500 or older.

I played a bit with my DHT22 in a Zero W & 3B+ boards using some python codes and did get it reporting correct values with some code modifications. However the DHT22 program in HG fails to load a widget in the 3b+ and will not display any info in the Zero W. Digging into the HG DHT program code I am seeing errors so although the GPIO Program appears to work it doesn’t completely fix the issue with the DHT Sensor programs.
Loading either the DHT11 or 22 programs into HG with or with out a sensor connected and compiling produces the same errors. At least it does for me in both a Zero W and 3b+.

As I said, I’d assume the code is broken and the sensors are ok. If you didn’t replace the file I posted for a RPi 1-3 based system then you will have to be using an ancient setup for GPIo to work. The update fixed the GPIO on all variants of hardware I tested. I have never used DHT sensors with HG so you will have to fix that if it’s still broken after replacing the dll.

I have updated to the GPIO file you posted. The only pi I can’t get to work with it (that I have) is the Pi 3B+. I don’t plan on using the 3B+ with HG so not a big deal for me just thought I’d mention the issue I have noticed with it.

When I updated the code I only had access to a few boards. All of those I tested worked great with GPIO. I looked at the hardware revision list and determined that there was a subset that would not work with my fix so I have modified it such that it should work with the following too:

  • RPi 3B (1 version was missed)
  • RPi 3A+
  • RPi 3B+
  • RPi CM3+

All other versions should have already been working up and including RPi4 though I have not tested all variants of hardware. If you test the attached update and it does not work for you, run the Test.Board.exe and post the output here and perhaps I can figure out why it’s not happy.

Raspberry.System.update.20201227.zip (14.0 KB)

The GPIO Program in HG seems to work it was/is only the DHT programs that I couldn’t pull into a group to test. I suspect that was(is still) due to errors in the programs them selves.
Not sure why I can pull the DHT programs into a group on a Zero W board but that’s where I plan to use the DHT sensors anyways.
In any case I ran the Test.Board.exe and here is its output:

Raspberry Pi running on Bcm2709 processor
Firmware rev10494163, board model B3 (Raspberry Pi 3 Model B)

Serial number: 000000006fff3f2f

Not sure why it shows Raspberry Pi 3 Model B when I have the Raspberry Pi 3 Model B+ :crazy_face:

It shows the 3B because it was easier that way and it doesn’t matter. If you ran the previous version I posted it would have reported unknown.

A lot of the code examples from the old forum will need to be edited and recompiled.

Do bear this in mind when running any program snippets pre 2016.

Best to start fresh bearing in mind the results of @bkenobi investigations into the whole subject of board compatibility when it comes to GPIO and should there be any updates that do not incorporate his revisions they will need to be redone again.

@bkenobi thanks again for this it will make adding GPIO projects to HG so much easier.

@Petediscrete so true Ive had to this for a few things now. Saddly that makes a HG update to much of a pain for many. Even I hold off updating now till I’m about 3 updates behind unless there is a fix or improvement that interests me.

The last update was 6 months ago. Gene seems to have taken a sabbatical so if you aren’t up to date, you probably won’t be any time soon.

The current version is fine but there are always improvements/fixes required. Staying on 1.3.17 doesn’t fix the GPIO issue. The problem is that there is nobody to turn to in order to fix issues once identified.

1.3.19 was released to fix the backup bug in 1.3.17 so if anyone is running this version be mindful you won’t be able to make a HG config backup to the location of your choice. You’ll need to physically go looking for it on the SD card as that’s where backup is pointing to.

I have to clean some things up, but this is an image of all of my senors working happily.

The widget was pretty simple change, just modify line 155.

if (!ctx.isUnknown || parameter.Name.indexOf("Sensor.") >= 0 || parameter.Name.indexOf("Meter.") >= 0 ) {

I was planning on modifying it further to use a different icon for things like wind direction but I haven’t found an icon I like yet for the different values. I have been looking through other submitted widgets and the ones already included trying to find some images to borrow but haven’t located the right ones yet.

The other option to modifying the widget is to update the HG file that controls the default icon. I started with that, but have been waffling on whether I want to modify the widget or the base code. Gene will never update a push request at this point, so I’m not sure I want to modify anything on that side right now. If you wanted to look at what is built in, check out:

/usr/local/bin/homegenie/html/js/api/homegenie.ui.js