Reading Itron EverBlu Cyble RF Water/Gas Meters (ESP8266/ESP32 + CC1101) - MQTT & ESPHome Integration

Share your Projects!
, , , ,
64

That’s awesome, nice work!

66

PING: @Minims @frazor77 @Vorhees @GSzabados @AltF4me @91JJ @smartmatic @DWeyel @titidelain @Syl20-62

Major Update: v2.1.0 Released + ESPHome Integration Now Available

Hi everyone! Big news on the EverBlu Cyble meter reader project.

What’s New in v2.1.0

I’ve just released v2.1.0 with significant improvements to both the existing MQTT firmware and a brand new ESPHome integration option.

For MQTT Users (Existing Setup)

If you’re already using the MQTT version, here’s what’s new:

New Features:

  • Adaptive Frequency Tracking: The firmware now intelligently optimizes the CC1101 frequency offset based on successful reads. This means better signal reliability over time as it adapts to your specific hardware.
  • Enhanced Monitoring: New sensors for read attempts counter, frequency offset, and tuned frequency reporting
  • Improved Reliability: Better frequency persistence and handling across reboots

All existing MQTT functionality remains unchanged - this is a drop-in upgrade. Your current configurations will continue to work.

NEW: ESPHome Integration

This is the big announcement: I’ve created a fully functional ESPHome external component that brings native Home Assistant integration without needing an MQTT broker.

Why ESPHome?

  • Simple YAML configuration (no C++ header editing)
  • Native Home Assistant integration with automatic discovery
  • All the ESPHome benefits (OTA updates, logging, diagnostics)
  • Same proven codebase as the MQTT version (years of testing and refinement)

Available Sensors (15+):

  • Volume (liters/m³), Battery, Counter, RSSI, LQI
  • Time Start/End, Backflow, Leak, Meter Error indicators
  • Read attempts, Frequency offset, Tuned frequency
  • WiFi diagnostics
  • Plus button controls for manual reads and frequency reset

Technical Highlights

Shared Codebase: Both MQTT and ESPHome versions use the exact same core code (~95% shared). All the CC1101 radio handling, RADIAN protocol decoding, frequency calibration, and multi-layer frame validation is identical between both implementations.

Advanced Frame Validation:
The firmware implements 5 layers of validation to ensure data integrity:

  1. Custom serial decoding (proprietary 4x oversampled encoding)
  2. CRC-16/KERMIT Frame Check Sequence
  3. Frame structure validation (preamble, length, headers, serial matching)
  4. Temporal validation (wake windows, counter continuity, battery bounds)
  5. Signal quality filtering (RSSI threshold, LQI assessment)

Result: You only get data when the firmware is highly confident the reading is genuine.

Known Issue

There’s one known limitation in the ESPHome version: the discovered best frequency offset isn’t persistent between reboots (the frequency scan will re-run on each boot). The MQTT version doesn’t have this issue. I’m working on refining the persistence mechanism, but all core functionality works perfectly in the meantime.

Documentation

Full ESPHome Guide: ESPHOME/README.md

GitHub Repository: genestealer/everblu-meters-esp8266-improved

Changelog: CHANGELOG.md

Migration

From MQTT to ESPHome: Super easy - just use the same meter_year and meter_serial values from your private.h. ESPHome will auto-discover sensors with similar entity IDs, so no dashboard reconfiguration needed.

Staying on MQTT: That’s perfectly fine too! Both versions are actively maintained and share the same codebase improvements.

Feedback Welcome

I’ve been testing both versions extensively on real hardware (ESP8266 and ESP32, water and gas meters), but would love to hear from the community:

  • How does the ESPHome version work for you?
  • Any issues with the adaptive frequency tracking?
  • Feature requests?

Feel free to open issues on GitHub or reply here. Happy to help with setup questions!

Credits: As always, this builds on the amazing reverse engineering work by La Maison Simon, neutrinus, and psykokwak. This update is my contribution to make it even better for the Home Assistant community.

67

PING: @AltF4me @llaumgui
See link above for ESPHome integration for reading these meters.

68

I have just built the ESP8266 + CC1101 ESPHome version and it works just great … :grin:

Thanks for all your hard work and the excellent documentation.

I have just one query - and it is to do with the time. I am in Melbourne, Australia and we are currently 11 hours ahead of UTC. I have this in my YAML code:

# Time component (required for scheduled readings)
time:
  - platform: homeassistant
    id: homeassistant_time
    timezone: Australia/Melbourne

but in the log I see this:

[12:01:13.131][C][everblu_meter:310]:   Reading Schedule: Monday-Friday
[12:01:13.142][C][everblu_meter:311]:   Read Time: 10:00
[12:01:13.142][C][everblu_meter:312]:   Timezone Offset: 0

It is not clear to me if the “Read Time:” will be 10:00 UTC or 10:00 AEST (my time)?

69

@Taipan

Good catch.

Please add the optional timezone_offset setting to everblu_meter

everblu_meter:
  id: my_water_meter
  
  # Link to time component
  time_id: homeassistant_time
  
  # Optional: Timezone offset in MINUTES (default: 0 = UTC)
  # ⚠️ IMPORTANT: ESPHome's 'timezone' setting above is NOT automatically used!
  # You must manually set this parameter for scheduling in your local timezone.
  # This is a static offset (doesn't auto-adjust for DST).
  # Examples: 60 = UTC+1, -300 = UTC-5, 660 = UTC+11 (Melbourne summer)
  timezone_offset: -240  # US Eastern EDT (UTC-4)

This is currenlty a Known Limitation, the timezone_offset parameter is currently required for scheduling in your local timezone. The ESPHome time component’s timezone setting (e.g., timezone: Australia/Melbourne) is not automatically used by the everblu_meter component.

This is a design limitation inherited from the MQTT/standalone version:

  • MQTT/Standalone mode: Uses NTP which only provides UTC time, so manual offset is necessary

  • ESPHome mode: Could leverage ESPHome’s timezone-aware time (which handles DST automatically), but currently doesn’t

Current Workaround:

  • You must manually specify timezone_offset in minutes (not hours)

  • The offset is added to UTC to get your local time

  • Positive values for east of UTC, negative for west

  • This is a static offset - it doesn’t automatically adjust for Daylight Saving Time

70

Thanks for the clarification on time zones.

As I thought that the Timezone Offset value was in hours, I had it entered as 11. But now I realise that the value should be 660, in minutes.

Even so, I was getting a reading everyday at exactly 12:00 pm (midday).

[10:27:53.606][C][everblu_meter:310]:   Reading Schedule: Everyday
[10:27:53.616][C][everblu_meter:311]:   Read Time: 01:00
[10:27:53.616][C][everblu_meter:312]:   Timezone Offset: 11
[10:27:53.628][C][everblu_meter:313]:   Auto Align Time: Enabled
[10:27:53.628][C][everblu_meter:314]:   Auto Align Midpoint: Enabled

Is that because Auto Align Time and Auto Align Midpoint are both enabled and since my EverBlu unit’s awake time is from 05:00 to 19:00 (of which the midpoint is 12:00) , then this will override the Timezone Offset value anyway?

71

Hello everyone. I see this project is evolving nicely, that’s good. I’m wondering though, do ppl still have issues with water companies not being able to read water meter, if using this as well?

V.

72

Yes, a few users have historically reported issues with the water company not liking it when the water meter’s built-in read counter is outside of some arbitrary threshold from the last reading they made.

If that is a concern for you, then I have a documented workaround in the README for the project.

73

Hello Richard,

did you see my issue on GitHub that wifi.h is missing?
No compiling via ESPHome Builder is possible.

Here is what I see in the log:

Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.10
|-- SPI @ 3.3.7
Compiling .pioenvs/everblu-water-meter/src/esphome/components/everblu_meter/everblu_meter.cpp.o
Compiling .pioenvs/everblu-water-meter/src/esphome/components/everblu_meter/frequency_manager.cpp.o
Compiling .pioenvs/everblu-water-meter/src/esphome/components/everblu_meter/meter_history.cpp.o
Compiling .pioenvs/everblu-water-meter/src/esphome/components/everblu_meter/meter_reader.cpp.o
src/esphome/components/everblu_meter/everblu_meter.cpp:14:10: fatal error: WiFi.h: No such file or directory

********************************************************************
* Looking for WiFi.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:WiFi.h"
* Web  > https://registry.platformio.org/search?q=header:%1B%5Bm%1B%5BKWiFi.h
*
********************************************************************

   14 | #include <WiFi.h>
      |          ^~~~~~~~
compilation terminated.
*** [.pioenvs/everblu-water-meter/src/esphome/components/everblu_meter/everblu_meter.cpp.o] Error 1
========================= [FAILED] Took 11.77 seconds =========================

Regards
René

74

Yes fixed :slight_smile:

75

Hi everyone,

I’m trying to read my water meter using ESP32 + CC1101 and the everblu-meters-ESPHome component.

My meter:

•	Model: Itron AnyQuest Cyble Basic V1.1
•	Serial format: 15-XXXXXXX-075
•	Date: 12/2015
•	Frequency: 433MHz

My hardware:

•	AZ-Delivery ESP32 DevKitC V4
•	Ebyte E07-M1101O (CC1101 433MHz SMA)
•	Wiring: CSN→GPIO5, GDO0→GPIO4, SCK→GPIO18, MOSI→GPIO23, MISO→GPIO19

Problem:
Every read attempt results in GDO0 never asserted. I tested frequencies from 433.76 to 433.90 MHz — all timeout. ESP32 placed directly next to the meter (10cm). Tested on Monday morning 08:30-10:00 (business hours).

TX is sent correctly (TX: request len=39) but meter never responds.

Meter read start (freq=433.820007 MHz, year=15, serial=XXXXXXX)
TX: request len=39
RX stage1: GDO0 never asserted (tmo=150ms)
Timeout on first receive
Failed to read meter

Question:

Has anyone successfully read an AnyQuest Cyble Basic (not Enhanced)? Is the RADIAN protocol identical? Could this model use a different protocol or timing?

Any help appreciated!

76

That's interesting; I hadn't realised there was a basic version. After researching it, it seems it might be readable, but it would need a different transmission frame, which would require reverse engineering.

Feel free to open an issue ticket on my repository and provide a raw received frame, and we can see if we can reverse engineer it.

77

Hello, first of all, thanks for this project.

I’d like to switch to the new version of ESPHome, but I can't pick up the signal—even though it works fine with an older version! Here are some logs below.

OLD VERSION

Everblu Meters ESP8266 Starting...
Water usage data for Home Assistant
https://github.com/genestealer/everblu-meters-esp8266-improved
Target meter: 24-0336270
Target frequency: 433.7849120000

Wi-Fi PHY mode set to 11G.
> Reading schedule: Monday-Sunday
###### FREQUENCY DISCOVERY ENABLED (433 MHz) ######
Starting Frequency Scan...
Test frequency : 433.760010
CC1101 Partnumber: 0x00
CC1101 Version != 00 or 0xFF  : 0x04
MARCSTATE : raw:0x13  0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
202 free_byte:0x0F sts:0x07

...

size_byte=18  l_radian_frame_size_byte=25
GDO0! (0, 0) 1st synch received (1)  rssi=170 lqi=128 F_est=254
GDO0! (1, 70) TMO on REC

size_byte=124  l_radian_frame_size_byte=171
GDO0! (0, 0) 1st synch received (1)  rssi=170 lqi=128 F_est=255
GDO0! (1, 95) frame received (687)
stop bit error10
------------------------------
Got frequency : 433.786865
------------------------------
Liters : 275735
Battery (in months) : 156
Counter : 110


--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Soft WDT reset
...


NEW VERSION

Everblu Meters ESP8266/ESP32 Starting...
Water/Gas usage data for Home Assistant
https://github.com/genestealer/everblu-meters-esp8266-improved
[STATUS] Firmware version: 3.0.1
[STATUS] Target meter: 2024-0336270

[STATUS] Meter type: WATER (readings in L)

=== Configuration Validation ===
✓ METER_CODE: 24-0336270-219 (year=24, serial=336270)
✓ FREQUENCY: 433.820000 MHz
✓ Reading Time (UTC): 10:00
✓ GDO0 Pin: GPIO 5
✓ GDO2 Pin: GPIO 4 (TX/RX FIFO threshold - hardware-assisted underflow prevention)
✓ Reading Schedule: Monday-Friday
================================

✓ Configuration valid - proceeding with initialization

[MQTT] Base topic: everblu/cyble/336270
[MQTT] Meter serial string: 336270
[MQTT] mqttBaseTopic length: 20
[STORAGE] EEPROM initialized
[FREQ] No valid frequency offset found in EEPROM
[FREQ] No stored frequency offset found. Performing wide initial scan...
[FREQ] Performing wide initial scan (first boot - no saved offset)...
[FREQ] Wide scan from 433.720001 to 433.920013 MHz (step: 0.010000 MHz)
[FREQ] This may take 1-2 minutes on first boot...
[I][everblu_meter] Radio found OK (PARTNUM: 0x00, VERSION: 0x04)
[FREQ] Wide scan failed - no meter signal found!
[FREQ] Please check:
[FREQ]  1. Meter is within range (< 50m typically)
[FREQ]  2. Antenna is connected to CC1101
[FREQ]  3. Meter serial/year are correct in private.h
[FREQ]  4. Current time is within meter's wake hours
[FREQ] No valid frequency offset found in EEPROM
[WIFI] Wi-Fi PHY mode 11G is disabled.
[SCHEDULE] Reading schedule (configured): Monday-Friday
[SCHEDULE] Reading schedule (effective): Monday-Friday
[FREQ] Frequency (effective): 433.820000 MHz
[NOTE] FREQUENCY not set in private.h; using default 433.820000 MHz (RADIAN).
[FREQ] Initializing CC1101 radio...
[CC1101] GDO2 pin 4 configured as FIFO threshold input (pull-up)
[CC1101] Frequency synthesizer calibrated for 433.820007 MHz
[FREQ] CC1101 radio initialized successfully
[FREQ] Adaptive frequency threshold set to 1 reads

With the old version, I pick up a few nearby frequencies.
With the new one, nothing!

------------------------------
Got frequency : 433.783936
------------------------------
Liters : 271645
Battery (in months) : 157
Counter : 218

------------------------------
Got frequency : 433.784912
------------------------------
Liters : 275722
Battery (in months) : 156
Counter : 63

-----------------------------
Got frequency : 433.785400
------------------------------
Liters : 275730
Battery (in months) : 156
Counter : 177

------------------------------
Got frequency : 433.789307
------------------------------
Liters : 275735
Battery (in months) : 0
Counter : 0

No response either if I use a frequency retrieved from the old version.

Everblu Meters ESP8266/ESP32 Starting...
Water/Gas usage data for Home Assistant
https://github.com/genestealer/everblu-meters-esp8266-improved
[STATUS] Firmware version: 3.0.1
[STATUS] Target meter: 2024-0336270

[STATUS] Meter type: WATER (readings in L)

=== Configuration Validation ===
✓ METER_CODE: 24-0336270-219 (year=24, serial=336270)
✓ FREQUENCY: 433.784912 MHz
✓ Reading Time (UTC): 10:00
✓ GDO0 Pin: GPIO 5
✓ GDO2 Pin: GPIO 4 (TX/RX FIFO threshold - hardware-assisted underflow prevention)
✓ Reading Schedule: Monday-Friday
================================

✓ Configuration valid - proceeding with initialization

[MQTT] Base topic: everblu/cyble/336270
[MQTT] Meter serial string: 336270
[MQTT] mqttBaseTopic length: 20
[STORAGE] EEPROM initialized
[FREQ] No valid frequency offset found in EEPROM
[FREQ] AUTO_SCAN_ENABLED=0; skipping automatic frequency scan (offset remains 0.0 MHz).
[WIFI] Wi-Fi PHY mode 11G is disabled.
[SCHEDULE] Reading schedule (configured): Monday-Friday
[SCHEDULE] Reading schedule (effective): Monday-Friday
[FREQ] Frequency (effective): 433.784912 MHz
[FREQ] Initializing CC1101 radio...
[CC1101] GDO2 pin 4 configured as FIFO threshold input (pull-up)
[I][everblu_meter] Radio found OK (PARTNUM: 0x00, VERSION: 0x04)
[CC1101] Frequency synthesizer calibrated for 433.784912 MHz
[CC1101] GDO2 self-test passed (LOW when empty / HIGH when filled)
[FREQ] CC1101 radio initialized successfully
[FREQ] Adaptive frequency threshold set to 1 reads
[NET] Waiting for Wi-Fi/MQTT... timeouts enabled (Wi-Fi 30s, MQTT 30s). Will retry automatically.
[Wi-Fi] Connecting to 'Swil'... (status=7: DISCONNECTED)
[Wi-Fi] Connected to 'Swil' (IP: 192.168.1.77, RSSI: -29 dBm)
[MQTT] Connected to MQTT Broker)
[TIME] Configure time from NTP server. Please wait...
[TIME] ✓ NTP sync successful after 200 ms
[TIME] current date (UTC) : 2026/07/02 13:05:38 - 1782997538
[TIME] Configured UTC offset: +0 minutes
[TIME] Current date (UTC+offset): 2026/07/02 13:05:38 - 1782997538
[OTA] Configure Arduino OTA flash.
[STATUS] IP address: 192.168.1.77
[WIFI] WiFi Serial Monitor: DISABLED
[MQTT] Send Home Assistant discovery config.
[MQTT] Publishing Home Assistant discovery messages...
[MQTT] Publishing Reading (Total) sensor discovery...
[MQTT] Water Usage state topic: everblu/cyble/336270/liters
[MQTT] Home Assistant discovery messages published
[MQTT] MQTT config sent
[MQTT] Publish Wi-Fi details...
[MQTT] Wi-Fi details published
[MQTT] Publish meter settings...
[MQTT] Meter settings published
[STATUS] Setup done
================================

[MQTT] Connected to 192.168.1.119:1883 as 'watermeter2mqtt-336270'
[STATUS] Force update requested via MQTT (command: update) - overriding cooldown

========================================
        METER READ - START (fw 3.0.1)
========================================
[STATUS] Updating data from meter...
[STATUS] Retry count: 0
[STATUS] Reading schedule: Monday-Friday
[STATUS] Scheduled read time: 10:00 UTC (10:00 local-offset)
[METER] Starting meter read sequence...
[METER] Transmitting wake-up + interrogation (Year=24, Serial=336270)...
[CC1101] Pre-TX reset: IDLE + FIFO flush complete
MARCSTATE : raw:0x13  0x13 free_byte:0x09 sts:0x02 sending 2s WUP...
[CC1101] Wake-up burst sent; TX FIFO drained at tmo=212 (normal end of transmit)
[METER] Wake-up/interrogation transmitted in 2120ms (MARCSTATE=0x16)
[CC1101] tmo=212 free_byte:0x02 sts:0x07[METER] Waiting for ACK frame (18-byte frame, 150ms timeout)...
[RX] size_byte=18  l_radian_frame_size_byte=25
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No ACK frame received (meter may be asleep/out of range)
[METER] Meter acknowledgement frame timeout
[METER] Waiting for data frame (124-byte frame, 700ms timeout)...
[RX] size_byte=124  l_radian_frame_size_byte=171
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No data frame received within the timeout window - the meter did not respond.
[METER] This usually means the meter is asleep (outside its daily listening window), out of range, the signal is too weak, or the configured Year/Serial is incorrect.
[METER] If this persists, try improving antenna placement or running a frequency scan to recalibrate the radio (see AUTO_SCAN_ENABLED / CLEAR_EEPROM_ON_BOOT).
[METER] Meter data frame timeout
[TIME] Current date (UTC): 2026/07/02 13:06:17 - 1782997577
[ERROR] Unable to retrieve data from meter (attempt 1/5)
[STATUS] Scheduling retry in 10 seconds... (next attempt 2/5)
========================================
        METER READ - FAILED
========================================


========================================
        METER READ - START (fw 3.0.1)
========================================
[STATUS] Updating data from meter...
[STATUS] Retry count: 1
[STATUS] Reading schedule: Monday-Friday
[STATUS] Scheduled read time: 10:00 UTC (10:00 local-offset)
[METER] Starting meter read sequence...
[METER] Transmitting wake-up + interrogation (Year=24, Serial=336270)...
[CC1101] Pre-TX reset: IDLE + FIFO flush complete
MARCSTATE : raw:0x13  0x13 free_byte:0x09 sts:0x02 sending 2s WUP...
[CC1101] Wake-up burst sent; TX FIFO drained at tmo=212 (normal end of transmit)
[METER] Wake-up/interrogation transmitted in 2120ms (MARCSTATE=0x16)
[CC1101] tmo=212 free_byte:0x02 sts:0x07[METER] Waiting for ACK frame (18-byte frame, 150ms timeout)...
[RX] size_byte=18  l_radian_frame_size_byte=25
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No ACK frame received (meter may be asleep/out of range)
[METER] Meter acknowledgement frame timeout
[METER] Waiting for data frame (124-byte frame, 700ms timeout)...
[RX] size_byte=124  l_radian_frame_size_byte=171
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No data frame received within the timeout window - the meter did not respond.
[METER] This usually means the meter is asleep (outside its daily listening window), out of range, the signal is too weak, or the configured Year/Serial is incorrect.
[METER] If this persists, try improving antenna placement or running a frequency scan to recalibrate the radio (see AUTO_SCAN_ENABLED / CLEAR_EEPROM_ON_BOOT).
[METER] Meter data frame timeout
[TIME] Current date (UTC): 2026/07/02 13:06:30 - 1782997590
[ERROR] Unable to retrieve data from meter (attempt 2/5)
[STATUS] Scheduling retry in 10 seconds... (next attempt 3/5)
========================================
        METER READ - FAILED
========================================


========================================
        METER READ - START (fw 3.0.1)
========================================
[STATUS] Updating data from meter...
[STATUS] Retry count: 2
[STATUS] Reading schedule: Monday-Friday
[STATUS] Scheduled read time: 10:00 UTC (10:00 local-offset)
[METER] Starting meter read sequence...
[METER] Transmitting wake-up + interrogation (Year=24, Serial=336270)...
[CC1101] Pre-TX reset: IDLE + FIFO flush complete
MARCSTATE : raw:0x13  0x13 free_byte:0x09 sts:0x02 sending 2s WUP...
[CC1101] Wake-up burst sent; TX FIFO drained at tmo=212 (normal end of transmit)
[METER] Wake-up/interrogation transmitted in 2120ms (MARCSTATE=0x16)
[CC1101] tmo=212 free_byte:0x03 sts:0x07[METER] Waiting for ACK frame (18-byte frame, 150ms timeout)...
[RX] size_byte=18  l_radian_frame_size_byte=25
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No ACK frame received (meter may be asleep/out of range)
[METER] Meter acknowledgement frame timeout
[METER] Waiting for data frame (124-byte frame, 700ms timeout)...
[RX] size_byte=124  l_radian_frame_size_byte=171
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No data frame received within the timeout window - the meter did not respond.
[METER] This usually means the meter is asleep (outside its daily listening window), out of range, the signal is too weak, or the configured Year/Serial is incorrect.
[METER] If this persists, try improving antenna placement or running a frequency scan to recalibrate the radio (see AUTO_SCAN_ENABLED / CLEAR_EEPROM_ON_BOOT).
[METER] Meter data frame timeout
[TIME] Current date (UTC): 2026/07/02 13:06:43 - 1782997603
[ERROR] Unable to retrieve data from meter (attempt 3/5)
[STATUS] Scheduling retry in 10 seconds... (next attempt 4/5)
========================================
        METER READ - FAILED
========================================


========================================
        METER READ - START (fw 3.0.1)
========================================
[STATUS] Updating data from meter...
[STATUS] Retry count: 3
[STATUS] Reading schedule: Monday-Friday
[STATUS] Scheduled read time: 10:00 UTC (10:00 local-offset)
[METER] Starting meter read sequence...
[METER] Transmitting wake-up + interrogation (Year=24, Serial=336270)...
[CC1101] Pre-TX reset: IDLE + FIFO flush complete
MARCSTATE : raw:0x13  0x13 free_byte:0x09 sts:0x02 sending 2s WUP...
[CC1101] Wake-up burst sent; TX FIFO drained at tmo=212 (normal end of transmit)
[METER] Wake-up/interrogation transmitted in 2120ms (MARCSTATE=0x16)
[CC1101] tmo=212 free_byte:0x02 sts:0x07[METER] Waiting for ACK frame (18-byte frame, 150ms timeout)...
[RX] size_byte=18  l_radian_frame_size_byte=25
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No ACK frame received (meter may be asleep/out of range)
[METER] Meter acknowledgement frame timeout
[METER] Waiting for data frame (124-byte frame, 700ms timeout)...
[RX] size_byte=124  l_radian_frame_size_byte=171
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No data frame received within the timeout window - the meter did not respond.
[METER] This usually means the meter is asleep (outside its daily listening window), out of range, the signal is too weak, or the configured Year/Serial is incorrect.
[METER] If this persists, try improving antenna placement or running a frequency scan to recalibrate the radio (see AUTO_SCAN_ENABLED / CLEAR_EEPROM_ON_BOOT).
[METER] Meter data frame timeout
[TIME] Current date (UTC): 2026/07/02 13:06:56 - 1782997616
[ERROR] Unable to retrieve data from meter (attempt 4/5)
[STATUS] Scheduling retry in 10 seconds... (next attempt 5/5)
========================================
        METER READ - FAILED
========================================


========================================
        METER READ - START (fw 3.0.1)
========================================
[STATUS] Updating data from meter...
[STATUS] Retry count: 4
[STATUS] Reading schedule: Monday-Friday
[STATUS] Scheduled read time: 10:00 UTC (10:00 local-offset)
[METER] Starting meter read sequence...
[METER] Transmitting wake-up + interrogation (Year=24, Serial=336270)...
[CC1101] Pre-TX reset: IDLE + FIFO flush complete
MARCSTATE : raw:0x13  0x13 free_byte:0x09 sts:0x02 sending 2s WUP...
[CC1101] Wake-up burst sent; TX FIFO drained at tmo=212 (normal end of transmit)
[METER] Wake-up/interrogation transmitted in 2120ms (MARCSTATE=0x16)
[CC1101] tmo=212 free_byte:0x03 sts:0x07[METER] Waiting for ACK frame (18-byte frame, 150ms timeout)...
[RX] size_byte=18  l_radian_frame_size_byte=25
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No ACK frame received (meter may be asleep/out of range)
[METER] Meter acknowledgement frame timeout
[METER] Waiting for data frame (124-byte frame, 700ms timeout)...
[RX] size_byte=124  l_radian_frame_size_byte=171
[RX] No sync detected before timeout (meter may be asleep/out of range/wrong config)
[METER] No data frame received within the timeout window - the meter did not respond.
[METER] This usually means the meter is asleep (outside its daily listening window), out of range, the signal is too weak, or the configured Year/Serial is incorrect.
[METER] If this persists, try improving antenna placement or running a frequency scan to recalibrate the radio (see AUTO_SCAN_ENABLED / CLEAR_EEPROM_ON_BOOT).
[METER] Meter data frame timeout
[TIME] Current date (UTC): 2026/07/02 13:07:09 - 1782997629
[ERROR] Unable to retrieve data from meter (attempt 5/5)
[ERROR] Max retries (5) reached. Entering 1-hour cooldown period.
========================================
        METER READ - FAILED
========================================

Do you have any idea what the problem is?

Thanks in advance

78

Happy to help. If you wouldn't mind raising an issue on the repository, I can use that to track it through. @swil85

79

EverBlu Meters v3.1.0 - What's New

v3.1.0 is out! Here are the changes that matter for day-to-day use.

The Big One: No More Frequency Scanning on First Boot

The CC1101 radio bandwidth has been widened from 58 kHz to 270 kHz, giving the chip ±67 kHz of automatic carrier-offset correction. For most installs this means the device locks onto your meter at the default 433.82 MHz without any manual scan. The startup Deep Scan is now disabled by default - you probably won't need it.

What Changed

Frequency / Radio

  • Startup auto-scan is now opt-in (auto_scan: true or #define AUTO_SCAN_ENABLED 1). Most users won't need it.

  • New Auto-Scan on Failure option (auto_scan_on_failure: true): runs a narrow re-tune automatically if the device hits MAX_RETRIES. Disabled by default (blocks ~1–2 min while scanning).

  • Deep Scan is smarter: two-phase sweep + zoom, plus a post-lock quality check that won't overwrite a good calibration with a worse one.

  • New rx_attenuation option (0 / 6 / 12 / 18 dB) for devices mounted very close to the meter - fixes front-end overload. Related: the firmware now logs a clear NEAR-FIELD SATURATION DETECTED warning instead of a generic error when RSSI is too strong.

Sensors & MQTT

  • tuned_frequency and frequency_estimate sensors now appear in MQTT Home Assistant discovery (they were ESPHome-only before).

  • New Reset Frequency Offset MQTT button in the standalone build.

  • Serial log lines now include a [HH:MM:SS] UTC timestamp.

Data Quality

  • Reading plausibility guard: rejects a reading if its implied monthly usage is 100× larger than historical normal - catches corrupted decodes before they pollute your history.

  • Monthly usage history no longer includes the oldest month (no prior baseline for delta), so the numbers are now correct.

  • LQI percentage was wrong - the CRC bit was included in the value (inflating it by 128) and the percentage mapping was inverted. Both are fixed; LQI now reads correctly in both builds.

ESPHome

  • Config validation catches mistakes early: invalid reading_schedule, mismatched GDO0/GDO2 pins, and ESP32 non-Arduino framework all now fail esphome config with a clear message instead of a cryptic compile error.

  • reading_schedule is now case-insensitive (monday-friday works).

Breaking Changes

If you're upgrading, update these YAML / MQTT references:

| Old | New |

|---|---|

| frequency_scan_button / wide_frequency_scan_button | deep_scan_button |

| MQTT topic freq_scan | deep_scan |

| fast_scan_button / fast_scan | Removed |

auto_scan now defaults to false - set it to true if you want the old startup-scan behaviour.

Upgrading From Before v3.0.0?

Also review the v3.0.0 breaking change: gdo2_pin / GDO2 must be wired and declared (or explicitly opted out), and the v2.3.0 strict meter-code format (YY-SSSSSSS).

Full details: CHANGELOG.md | RELEASE_NOTES_v3.1.0.md

80

Just for You info : works perfectly with AnyQuest Cyble Enhanced . I am trying now to read every 30mins just to be able to create alerts or close the valve in case of a big leak. It is interesting to see how much battery power it will use

81

@Piotrkkt reading that frequently will drain the battery quickly, be careful. What’s interesting is is the metre is supposed to have leak detection built into it but as the protocol isn’t documented, everything has had to be reverse engineered and that’s one aspect I have to be able to figure out.