search

genielabs / HomeGenie

HomeGenie, the programmable automation intelligence
https://homegenie.it
GNU General Public License v3.0
387 stars 154 forks source link

GPIO not working in HG 525 thru 1.3.19 [BUG] #424

Closed bkenobi closed 1 year ago

bkenobi commented 3 years ago

Version RPi 1B

RPi 3B

Mono - tested various versions to see if it would impact GPIO function but did not see any impact. Some versions did not seem to work with HG, so assume this is not related.

all testing with GPIO 25

HG versions

Describe the bug HG 1.1.r525 running on RPi 1B with Wheezy (unknown release date) worked correctly to implement GPIO pins such that a motion sensor (dry contact open/closed) would report sensor state with the setting "IN-". That SD failed and so rebuilding using both RPi 1B and 3B boards and Raspbian Stretch and Buster with versions of HG from 525 thru 1.3.39 all fail to update the GPIO status when toggled. Status is correctly toggled as WiringPi reports the change via the gpio command. I was unable to install HG on Wheezy as there were issues installing Mono on such an old OS.

Code to Reproduce With fresh OS with HG installed, add the RPi GPIO handler via package manager. Disable all programs other than GPIO handler. Set all GPIO configurations to "OFF". Set GPIO 25 to "IN-". Add GPIO 25 to dashboard and change to type SENSOR.

Install WiringPi. Run command "gpio readall" and monitor GPIO 25 between configurations to witness difference.

Expected behavior Using jumper (or another similar method) connect GPIO 25 to 3v3. When connected WiringPi reports "1" and when disconnected "0". This is expected behavior. HG does not see a status change.

Screenshots/Stacktrace N/A

Additional context There have been a number of issues where this has been reported (297, 393, 400). It appears that 393 and 400 were fixed by release v1.3.15 but I see the same issue before and after on both my RPi 1B and 3B.

It may be unrelated or tied to the same issue, but I have also seen an error displayed stating that the some GPIO are already in use. It appears this is generated in the GPIO handler program at line 59: https://github.com/genielabs/homegenie-packages/blob/master/packages/Single%20Board%20Computers/Raspberry%20Pi/GPIO%20Modules/GPIO_Modules.hgx#L89

bkenobi commented 3 years ago

In order to be more complete with my testing, I have tested r500 as well with the same results. I cannot source Wheezy at this point but plan on installing Jessie as the oldest OS available. If this is a known bug that is understood please let me know so I can stop trying to generate debug points.

bkenobi commented 3 years ago

I installed Jessie (2015-11-21-raspbian-jessie-lite), performed all update/upgrades and then installed HG r500. I can confirm that with this configuration HG DOES see the GPIO changing and it does notify the interface of the change. I don't know what to do from here to get the RPi GPIO to function in HG as I plan on using a more current version of HG than r500 and I also intend to use Buster. Any suggestions for other configurations to interrogate are welcome but it appears this is an issue with the RPi OS in combination with HG that is causing the issue.

bkenobi commented 3 years ago

I ran one more very telling test this morning that nails the issue being with how HG is interacting with the hardware somehow:

I installed Jessie and HG 500 with only dependencies as needed. I ran HG and set up GPIO25 to be "IN-" in the settings. I checked before installing HG that the GPIO worked in wiringpi (confirmed) and after installation (confirmed). I then checked that the GPIO triggers in HG (confirmed). Outcome was RPi1 works 100%.

I then shutdown and moved the card to the RPi3. I checked that the GPIO triggers correctly with wiringpi (confirmed) and then checked HG (FAILED).

For reference, I read that all recent versions of Raspbian can be moved from one version of RPi to another without any modifications to the SD since all RPi kernels are installed on the card. I have not tried upgrading the kernel yet.

I read an issue relating to I2C and wonder if there is any similar issue with addressing for other things as well. You said something about RPi2 and on having different addressing and requiring a change. Here's a link to the old thread: http://old.homegenie.club:8080/www.homegenie.it/forum/index4a65.html?topic=728.15 And this is where the change was made in your code: https://github.com/genemars/raspberry-sharp-io/commit/1d5dce1dadd3f1bb3e5539909669a7495c816ad3

I'll keep poking away at this but so far have had no luck getting GPIO functioning with HG in any configuration so far.

bkenobi commented 3 years ago

I believe I have located the issue and it would be an easy fix. Unfortunately, I am not able to compile the raspberry-sharp-io library to verify that fix. When the raspberry-sharp-system and raspberry-sharp-io libraries were updated in June-2020 to work with RPi4 this did not fix earlier processors. The same approach is needed for all RPi variants due to the change in how the OS reports the processor version. In order to make the RPi1-4 fully compatible, I believe the following change needs to be made:

In raspberry.system Processor.cs within Processor Processor: replace the switch (Model) with the following:

                switch (Model)
                {
                    case Model.A:
                    case Model.APlus:
                    case Model.BRev1:
                    case Model.BRev2:
                    case Model.BPlus:
                    case Model.ComputeModule:
                    case Model.Zero:
                        processor = Processor.Bcm2708;
                        return processor;

                    case Model.B2:
                    case Model.B3:
                    case Model.ComputeModule3:
                        processor = Processor.Bcm2709;
                        return processor;

                    case Model.Pi4:
                        processor = Processor.Bcm2711;
                        return processor;

                    default:
                        processor = Processor.Unknown;
                        return processor;
                }

This will require enumerating the new processor types. Note that the B3 and ComputeModule3 are actually chip BCM27010 but for GPIO puproses they are identical. It would be more correct to change this to Processor.Bcm2710 but and also modify the raspberry-sharp-io library to properly address this chip.

bkenobi commented 3 years ago

It should also be noted that in order for the RPi Zero W to work, the firmware must also be added to the Model LoadModel method.

        private Model LoadModel()
        {
            ///Console.WriteLine("Inside  Boards.cs Model LoadModel");
            var firmware = Firmware;
            Console.WriteLine("Firmware = {0:x}", firmware);
            Console.WriteLine("Firmware & 0xFFFF = {0:x}", firmware & 0xFFFF);

            switch (firmware & 0xFFFF)
            {
                case 0x2:
                case 0x3:
                    Console.WriteLine("Model.BRev1");
                    return Model.BRev1;

                case 0x4:
                case 0x5:
                case 0x6:
                case 0xd:
                case 0xe:
                case 0xf:
                    Console.WriteLine("Model.BRev2");
                    return Model.BRev2;

                case 0x7:
                case 0x8:
                case 0x9:
                    Console.WriteLine("Model.A");
                    return Model.A;

                case 0x10:
                    Console.WriteLine("Model.BPlus1");
                    return Model.BPlus;

                case 0x11:
                    Console.WriteLine("Model.ComputeModule");
                    return Model.ComputeModule;

                case 0x12:
                    Console.WriteLine("Model.APlus");
                    return Model.APlus;

                case 0x1040:
                case 0x1041:
                    Console.WriteLine("Model.B2");
                    return Model.B2;

                case 0x0092:
                case 0x0093:
                case 0x00C1:
                    Console.WriteLine("Model.Zero");
                    return Model.Zero;

                case 0x2082:
                    Console.WriteLine("Model.B3");
                    return Model.B3;
                case 0x20A0:
                    Console.WriteLine("Model.ComputeModule3");
                    return Model.ComputeModule3;

                case 0x03111:
                case 0x03112:
                case 0x03114:
                    Console.WriteLine("Model.Pi4");
                    return Model.Pi4;

                default:
                    Console.WriteLine("Model.Unknown");
                    return Model.Unknown;
            }
        }
bkenobi commented 3 years ago

In order to make this also work with the 3A+, 3B+, and CM3+ additional revision numbers need to be added. I also found a different revision number for the 3B that was not included. It would be good to change this section to include those:

                case 0x2082:
                case 0x2083:
                case 0x20D3: ///3A+ and 3B+
                    return Model.B3;

                case 0x20A0:
                case 0x2100: ///CM3+
                    return Model.ComputeModule3;

I have included these in my repository but since the pull request has gone unanswered I'll leave this here in case you get to it at some point.

bkenobi commented 1 year ago

While you are making updates to HG, this would be an easy one to fix. I don't know if the new version of raspberry sharp system fixes this but if not, I have provided the code that will make your user base able to use more than the RPi1 and RPi4 based boards.