The itch to investigate lurks within all us hackers. Sometimes, you just have to pull something apart to learn how it works. [Stephen Crosby] found himself doing just that when he got his hands on a Flume water monitor.
[Stephen] came by the monitor thanks to a city rebate, which lowered the cost of the Flume device. It consists of two main components: a sensor which is strapped to the water meter, and a separate “bridge” device that receives information from the sensor and delivers it to Flume servers via WiFi. There’s a useful API for customers, and it’s even able to integrate with a Home Assistant plugin. [Stephen] hoped to learn more about the device so he could scrape raw data himself, without having to rely on Flume’s servers.
Through his reverse engineering efforts, [Stephen] was able to glean how the system worked. He guides us through the basic components of the battery-powered magnetometer sensor, which senses the motion of metering components in the water meter. He also explains how it communicates with a packet radio module to the main “bridge” device, and elucidates how he came to decompile the bridge’s software.
When he sent this one in, [Stephen] mentioned the considerable effort that went into reverse engineering the system was “a very poor use” of his time — but we’d beg to differ. In our book, taking on a new project is always worthwhile if you learned something along the way. Meanwhile, if you’ve been pulling apart some weird esoteric commercial device, don’t hesitate to let us know what you found!
Since the other comment was deleted:
“Water {WHAT} monitor”?
1. Level – alarm to trigger a sump pump?
2. PH level / quality?
3. oh, just a utility meter reader….
and this only indirectly/vaguely explained in the second paragraph.
So yeah, the deleted criticism is kinda relevant.
Even just
instead of
would’ve turned a clickbait title into a good one because you don’t need to open the article to know what is monitored.
Or even better: integrate a photo of the water utility meter into the article’s header(?) image
The device is called the “Flume Water Monitor” by the manufacturer. I have one. The title seems appropriate to me. https://flumewater.com/product/
Or “when he got his hands on a Flume water monitor.” could have been followed by a comma, “which is a smart device that measures water usage.”
I wonder if it wpild have not been easier to also sniff de data going into the rf69, maybe connect an esp there instead. Though connecting an rf69 to a nother esp (like he done) and running espgome surely must be the preferred solution?
My gut tells me, he spent way too much time on the mqtt side, and encryption, instead of just receiving the ota data from the unit. Granted theres this one bit of rf69 encryption keys/pairing thatbis probably done at the factory (or would they use the same keys everywhere??) . After running this on a custom esp, reflash the original :)
“To get started, download the app.” NO. 0/10, would not recommend.
Any time we see those words and the product can’t be used without an internet connection, nobody should buy it and the product should fail. I can dream…
Yes! I was gifted a Meater meat thermometer for Christmas. Had to download an app and create an account just to check the temperature.
About 5 months ago the API was updated to include a flow rate call. Now I want an advisory/warning rgb light if anyone left a faucet running (or a leak) without having to go to the app or until checking email. But now maybe an SDR intercept library will provide that functionality independently.
I love the idea of using SDR. I did briefly explore the idea, but the frequency hopping algorithm covers 20Mhz and without knowing where to tune for the next message, I believe you’d need that much ‘instantaneous’ bandwidth in order to reliably receive data. 20Mhz of instantaneous bandwidth is actually possible with some SDR hardware, but it can get expensive and the compute required to handle that much bandwidth is significant.
Although, it could still be possible with cheap hardware if the messages follow a pattern where the next channel can be known in advance. I would love to know if this is possible in case anyone does try it!