Slimme Lezer + Water Meter reader joint ESPHome configuration.

utilities-meter.yaml

---
# Based on:
# - Slimme Lezer for the Electricity Meter
#   - https://github.com/zuidwijk/dsmr/blob/main/slimmelezer.yaml
#   - @ 0f34e14 on Oct 10
# - Blog post for the Water Meter
#   - https://www.pieterbrinkman.com/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-proximity-sensor/
#   - Using the same pin for multiple sensor types is no longer supported:
#     - https://github.com/esphome/issues/issues/3364#issuecomment-1179691203
#   - Connect same input to 2 GPIOs to make them read the same sensor, but keep separate counts internally.

substitutions:
  device_name: utilities-meter

esphome:
  name: ${device_name}
  project:
    name: alexivia.utilities-meter
    version: "1.0.0"
  name_add_mac_suffix: false

esp8266:
  board: d1_mini
  restore_from_flash: true

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: ${device_name}

captive_portal:

ota:

web_server:
  port: 80
  ota: false

# Enable logging
#
# Baud-rate is set to zero to disable serial logging so that the UART interface can perform well enough to receive the
# DSMR packages.
#   - https://esphome.io/components/sensor/dsmr.html#improving-reader-results
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  reboot_timeout: 30min
  services:
    - service: set_pulse_total
      variables:
        new_pulse_total: int
      then:
        - pulse_counter.set_total_pulses:
            id: water_sensor_freq
            value: !lambda 'return new_pulse_total;'

uart:
  baud_rate: 115200
  rx_pin: D7
  rx_buffer_size: 1700

dsmr:
  id: dsmr_instance
  max_telegram_length: 1700

sensor:
  - platform: dsmr
    energy_delivered_tariff1:
      name: "Energy Consumed Tariff 1"
    energy_delivered_tariff2:
      name: "Energy Consumed Tariff 2"
    power_delivered:
      name: "Power Consumed"
      accuracy_decimals: 3
    electricity_failures:
      name: "Electricity Failures"
      icon: mdi:alert
    electricity_long_failures:
      name: "Long Electricity Failures"
      icon: mdi:alert
    current_l1:
      name: "Current Phase 1"
      accuracy_decimals: 0
    current_l2:
      name: "Current Phase 2"
      accuracy_decimals: 0
    current_l3:
      name: "Current Phase 3"
      accuracy_decimals: 0
    power_delivered_l1:
      name: "Power Consumed Phase 1"
      accuracy_decimals: 3
    power_delivered_l2:
      name: "Power Consumed Phase 2"
      accuracy_decimals: 3
    power_delivered_l3:
      name: "Power Consumed Phase 3"
      accuracy_decimals: 3

  - platform: uptime
    name: "Uptime"
    update_interval: 60s

  - platform: wifi_signal
    name: "WiFi Signal Strenght"
    id: wifi_signal_db
    update_interval: 60s

  # Reports the WiFi signal strength in %.
  # https://esphome.io/components/sensor/wifi_signal.html
  - platform: copy
    source_id: wifi_signal_db
    name: "WiFi Signal (percent)"
    id: wifi_signal_pct
    unit_of_measurement: "Signal %"
    accuracy_decimals: 0
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    entity_category: "diagnostic"

  - platform: pulse_counter
    pin: GPIO14
    name: "Sensor Average Frequency"
    id: water_sensor_freq
    accuracy_decimals: 1
    update_interval : 15s
    total:
      name: "Sensor Pulses"
      id: water_sensor_pulses
      unit_of_measurement: "pulses"
      accuracy_decimals: 0
      state_class: total_increasing

  # Timeout after 1 minute, for a minimum resolution of 1.0 litres per minute.
  # Default is 5 minutes, meaning 1 pulse per 5 minutes, which is 0.2 litres per minute.
  - platform: pulse_meter
    pin: GPIO12
    name: "Water Instantaneous Consumption"
    id: water_inst_cons
    unit_of_measurement: "litre/min"
    accuracy_decimals: 1
    timeout: 1min
    icon: "mdi:water-pump"
    total:
      name: "Water Consumed"
      id: water_consumed
      unit_of_measurement: "litre"
      accuracy_decimals: 0
      device_class: water
      state_class: total_increasing
      icon: "mdi:water"

  - platform: copy
    source_id: water_consumed
    name: "Water Meter Reading"
    id: water_meter_reading
    unit_of_measurement: "m³"
    accuracy_decimals: 2
    device_class: water
    state_class: total_increasing
    icon: "mdi:water"
    filters:
      - multiply: 0.001

  - platform: copy
    source_id: water_consumed
    name: "Water Meter Total"
    id: water_meter_total
    unit_of_measurement: "m³"
    accuracy_decimals: 3
    device_class: water
    state_class: total_increasing
    icon: "mdi:water"
    filters:
      - multiply: 0.001

text_sensor:
  - platform: dsmr
    identification:
      name: "DSMR Identification"
    p1_version:
      name: "DSMR Version"

  - platform: wifi_info
    ip_address:
      name: "IP Address"
    ssid:
      name: "WiFi SSID"
    bssid:
      name: "WiFi BSSID"

  - platform: version
    name: "ESPHome Version"
    hide_timestamp: true

Hi @Alexivia, do you happen to have a photo of the soldering? I have the SlimmeLezer+ and I guess I can manage to solder a cable to gpio12 and 14 together. But where did you solder the gnd and 5v to? To the P1 connector maybe?

I have soldered the 5V and GND cables of the sensor across the capacitor C3 on the board, the one besides the integrated circuit D1. That I found to be a reliable 5V source, presumably the input filter capacitor for the board's regulator. The sensor's output cable I soldered directly on the castellated solder pads of the ESP module.

As a 5+ months update, I must report that for some reason the pin marked to use pulse_counter sometimes reads a couple of pulses less than the one using pulse_meter. If someone knows of a possible cause for this, please do share 🙂.

Great, thanks @Alexivia I'll try the same. I just hope my (SMD) soldering skills won't kill the thing :)

I'll let you know if I notice the same issue with missing / unaligned counts. Just a stab in the dark: could it be that the internal pull up resistors aren't enabled and that one gpio is just a bit more sensitive to that than the other? Also, I don't know how the NPN sensor works internally, but could it be some sort of debouncing needs to be implemented? Note that these are just some guesses without any form of testing from my part yet...