Support for other boards

[SecT0uch]

Would you consider support for other boards ?

I have a setup with a Pine64, started developping something similar and came across your project (which is awesome btw).

One blocking problem is the dependency RPi.GPIO, which works with Raspberry Pi only.
One possible solution would be to migrate to python-periphery.

I'm willing to contribute to the project in a separate branch to go in that direction if you're OK with that.

[yeyeto2788]

Another way to use other boards would be using Adafruit's Blinka which will enable you to use other Linux based boards. I actually added the support for some Pine64 devices on that and they are working as expected.

If there is help needed I can also provide some help.

[olixr]

Support for more boards is welcome! I would go down the route of an adapter then for the GPIO and have this toggled in configs based on the device. This would allow users to easily swap out GPIO for other libraries and add support easier.

We should extract any calls directly to the GPIO into a GPIO adapter. This adapter should have a uniform syntax that can be used in MudPi without needing to change based on on the library you choose to use. I am going down a similar path with some of the event emitters.

Please start a branch and submit some items as you like. I would be happy to review and see what we can do. I personally do not have those boards to test on so I would need some help verifying changes later on.

Thanks for taking this on!

[SecT0uch]

@yeyeto2788 I've actually never used blinka.
From my understanding, it allows us to run CircuitPython code on a classic CPython.

What would be the advantages of using CircuitPython/blinka layer than directly using python-periphery or the libgpiod Python wrapper ?

Edit: I think I got your point, it would allow us to use the Adafruit libraries (sensors, etc.), which would be useful.

@olixr Just found that https://github.com/underground-software/RPi.GPIO2, which would be a simpler solution and would allow us to keep the same syntax. Never tested though

[yeyeto2788]

Hey @SecT0uch,

IMHO the easy part is that it automatically detects GPIO pins and interfaces on the SBC automatically and creates the object instead of you writing the file path manually of the GPIO/interface as you would do on python-periphery (based on my poor experience with it).

In the end, CircuitPython is a port of MicroPython which is a re-implementation of Python for Microcontrollers.

Blinka lets you write Python code to interact with many Linux SBC so let's say you want to toggle an led is as simple as doing:

import board
import digitalio
import time

led = digitalio.DigitalInOut(board.A1)
led.direction = digitalio.Direction.OUTPUT

while True:
  led.value = False
  time.sleep(1)
  led.value = True
  time.sleep(1)

Also the good think about it is the broad range of sensors that can be used for which Adafruit has already worked on.

Maybe you can share your thoughts on python-periphery and I would change my mind 😛

[SecT0uch]

That's what I figured out. :)

I'm thinking of a way to completely replace RPi.GPIO by blinka, without changing the configuration too much.
It would work with Raspberry Pi + all the other (blinka-compatible) boards.

We should target:

• Raspian boards : Raspberry Pi
• Armbian boards: The others

Reference for pin mapping

The advantages:

• More compatible boards
• Wider public (and potentially contibutors)
• Replaces deprecated libraries : RPi.GPIO, Adafruit_DHT
• Using an unified solution

I know it would need some refactoring, but really think it would worth the effort.

Any thoughts ?

[yeyeto2788]

I completely agree with that, I can test on some boards I have laying around.

The only comment I have is that not all armbian boards are supported by blinka but for example, I know for sure that Pine64 devices are supported and the majority of the Orange Pi boards.

[SecT0uch]

Actually working sensor.py and humidity_sensor.py to make it work with blinka.
I'm testing on my Raspberry Pi Zero W.

I also have a SoPine64, but will test that when everything is fully working on Raspis.

I'll come back later to share my work-in-progress.

[olixr]

I think support for multiple boards would be great. I have used the blinka a bit but not extensively. Once you get a few tests going the first big step will be to go and extract all the current GPIO calls into a GPIO Adapter. Using adapters will make it easy to swap out the library without changing the core calls once completed.

Each GPIO adapter will follow expose the exact same methods while keeping the underlying implementation details specific to the board. I.e. we should just call adapter.digitalRead() and behind the scenes it would make a call to the libraries to actually take the digital reading.

I expect the adapter to be relatively simple in its api so the main work will be the initial extraction and then it would be easier to add adapters going forward. This is the strategy I will be applying to other areas of the system too like the event system. Using adapters it will be easier to provide multiple support options without a complex web of calls based on configs.

We can introduce a gpio config object to the configs that can contain a platform to specify the gpio platform desired.

Here would be an example of pi gpio

'gpio': {
    'platform': 'gpio' 
}

Then we can make adapters and options for pine64, blinka, and others.

[SecT0uch]

I'm not sure to understand how or why we would need adaptors as migrating to Blinka would make it compatible with Pi + all the blinka compatible boards, without having to specify the board.

I started going down that path:

• Created sensors/linux and workers/linux
• Copied and adapted sensor.py, humidity_sensor.py, worker.py and sensor_worker.py to replace RPi dependancies with blinka.

I have a working example with my Pi zero and a DHT22:
See my WIP branch
I'm using the following config:

{
    "name": "NewBoard SecT0uch",
    "version": 0.8,
    "debug": false,
    "redis": {
        "host": "127.0.0.1",
        "port": 6739
    },
    "relays": [],
    "workers": [
        {
            "type": "sensor",
            "sensors": [
                {
                    "pin": "D12",
                    "is_digital": true,
                    "model": "22",
                    "type": "Humidity",
                    "key": "HumTem_sensor",
                    "name": "MyTempHumSensor"
                }
            ]
        }
    ],
    "nodes": []
}

With this configuration and my changes, I'm successfully reading the Humidity and Temperature using blinka libraries.

The only configuration difference is pin value.
For example, for a Raspberry pi instead of setting "pin": "12", it would be "pin": "D12". D for digital, A for analog
Each user can refer to his board pins here
For example, you can find the Raspberry pi pin names here

To make it work with a Pine64 or whatever, I just need to change the pin value and that's all.

Once the migration completely done, we could rename the pi folders to linux and all the linux board would use it (incl. Raspi).
Does it make sense ?

If you allow me, I can continue going down that path to get rid of RPi dependencies, without losing Raspberry Pi compatibility.

Side notes:

• In all the files I edited, I replaces the tabs with 4 spaces to make it PEP8 compliant. (You can configure your IDE to automatically insert 4 spaces when you press )
• Is it really necessary to do sys.path.append('..') before importing your modules ?
• I noticed that in most of the files there are imported modules but unused. Ex: time and json in sensors/pi/sensor.py. Are they actually used ? Can we remove them safely ?
• I had to specify the key and model value manually because the config builder is not generating it . Did I miss something ?

[olixr]

The main reason I suggest adapters was to be open for future additions. I personally have not had any other boards to even test this on though. For the time the path you have started on should be fine as it still supports the pi while gaining additional board support. The blinka uses RPi GPIO under hood for the pi anyway so it just adds more support for those other linux boards while keeping same pi behavior.

The breaking change in pin configurations would be acceptable given the features we are adding on. Changing the folder names makes sense too.

I had tabs in my files coming from PHP and following PSR a lot. Didn't spend a lot of time digging into the python standards on this yet so open to going with PEP8 or whichever is the common one.

The sys.path.append('..') is linked to the dynamic imports if I remember. This and a combination of me stubbing out new features while not removing some debug items i.e. additional module as you see. I am currently working on another large refactor to consolidate a lot of things and bring more cohesion to some underlying systems. In the refactor I will go do some trimming on modules and left over stuff from before.

The config tool on the site is v0.8 and why you are noticing this difference. The core had been updated a lot recently and I haven't got around to update the config tool. It will be updated after I finish some more of these large core changes. I am only a solo developer on this project so it takes me some time to get around to all the various odds and ends. Plus I have a few week old newborn at the moment :)

Keep up the good work I am looking forward to the updates. I have some large updates I am doing as well so I will want to merge this in soon that later to my branch.

[SecT0uch]

Yeah sorry, I had no clue on how to implement adapters. But good to know I can keep going.
I'll leave the unused modules and let you see what you want to do with that later on.

Nothing urgent, I know what it is to be a solo dev. Take care of you family :)

I will submit a PR for you to check when I'm done.

Thanks

[yeyeto2788]

@SecT0uch if you finished your part I can handle some refactor and some linting tomorrow based on your branch so I can file a PR against your branch and then you can file a PR to @olixr branch so it gets easier for him to merge everything at once.

@olixr it would actually recommend you to wait a bit more for your changes so you don't stumble across many merge issues.

Does ot sound good to guys?

[SecT0uch]

@yeyeto2788 Fantastic!
Didn't finish yet, I'm done for today.
I'll let you know :)