Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for MCP23017 16 bit I/O expander #53

Closed
flyte opened this issue Feb 18, 2019 · 65 comments
Closed

Add support for MCP23017 16 bit I/O expander #53

flyte opened this issue Feb 18, 2019 · 65 comments

Comments

@flyte
Copy link
Owner

flyte commented Feb 18, 2019

Originally posted as a pull request by @eXCepT74 so I've moved it to an issue:

Is that possible to add support for MCP23017 - it has 16 I/O ports , I2C and each port can be loaded with 20mA , it has as well switchable active pullup resistors. I probably will use ur project to control my smart house based on PCF, but MCP is good idea as well. Anyway great project! Keep going like that!!! regards

@rbswift
Copy link

rbswift commented Sep 8, 2019

Yes please!

This would be great because then the AB Electronics IO Pi Plus 32 channel IO expansion board would be supported. (https://www.abelectronics.co.uk/p/54/io-pi-plus).

I see the MCP23017 is the I2C version of the MCP23S17 which uses SPI and is used on the piface2 expansion board which is already supported.

I'm currently using piface2 successfully but need more IOs

@rbswift
Copy link

rbswift commented Sep 8, 2019

there is actually some sample code here that might be useful...

https://github.com/abelectronicsuk/ABElectronics_Python_Libraries

@genex89
Copy link

genex89 commented Sep 11, 2019

I Need support for MCP23017 - it has 16 I/O ports. News about this?

@Misiu
Copy link

Misiu commented Oct 15, 2019

Home Assistant recently added MCP23017 support - home-assistant/core#23127 maybe this code will be useful

@rbswift
Copy link

rbswift commented Apr 19, 2020

Is there any update on this? It seems like quite a popular chip. I'd really like to have 16 I/Os

@aerodolphin
Copy link

Any update on this? I came from openhab, and I would like to use my expander boards That I develop with MCP23017.

I have some boards with 48 I/O and another boards with 32 I/O. It's very useful for everyone like me that want to have a lot of wired sensors and switches.

@aerodolphin
Copy link

aerodolphin commented Oct 16, 2020

Can someone give some guidance to develop this new module or make it? I can pay for the job.

Maybe the module pcf8575 will work.

@flyte
Copy link
Owner Author

flyte commented Oct 16, 2020

Hey, sorry for the delay. Is there an existing Python MCP23016 library that we could use for integration? If so, it's a relatively simple job of copying one of the other modules for reference and modifying it to work with the different library.

@flyte
Copy link
Owner Author

flyte commented Oct 16, 2020

I've just read the rest of the comments.. Ideally we'd use some kind of pip-installable package that enables control of the MCP23017. I suspect there is something usable, and I'll have a look this weekend.

@aerodolphin
Copy link

The is some Python libraries on the internet. Here you have two examples:

https://pypi.org/project/RPi-MCP23017/

https://github.com/owainm713/MCP230XX-Python-Module

Maybe can be useful. Thanks for the help.

I will share after the hardware info that can be used by anyone.

@aerodolphin
Copy link

aerodolphin commented Oct 19, 2020

Here is a photo of the 48Ch expander that I developed to expand the Raspberry Pi GPIO IOs by I2C with MCP23017 multiplexers.

48CH_gpio_expander

@Misiu
Copy link

Misiu commented Oct 19, 2020

@aerodolphin this looks awesome 👍🎉🚀
Are you planning to release the schematics? I'd like to make one to use this with Home Assistant (it supports MCP23017)
I don't need 48 I/O, 30 will be enough, but maybe in the future, they will be used.

@aerodolphin
Copy link

@Misiu Yes, I will release the schematics and also can sell the PCB board and components assembled or in kit. As soon as finish all the tests.

@Misiu
Copy link

Misiu commented Oct 19, 2020

@aerodolphin I need this for a school project, so I'll try to build one on my own or buy it if the price will be good (sadly a low budget), but please let me know when tests are over. Really looking forward to this!

@flyte
Copy link
Owner Author

flyte commented Oct 19, 2020

Looks great, good work @aerodolphin !

I worked on this project most of the weekend but this Issue slipped through the net I'm afraid. I'll try to make some progress with it this week.

@aerodolphin
Copy link

Thank you @flyte Your help will be much appreciated.

Will be very usefull for wired systems for Smart Homes with Home Assistant or Openhab.

@aerodolphin
Copy link

@flyte did you made some progress?

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 4, 2020

Hey, I've created a draft, but i can't test it here. It's on feature branch "feature/MCP23017". may you get it and test it, please? It is based on https://github.com/owainm713/MCP230XX-Python-Module

config should be something like:

gpio_modules:
  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20 //depends on your address...

digital_outputs:
  - name: out2
    module: mcp23017_chip
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    on_payload: "ON"
    off_payload: "OFF"

I haven't added interrupts yet. Do you need them?

Please try it and report the errors here :-)

@aerodolphin
Copy link

I can test it. But I don't know how to install that branch. Can you explain?

Interrupts are good to have, but we can keep this feature for future development.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 4, 2020

May you have a look at this answer?:
#114 (comment)
Just replace the branch name. Does it work?

@aerodolphin
Copy link

I made these steps:

cd /home/pi
. ve/bin/activate
git clone https://github.com/flyte/pi-mqtt-gpio.git
cd pi-mqtt-gpio
git checkout feature/MCP23017

Inserted your lines in my config file (pi-mqtt-gpio.yml) that is located inside the user pi directory:

gpio_modules:
  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20 //depends on your address...

digital_outputs:
  - name: porta
    module: mcp23017_chip
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    on_payload: "ON"
    off_payload: "OFF"

Run it with this line:

python -m pi_mqtt_gpio.server pi-mqtt-gpio.yml

And got this errors:

mportError: No module named mcp23017
2020-11-04 22:59:37,096 mqtt_gpio (INFO): Startup
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/pi/ve/lib/python2.7/site-packages/pi_mqtt_gpio/server.py", line 887, in <module>
    main(args)
  File "/home/pi/ve/lib/python2.7/site-packages/pi_mqtt_gpio/server.py", line 759, in main
    GPIO_MODULES[gpio_config["name"]] = configure_gpio_module(gpio_config)
  File "/home/pi/ve/lib/python2.7/site-packages/pi_mqtt_gpio/server.py", line 427, in configure_gpio_module
    gpio_module = import_module("pi_mqtt_gpio.modules.%s" % gpio_config["module"])
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: No module named mcp23017
2020-11-04 22:59:40,031 mqtt_gpio (INFO): Startup

I also tried to install the mcp23017 module. Don't know if it's needed:

(ve) pi@raspberrypi:~ $ pip install MCP23017

I got these errors:

DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
ERROR: Could not find a version that satisfies the requirement MCP23017 (from versions: none)
ERROR: No matching distribution found for MCP23017
WARNING: You are using pip version 20.2.3; however, version 20.2.4 is available.
You should consider upgrading via the '/home/pi/ve/bin/python -m pip install --upgrade pip' command.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 5, 2020

First, please make a git pull. I fixed something. But that does not concern your problem.

Are you in the correct directory? May you look, if there is a pi_mqtt_gpio/modules/mcp23017.py file?

In the config I removed the // in the chip_addr line, because yaml it doesn't like it.

gpio_modules:
  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20

When i start it, i get this output: I think it works (maybe we have to find the correct address), i get the IOError, because I don't have any i2c device.

pi@testpi:~/pi-mqtt-gpio $ python -m pi_mqtt_gpio.server config.mcp23017.yml
2020-11-05 10:47:56,552 mqtt_gpio (INFO): Startup
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/pi/pi-mqtt-gpio/pi_mqtt_gpio/server.py", line 1267, in <module>
    main(args)
  File "/home/pi/pi-mqtt-gpio/pi_mqtt_gpio/server.py", line 1112, in main
    initialise_digital_output(out_conf, GPIO_MODULES[out_conf["module"]])
  File "/home/pi/pi-mqtt-gpio/pi_mqtt_gpio/server.py", line 677, in initialise_digital_output
    gpio.setup_pin(out_conf["pin"], PinDirection.OUTPUT, None, out_conf)
  File "pi_mqtt_gpio/modules/mcp23017.py", line 36, in setup_pin
    self.io.set_mode(pin, "output")
  File "pi_mqtt_gpio/modules/mcp23017.py", line 202, in set_mode
    regValue = self.single_access_read(reg)
  File "pi_mqtt_gpio/modules/mcp23017.py", line 100, in single_access_read
    dataTransfer = self.bus.read_byte_data(self.i2cAddress, reg)
  File "/home/pi/.local/lib/python2.7/site-packages/smbus/util.py", line 59, in validator
    return fn(*args, **kwdefaults)
  File "/home/pi/.local/lib/python2.7/site-packages/smbus/smbus.py", line 132, in read_byte_data
    raise IOError(ffi.errno)
IOError: 121
Exception IOError: IOError(121,) in <bound method MCP230XX.__del__ of <pi_mqtt_gpio.modules.mcp23017.MCP230XX instance at 0x76220f30>> ignored

@aerodolphin
Copy link

Sorry this basic question, but how I can make the git pull? Can you write the complete command line?

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 5, 2020

Of course: that would be git pull in the pi-mqtt-gpio directory.

@aerodolphin
Copy link

I made the git pull. Thank you.

Got the same error.:
ImportError: No module named mcp23017

The location of the mcp23017.py is:
/home/pi/pi-mqtt-gpio/pi_mqtt_gpio/modules/mcp23017.py

Where could be the problem?

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 5, 2020

Hmm, may you try make in pi-mqtt-gpio folder? It makes a schema for me, but fails with black....
Then try it again, please.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 5, 2020

Or something is broken with the virtual env? maybe you try it again, but without the first step (#114 (comment)) Just clone the repo in another directory...

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 6, 2020

By the outputs, the module must be the module_name from the module section:

  - name: porta
    module: mcp23017_chip
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    on_payload: "ON"
    off_payload: "OFF"

@aerodolphin
Copy link

Hi, stupid error. Sorry about that. I will try now after the work when I get back to home. Thanks.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 6, 2020

No problem :-) Good luck!

@aerodolphin
Copy link

I confirm that is working. I was able to control an output with Home Assistant. Next I will test some sensors.

@BenjiU BenjiU mentioned this issue Nov 9, 2020
@aerodolphin
Copy link

BenjiU, Interrupts are simple to implement?

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 9, 2020 via email

@aerodolphin
Copy link

It's up to you. I think will be very useful to use this module. And after that I plan to share and distribute the boards.

I can test it. I'm right now making some more tests to check if it's stable. In terms of hardware and software.

@aerodolphin
Copy link

aerodolphin commented Nov 12, 2020

I made some tests with 32 inputs and outputs at the same time and it's working well. Only getting some delays. Sometime it is more than 20 seconds. The interrupts will resolve that issue.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 12, 2020 via email

@aerodolphin
Copy link

aerodolphin commented Nov 12, 2020 via email

@jjarokergc
Copy link

@BenjiU: Thank you for developing this module.

I assembled a prototype board to test it using three MCP23017 chips wired into 6 outputs and 6 inputs. The testing used an RPI4B 8GB running Ubuntu 20.04 I also confirm that these 12 I/Os can be controlled by homeassitant over mqtt.

There is an up-to 2 second lag when the six inputs are switched. This was configured as 2 inputs per chip. Using 32 inputs, as @aerodolphin mentioned, could have significant polling delay especially with many modules on the I2C bus.

Could a callback-on-interrupt be used to replace polling? It would be very desirable for the MCP23017 as there can be up-to 8 of these chips on the I2C bus.

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 15, 2020

Hi, thanks for your feedback. I haven't had time to do it this weekend, but I thought a lot about it. One problem would be the "configuration" of the interrupt pin: currently the modules don't know each other. So I don't want to add the RaspberryPI into the MCP23017 module for interrupt handler. It should be some generic method.

For the yaml two solutions came to my mind.

  1. The interrupt config is in the module section (more logically, I think)
mqtt:
  host: 192.168.0.180
...

gpio_modules:
  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20 #depends on your address...
    interrupt:
          module: raspberrypi
          pin: 2 #pin 2 on raspberry pi module is interrupt pin for mcp23017_chip module
          trigger: rising
          pullup: yes
          pinterrupt: ulldown: no
          bouncetime: 200

digital_inputs:
  - name: doorbell
    module: mcp23017
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    on_payload: "ON"
    off_payload: "OFF"
    interrupt: falling
  1. The configuration of the interrupt is in the input section (prevents better double usage of pin 2, maybe)
mqtt:
  host: 192.168.0.180
...

gpio_modules:
  - name: raspberrypi
    module: raspberrypi

  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20 #depends on your address...

digital_inputs:
  - name: doorbell
    module: mcp23017
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    on_payload: "ON"
    off_payload: "OFF"
    interrupt: falling

  - name: mcp23017_interrupt
    module: raspberrypi
    pin: 2 #pin 2 on raspberry pi module is interrupt pin for mcp23017_chip module
    interrupt_module: mcp23017_chip
    interrupt: rising

(I don't know, if the yaml syntax is 100% correct, it's just a dump of my mind)
In the future, we will need a graphical configuration tool: it gets complicated :-D

@aerodolphin
Copy link

Hi @BenjiU,

Any news about the interrupts?

@BenjiU
Copy link
Collaborator

BenjiU commented Nov 30, 2020

Hi,

not now. We are getting new windows, so I'm busy :-) Also nobody responded to my configure examples above, what would be better...

@aerodolphin
Copy link

Hi,

No problem. I can wait. I'm developing another things at the same time.

Regarding to your question, In my opinion, It's better to have the interrupt configuration in the input section.

@flyte
Copy link
Owner Author

flyte commented Nov 30, 2020

Ah, interrupts across modules! I've not considered that before..

Each input pin is uniquely named, so what do you think about something like this?

mqtt:
  host: 192.168.0.180
...

gpio_modules:
  - name: raspberrypi
    module: raspberrypi

  - name: mcp23017_chip
    module: mcp23017
    i2c_bus_num: 1
    chip_addr: 0x20 #depends on your address...

digital_inputs:
  - name: doorbell
    module: mcp23017
    pin: 2  # This device is connected to pin 2 of the mcp23017 IO expander
    poll: no  # Disable standard polling

  - name: button
    module: mcp23017
    pin: 3
    poll: no

  - name: mcp23017_interrupt
    module: raspberrypi
    pin: 2 #pin 2 on raspberry pi module is interrupt pin for mcp23017_chip module
    interrupt: rising
    interrupt_for:  # When this pin rises, the following pins will be polled for changes
      - doorbell
      - button

This seems a little more configurable, if for some reason we don't want the interrupt to cause a poll of all of the MCP23017's inputs.

@BenjiU
Copy link
Collaborator

BenjiU commented Dec 17, 2020

I don't think, the polling of inputs, after a input occured, is a good solution. Following situation: two inputs on mcp23017 chips are configured as interrupt inputs. The int pin is connected to rapi input. If a interrupt occurs, you would read the both inputs via i2c, but how do you elevate, which pin generated the interrupt? Maybe it's just a short spike, that's already gone, when you read the inputs.

I think you need a real interrupt service handler, that reads the mcp23017 interrupts register and looks, what interrupts have occured and send a mqtt message for that input.

Sorry guys for slow progress on this topic. But it's always in my mind ;-) Maybe it gets better in the upcoming holidays.

@jjarokergc
Copy link

Here is an example of my home automation/security system that I am integrating that uses four MCP23017 chips. I hand-soldered these onto a breadboard and interfaced about 16 hardwired sensors. It is a work-in-progress, but from testing and observation it appears that a "bank-based polling on interrupt" strategy would be optimal.

The MCP23017 has two interrupts (A and B) that signal changes on any of the input pins in Bank A (pins 0-7) or Bank B (pins 8-15). For example, interrupt A signals a change on any of the pins in Bank A.

Polling all of the pins on Bank A when interrupt A occurs would be sufficient: it would be faster than the current polling approach, and it would be fast enough; and, it would update the state of the changed-pin, even if other pins are polled unnecessarily. I'm not sure I understand BenjiU's comment, "how do you elevate, which pin generated the interrupt?" I don't think it is necessary to know which pin's input changed. That type of intelligence belongs in homeassistant.

The goal is to improve performance (by decreasing delay between an input change and firing a mqtt message). A "bank-based polling on interrupt" strategy would achieve this by prioritizing polling only onto the groups-of-8 pins where a change occurred.

20201214_122129

@aerodolphin
Copy link

Polling all of the pins on Bank A when interrupt A occurs would be sufficient: it would be faster than the current polling approach, and it would be fast enough; and, it would update the state of the changed-pin, even if other pins are polled unnecessarily. I'm not sure I understand BenjiU's comment, "how do you elevate, which pin generated the interrupt?" I don't think it is necessary to know which pin's input changed. That type of intelligence belongs in homeassistant.

I agree with you. We only need to poll the bank where the interrupt occurred. And we don't need to know winch input was.

For sure we will need this part of interrupts working. Because the intend is to used in wired smart homes with a lot of sensors.

Very nice integration @jjarokergc.

@aerodolphin
Copy link

@jjarokergc Can you share a simple schematic of the main components of your hardware?

@aerodolphin
Copy link

@BenjiU any spare time to get back to this project?

@flyte
Copy link
Owner Author

flyte commented Jan 21, 2021

I'm working on an asyncio rewrite of the project on the feature/asyncio branch, which uses separate coroutines to poll each module. This should speed up polling at least, and I'll implement interrupts soon as well. I don't want to spend a lot of time working on the non-asyncio code, so I'd prefer to take a good look at the interrupts as part of the asyncio work.

I do need people to test the asyncio code, so once I've implemented interrupts on there, I'll update the ticket and hopefully you guys can give it a test.

@aerodolphin
Copy link

Ok @flyte I can test it with MCP23017. ;)

@flyte
Copy link
Owner Author

flyte commented Jan 22, 2021

@aerodolphin

I've added an untested MCP23017 module to the feature/asyncio branch. I know @BenjiU added one before, but I'd prefer to use a library that's maintained by a third party than implement it at a low level in this project.

I have an MCP23017 chip arriving later this evening to test with, but feel free to pull feature/asyncio and give it a try. If you run into problems, it might be quicker and better to discuss them on Discord. I'll try to keep an eye on it, but @ me on there if you like.

@aerodolphin
Copy link

@flyte I have basic knowledge about Pyton and linux. For testing purposes I will need to know all the steps for it.

@flyte
Copy link
Owner Author

flyte commented Feb 12, 2021

I've implemented a new way of handling interrupts, including across modules as inspired by some of the comments here. I've explained it on the wiki, but it's still very much a work in progress.

I'd appreciate it if some of you could test out the code on feature/asyncio and let me know any issues you encounter.

@flyte
Copy link
Owner Author

flyte commented Feb 25, 2021

Closing this issue since the mcp23017 is implemented on the new version #178 . Let's move any further discussion about interrupts to #179

@flyte flyte closed this as completed Feb 25, 2021
Repository owner locked as resolved and limited conversation to collaborators Feb 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants