ESP32-POE-ISO and multiple MCP23017

[Nixay]

Hi,

Having some difficulty running two MCP23017 GPIO expanders together on the I2C bus on an ESP32-POE-ISO.

One expander (addressed at 0x20) is configured as 16 input pins.
Other expander (addressed at 0x27) is configured as 16 output pins.

The boards are daisy-chained together off the I2C bus using the pins from the UEXT header for 3.3v, GND, GPIO16 and GPIO13 and wired as per the "cascade connection" illustrated here: DFRobot DFR0626

Currently powering via the USB input, however I've also tested using PoE with USB disconnected.

Using ESPHome I've loaded a program which listens for inputs on the input board and sends momentary triggers to the output board upon receiving MQTT commands. When I receive input triggers from the input board all seems well. When I send output commands to the output board I'm successful about 50% of the time, the rest of the time I get error messages as per below.

Code Select Expand

[08:32:46][W][i2c:086]: Requesting 1 bytes from 0x20 failed!
[08:32:46][D][binary_sensor:036]: 'back_lights_load': Sending state ON
[08:32:46][D][binary_sensor:036]: 'back_lights_load': Sending state OFF
[08:32:48][W][i2c:076]: Unknown transmit error 4 for address 0x27
[08:32:49][W][i2c:076]: Unknown transmit error 5 for address 0x20
[08:32:49][D][binary_sensor:036]: 'hall_lights_load': Sending state ON
[08:32:49][D][binary_sensor:036]: 'hall_lights_load': Sending state OFF
[08:32:50][W][i2c:076]: Unknown transmit error 4 for address 0x27
[08:32:50][W][i2c:076]: Unknown transmit error 5 for address 0x20
[08:32:50][D][binary_sensor:036]: 'frontdoor_lights_load': Sending state ON
[08:32:50][D][binary_sensor:036]: 'frontdoor_lights_load': Sending state OFF
[08:32:55][W][i2c:073]: Received NACK on transmit of data for address 0x27
[08:32:55][W][i2c:086]: Requesting 1 bytes from 0x20 failed!
[08:32:55][D][binary_sensor:036]: 'ensuite_lights_load': Sending state ON
[08:32:55][D][binary_sensor:036]: 'ensuite_lights_load': Sending state OFF
[08:32:56][W][i2c:076]: Unknown transmit error 4 for address 0x27
[08:32:56][W][i2c:076]: Unknown transmit error 5 for address 0x20
[08:32:56][D][binary_sensor:036]: 'kitchen_lights_load': Sending state ON
[08:32:56][D][binary_sensor:036]: 'kitchen_lights_load': Sending state OFF
[08:32:57][W][i2c:076]: Unknown transmit error 4 for address 0x27
[08:32:57][W][i2c:076]: Unknown transmit error 5 for address 0x20
[08:32:57][D][binary_sensor:036]: 'bed2_lights_load': Sending state ON
[08:32:57][D][binary_sensor:036]: 'bed2_lights_load': Sending state OFF
[08:32:58][W][i2c:073]: Received NACK on transmit of data for address 0x27
[08:32:58][W][i2c:086]: Requesting 1 bytes from 0x20 failed!
The errors above are most often accompanied by a false reading from the input board, as seen in the binary_sensor lines.

I've tried connecting to the 5v line instead of the 3.3v line, reversing the order of the boards in the daisychain, changing board addresses, changing the I2C bus frequency (normally at the lowest setting ESPHome allows, 50Khz), wiring the boards in parallel instead of using their provided passthrough for daisychaining. I've also tried fully disconnecting the input and output modules leaving just the GPIO expanders connected and I get the same results.

If I try the GPIO expanders connected one at a time they work as expected. Problems arise when two are connected.

Any ideas?

[Nixay]

As part of further testing I condensed the project down to 8 inputs and 8 outputs using one GPIO expander and the errors persist in this arrangement using just one GPIO expander - previously I thought the issue was to do with having two expanders attached. It now looks like an issue with inputs and outputs being used simultaneously on the I2C bus generally.... this is looking like it might be more of a software issue with ESPhome.

[Nixay]

So I "resolved" this problem by creating a second I2C bus and putting one expander on each - one configured fully as outputs and the other configured fully as inputs, and this works having the inputs and outputs separated on different buses. No idea why, and it chews another two data pins, but it works.