Gpiozero: Addon boards compatibility question

[lurch]

Something that occurred to me while I was adding #333 ...

As we all know, GPIOzero _only_ deals with GPIO / Broadcom / BCM numbers, rather than physical pin numbers. This is all fine and helps prevent confusion.

However (by their very nature) add-on boards always attach to fixed physical pin numbers. And some add-ons, such as https://www.piborg.org/ledborg/specs connect to a physical pin that has a different GPIO number on the original Rev1 pinout than later revisions.
This means that if a Rev1 ModelB Pi owner connects an LedBorg and tries using GpioZero to control it, it won't work properly.

With the 'pins database' @waveform80 added, we could fix this so that add-on boards with fixed physical pins could lookup (at runtime) the appropriate GPIO numbers for the physical pins they actually use.
Alternatively, we could say that the proportion of people still using Rev1 ModelB Pis is so small that it's not worth bothering with? I see for example that http://gpiozero.readthedocs.io/en/latest/recipes.html#pin-numbering doesn't bother mentioning the GPIO numbers of the Rev1 Pis.

Comments / opinions welcomed... :-)

[tmarkettos]

I have this problem with an Energenie on GPIOZero 1.2 on a Rev 1 Model B:

pi@raspberrypi:~ $ python 
Python 2.7.9 (default, Mar  8 2015, 00:52:26) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gpiozero import Energenie
>>> 
>>> lamp = Energenie(1)
/usr/lib/python2.7/dist-packages/gpiozero/pins/rpigpio.py:95: PinNonPhysical: no physical pins exist for GPIO27
  'no physical pins exist for GPIO%d' % number))
>>> lamp.on()

Nothing happens.

The vendor supplied ENER002-2PI.py does work, suggesting it is the numbering at fault.

[lurch]

Might be worth having a think about this, while #354 is still fresh in our minds? ;)
@bennuttall @waveform80

[bennuttall]

Good point. How likely are these edge cases for the add-on boards currently supported?

[lurch]

I've just checked through http://gpiozero.readthedocs.io/en/v1.3.1/api_boards.html, and AFAICT these are the boards that connect to the pins that correspond to different GPIOs on a Rev1 Model B and a Rev2 Model B:

• LedBorg
• PiLiter / PiLiterBarGraph
• Energenie

(in each case, it's only GPIO27 that's used, which is GPIO21 on the very first Pis)

But I guess the bigger problem will come if / when GpioZero supports I2C-connected devices, as the I2C GPIOs are GPIO0 and GPIO1 on Rev1 Model Bs, but GPIOs 2 & 3 on all later Pis.

EDIT: And now the PiStop board too (optionally uses GPIOs 2 & 3, which are GPIO0 and GPIO1 on Rev1 Model Bs).

[dogsbody]

Have also just had this problem with Energenie on a Rev 1 Model B :-(

[lurch]

Now that #470 has been merged, it might be worth squeezing this in too for the v1.5 release? @bennuttall @waveform80 I guess it'd need to use the BOARD numbering scheme, since the header:pin numbering scheme has different header-names (P1 and J8) on different Pis?

[martynwheeler]

Hi,
Sorry to bring this old thread back to life. Is there anyway to use gpiozero with energenie on a model B pi?

[lurch]

@bennuttall I'm tempted to suggest closing this, given how "old" the original Rev1 Model B Pis are now?

[dogsbody]

I totally get that this is not a priority ticket but there are still those of us (above) that have fallen into this trap, not to mention the ones that find this thread and don't comment.

I'd personally rather see issues like this stay open (indefinitely) which gives people with more time or the next person to have an issue the opportunity to fix it; than close this as "won't fix" which i feel gives the wrong message.

Just my opinion, I hope it is taken in the way it was intended

[lurch]

Fair enough :+1:

[bennuttall]

I like your idea about using BOARD numbering for add-on boards. Not a huge priority but it could be done as and when.

[bennuttall]

@dogsbody please test the branch in PR #860