Gas meter (pulses) using Beetle ESP32-C6

ESPHome
1

I had decided to write this after not been able to find a tutorial to use a reed sensor to measure the consumption of gas in my home.

Requirements

  • A meter (not necesarily a gas meter) that has a magnet attached to one of the numbers that rotate in the screen.
  • An Beetle ESP32-C6 board (mine cost me around 7USD from Botland.pl).
  • A reed sensor compatible with your meter*
  • A Li-Pol battery pack (I bought a 4000mAh for 12USD)

*I had to purchase the Apator NI-3 pulse transmissor since my gas meter has a special socket for it. No other reed sensor gets close enought to the magnet to work.

Once I got the board I solder the pins into the it and connected the cables in this way:

image
image847Ă—526 72.5 KB

This is the EspHome configuration I used:

I had removed sections for configuring openthread/wifi, ota, logger, etc.

esphome:
  name: gas-meter
  friendly_name: Gas Meter
  on_boot: 
    then:
      - globals.set: 
          # This is used below to avoid updating the global total_pulses BEFORE pulse_counter.set_total_pulses is executed. Otherwise "total_pulses" will be set to 0
          id: data_was_restored
          value: 'true'
      - pulse_counter.set_total_pulses: 
          id: gas_pulse_counter
          value: !lambda 'return id(total_pulses);'

preferences:
  # This reduces the number of writes in the onboard memory and extends its lifespan
  flash_write_interval: 60s

globals:
  - id: total_pulses
    type: int
    restore_value: yes
    initial_value: "0" # This is not a mistake. Globals are all stored as strings.
  - id: data_was_restored
    type: bool
    initial_value: "0"

esp32:
  variant: esp32c6
  board: esp32-c6-devkitc-1
  framework:
    type: esp-idf

sensor:
  - platform: pulse_counter
    id: gas_pulse_counter
    name: "Current consumption"
    unit_of_measurement: "mÂł/hour"
    device_class: "gas"
    state_class: "measurement"
    icon: "mdi:meter-gas"
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT
    pin: 
      number: 7
      inverted: true
      mode:
        input: true
        pullup: true
    update_interval: 600s # 10 minutes
    accuracy_decimals: 2
    filters: 
        # According to my meter's manual, it makes a pulse every 0.01 m3. It could be different for yours
      - multiply: 0.06 # 1 pulse = 0.01 m3. 1h = 3600s. That's 6 times the update_interval.
    total:
      name: "Total consumption"
      id: total_gas_consumption
      unit_of_measurement: "mÂł"
      icon: "mdi:meter-gas"
      accuracy_decimals: 2
      device_class: "gas"
      state_class: "total_increasing"
      on_value: 
        then:
          - if:
              # This avoids overriding the total_gas_consumption global before the value is restored by on_boot
              condition:
                lambda: 'return id(data_was_restored);'
              then:
                - lambda: 'id(total_pulses) = id(total_gas_consumption).raw_state;'
      filters: 
        - multiply: 0.01
  - platform: adc
    name: "Battery voltage"
    pin: GPIO0 # The voltage of the battery is connected to this internal pin to messure its voltage
    accuracy_decimals: 2
    update_interval: 60s
    attenuation: 12dB
    samples: 10
    filters:
      - multiply: 2.0  # The voltage divider requires us to multiply by 2

# Enable Home Assistant API
api:
  encryption:
    key: "YOU NEED TO GENERATE THIS"
  actions:
      # This will create an HASS action you can use to manually update the total count of recorded pulses
    - action: set_pulse_total
      variables:
        new_pulse_total: int
      then:
        - pulse_counter.set_total_pulses:
            id: gas_pulse_counter
            value: !lambda 'return new_pulse_total;'

I bought the C6 because I wanted to use it with opentread in the hope the battery will last for months, not days.

I have it running for 113 hours using Wifi. The battery has drop from 4.16v to 3.54v so far. That’s 0.0054v per hour. Assuming the voltage will keep dropping at a similar rate, that means the 4000mAh battery will give me 8.8 days with the current configuration.

image
image1536Ă—560 42.2 KB

Today I’ll re-fjash it using openthread and compare the difference. I’ll post the results here in a few days.

1 Like
2

Nice. But I’ll be surprised if you end up with a solution that has an “acceptable” battery life. That tends to be quite difficult to achieve even with a “aggressive deep sleep” set-up.

I think some people have similar solutions which involve using a “wake-up” pin (so wake up on pulse, send data, go back to sleep).

Did you see the ZigBee alternatives? There’s one listed here. I haven’t used it.

I don’t know about openthread so keen to hear how you go there.

3

Maybe even less. Voltage drop is not linear. Many cells drop like a stone at ~3.2V.

4

The same day I published this I updated the board to update hourly instead of every 10 minutes. I send the update OTA and the battery was dead at the next day.

image
image1346Ă—506 29.1 KB

I recharge it and kept it running again to see if 3.5v is the threshold when the battery drops or the update I sent for some reason consumes more power.

It’s still on Wifi.

5

Like expected.
Esp is not low-power board.
What’s the frequency range of your pulses ?

6

You don’t frequent the Instructibles website? They have lots of implementations documented. You may even find an example or two in these forums that may have discussed battery issues with Espressif SOCs and measuring gas consumption with a reed switch meter sensor to save you re-inventing rhe wheel.

7

I based my project in what of those. But were based on using the Wifi antena. I wanted to try using Thread to see if that could be work better.

Even if it doesn’t work, I will try something else. At least this motivated me to start my first ESP32 project.

1 Like
8

Welcome!
With esp on batteries, don’t expect too much if you can’t apply sleep cycles.

9

Lately, my house consumes around 8m3 of gas per day. My meter makes a pulse every 0.01m3, so that means 800 pulses per day. An average of 33 pulses per hour.

10

In theory esp could stay in deep sleep and get wake-up signal from the meter , add counter and go back to sleep…

11

The Nordic nRF52840 SOC is a lot less power hungry and has recent ESPHome support. Worth considering as an alternative.

12

No sleep still implemented. Waiting for that…

13

Ok. I tried enabling deep sleep.

 deep_sleep:
   wakeup_pin: 
     number: 7
     allow_other_uses: true
   wakeup_pin_mode: INVERT_WAKEUP
   run_duration: 10s
   sleep_duration: 10min

It appears to wake up and report the battery, it doesn’t update the count.

I think the count doesn’t update because the event happens when the device was sleeping.

sensor:
  - platform: pulse_counter
    id: gas_pulse_counter
    name: "Current consumption"
    unit_of_measurement: "cmÂł/hour" # 1 pulse = 0.01 m3
    device_class: "gas"
    state_class: "measurement"
    icon: "mdi:meter-gas"
    count_mode: 
      rising_edge: DISABLE
      falling_edge: INCREMENT
    pin: 
      number: 7
      inverted: true
      mode:
        input: true
        pullup: true
       allow_other_uses: true
    update_interval: 600s # 10 minutes
    accuracy_decimals: 0
    filters: 
      - multiply: 6 # Update interface is every 10 min, so extrapolate the consumption of the last 10min for the entire hour

I could update my config to wake up the board when the reed sensor is closed, and count when its open. But I had seen a couple time when the meter stops just when the sensor is close. There’s 1/10 chance for that. But over time that will introduce too much error.

What could I do?

14

That’s why I wrote “in theory”. You can count the wakeups separately, use binary sensor to count pulses when awake and put them together.
I’m not very confident of the behavior when meter stops “on the edge” of the reed though…

15

Even with deep sleep I reckon with a wake cycle of ~2min you’re not going to get the battery life you’ll want for this long term. Might be ok if those esps are well optimised for battery, but will depend a lot on idle current and minimising wake time.

I would be looking around at zigbee solutions before going down ESP deep sleep rabbit holes (unless you want to do it as a learning project).

16

Whatever wireless approach / microcontroller you choose, you still need sleep cycling.
Esp32 is power hungry, but it can be optimized for double digit microamp draw for sleep. Wake current is double digit milliamps at best. So if the device is sleeping 99.99% of the time, battery life is measured in years.
Obviously you can’t connect to wifi every time it wakes up, it takes forever and raises the current draw to triple digits mA.

Waiting for NRF52 deep sleep component on esphome to jump into next rabbit hole… :grinning:

1 Like
17

That is the normal mantra.

This has changed with the latest low power models recently announced by Espressif that target low power consumption needs. They have listened to their customers and recognised their competitors can do it easily.

33 wakes per hour to transmit is going to chew quite a bit of battery power on your ESP32. You also need to keep the count running somehow. Maybe you need to change your approach, using an external counter chip that is low power, and poll via your ESP chip on a regular basis, woken by a trigger from a clock chip or similar. By the time you do this with all the added chips, you could be using another chipset that already has this specifically included in the SOC.

Support for the new chips and how to invoke low power operation is nearly here. You are wasting your time trying to use the older generation ESP chips - many people have tried with poor results.

Counting while sleeping is a big ask unless the chip is specifically designed for that function. A lot of competitors do have that, but not the chips you are trying to use to do the impossible.

Not to rain on your parade but there are numerous threads in these forums (I discussed it with another naive enthusiast neophyte recently in another thread) and discussions on the internet that you may wish to read, and this will save you a lot of frustration and wasted time to continue down this track with your current chip.

In the four requirements you listed in the first post in this thread, the second is the one you need to examine closely - the other three have been used widely for many years. It is common for ten year battery life for carefully designed smart meter interfaces, and you are wasting your time looking to extend your battery time by a matter of days and weeks.

Sorry to inject a bit of reality into your endeavours. Read a little more widely and learn from others’ failures. When the new Espressif chips become more common and prices become attractive, and the software and firmware support eventuates, come back and reinvestigate this challenge.

As I mentioned earlier, the NRF52840 is one chip you may wish to look at. There are many more, and you don’t have to stick to ESPHome as the method to count meter pulses - you have many other choices such as MQTT to get your data into HomeAssistant, and there is a lot of source code on GitHub to give you ideas, even in the Arduino ecosystem which is also widely established.

Best wishes in your path of discovery. Your time here hasn’t been wasted. The concepts you have learned will be applied to future attempts. Please be sure to come back and tell us what has eventually worked for you.

18

Problem here is not just Esp32, but also esphome. To wake up and boot the esphome setup and then add to counter (even wireless connections disabled) takes probably 10x what it could with optimized idf setup.

I’m usually not thrilled marrying two microcontrollers, but in OP’s case I would source the pulse counting to some ultra low power MCU and wake up esp once an hour or two to update.

19

As a diversion, whole discussing alternate SOC chipsets, are the Raspberry Pi Pico series that ESPHome also supports able to do low power meter reading? Haven’t bothered to check that out as the Pico 1 series didn’t have wireless, and the Pico 2 uses an external chip onboard for wireless (WiFi and BlueTooth) connectivity. Any comments welcome while waiting for expanded nRF52840 functionality in ESPHome.

Most of these new chips also have BlueTooth, ZigBee and even Thread/Matter support.

I haven’t seen a lot of discussion in these forums on the Pico series.

IOT industry giant Tuya have been doing it for ages [TuyaMCU], using the strengths of each chipset to achieve their goals at a competitive pricepoint.

20

What I’ve observed a fair bit is that while low power esp projects often look reasonable on paper, in practice they are not a good newbie project.

You really need to be selective with hardware and then optimising the software, sleep cycles, data updates is quite involved.

At least intermediate or advanced knowledge required.

People seem to be getting about 6months out of comparable zigbee solutions.