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

Share your Projects!
, , , ,
1

Sharing my project: Fetch water/gas usage data from Itron EverBlu Cyble Enhanced RF water meters using the RADIAN protocol on 433 MHz with an ESP32/ESP8266 and CC1101 transceiver. Integrated with Home Assistant via MQTT AutoDiscovery.

I live in the UK and my Water Meter is out on the street and has an Itron EverBlu Cyble Enhanced module that allows for wireless remote meter functionality.

board2
board21113×853 280 KB

meter
meter1031×837 156 KB

MQTT_HASS2
MQTT_HASS21022×792 186 KB

Ref: Water Meter Reading/Integration with Itron EverBlu Cyble Enhanced

Software original code (but also all the hard work to get things working was originally done here then put on github by @neutrinus here and then forked by psykokwak

Update – 17th April 2025
PING: @Minims @frazor77 @Vorhees @GSzabados @AltF4me

Exciting news! I’ve added several new features:

  • Diagnostics for 433 MHz communication: Now includes RSSI (Radio Signal Strength Indicator), LQI (Link Quality Indicator), and signal strength readings to help with diagnostics and finding the best position for the transceiver.
  • Meter sleep/wake tracking: New Time Start and Time End sensors show when the meter wakes and sleeps, read directly from the meter’s settings.
  • Frequency discovery: You can now enable automatic frequency discovery for meter communication via the config file.
  • Wi-Fi improvements: Added support for enabling 802.11g (11G) PHY mode via the config file, along with expanded Wi-Fi diagnostics and OTA updates.
  • Reading schedule configuration: You can now define which days the meter should be queried (e.g. Monday to Friday, Monday to Saturday, or Monday to Sunday). This is also configured via the config file.
  • Confirmed counter behaviour: As previously reported, I’ve now confirmed that the read counter can be “reset” or wrap around under certain conditions. For example, a reading that originally showed a counter of 255 was followed shortly after by another showing it as 1.

Current date (UTC) : 2025/04/17 17:21/50 - 1744910510
Data from meter:
Liters : 635633
Battery (in months) : 107
Counter : 255
RSSI : 226
Time start : 06:00
Time end : 18:00

Current date (UTC) : 2025/04/17 17:22/03 - 1744910523
Data from meter:
Liters : 635633
Battery (in months) : 107
Counter : 1
RSSI : 227
Time start : 06:00
Time end : 18:00

Important note on counter implications:
There’s a known issue where, if the water company makes a reading and the counter value differs significantly from their previous reading, they may assume something is wrong and replace the meter. In this edge case, one theoretical (but very much a last-resort) workaround would be to record the counter value at the time of the water company’s last reading, and then, just before their next visit, perform enough reads to cause the counter to roll over and match that same number again.

To be absolutely clear: I’m not recommending this as a good solution. It will drain the battery very quickly and should only be considered if there are no other options available and all alternatives have been exhausted. It’s a bodge, not a fix, but it might be the only logical fallback in a worst-case scenario.

Update – 29th October 2025
PING: @Minims @frazor77 @Vorhees @GSzabados @AltF4me

Major update! I’ve completely overhauled the radio handling and reliability. The firmware now works out-of-the-box with any CC1101 module without manual tuning:

Automatic Frequency Calibration & Tracking:

  • Wide initial scan on first boot: Automatically finds your meter’s frequency (±100 kHz coarse scan, then ±15 kHz fine scan) and saves it permanently
  • Adaptive frequency tracking: Uses the CC1101’s FREQEST register to monitor and correct for frequency drift over time (temperature changes, crystal aging)
  • Manual scan on demand: Trigger a frequency scan via MQTT or the new Home Assistant “Scan Frequency” button
  • Automatic CC1101 calibration: Enable synthesizer auto-calibration and FOC (Frequency Offset Compensation) for robust operation

Stability & Security Improvements:

  • Watchdog protection: Prevents device resets during long operations (scans, meter reads)
  • Fixed stack overflow risk: Replaced recursive retries with safe delayed callbacks
  • Buffer overflow protection: Added bounds checking to prevent memory corruption from malformed RF data
  • MQTT input validation: Strict command validation with clear warnings for invalid inputs

Performance & Memory:

  • 90% faster MQTT operations: Reduced publish delays from 50ms to 5ms
  • ~500 bytes heap saved per cycle: Eliminated Arduino String usage in favor of efficient stack buffers
  • Self-documenting code: Replaced cryptic hex values with descriptive constants for all CC1101 registers

Enhanced Diagnostics:

  • New MQTT topics: total_attempts, successful_reads, failed_reads, last_error, cc1101_state, frequency_offset
  • All diagnostic sensors auto-discover in Home Assistant
  • Real-time CC1101 state monitoring (“Idle”, “Reading”, “Frequency Scanning”)

Configuration Improvements:

  • Startup validation: Checks meter year/serial, frequency bounds, GPIO pins, and schedule before operation
  • Default frequency: Falls back to 433.82 MHz if not configured (standard RADIAN frequency)
  • Persistent offset storage: ESP8266 uses EEPROM, ESP32 uses Preferences API
  • Hardware change guidance: Clear instructions for when to clear stored calibration (replacing CC1101/board/meter)

Note on “Frequency” entity removal: The frequency is a radio configuration parameter (like WiFi channel), not a meter sensor value. It’s been removed from Home Assistant to avoid confusion. The discovered frequency offset is still available as a diagnostic metric.

Previous features (still included):

  • Diagnostics for 433 MHz communication (RSSI, LQI, signal strength)
  • Meter sleep/wake tracking (Time Start and Time End sensors)
  • Wi-Fi improvements (802.11g support, expanded diagnostics, OTA updates)
  • Reading schedule configuration (customize query days)

Update – 19th January 2026
PING: @Minims @frazor77 @Vorhees @GSzabados @AltF4me

:tada: Major Release: v2.1.0 + ESPHome Integration Now Available! :tada:

I’m excited to announce that this project now supports two integration methods:

Option 1: ESPHome Component (NEW!)

  • Native Home Assistant integration with YAML configuration
  • No MQTT broker required
  • Automatic sensor discovery (15+ sensors)
  • All ESPHome features (OTA, logging, diagnostics)
  • Same proven codebase as the MQTT version

Full ESPHome documentation: ESPHOME/README.md

Option 2: Standalone MQTT (Existing)

  • Continues to work as before with all new improvements
  • Full control over firmware and customization
  • PlatformIO-based development

New Features in v2.1.0 (both versions):

  • Adaptive frequency tracking: Intelligent frequency offset optimization based on successful reads
  • Enhanced monitoring: Read attempts counter, frequency offset reporting, tuned frequency sensors
  • Better reliability: Improved frequency persistence and handling
  • Multi-layer validation: 5 layers of frame validation (custom serial decoding, CRC-16/KERMIT FCS, frame structure, temporal checks, signal quality filtering)

Known Issue (ESPHome only): The discovered frequency offset doesn’t persist between ESPHome reboots (will re-scan on each boot). The MQTT version doesn’t have this limitation. I’m working on refining the persistence mechanism.

Migration from MQTT to ESPHome: Super easy - use the same meter_year and meter_serial values from your private.h. Sensors will auto-discover with similar entity IDs.

Both versions are actively maintained and tested on ESP8266/ESP32 with real water and gas meters. Choose whichever integration method works best for you!

ESPHome

esphome
esphome1673×1648 378 KB

2 Likes
2

I’m still using a custom fork of the original neutrinus code (mainly changed text outputs to English and fixed some HA integration issues)
 I had been meaning to look at compiling the psykokwak build
 but lookls like you’ve built more improvements on top of that?

What improvments have you made?

3

@Richard.Huish, has your water company contacted you already, that they cannot read the meter? I faced that with an AnyQuest Cyble, which is the simpler version of the module. The software, by the water company, reading the meter has a running counter how many times reads were requested from the meter, if it doesn’t match with the read count in the meter, it just doesn’t read the data.

4

I haven’t edited any of the underlying functionality. I will add a change summary to the GitHub page in the next couple of days.
In summary though, everything’s pretty much summed up in the screenshot you can see from home assistant.
It’s mostly around mqtt auto Discovery improvements.

So you have telemetry data about the ESP, a button to make an immediate reading, status information about the current read state and its ability to reset.

I actually was looking through all the different forks yesterday after publishing this and realised that someone else has rewritten the radio code which I will have a look at as it might be worth trying and I would then integrate it into mine.

5

I’ve only been using it for it’s about 7 months. I have had at least one water bill that took an actual reading but there haven’t been any communication from the water company.

I did try one day where I read every hour just to see what kind of usage I get but it is not advisable as it would very quickly run down the battery as well as increasing the counter.

6

Good to hear that. Again, I have had this issue with an AnyQuest, where the documentation lists it like a tamper protection. But I think that is more like that the water company doesn’t know the software and its functions, when the company couldn’t read it, I could read it without any issue, every day.

Are the meters there connected to a central system with stations around the city, or the company does a drive by type reading acquisition? I my place is the second.
It took about 4-5 month until they came to replace the meter, saying that they cannot read it. Another user reported the same with an AnyQuest as well, where the company had the same issue.

7

Actually, my water company did replace my EverBlu about 9 months ago claiming it was faulty
 but the unit was only about 2 year old
 the workmen doing the replacment were perplexed as to why a newer unit needed replacing but said its possibly due to that it was ‘wonky’ (TBH it was at a slightly weird angle)
 but I knew it was ‘working’ as I was reading from it
 but I did wonder if my reading it could be the cause

1 Like
8

In my case it would be a drive-by. The range is not long enough for it to be anything other. It’s quite deep below the surface.

9

My company replace the itron after 1Y too because unreadable, but i was able to read it everyday.
Don’t know if your code fix the issue. I would like to avoid a replacement each year.

I was using psykokwak code.

10

Not sure if you have the same metre (EverBlu Cyble Enhanced), you haven’t.

Please note, my code is a fork of psykokwak with the same underlying logic of one reading per day. So over the course of a year I would expect to see about 260 (number of weekdays per year) reads a year. Of course, if the number of reads is causing a problem then we could always modify the logic to only make less than 5 reading a week, perhaps one reading a week or month or however long you would like, but at that point the granularity of readings probably isn’t worth bothering.

In actual fact you’ve just given me a good idea, I think I will add the option to select how frequently you would like to make a reading and what time of the day to the home assistant in MQTT auto Discovery so you can just set it from home assistant with no programming required. I could probably do something as well with the frequency so that could all be set from home assistant without having to modify the code.

I haven’t tested to see what happens if I try to get the read counter to roll over 999, whether it just resets back to 000.

11

Yes i have the exact same model : EverBlu Cyble Enhanced

My guess is that i think the water provider reads the value of number of reads.

So they read the 1 the first time for example.
On their 2nd read, they read 213 and the soft fails because they expect 2.

I can’t confirm this, but we are many with this issue on many Country. ( means water provider replace the itron every year because unreadable on their side)

I would avoid this replacement as my water provider will start asking why it always fails with my water meter.

12

Same here. Water company changed reader twice, not knowing what is going on. I stopped reading after that.

13

OK, so we don’t want the meter changed unnecessarily
 it costs the water company money, and you can bet that gets paid forward to the cusomers
 plus is extra drisruption.

On the flip side, it seems short-signtd of them to implement it in this way since its an openly readable IoT device.

So the question is can the meter be read without causing this? Does this device firmware enact the read increment? Or is that done by the EverBlu device?

14

I think the fault is on the IOT software provide by iTron to the water compagny.

If we can avoid the read increment, it will be great, but i think it’s in the itron FW.

Don’t know if someone has the answer.

15

As far as it seems, the firmware inside the water mater tracks the number of reads, so there is no way to make a read without incrementing the read counter.

16

Is it possible to see what read number was last read by water company? If read counter rolls over at 999, we could use it in a way that you do 1000 reads between their 2 reads :slight_smile:

17

OK so maybe the read count itself is not the problem, the problem is how that data is interpreted by the water companies. Why do they care about the read count?

Hypothesis: if its >1 and they expect =<1 AND they are assuming its just them reading it, therefore >1 without a recorded dataset probably leads them to assume they are having read issues and its a potentially faulty meter - but that is an incredibly flawed approach for an IoT device out in the wild. Wworse still they could be NOT reading it if the read count >=1 so then assuming they have already read it and ignoring the dataset, again flawed given its an in-the-wild device, and becuase its an absolute/actual-value dataset so no big deal if they get the data again.

In short I don’t get why the read count should be an issue if their approach is sensible, so I’m assuming their approach is very flawed.

18

I cannot have the link or the pdf now, but I will try to dig it out, that has a vague description of the tamper protection. I think the enhanced version has a bubble up feature, means automatically transmits without interrogation, if the water conpany can change to that, then that is the solution.

Sorry for bringing up the subject, but I try to warn people about my experience and I see that other had similar experience.

19

No, thank you @GSzabados. We need to play nice when doing these kinds of things. Nobody needs an angry letter from the water company. I’ve attempted to contact my water company to find out exactly why they replaced my meter and if it was anything to do with this. So, providing your evidence would be super useful.

And sorry to @Richard.Huish if this has taken your thread off on a (hopefully temporary) side quest. Thank you for your hard work and keep it up - I’m keen to update to this version in the coming weeks.

1 Like
20

Just a quick update to say I’m going back and forth with my water company. I’m kind of going through the customer support cycles at present and even though they are being very polite and helpful, I’m not convinced they are fully grasping what I’m trying to explain and I have asked them (twice now) to refer the case to their tech teams. Understandably they are protecting those teams from unnecessary requests. However, at present, they are not at all concerned with anyone reading the meter data and dont see this activity posing any risk (or at least that’s how I’m reading their responses).

1 Like