Pulse-counter on MCP23017 io extender

I’m trying to setup a pulse-counter to use a pin on a MCP23017 IO extender connected via I2C to a D1 Mini

The issue is defining the pin for the pulse_counter. How do I setup a the pulse_counter to use a pin on the IO extender.

— Error — when validating
sensor.pulse_counter: [source /config/esphome/mcp2307.yaml:282]
platform: pulse_counter
pin: [source /config/esphome/mcp2307.yaml:284]

[mcp23017] is an invalid option for [pin]. Please check the indentation.
mcp23017: mcp23017_z1 [source /config/esphome/mcp2307.yaml:284]
number: 15
mode: INPUT
inverted: False

name: pulse_counter_mcp
id: pulse_counter_mcp
force_update: False
update_interval: 5s
icon: mdi:pulse
unit_of_measurement: pulses/min
count_mode:
rising_edge: INCREMENT
falling_edge: DISABLE
accuracy_decimals: 2
internal_filter: 13us

----  pulse_counter setup -----
sensor:  
# Waterflow pulse counter
  - platform: pulse_counter
    pin:
      mcp23017: mcp23017_z1
      number: 15
      mode: INPUT
      inverted: false
    name: "pulse_counter_mcp"
    id: "pulse_counter_mcp"
    force_update: false
    update_interval: 5s
    icon: mdi:pulse
    unit_of_measurement: pulses/min
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    accuracy_decimals: 2
    internal_filter: 13us

----  MCP23017 setup ----

i2c:
  - id: bus_a
    # sda: GPI04
    # scl: GPI05
    scan: True

mcp23017:
  - id: mcp23017_z1
    address: 0x27

--- Binary_sensor setup that works 
--- I used the same format for the pulse_counter to use a pin on the
--- IO extender but get the above error

  - platform: gpio
    name: "MCP23017_z1_14"
    id: mcp23017_z1_14
    pin:
      mcp23017: mcp23017_z1
      number: 14
      mode: INPUT
      inverted: false

Hello and welcome to the forum. Please read point 11 here then edit your post.

It could be that your indentation is incorrect but we have no way of telling unless you format it correctly.

How to use the MCP23017 pins is documented here:

The issue is that pulse-counter pin definition does not allow the extra attribute of specifying mcp23017. The pulse-counter docs do not show how to specify that the pin to use is on the mcp23017 extender.

I can’t help you if you don’t format your posted code correctly.

Code share has been fixed

Try this:

sensor:  
# Waterflow pulse counter
  - platform: pulse_counter
    pin:
      mcp23xxx: mcp23017_z1   #### <------- THIS
      number: 15
      mode: INPUT
      inverted: false
    name: "pulse_counter_mcp"
    id: "pulse_counter_mcp"
    force_update: false
    update_interval: 5s
    icon: mdi:pulse
    unit_of_measurement: pulses/min
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    accuracy_decimals: 2
    internal_filter: 13us

Same error

INFO Reading configuration /config/esphome/mcp2307.yaml...
Failed config

sensor.pulse_counter: [source /config/esphome/mcp2307.yaml:282]
  platform: pulse_counter
  pin:  [source /config/esphome/mcp2307.yaml:284]
    
    [mcp23xxx] is an invalid option for [pin]. Please check the indentation.
    mcp23xxx: mcp23017_z1 [source /config/esphome/mcp2307.yaml:284]
    number: 15
    mode: INPUT
    inverted: False
  name: pulse_counter_mcp_192_168_010_010
  id: pulse_counter_mcp_192_168_010_010
  force_update: False
  update_interval: 5s
  icon: mdi:pulse
  unit_of_measurement: pulses/min
  count_mode: 
    rising_edge: INCREMENT
    falling_edge: DISABLE
  accuracy_decimals: 2
  internal_filter: 13us

I get the feeling that how pulse_counter defines a pin is different to how a binary_sensor defines a pin.
If I run the pulse_counter off a D1 Mini pin it works fine but as soon as the mcp23xxx or mcp23017 additional info is added then the error occurs when validating.

When I comment out the MCP23…

sensor:  
# Waterflow pulse counter
  - platform: pulse_counter
    pin:
#      mcp23xxx: mcp23017_z1
      number: 15
      mode: INPUT
      inverted: false
    name: "pulse_counter_mcp_192_168_010_010"
    id: "pulse_counter_mcp_192_168_010_010"
    force_update: false
    update_interval: 5s
    icon: mdi:pulse
    unit_of_measurement: pulses/min
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    accuracy_decimals: 2
    internal_filter: 13us

the code validates fine

--- code  validate displays after a successfully pass
sensor:
- platform: pulse_counter
  pin:
    number: 15
    mode: INPUT
    inverted: false
  name: pulse_counter_mcp_192_168_010_010
  id: pulse_counter_mcp_192_168_010_010
  force_update: false
  update_interval: 5s
  icon: mdi:pulse
  unit_of_measurement: pulses/min
  count_mode:
    rising_edge: INCREMENT
    falling_edge: DISABLE
  accuracy_decimals: 2
  internal_filter: 13us

Well there is this quote in the docs:

Within ESPHome they emulate a real internal GPIO pin and can therefore be used with many of ESPHome’s components such as the GPIO binary sensor or GPIO switch.

Note the use of “many” not “all”. Might be that the counter is not one of the many.

I saw that and I read it as it applies directly to the MCU.
Maybe in esphome that everywhere where a pin is defined that the ability to specify where where the pin is be added similar as provided for on a binary_sensor.

Eventually IO extenders are going to be used more as they offer a cheap way to massively increase the number of pins a MCU has to offer.
Sacrifice 2 pins on the MCU and gain a potential 64 pins at a fraction of the cost.

I’m at a point now where only the I2C pins are used on the MCU everything else needs to run from the IO extenders

I use the ESP32 and haven’t run out of i/o yet.

Which brings up another possible issue, are you using an ESP32 or 8266?

8266 - WeMos D1 Mini’s. Used to use sonoffs that they became very expensive.
I have tried a ESP32 but just could not get it programmed the first time. Have not been able to find away to rest\et it to factor.
Have a esp32 camera kit that I will try later.
Right now it’s all about getting 100’s of beds wet on the farm. So you can see why the IO extenders to control pumps, solenoid valves, PIRs, tank levels etc. Camera’s to monitor growth at a later stage. You have my email address we can chat there about it.

Actually I thought it would be more likely to work on an ESP8266. The ESP32 has hardware counters that I thought might be tied to the chip’s i/o. Where as the ESP8266 has software counters that would be less likely to have this requirement. :man_shrugging:

As for programming the ESP32 some of them require this procedure (part 2):

If you want to open an issue for the pulse counter and expander you can do it here:

I had a look and could not find anything relevant.

Alternatively the devs hang out here and may have some info for you