HI Florizz,
Dit you get your question aswered? I am struggling with the same. Even though it works with an ouput voltage of 4.8v volt for me, I am afraid that on the long run it will fry my ESP.
Hi there,
I know, that the post is somewhat older, but i have seen it because I found the idea great. Therefore for the first I really want to thank Pieter for the great Project and his work.
I have bought a ESP8266-12F. Unfortunately after about 3 months the card broke. Because of the post of Marcel1 I had a closer look into the technical specs. indeed they warn to operate it with 5V on the GPIO Pins, because it is not 5 V tolerant. If you operate it with more than 3,6 V will destroy the Chip so they write. Because I am not keen in electronics, I was searching the web and found something in the IObroker forum. George the guy, building the project for IObroker was introducing a voltage divider to reduce the voltage on the pin and a capacitor for eliminating disrupting factors.
Here is the link. It found it very interesting.
Perhaps someone is interested in the project even it is older now.
I used the code of @Frank_R and that works. Three new devices were created in HA:
Water Flow Rate
Water Usage
Water Usage M3
Hi Seb, did you find a solution for that Maddalena DS TRP water meter? I have the same.
Cheers
Paolo
@Theeyeinthesky @Olivier974 long time ago… here my mounting for 3D printing yourself https://www.thingiverse.com/thing:7039889
I’ve got a 18A3-8-Z/BX NPN sensor (5VDC 300 mA). LED is blinking when I use water, but the output is around 5V which is too high for a ESP.
Are you using this without resistors?
@pbrink and and others… thanks for sharing the info in this thread.
I’ve just installed a water meter in my home pipework with a reed sensor and want to get the data into HA. I’m struggling a bit because, unlike all the posts I’ve seen here, I’m not using ESPhome as an intermediary. I’ve connected my meter’s pulse output to an EMS-ESP32 device which is monitoring my home heating system. This is then passing the pulse data to HA via MQTT…
Which I can then add to a card to see the on/off state changes…
I’ve disabled it in the recorder because I don’t need to keep the timestamped state changes!
So… I’d like to do a few things from there…
- Convert the pulse train into a litres/minute graph - hours and days I can get in the Energy dashboard
- Convert the pulse train into a metered value I can add to the Energy dashboard
How can I do this with my setup, please, rather than via ESPhome? Thanks!
Awesome project! Going to try this
For people interested in storing the usage total in flash mem to have it survive reboots, have a look at my writeup on adding a water meter to the SlimmeLezer WT32-ETH01.
1 Like
Hey there,
I have the exact same meter and I tried today with a reed sensor, but I cant get a reading.
Did you manage to get it to work?
Thanks!
Did you ever get monitoring setup for your Water Meter? I have the exact same Recordall model.
No, at this point I’d just use the LLM integration to google or whatever and make it tell you. My area everyone has soft water tanks and it has to essentially for us weekly regenerate so i have a leak detecter that helps me validate its working and such which was my main goal. Getting anything else proved to be too much trouble for what it was worth for me.
I have worked out a solution based on the design of mdklapwijk. Thanks for sharing your code.
I re-designed it so you have only the water meter into the solution.
esphome:
name: watermeter
friendly_name: watermeter
on_boot:
then:
- pulse_meter.set_total_pulses:
id: water_meter
value: !lambda "return id(water_meter_total);"
esp32:
board: esp32dev
framework:
type: esp-idf
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "*************************************"
actions:
- action: set_water_meter_total
variables:
new_water_meter_total: int
then:
- logger.log:
format: Setting water meter total from %d to %d.
args: [id(water_meter_total), new_water_meter_total]
- pulse_meter.set_total_pulses:
id: water_meter
value: !lambda 'return new_water_meter_total;'
ota:
- platform: esphome
password: ""*************************************""
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Watermeter Fallback Hotspot"
password: "*************************************"
captive_portal:
# Web server for local access
web_server:
port: 80
globals:
- id: water_meter_total
type: int
restore_value: yes
sensor:
- platform: pulse_meter
pin:
number: GPIO12
name: "Water Pulse Meter"
id: water_meter
internal_filter_mode: "PULSE"
internal_filter: 100ms
unit_of_measurement: "liter/min"
timeout: 60s
icon: "mdi:pulse"
total:
id: water_consumed
name: "Water Consumed"
accuracy_decimals: 3
unit_of_measurement: "m³"
icon: mdi:water
device_class: water
state_class: total_increasing
filters:
- multiply: 0.001
- lambda: |-
id(water_meter_total) = id(water_consumed).raw_state;
return x;
Hi all, I have a working solution since about year based on the initial idea and code of Pbrink.
I tried different hardware configuration but ended up with the Zener diode to bring back the voltage from 5V(usb) to 3.x.
Here is my diagraming; (drawIO in Github)
code of my esp yaml sensor:
# Sensor watermeter
sensor:
- platform: pulse_counter
pin:
number: 12
allow_other_uses: true
mode:
input: true
output: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
update_interval: 6s
name: water pulse
id: water_pulse
disabled_by_default: false
force_update: false
unit_of_measurement: pulses/min
icon: mdi:pulse
accuracy_decimals: 2
state_class: measurement
count_mode:
rising_edge: INCREMENT
falling_edge: DISABLE
internal_filter: 13us
- platform: pulse_meter
id: water_pulse_meter
pin:
number: 12
allow_other_uses: true
mode:
input: true
output: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
name: Water Pulse Meter
unit_of_measurement: L/min
icon: mdi:water
total:
name: Water Total
unit_of_measurement: L
id: water_total
accuracy_decimals: 0
device_class: water
state_class: total_increasing
disabled_by_default: false
force_update: false
icon: mdi:pulse
disabled_by_default: false
force_update: false
accuracy_decimals: 2
state_class: measurement
internal_filter: 13us
timeout: 5min
internal_filter_mode: EDGE
- platform: copy
source_id: water_total
name: Water Meter Total
unit_of_measurement: m³
id: water_meter_total
accuracy_decimals: 3
device_class: water
state_class: total_increasing
filters:
- multiply: 0.001
disabled_by_default: false
force_update: false
icon: mdi:water
- platform: template
name: Water Usage Liter
id: water_flow_rate
accuracy_decimals: 1
unit_of_measurement: L/min
icon: mdi:water
lambda: !lambda |-
return (id(water_pulse).state * 10);
update_interval: 6s
disabled_by_default: false
force_update: false
code of my configuration.yaml :
# Water Meters
# omrekeningsvariabelen voor opsplitsing van totalizer naar etmalen etc
# source format https://www.home-assistant.io/integrations/utility_meter/
utility_meter:
util_water_usage_quarter_hourly:
source: sensor.watermeterplus_water_total
cycle: quarter-hourly
name: Water usage quarter hourly
unique_id: util_water_usage_quarter-hourly
util_water_usage_hourly:
source: sensor.watermeterplus_water_total
cycle: hourly
name: Water usage hourly
unique_id: util_water_usage_hourly
util_water_usage_daily:
source: sensor.watermeterplus_water_total
cycle: daily
name: Water usage daily
unique_id: util_water_usage_daily
util_water_usage_monthly:
source: sensor.watermeterplus_water_total
cycle: monthly
name: Water usage monthly
unique_id: util_water_usage_monthly
util_water_usage_yearly:
source: sensor.watermeterplus_water_total
cycle: yearly
name: Water usage yearly
unique_id: util_water_usage_yearly
Besides the graphs of Frank I added the monthly graph with apexchart:
type: custom:apexcharts-card
header:
show: true
title: Monthly Water Use
show_states: true
colorize_states: true
graph_span: 12 months
span:
start: month
offset: "-11month"
series:
- entity: sensor.water_usage_monthly
type: column
statistics:
type: state
period: month
align: middle
I have one challenge to figure out. If I do a firmware update of the ESP the totalizer does not get reset. But when WIFI drops or power outage for a short moment, the totalizer gets reset.
I’m thinking of playing with the ‘total_increasing’ or ‘total’ as state_class. But don’t know if that will help.
3 Likes
@Floriszz, using total_increasing helps when having Home Assistant calculate statistics such as change (like hourly usage) or sum (meter reading), rather than doing the calculations in the ESP. These work just as expected, even if state was reset to zero.
And I guess you know, but I’m quite sure that the WiFi-drop is causing your ESP to reboot:
ESPHome intentionally reboots after a configured duration in specific situations, such as when the Wi-Fi connection cannot be made, API connection is lost or MQTT connection is lost. To disable this behavior, you’ll need to explicitly set the
reboot_timeoutoption to0son the relevant components.
I could imagine there’s some callback that can make sure your totals are saved prior to such reboot as well, but I’ve not searched the docs for that. Also, such would still not handle power interruptions.
And aside, for future readers: rather than using a proximity sensor and deal with its power requirements, I successfully used a 3.3 volts infrared TCRT5000 Line Tracking Sensor Module on an Itron Aquadis+ water meter. I figured using an infrared sensor to detect a shiny metal-like segment on a rotating white disc could be troublesome. But it was really easy to read the pulses using its digital output, and it’s quite small. (It’s unclear to me if the metal part on the flow indicator is a magnet. Itron also sells a lot of pulse sensors, but most actually explicitly claim resistance to external magnetic influence, to avoid fraud. So, unsure if a hall sensor may work too?)
Thanks for your reply/feedback. I use many of those ir line sensors(mainly designed for robots). They work just as well. But still reliant on pulses. If I make a new meter I think I will go for an esp with cam to read the actual meter numbers and ocr them to numbers. That is 100% statefull.
Note on Pulse Counter in my code above.
I noticed that the pulse counter does not register any pulses. I do see it polling in the logs, but it never picks up anything. I changed to falling edge, but no difference.
The pulse meter works well, besides the resets. But the resets do not have effect on daily/weekly/monthly/yearly totals.
@Floriszz, also when only using Pulse Counter?
The Pulse Meter documentation states:
Please note that it is not possible to use both of these two sensors on the same pin at the same time.
More details
I doubt multiple interrupt service routine (ISR) handlers can be attached to a single GPIO. For an ESP32 the documentation for gpio_isr_handler_add may not be explicit about that, but its counterpart gpio_isr_handler_remove only needs the pin number. So, I’d say: one handler (and one type) per pin. And that first function is called by ESPHome’s attach_interrupt for an ESP32.
Similar code in ESPHome for the ESP8266 you’re using. (For which I cannot find the definition of attachInterruptArg which is used there, but assuming it works the same.)
So, I’d guess that using both Pulse Counter and Pulse Meter simultaneously on the very same GPIO like in your configuration, will make the second override the configuration of the first?
Aside, I’d prefer Pulse Meter for the documented reasons, though (today) it may still need a PR that has not been merged into ESPHome yet.
1 Like
@vxbx , thanks for the feedback. I removed the pulse counter, while the pulse meter is way more efficient.
I start a monitor of the actual meter readings over de last 5 days and what the pulse meter registered.
The acutal meter says 1.533m3, which sounds reasonalbe, while we use around 100m3 per year.
But the pulse meter has registered 1902m3. That is quite a difference.
I think the problem is when the iron rotator stops under the sensor and the red led of the sensor stays on. I can see the pulse meter (L/min) stays for example on 5,4L/min for multiple minutes.(until the next water usage).
So if the pulse stays high(led on) for more than the flow rate it should stop counting. But don’t know where to tweak this.?
The little iron rotator counts from 0-10 and there is a printed ‘x0.0001’ on the display. So 1 rotation should be 10x0.0001=0.001m3=1ltr.
As it is a QN1.5 meter it has a rated flow of 1.5m3/hour with a max of 3m3/hour.(=3000 L/h)(according to specs).
That would mean the max rotation speed of the iron wheel would be:
3000 L/h ÷ 60 = 50 L/min = max 50 rotations/min.
I noticed the sensor picks up on the ‘big’ part of the pointer.(not the little arrow). That means every pulse stays high for 3x10x0.0001m3=0.3liter.
So 1 rotation is on it’s fastest 1,2sec(60sec/50rotations). Where the pulse will be high for the least amount of time of 3/10 of 1,2=0,36sec=360ms.
So should I set the internal_filter to 360ms in stead of 13us? Or does it not matter in this case?
@Floriszz, that is actually as expected, if it’s not getting any new pulses. It needs the time between two pulses to guesstimate the real-time current usage. When not getting any new pulses, it awaits timeout to stop reporting the last known usage per minute, and then reports zero usage:
timeout (Optional, Time): If we don’t see a pulse for this length of time, we assume 0 pulses/s. Defaults to
5 min.
So, I’d say seeing this actually confirms that the sensor is working as expected then.
Now, maybe things are different if the rotating disc stops just in between its on/off position, erroneously generating many pulses. That would show as a very high real-time usage per minute though. Do you see that in any statistics? If yes, then changing internal_filter may help, if you cannot adjust the sensor.
And in any case, if all is well, the total should not increase even if seeing the last value for liters/minute over an extended period of time, since pulse meter is not counting any new pulses.
So: how did you get to the 1,902 m3?
Also, are you using the PR? That is still not merged yet, and may surely be needed.
By the way, @Floriszz: were the measurements okay before removing Pulse Counter? If yes: was this the first time you uploaded a new configuration to your ESP8266 since that year that you mentioned? And did you meanwhile also upgrade ESPHome?
The forum post Pulse_meter seems to be buggy dates back to September 2025. But the bug report #4807 pulse_meter seems to have broken with 2023.8.0, which seems to be the result of some December 2022 thru August 2023 code refactoring, was reported all the way back in August 2023. (The bug report shows some nice graphs showing the spikes that make Pulse Meter think usage is much higher, due to fake pulses that the sensor never actually registered.) Earlier I thought all should be fixed by using the PR #12360 mentioned earlier, but according to the author, #12360 only fixes a bug introduced in 2024.5.0. For me, that sufficed.
If you remember the last time you uploaded working code to your ESP8266, then maybe the readings are also better if you pin/downgrade Pulse Meter to the version you used back then. Like if your ESPHome was up-to-date at that time, then maybe 2024.12.4 works. It’s more likely 2024.4.2 will work. And surely 2023.7.1 should be okay:
external_components:
- source: github://esphome/[email protected]
components: [pulse_meter]
refresh: 1h
But I’d prefer to use code that is likely to become mainstream soon, and needs confirmation that it works for others. So, to use the PR:
external_components:
- source: github://pr#12360
components: [pulse_meter]
refresh: 1h