-
Notifications
You must be signed in to change notification settings - Fork 158
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
Comments
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 |
there is actually some sample code here that might be useful... https://github.com/abelectronicsuk/ABElectronics_Python_Libraries |
I Need support for MCP23017 - it has 16 I/O ports. News about this? |
Home Assistant recently added MCP23017 support - home-assistant/core#23127 maybe this code will be useful |
Is there any update on this? It seems like quite a popular chip. I'd really like to have 16 I/Os |
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. |
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. |
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. |
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. |
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 this looks awesome 👍🎉🚀 |
@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. |
@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! |
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. |
Thank you @flyte Your help will be much appreciated. Will be very usefull for wired systems for Smart Homes with Home Assistant or Openhab. |
@flyte did you made some progress? |
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:
I haven't added interrupts yet. Do you need them? Please try it and report the errors here :-) |
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. |
May you have a look at this answer?: |
I made these steps:
Inserted your lines in my config file (pi-mqtt-gpio.yml) that is located inside the user pi directory:
Run it with this line:
And got this errors:
I also tried to install the mcp23017 module. Don't know if it's needed:
I got these errors:
|
First, please make a Are you in the correct directory? May you look, if there is a In the config I removed the // in the chip_addr line, because yaml it doesn't like it.
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.
|
Sorry this basic question, but how I can make the git pull? Can you write the complete command line? |
Of course: that would be |
I made the Got the same error.: The location of the mcp23017.py is: Where could be the problem? |
Hmm, may you try |
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... |
By the outputs, the module must be the module_name from the module section:
|
Hi, stupid error. Sorry about that. I will try now after the work when I get back to home. Thanks. |
No problem :-) Good luck! |
I confirm that is working. I was able to control an output with Home Assistant. Next I will test some sensors. |
BenjiU, Interrupts are simple to implement? |
Hmm, will be some hours, i guess. Are you able to test it?
|
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. |
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. |
Maybe i'll have a look at the interrupts this weekend.
|
Good to now. Thanks ;)
…On Thu, Nov 12, 2020 at 7:25 PM Benji ***@***.***> wrote:
Maybe i'll have a look at the interrupts this weekend.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#53 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADX4NQITPGS75G3PEDPEWTSPQZA5ANCNFSM4GYFIXTA>
.
|
@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. |
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.
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
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) |
Hi @BenjiU, Any news about the interrupts? |
Hi, not now. We are getting new windows, so I'm busy :-) Also nobody responded to my configure examples above, what would be better... |
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. |
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. |
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. |
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. |
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. |
@jjarokergc Can you share a simple schematic of the main components of your hardware? |
@BenjiU any spare time to get back to this project? |
I'm working on an asyncio rewrite of the project on the 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. |
Ok @flyte I can test it with MCP23017. ;) |
I've added an untested MCP23017 module to the I have an MCP23017 chip arriving later this evening to test with, but feel free to pull |
@flyte I have basic knowledge about Pyton and linux. For testing purposes I will need to know all the steps for it. |
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 |
Originally posted as a pull request by @eXCepT74 so I've moved it to an issue:
The text was updated successfully, but these errors were encountered: