rtl_433
rtl_433 copied to clipboard
Decoder for Mueller Hot Rod V1 Water Meter Transmitter
This software is awesome; I appreciate the work of the devs.
Could support be added for this water meter?
Someone has already been able to get the consumption data out of it: https://github.com/sycophantic/muellerhotrod/
And, some more information: https://www.oaklodgewaterservices.org/files/7babb4e56/meters+installed.pdf
Is this sufficient information to create the decoder?
Thank you.
A very nice teardown/description there. Seems easy to add. Can you grab some (20 to 100 maybe?) raw codes (e.g. {92}feb10014376017005053000
) and post here so we can take a swing at the checksum?
I'd be happy to, but, forgive me, is there a way to do this with my current setup?
I am running rtl_433 as part of a Docker container called "SDR to Home Assistant" on a Raspberry Pi 4 running the most recent version of HA.
If not, I will get a second SDR dongle and set up another machine, though that may take a couple weeks.
Thanks, again.
I'd be happy to, but, forgive me, is there a way to do this with my current setup?
Yes, the -X
line from the linked repo
I don't think that I can do this in the Docker container (or I don't know enough how to do so, haha), but I have some additional hardware en route that will let me do this. I will post again with the raw codes in a few days. Thanks.
Well, I'm not receiving anything with those flags. I have what looks like the same unit as the linked repo (same model and FCC ID, appearance is the same). Should I change the frequency in the command, or other flags?
Try to use a UI with a waterfall display first. Locate the signal and then pick a center frequency close but not directly on the signal (10 to 50 kHz offset should work best).
Ok, will do. Do you have recommendations on suitable (Linux) software with a waterfall view? How wide is the bandwidth that rtl_433 looks at with these options? Thanks.
In no particular order: Gqrx, CubicSDR, SDRangel, SigDigger.
Bandwidth is equal to sample rate, default is 250k for lower freqs like 433.92M and 1024k for higher like 868M.
Got it; thank you. This is a good place to start. I will work with one or more of these and see what I can find.
Alright; I have finally made some headway.
The reason I wasn't picking up anything initially wasn't due to an incorrect frequency; it was the gain. Allowing for auto-gain, with the command "rtl_433 -f 909M -s 1M -R 0 -X 'preamble={44}aaaaafeb100,n=hotrod,m=FSK_PCM,s=20,l=20,r=3000'", I was able to pick up the transmitters, filtered for uniques: {63}1259651602371200 {66}125965600071122e0 {66}12596579013723068 {67}12597187027498060 {68}12597235027507062 {70}125964390531330538 {70}1259651402670905c0 {70}125971840000561710 {70}125972450281820090 {71}1259651502179517a4
I am not confident that all of these are error-free and complete, just results of the command above.
The preamble I used was longer than that in the linked repo because there was a lot of noise without it, and it uses the same characters that were at the beginning of his/her sample code.
The first 8 characters of my codes are meter IDs.
The current reading in gallons follows, but I am not sure how many positions: The meters read to tens of gallons, which is reported on the water bills in hundreds of gallons. As an example, for 12596515, the currently reported value on the bill is "2179", representing 217900 gallons of lifetime consumption. In most of the codes, the 15th position is '0', which I do not think is coincidental: I think that the meter may only report to the transmitter tens of gallons, but still use the '0' as a placeholder. The others may be erroneous.
I would guess that a checksum follows, but it is not a consistent number of bits long. Should I adjust my command?
Looks good. With FSK the end can show a few invalid bits. Your description is as in this BitBench?
Can you get consecutive codes from the same meter? We need to observe as little change in the code as possible to guess the checksum.
BitBench: Nice piece of software, there. Thanks. Not quite what I meant, but looks like I was a little bit wrong, anyway. See below.
Consecutive codes: Yes, makes sense.
Here is a couple hours of data stream from one meter, with repeated lines deleted:
{70}1259651402670905c0 {74}1259651402670905c30 {70}1259651402670905c0 {74}1259651402670905c30 {70}1259651402670905c0 {73}1259651402670905c30 {70}1259651402670905c0 {73}1259651402670905c30 {74}1259651402670905c30 {75}1259651402670905c30 {70}1259651402670905c0 {75}1259651402670905c30 {70}1259651402670905c0 {72}1259651402670905c3 {70}1259651402670905c0 {73}1259651402670905c30 {70}1259651402670905c0 {74}1259651402670905860 {70}1259651402670905c0 {74}1259651402670905c30 {73}1259651402670905c30 {70}1259651402670905c0 {74}1259651402670905c30 {70}1259651402670905c0 {75}1259651402670905c30 {70}1259651402670905c0 {73}125965140266120b860 {74}1259651402670905c30 {70}1259651402670905c0 {75}1259651402670905c30 {70}125965140267090b84 {75}1259651402670905c30 {74}1259651402670905c30 {70}1259651402670905c0 {69}125965140267190590 {70}125965140267190594 {69}125965140267190590 {70}125965140267190594 {74}1259651402671905940 {75}1259651401338c82ca0 {78}125cb28a0099c3205940 {69}125965140267190590 {74}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {75}1259651402671905940 {69}125965140267190590 {75}1259651401338c82ca0 {69}125965140267190590 {75}1259651402671905940 {69}125965140267190590 {74}1259651402671905940 {75}1259651402671905940 {69}125965140267190590 {75}1259651402671905940 {69}125965140267190590 {74}1259651402671905940 {75}1259651402671905940 {73}1259651402671905940 {69}125965140267190590 {70}125965140267190594 {69}125965140267190590 {72}125965140267190594 {69}125965140267190590 {75}1259651402671905940 {69}125965140267190590 {73}12596514026e6414a00 {74}12596514026719058a0 {69}125965140267190590 {74}1259651402671905940 {75}1259651402671905940 {74}1259651402671905940 {69}125965140267190590 {67}1259651404ce64164 {75}1259651401338c82ca0 {74}1259651402671905940 {69}125965140267190590 {72}125965140267190b28 {69}125965140267190590 {75}1259651402671882ca0 {74}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {74}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {75}1259651402671905940 {74}1259651402671905940 {69}125965140267190590 {74}1259651402671905940 {69}125965140267190590 {67}12596514099c64164 {75}1259651402671905940 {69}125965140267190590 {74}1259651402671905940 {72}125965140267190b28 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {73}1259651402671905940 {69}125965140267190590 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {72}1259651402672105c5 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {73}1259651402672105c50 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {73}1259651402672105c50 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4 {75}1259651402672105c50 {71}1259651402672105c4
This represents ~200 gallons (~757 L!) of water consumption.
There is a rather long (?40-80 minutes) delay from the time that the value displayed on the physical meter changes to the time that the transmitted code changes.
The mess at the end, what you say is due to the FSK. So, I think that these codes could be simplified to:
`(
{70}1259651402670905c0 OR
{73}1259651402670905c30 OR
{74}1259651402670905c30 OR
{75}1259651402670905c30
)
( {69}125965140267190590 OR {73}1259651402671905940 OR {74}1259651402671905940 OR {75}1259651402671905940 )
( {71}1259651402672105c4 OR {75}1259651402672105c50 )` The linked brochure says that "data integrity [is] verified with every data message". It looks like consumption is only being reported to the hundreds of gallons; two digits are not being transmitted. So: BitBench
The last byte could be a CRC (CRC-8/ITU, poly 0x07 init 0). But for that the code needs to be 72 bits (or more).
The only 3 good codes (your three truncation examples above) work.
The 10 "filtered for uniques" you posted also work (up to the truncation -- they are all too short).
E.g. truncate codes to 64 bits (like this 1259651402670905
) and observe the crc value of c3
in https://crccalc.com/
I think that I am following what you are writing.
For the three "good" codes: 1259651402670905 1259651402671905 1259651402672105 This method (truncation, CRC-8/ITU), matches what is there: C3 94 C5
I don't see it working by the same method with the "filtered for uniques" list, but perhaps I don't quite understand what you mean. So, I'm not sure that this solution can be universalized? Also, we don't know what the values in the last three positions of these codes signifies.
Can this now be turned into a decoder, or would that be premature?
I don't see it working by the same method with the "filtered for uniques" list,
E.g. {70}125964390531330538
using 1259643905313305
matches the CRC of 3A
if we ignore the missing bits at the end. Similar for all others.
Can this now be turned into a decoder, or would that be premature?
Yes, it has a checksum and most fields are known. Do you want to code a PR or should I just add a decoder?
Oh, so each of the "filtered for uniques" were missing bits, then?
I honestly wouldn't know where to start coding it myself, so if you are able to, that would be great. This would then be merged so that others would be able to use it, right? Looks like there are others interested and this may be applicable to other models.
The scheme that we have come up with matches another model: https://github.com/merbanan/rtl_433/issues/2719
I meant to ask, will the decoder be part of the next release? Thank you.
I meant to ask, will the decoder be part of the next release? Thank you.
@zuckschwerdt : I can help on this issue, let me know. Sounds to be a simple decoder here: we have samples, bitbench, preamble/sync word, crc, another issue is opened on the same protocol, I guess we have enough information, just the unit to be confirmed gallon or liter or just a counter without unit ?
@ProfBoc75 that would be great! I currently don't have much time for this :/
Oh, nice, thanks... the units are gallons, monotonically increasing. Please let me know if there is any other information that I can provide that would help.
Hi @dolai1:
I started to write the decoder, I would like some more codes / more samples.
Notice that from the cu8 files I analyzed, the pulse is more around 26 µs than 20. Can you try this:
rtl_433 -f 909M -R 0 -X 'n=hotrod,m=FSK_PCM,s=26,l=26,r=2500,preamble={24}feb100,bits>=72'
I would like to confirm the data layout at the volume level, with 5, 6 or 7 nibbles after the ID.
Possible bitbenchs
Let me know.
I will pull a request soon, starting with volume based on 5 nibbles / 20 bit.
Interesting. Maybe we could get more reliable reads, then. I am in a similar situation to where I was earlier; I need to get another receiver as my others are busy in "production" environments, but I should receive this and be able to get you output in about two days. Thank you.
I got "{68}12596514027330058" most frequently, but accidentally deleted most of my captured data, so I will re-acquire and post it. Thanks.
As I mentioned in my original BitBench, I am fairly sure the volume is only transmitted in hundreds of gallons. The digit afterward does not seem to be part of the reading as it is not incremental. The values that I had there were sequential during a period of use of ~200 gallons. Modifying it per your linked BB for clarity: BitBench
Here's about 45 minutes of codes.
Most appear to be incomplete, but from those that are, no consumption registered during this time (I was using the water, but, evidently, not more than one hundred gallons).
(maybe it's being transmitted in tens of gallons?)
@dolai1 : Thanks for your feedback.
So, yes, for me the increase is by 10 gallons, but we can use the 7 nibbles, the unit will stay 0. Then you have a flag always at 5 then the CRC.
My bitbench
Very nice. Thank you.