Track a gas meter with ESPHome

Hi,
i have a gas meter i want to track in Home Assistant. I have attached a reed switch to the gas meter and every time the second decimal place completes one turn the switch gets triggered.

I have created a pulse counter with ESPHome and a utility meter inside Home Assistant that tracks the total daily usage based on the pulse counter. However this is a very unprecise way of measurement, because the pulse meter often lags behind. I believe this is caused by the fact that the gas meter often is not turning at all, because no gas is used (see the attached picture) and ESPHome takes a few seconds to ā€œrealizeā€ this and correct the value. Please correct me if i missunderstoof the functioning of the pulse counter.

chrome_2020-01-12_10-48-37
Gas consumption in mĀ³/min

I also implemented a template sensor in ESPHome that simply counts the number of times the reed switch got triggered. This value perfectly corresponds to the actual value on the meter.

Im unsure where to go from here. While the second method results in precise values, im unsure how to implement this in Home Assistant. I also see the problem, that in the case of a power loss the esp loses the value and the whole measurement gets thrown off.

I canā€™t speak to the HA setup side of things, but you are rightly concerned about power/data loss. You could try adding a LiPO charger and battery to your circuit. Sometimes like this one could work:

This makes no sense. What precisely are you seeing?

One full rotation ( 0 back to 0 ), or increments one number ( ie: 3 to 4 )?

I think youā€™re confusing instantaneous and accumulated usage.

You want a counter to add the pulses together rather than measure individual pulses over time as you currently are.

You could then tie this in with the utility_meter integration:

Hi, I have done this and documented it here (in german):
https://smarthome.ms1.de/projekte/gasverbrauch/

4 Likes

Hi, thanks for sharing your project @saruter. I didnā€™t know traditional gas meters had that magnet feature. Iā€™m going to check if mine supports this to try implementing your project.
A pair of questions:

  • when you say ā€˜extract from the ESP yaml codeā€™ is it the full code needed for the ESP part or is it just a part (extract) of the whole code?
  • In the hardware needed you include: ā€˜KƤbelchenā€™ that translates as ā€˜smallā€™ . I guess this is a typo or a bad translation, isnā€™t it? I understand that all is needed includes the magnet switch, the ESP8266 NodeMCU, the USB power supply and the housing, am I right?
    Thanks again for sharing!!

It is an extract, it is not the full yaml. For example the wifi settings, api, ota, device type.

Kabelchen is (I think) small cable or what might be written as hookup wire.

Hi, nickrout is right, the code lacks the standard settings for Wi-Fi and so on but the code is complete for the reading and calculation.
KƤbelchen are the typical jumper wires often used with breadboards and so on. I used them to connect the loose end of the reed switch cable to the ESP (Female to Female Jumper Wire). Soldering is another optionā€¦

Ok thanks, understood @saruter .
And regarding connections from the reed switch to NODE MCU: I understand that the reed switch is normally open and has 2 wires, so one will connect, according to your code, to GPIO5(D1) and the other one, I guess to 3V3?? Thanks again.

Typically you use the input_pullup mode for the pin in esphome and then connect one wire to that pin on the esp and the other to ground.

1 Like

I found this tuturial helpful when trying to understand pullup resistors

https://learn.sparkfun.com/tutorials/pull-up-resistors/all

1 Like

Hi! Iā€™ve already implemented @saruter ESPHome gas meter(thanks!!) with espHome and Iā€™ve already tied it with an utility meter. Itā€™s working well but it is not very accurate. I guess because of the way it measures every 60 seconds. So if I understand your code:

  • Being the code as it is, if the gas consumption just stops (gas meter stops) precisely at the moment when it is closing the pullup input because of the magnetic reed and counter position closing the ā€˜switchā€™, then, every 60 seconds (updating interval chosen) weā€™ll get a not valid +0.01 increment into our gas meter.
    I know nothing about esphome coding but, is there anyway to manage to trigger the sensor only if the switch has just changed from 0 to 1 and only then add +0.01 to our gas meter?? and after that only keep listening if the sensor has changed from 1 to 0 only?? If this is possible, measures would be completely accurate. Thanks again!!

Hi, @nickrout, very useful. Now I understand it, and as NodeMcu offers an input pull up mode (having internally the adequate resistor, it can just be connected as @MatthewFlamm pointed out: one wire to the input pin (in pullup mode) and the other to ground. Thank you both!!

OK, Iā€™ve read the espHome code docs and now I get that teh platform pulse_counter already takes into account what I was talking about, but Iā€™m still getting more counts than the real ones and I donā€™t understand why. Just in case I have included this to the code:

count_mode:
    rising_edge: INCREMENT
    falling_edge: DISABLE
filters:
  - debounce: 15s

But the same issue still happens, itā€™s counting more than real. Iā€™ve no idea why I could have this problem. Now my gas meter itā€™s not really accurate at all.

1 Like

@jolaca: have you found a solution for accurate values? I also tried to build up the version @saruter mentioned, but get incorrect values.
What does your NodeMCU setup look like? I used that setup:
grafik

Hi, sorry, currently Iā€™m not living where I have it installed and I donā€™t remember how I connected it. If I have time Iā€™ll take a look at it and report back.

@jolaca
@ha2

anyone a solution ? ve the same problem, more counts as in real.
try it with pulse_counter and pulse_meter, both the same

Hi,

I try too but I have more count than real. Anybody found solutions?

Thx

For me, the following setting solved the problem:

    filters:
      - debounce: 1.5s

Consider reconsidering your design/architecture. (this may alarm some readers)
The sensor is not necessarily the best place to be tracking the ongoing state of the meter. And, itā€™s harder to make the sensor be robust enough to store state across power glitches, etc.
Whereas, your HA installation - the receiver and ultimate database supporting your goal - is more likely to be fortified (UPS?) against power outage, but also will remember its data during an actual outage.
So in such a rebalanced design, you put the emphasis on how HA processes and retains the usage ā€˜tickā€™ events for you.
For example:
Shift the ā€˜weightā€™ of your design inboard, away from the ā€˜sensorā€™ (the ESP) and toward the layer where the database will live.
Instead of having the ESP retaining state, let HA do that for you.
Let the ESP merely send HA the events when the pointer passes its mark, using the sensing equipment and setup you already have.
Turn your focus to how to make HA retain and present the data as you want.
Or consider using an alternative data gathering/presentation system (nagios, munin?) if HA doesnā€™t provide what the graph(s) you want to see.
Under this rebalanced design, in case of outage you may lose some usage events as the pointer passes the mark without being counted, but you wonā€™t lose the cumulative usage thatā€™s already stored in HA. That seemed to be your ultimate goal, if I understood your OP at all.

3 Likes