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. More details:
Software original code (but also all the hard work to get things working was originally done here then put on github by @neutrinushere and then forked by psykokwak
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.
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?
@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.
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.
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.
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.
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
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.
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.
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.
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?
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.
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
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.
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.
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.
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).
