Sharing my project: Reading usage data from Itron EverBlu Cyble Enhanced water/gas meters using RADIAN protocol on 433Mhz. 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
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.