-
-
Save Alexivia/9bdc891eb15cb7694e0154a88c67ee17 to your computer and use it in GitHub Desktop.
--- | |
# 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...
Thanks for the share!