About changes in ESPHome configuration validation – Pin Reuse validation

  • Post category:News / Tips

Recently, the ESPHome firmware has been changed to prevent the same controller I/O ports from being reused to create different entities.

This mechanism is called Pin Reuse validation: https://esphome.io/changelog/2023.12.0.html#pin-reuse-validation

These updates in ESPHome version 2023.12.0 also affected the examples developed by our company for the GGreg20_V3 Geiger counter ionizing radiation detector module.

According to the user’s request (https://github.com/iotdevicesdev/GGreg20_V3-ESP32-HomeAssistant-ESPHome/issues/2) regarding the repository for GGreg20_V3-ESP32-HomeAssistant-ESPHome, we have made the necessary updates to the configuration YAML file.

Now this example will work properly with the new ESHome configuration validation and you will be able to upgrade to newer versions of ESPHome without any problems.

We also plan to update other repositories with this issue.

You can also make changes to your ESPHome YAML configuration files yourself.

As of now, we know of two ways to fix the configuration so that it passes the new configuration validation rules:

Way #1. If you need to reuse the pin, use https://esphome.io/components/copy.html instead

This is the more correct path that we recommend using.

For sensor entities:


For binary sensor entities:


An example of the code you should get is given here:


Way #2. You can also use the exception described in the ESPHome Pin Schema document:


config key: “allow_other_uses”

You can use this config key to override the control of reusing pins in exceptional situations.

Please note that the key must be specified not only in duplicate entities, but in each entity where a particular pin is used for the configuration to pass validation:

Wrong keys:

Right keys:

You should get the following code using the “alow_other_uses” key:

# YAML code example:
- platform: pulse_counter
      number: GPIO2
      allow_other_uses: true
    state_class: "measurement"
    unit_of_measurement: 'CPM'
    name: 'Ionizing Radiation Power CPM'
      rising_edge: DISABLE
      falling_edge: INCREMENT # GGreg20_V3 uses Active-Low logic
  # It seems that only one instance of pulse counter internal filters can be set
  # So here no any debounce filters for CPM value 
    use_pcnt: False
    internal_filter: 180us
    update_interval: 60s
    accuracy_decimals: 0
    id: my_cpm_meter
  - platform: pulse_counter
      number: GPIO2
      allow_other_uses: true
      inverted: True
        input: True 
        pullup: False
        pulldown: False
    unit_of_measurement: 'uSv/Hour'
    name: 'Ionizing Radiation Power'
      rising_edge: DISABLE
      falling_edge: INCREMENT
    update_interval: 60s
    accuracy_decimals: 3
    id: my_dose_meter
  #    - sliding_window_moving_average: # 5-minutes moving average (MA5) here
  #        window_size: 5
  #        send_every: 1      
      - multiply: 0.0057 # or 0.00332 for J305 by IoT-devices tube conversion factor of pulses into uSv/Hour
# END of YAML code example

You can choose which of the methods suits your DIY project.

That’s all. Good luck!