Access to MCP23017 from other programs (aside from HA) possible ?

[lvanGithub]

Kia Ora from New Zealand and thank you for writing this integration for HA ! :-)
I would have one question :
Once this is installed and running on on a Raspberry Pi, is it at all possible to control pins of the MCP23017 from a different task - say a standalone python script ?

I have a new installation of HA supervised in Docker on a brand new install of BullsEye and my python3 script runs fine from a standard system shell (not inside a docker container and not in HA), controlling the pins of the MCP23017.
As soon as I restore my backup of HA, which has HA-mcp23017 installed, my script cannot control the MCP23017 anymore,
while - of course - I CAN control them from within HA then.
I am still to find out, if this changes definitely after installing your HA-mcp23017 integration (only) or if this might be caused by some other thing contained in my restored backup...

From your description, where you are saying that you are pulling pin states every 100ms, I would gather though, that installing this on HA will make access to the MCP23017 exclusively to HA and no other task can access the chip via I2C, while your intergration is controlling it.

Can you confirm this, or should it still be possible to control some pins from within HA and some others from a different task ?
Thank you for any help with this,
best regards
Lars

[jpcornil-git]

Hi Lars,

Can you check mcp23027 visibility (from host/from within container) and report results.

$ i2cdetect -y 1

If/where the device is visible can you try basic accesses (from host/from within container) and report results as well
See examples using i2cset/get or python p4 of RPi Hat – GPIO expansion boards.pdf

This should remove your script from the equation and help to root cause the issue.

Cheers,
jpc

PS: probably obvious but to access a shell within your docker image from host

$ sudo docker run -it <image_name> /bin/bash

[lvanGithub]

Hi jpc,
thank you for getting back so quickly.
I first had to get my head around getting a shell from inside the 'raspberrypi4-64-homeassistant' container ...

OK, from the host 'i2cdetect -y 1' produces:

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: 20 21 22 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

(I do have four MCP23017's ... )

and I can hear the attached relays click, when I run the python script from this page:
https://www.raspberrypi-spy.co.uk/2013/07/how-to-use-a-mcp23017-i2c-port-expander-with-the-raspberry-pi-part-2/
(change the print command in this script to say:   print (MyData) and it will work under python3).

So all working fine from the host.

From within the container:
I could not execute 'i2cdetect -y 1 ' from within the

• 'SSH&Web-Terminal' - community Add-on within HA OR
• from a shell, like you suggested above ($ sudo docker run -it <image_name> /bin/bash),

because I did not have access to i2c-tools there.
I could also not install these tools, because there is no access to apt / apt-get, as far as I could see.

(So still not quite sure, how I can check, if the MCP23017 is visible from within the container.)

However,
I then set up HACS and installed your 'HA-mcp23017' Integration. (all in a virgin install of HA supervised in Docker)
And then the python script (as above) ceased to work from the host.

(Script still runs but relays are not cklicking - as if the commands to the MCP23017 are ending in nirvana ... )

Although, on the host, '$ i2cdetect -y 1' still produces:

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
20: 20 21 22 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

And also:
$ i2cset -y 1 0x20 0x00 0x00
$ i2cset -y 1 0x20 0x09 0x01
$ i2cset -y 1 0x20 0x09 0x00

gives a nice click on the connected relay.

So access to the MCP23017 is still working from the host shell !

So I assume there is some take-over happening on the python(3) level ...)

Hope this helps,
Thanks for looking into this.
Lars

[jpcornil-git]

Hi Chris,

Thanks for the results, I believe I understand now what is happening.

MCP23017 has two possible register map (cfr. table 3.1 p12 of MCP23017 dataheet); default one is IOCON.BANK = 0 while HA-mcp23017 integration uses IOCON.BANK = 1 in order to be compatible/usable with mcp23008 as well.

Therefore, I suppose that if you change

IODIRA = 0x00 # Pin direction register
OLATA  = 0x14 # Register for outputs
GPIOA  = 0x12 # Register for inputs

by

IODIRA = 0x00 # Pin direction register
OLATA  = 0x0a # Register for outputs
GPIOA  = 0x09 # Register for inputs

Your script should work

Now, be carefull with scripts changing settings of the device as they may interfere with expected HA-mcp23017 behavior, i.e. OK to read GPIO or write OLAT (HA-mcp23017 will track that) but nothing more, e.g. remove following lines from the script when HA-mcp23017 is running (device configuration handled there)

# Set all GPA pins as outputs by setting
# all bits of IODIRA register to 0
bus.write_byte_data(DEVICE,IODIRA,0x00)
 
# Set output all 7 output bits to 0
bus.write_byte_data(DEVICE,OLATA,0)

Cheers,
jpc

PS: you can install i2c-tools in HA container by running

apk add i2c-tools

[lvanGithub]

Hi jpc,

thank you again for your quick reply.
You are awesome ! I changed the register addresses in the python code and that got the script working again.
All relays are clicking nicely ;-)
Quite interesting, how the chip can be operated in the two different modes - and great to know !

In some other scripts I was using the GPIOA and GPIOB registers ( 0x13 and 0x12) for outputs..
These also stopped working after the installation of HA-mcp23017.
But changing over to the OLATA abd OLATB registers (0x0a and 0x1a, respectively), got everything working again.
I didn't even need to change the order of the bits for the outputs - all registers are addressing the same outputs.

Thank you for your good explanation and for pointing me into the right direction.
Very happy, that I can continue to use these I/O expanders, even with the latest HA version !!
Keep up the excellent work.
Best regards,
Lars

[jpcornil-git]

Hi Lars,

Thanks for your feedback, always appreciated :-)!

Wrt chip mode, "byte mode" (IOCON.BANK = 1) was the original mode for devices with 8 I/Os while "sequential mode" was introduced for 16 I/Os devices like mcp23017 to enable read/write of the same register in two different banks with a single i2c transaction using automatic address increment. They should have kept compatible/byte mode as default for all devices and a clean way to set/get the mode you are in (rather than a workaround to implement this).

Wrt your use case, I'm not sure what your script is doing but can't that be implemented as an automation within HA ? (and avoid conflicts between two possible clients)

Cheers,
jpc