Change method of SBC model detection

[theophile]

This pulls the board model name from /proc/device-tree/model instead of /proc/cpuinfo. I made this change because I'm running a modified version of TerrariumPI on a Banana Pi M2 Zero that has an Armbian base, and its /proc/cpuinfo output didn't contain any useful information for pulling the model of the SBC. With this change, the resulting string is: Banana Pi BPI-M2-Zero

I also checked and confirmed that on a Raspberry Pi 3B+ running Raspberry Pi OS, this would produce the string: Raspberry Pi 3 Model B Plus Rev 1.3

NB: For my personal project, I changed line 285 to:
settings["device"] = self.device
to reuse the code, but this would probably need a little refactoring to preserve the error-checking logic of the try/except block.

[theyosh]

settings["device"] = self.device

I agree. That is better. Will update that later on.

But does the grep -i serial /proc/cpuinfo produce any output? Should look like something: Serial : 1000000045c63ee1
I need the serial value for encryption of data

[theyosh]

And this does mean that a Banana Pi M2 Zero is also supported? That is very nice!

[theophile]

settings["device"] = self.device

I agree. That is better. Will update that later on.

But does the grep -i serial /proc/cpuinfo produce any output? Should look like something: Serial : 1000000045c63ee1 I need the serial value for encryption of data

Yes, my grep -i serial /proc/cpuinfo does produce output in the format you specified.

And this does mean that a Banana Pi M2 Zero is also supported? That is very nice!

I would not call it supported based on my experimentation so far, for at least a couple of reasons:

1. The BPI M2 Zero only has 500MB RAM, so many of the python packages (or their dependencies) in the install script fail to compile due to out-of-memory errors. For my application (a self-watering planter), I do not need most of the hardware sensors or relays so I removed them to eliminate their dependencies. For other libraries, where available I installed the system packages via 'apt' and then symlinked them to the TerrariumPI venv. I should note that I've not tried using Docker. Maybe that would eliminate this particular issue.
2. To get GPIO to work on non-RPi hardware (and on this hardware specifically), I needed to use a patched version of the RPi.GPIO 0.5.5 library and then in terrariumEngine.py change the gpiozero pin factory to 'pigpio'.

I will say though, TerrariumPI runs far, far better on the BPI M2 Zero than it did on a RPi Zero W. For my application I am using a set of custom-built, individually addressable agricultural LEDs so that I can have customizable color "recipes" based on different "mixes" of the light wavelengths. I control these with a pca9685 relay board and have each color set up as its own dimmer/relay in TerrariumPI so that I can use the frontend to control them separately and I can accurately track the power consumption of each.

But then I also have a standalone python script that contains the color recipes, and that script is set up in TerrariumPI as a script relay for purposes of the automation, which I use to simulate things like sunrise and sunset. TPI tells the script what color recipe to use and what the overall percentage of the light intensity should be used, the script then calculates the appropriate level for each discrete LED and sets them using the TerrariumPI API.

On the RP0 this setup was somewhat unreliable and scaling steps would often be missed because it would sometimes take longer than 60 seconds for the script to complete five API calls. Also the web frontend was very sluggish on the RP0. But on the BPI M2 zero, those problems are gone. The frontend is snappy and responsive and the script fires API calls quickly and without issues.