Cannot see my kamstrup multical 21

[xaelsouth]

Cannot see my kamstrup multical 21

[xaelsouth]

I know ;-). The meters' TX rate rarely remains constant. I have observed my own meters for a long time (>1 year) and found following out:

• meters don't send anything at night
• meters don't send anything on national public holidays
• meters send more frequently after a "due date" (if configured) for a few months (30 .. 60 secs) - probably interesting for walk by read out
• meters utilize different sending schemes at weekends (~240 secs or not sending) and weekdays (60 ..120 secs) - probably interesting for both: walk and drive by read out
• at weekends meters only send so called synchronous telegrams (with S-bit set)
• at weekdays meters sends synchronous telegrams and a few asynchronous telegrams (with S-bit clear) in between

It's fully up to the manufacturer how to configure the meters.

It's possible to wake up the meters by sending a read out request. But no idea whether your company does this.

[cvjensen]

I've tried to scan for 24 hours like so
rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | grep 6301XXXX

Still no luck. Please correct me if I'm wrong. I expect that the water meters ID should be in the header and I then should be able to grep for the ID.

I'm thinking that I wanna keep going 24 hours for each minor frequence. If anyone know a more efficient way to get around this - please share!

[xaelsouth]

Hello cvjensen.

• well, if you can see T1 datagrams - does not matter if they are from yours or from foreign meters - this means you have already tuned to the right rx frequency of 868.95M.
• don't be confused by "mode C1" specified in the meter's doc - in this mode the meter sends always at the same frequency as in the mode T1, but utilizes an another channel coding.
• there is no meter which is getting filtered in the code except of the signal strength - should not be an issue at all because your RTL-SDR USB dongle is the same room as the meter.
• that you get by grepping output from rtl-wmbus is the LLA - the Link Layer Address - which is typically a serial number of the radio module not of the meter itself! As I understand https://products.kamstrup.com/documents/515d4ab700278.pdf the Multical 21 can be equipped with an external radio module. So you have to check not for the LLA but for ALA - the Application Layer Address!
• ALA has unfortunately no fixed place in the datagram. In order to find the ALA you should try to search for your meter in the datagram. Be careful: a meter with a unique (hexadecimal) manufacturer number 12345678 (which is printed on a meter's housing) transmits as 78563412! In your case you should search for something like YZWX0163 in the datagram.

Tell me if you had luck with that (or not).

Xael

Update: Hmm, just found in the pdf-file that "consumption data can be remotely read by means of Wireless M-Bus, which is built into the meter". In this case manufacturers use the same ID for the meter and for the radio module means LLA = ALA, so i'm not sure whether I had helped you with tips from above.

[cvjensen]

Hi again Xael , I'm a little busy these days - let me take a look at it later . Thanks for taking the time so far! :) Much appreciated! /C

[cvjensen]

Hi again ,

I tried to run the following but with no luck:

`ubuntu@ubuntu:~$ rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | grep -i 'YZWX'

Then I tried to run it for a few minutes and just grep for C1's like so:

ubuntu@ubuntu:~$ rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | grep '^C1*'
C1;1;1;2021-08-22 09:17:34.000;72;50;77966720;0x23442d2c206796771b168d20ef735bfa21d8c27a8c368020baf233c73f0d9b6460592b71
C1;1;1;2021-08-22 09:17:34.000;37;8;77966720;0x23442d2c206796771b168d20ef735bfa21d8c27a8c368020baf233c73f0d9b6460592b71
C1;0;1;2021-08-22 09:17:51.000;66;35;77966720;0x23442d2c206796771b168d20f0805bfa21ac4e27b9f8164a84eee43d0ff6d353db9a17ff
C1;1;1;2021-08-22 09:17:51.000;53;35;77966720;0x23442d2c206796771b168d20f0805bfa21ac4e27b9f8164a84eee43d0ff6d353db9a0fff
C1;1;1;2021-08-22 09:18:07.000;60;22;77966720;0x23442d2c206796771b168d20f1815bfa218f8c0ccdc29348741cd182b121a9a1dc4c4c33
C1;1;1;2021-08-22 09:18:07.000;50;12;77966720;0x23442d2c206796771b168d20f1815bfa218f8c0ccdc29348741cd182b121a9a1dc4c4c33
C1;1;1;2021-08-22 09:18:23.000;40;54;77966720;0x23442d2c206796771b168d20f2825bfa21af96c63d384f56018e555d51016ec59a28be54
C1;1;1;2021-08-22 09:18:23.000;31;13;77966720;0x23442d2c206796771b168d20f2825bfa21af96c63d384f56018e555d51016ec59a28be54
C1;1;1;2021-08-22 09:18:40.000;52;35;77966720;0x2a442d2c206796771b168d20f3835bfa21e3f3db527088c442112eb2e08ba8f943fe5cbf7af771a4ac3174
C1;1;1;2021-08-22 09:18:40.000;41;8;77966720;0x2a442d2c206796771b168d20f3835bfa21e3f3db527088c442112eb2e08ba8f943fe5cbf7af771a4ac3174
C1;1;1;2021-08-22 09:18:56.000;48;42;77966720;0x23442d2c206796771b168d20f4905bfa21c25c424b8a06bd312ba4207b88f32289d16f15
C1;1;1;2021-08-22 09:18:56.000;43;11;77966720;0x23442d2c206796771b168d20f4905bfa21c25c424b8a06bd312ba4207b88f32289d16f15
C1;1;1;2021-08-22 09:19:13.000;50;61;77966720;0x23442d2c206796771b168d20f5915bfa21e83fd36ca762b590c9063f945f5506bb909b10
C1;1;1;2021-08-22 09:19:13.000;57;15;77966720;0x23442d2c206796771b168d20f5915bfa21e83fd36ca762b590c9063f945f5506bb909b10
C1;0;1;2021-08-22 09:19:29.000;34;27;77966720;0x22442d2c206796771b168d20f6935bfa21ec6ebc1fe00203ec28953602aa12aefb6376
C1;0;1;2021-08-22 09:19:29.000;54;35;77966720;0x22442d2c206796771b168d20f6935bfa21ec6ebc1fe02287d8512a6c0554255df6c6ec
C1;1;1;2021-08-22 09:19:45.000;46;32;77966720;0x23442d2c206796771b168d20f7935bfa214fb1d87249ed58daa8e33c1774e55cfa5c4891
C1;1;1;2021-08-22 09:19:45.000;44;15;77966720;0x23442d2c206796771b168d20f7935bfa214fb1d87249ed58daa8e33c1774e55cfa5c4891
C1;0;1;2021-08-22 09:20:02.000;57;38;77966720;0x23442d2c206796771b168d20f8a25bfa21b69f507720ce40be3bdea2e37f30f240fd7683
C1;1;1;2021-08-22 09:20:18.000;52;42;77966720;0x23442d2c206796771b168d20f9a15bfa218625a382bd4abda2e17c2e729653c65d7932e4
C1;1;1;2021-08-22 09:20:18.000;44;6;77966720;0x23442d2c206796771b168d20f9a15bfa218625a382bd4abda2e17c2e729653c65d7932e4
C1;1;1;2021-08-22 09:20:35.000;50;45;77966720;0x23442d2c206796771b168d20faa25bfa218c58157fd5143245d3597614f7df9cc0c58a32
C1;0;1;2021-08-22 09:20:35.000;26;14;3BCB3310;0x23442d2d1033cb3b8d8b46907d512dfd10c62c0abfea8a1922e9acbb0a7befce6062c519
C1;0;1;2021-08-22 09:20:51.000;34;39;3BCB6620;0x2a442d2c2066cb3b8d8b46907dd1adfd10b97a6662e06ed808f1471d19c5b6efff0742ae623792cef4ff81
C1;0;1;2021-08-22 09:20:51.000;54;35;77966620;0x2a442d2c206696771b168d20fba35bfa2172f4ccc5c0ddb011e28e3a338b6ddffe0e855cc46f259de9ff02
C1;1;1;2021-08-22 09:21:08.000;61;50;77966720;0x23442d2c206796771b168d20fcb05bfa213866c6d914d5dc1d5e7aafdf6c11ab26b4ed60
C1;1;1;2021-08-22 09:21:24.000;49;54;77966720;0x23442d2c206796771b168d20fdb15bfa21882faf81d5d485eed26bc225dbf745bf3d8bee
C1;1;1;2021-08-22 09:21:24.000;17;9;77966720;0x23442d2c206796771b168d20fdb15bfa21882faf81d5d485eed26bc225dbf745bf3d8bee
C1;0;1;2021-08-22 09:21:41.000;82;34;77966720;0x23442d2c206796771b168db0fec05bfa215e998a485cdecb563e2bc208007740c8122802
C1;0;1;2021-08-22 09:21:41.000;51;37;77966720;0x23442d2c206796771b168db0fec05bfa215e998a485cdecb563e2bc208007740c8122802
C1;0;1;2021-08-22 09:22:30.000;56;7;779F6720;0x23442d2c20679f771b168d2001c35bfa21c115db82ebcb92b3bc7af0a1db75908794df0c
C1;0;1;2021-08-22 09:22:30.000;43;13;779F6720;0x23442d2c20679f771b168d2001c35bfa21c115db82ebcb92b3bc7af0a1db75908794df0c
C1;0;1;2021-08-22 09:22:47.000;47;12;77966720;0x23c42d2c206796771b168d2002d05bfa212c4efdf60c034a52902b4b8291b1ed899eae74
C1;1;1;2021-08-22 09:23:03.000;39;25;77966720;0x2a442d2c206796771b168d2003d15bfa21ab5dd9f7a2bc4160df3ea211f182aa43f88afae036adfa0fa1aa
C1;1;1;2021-08-22 09:23:03.000;36;15;77966720;0x2a442d2c206796771b168d2003d15bfa21ab5dd9f7a2bc4160df3ea211f182aa43f88afae036adfa0fa1aa
C1;1;1;2021-08-22 09:23:20.000;57;13;77966720;0x23442d2c206796771b168d2004d25bfa215d561df7fe71fc7d85b6ea5d43b30b6bd90cb6
C1;1;1;2021-08-22 09:23:20.000;45;12;77966720;0x23442d2c206796771b168d2004d25bfa215d561df7fe71fc7d85b6ea5d43b30b6bd90cb6
^C
ubuntu@ubuntu:~$

As you can see 77966720 keeps showing - pretty consistent. Could that be mine? I can't find anything else with that number written on it.

[nestorayuso]

{
"Raw": "0x2a442d2c2066cb3b8d8b46907dd1adfd10b97a6662e06ed808f1471d19c5b6efff0742ae623792cef4ff81",
"Length": 42,
"CField": "0x44",
"CFieldString": "0x44 (SND_NR)",
"MField": "0x2d2c",
"MFieldCodeString": "KAM",
"MFieldLongString": "Kamstrup Energi A/S, , ",
"Id": 1003185696,
"IdString": "3BCB6620",
"Version": 141,
"Device": "0x8b",
"DeviceString": "0x8b",
"CiField": "0x46",
"HeaderKnown": false,
"PayloadKnown": false,
"Header": null,
"Body": {
"Raw": null,
"DataRecords": [],
"PayloadKnown": true,
"IsEncrypted": false,
"DecryptionFailed": false,
"BlockCiField": 0
},
"AField": {
"Id": 1003185696,
"Version": 141,
"Device": 139
},
"Ell": null,
"Afl": null,
"BodyParseError": "can not parse CI-Field 0x46",
"CrcValid": false,
"HasCrc": false,
"SourceType": "",
"IsCompactFrame": false,
"FormatSignature": 0,
"FormatFrame": null
}

[cvjensen]

Would it help if I kept grepping for C1's in 24 hours , then we could get a distinct list of all the LLA's in showing in my house?
Perhaps I should just get all telegrams and not just C1's . Then we could get a complete list . Tell me if that would help .
If you wanna try a little yourself , tell me. SSH access can be arranged :)

[cvjensen]

{
"Raw": "0x2a442d2c2066cb3b8d8b46907dd1adfd10b97a6662e06ed808f1471d19c5b6efff0742ae623792cef4ff81",
"Length": 42,
"CField": "0x44",
"CFieldString": "0x44 (SND_NR)",
"MField": "0x2d2c",
"MFieldCodeString": "KAM",
"MFieldLongString": "Kamstrup Energi A/S, , ",
"Id": 1003185696,
"IdString": "3BCB6620",
"Version": 141,
"Device": "0x8b",
"DeviceString": "0x8b",
"CiField": "0x46",
"HeaderKnown": false,
"PayloadKnown": false,
"Header": null,
"Body": {
"Raw": null,
"DataRecords": [],
"PayloadKnown": true,
"IsEncrypted": false,
"DecryptionFailed": false,
"BlockCiField": 0
},
"AField": {
"Id": 1003185696,
"Version": 141,
"Device": 139
},
"Ell": null,
"Afl": null,
"BodyParseError": "can not parse CI-Field 0x46",
"CrcValid": false,
"HasCrc": false,
"SourceType": "",
"IsCompactFrame": false,
"FormatSignature": 0,
"FormatFrame": null
}

How should I interpret this? 😃

[weetmuts]

The meter 77966720 looks like a nice standard multical21.
Pick one of your collected lines and do:

echo "C1;1;1;...." | wmbusmeters stdin:rtlwmbus

and it will print:
Received telegram from: 77966720
manufacturer: (KAM) Kamstrup Energi (0x2c2d)
type: Cold water meter (0x16)
ver: 0x1b
device: rtlwmbus[]
rssi: 45 dBm
driver: multical21

So there is only a single link layer address. Wmbusmeters can properly decode telegrams with different LLA and ALAs,
but in this case it is not needed.

Now decrypt the telegram:
echo "C1;1;1;...." | wmbusmeters stdin:rtlwmbus MyWater multical21 77966720 00112233445566778899aabbccddeeff
and replace 00-ff with your meter key.

[cvjensen]

I tried but without luck

pi@raspberrypi:~/wmbusmeters $ echo "C1;1;1;2021-08-22 09:23:20.000;45;12;77966720;0x23442d2c206796771b168d2004d25bfa215d561df7fe71fc7d85b6ea5d43b30b6bd90cb6" | wmbusmeters stdin:rtlwmbus MyWater multical21 77966720 F7B9C058EF8E3B35E719F08512345678
Started config rtlwmbus on stdin listening on any
(wmbus) decrypted payload crc failed check, did you use the correct decryption key? 267e payload crc (calculated db2b) Permanently ignoring telegrams from id: 77966720 mfct: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b
(meter) newly created meter (MyWater 77966720 multical21) did not handle telegram!

[cvjensen]

So if 77966720 is not mine , but it is a kamstrup 21 water meter and its sending C1's .. why cant I see my own water meter ? 😕

[pswiatki]

Can it be too weak (of a signal) to pick up (by your reception device)?

[cvjensen]

Can it be too weak (of a signal) to pick up (by your reception device)?

Maybe ? The rtl-sdr device is sitting in a laptop that is in the same room - around 1,5 meters away .
If that cannot pick up the signal then I dont know how the water company is able to do it ...

[pswiatki]

Chances are they used the proper key then. ...and you've been given some bogus string of HEX numbers. Can this be a possibility?

[weetmuts]

You could perhaps verify that it is your meter by wrapping it in some layers of aluminium foil. If the the telegrams stop being received or the rssi sinks, then is your meter.

[cvjensen]

Chances are they used the proper key then. ...and you've been given some bogus string of HEX numbers. Can this be a possibility?

I can see that the water company sent me a direct export of their program ... my guess is that it is directly from some kind of kamstrup management software . So the encryption key seems legit in my eyes .

[cvjensen]

You could perhaps verify that it is your meter by wrapping it in some layers of aluminium foil. If the the telegrams stop being received or the rssi sinks, then is your meter.

Hi again Fredrik , where can I find the rssi when I try to parse the data I just receive the "decrypted payload crc failed check, did you use the correct decryption key" and no information about the rssi ?

[cvjensen]

Here's some tinfoiled telegrams:

C1;1;1;2021-08-22 16:35:47.000;49;11;77966720;0x23442d2c206796771b168d2059e076fa2112e73cc751abd8aea5a1404300fab301d7005c C1;1;1;2021-08-22 16:36:03.000;47;44;77966720;0x23442d2c206796771b168d205ae176fa2155d960d5a5546f4c0183dc3f9faf0a33cdfd15 C1;1;1;2021-08-22 16:36:03.000;39;9;77966720;0x23442d2c206796771b168d205ae176fa2155d960d5a5546f4c0183dc3f9faf0a33cdfd15 C1;1;1;2021-08-22 16:36:19.000;57;50;77966720;0x2a442d2c206796771b168d205be276fa21706d8b8a218cbc8934a5bcf83356301be0e2f8a4ebc35027e1ab C1;1;1;2021-08-22 16:36:19.000;57;5;77966720;0x2a442d2c206796771b168d205be276fa21706d8b8a218cbc8934a5bcf83356301be0e2f8a4ebc35027e1ab C1;1;1;2021-08-22 16:36:35.000;47;41;77966720;0x23442d2c206796771b168d205ce376fa2187f87b2bfbcd905627d92910dc9009609d89fc C1;1;1;2021-08-22 16:36:35.000;43;33;77966720;0x23442d2c206796771b168d205ce376fa2187f87b2bfbcd905627d92910dc9009609d89fc C1;1;1;2021-08-22 16:36:50.000;54;60;77966720;0x23442d2c206796771b168d205df076fa21dfb814e406fc9baaf8acd0d177eacb393af065 C1;1;1;2021-08-22 16:36:50.000;63;33;77966720;0x23442d2c206796771b168d205df076fa21dfb814e406fc9baaf8acd0d177eacb393af065

[weetmuts]

The number after the timestamp is the packet_rssi and the number after that is the current_rssi.
So for this line:
C1;1;1;2021-08-22 16:36:50.000;63;33;77966720;0x23442d2c206796771b168d205df076fa21dfb814e406fc9baaf8acd0d177eacb393af065
The packet rssi is 63
and the current rssi i 33.

Lower values means less signal strength. They are not bound to any physical value because we do not know enough about your rtlsdr donle, but are correct for your dongle. So if these numbers are dropping then you have tinfoilded the right meter.

If you want you can run this:
rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | wmbusmeters stdin:rtlwmbus
to get the rssi printed by wmbusmeters.

Or you can print only the rssi columns directly:
rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | grep 77966720 | cut -f 5,6 -d ';'

[cvjensen]

Hi again Fredrik ,

I'm not really able to wrap the water meter completely because its placed to tight to the wall. But Icollected 30 telegrams and made an average...

With tinfoil the numbers are:
47,5 27,4

Without tinfoil:
40,76666667 24,66666667

So I guess that's not my meter... which explains why I cannot decode with my key .
But it almost seems like when I remove the tinfoil my own meter disturbe 77966720 and make the rssi worse for this meter... or well... I would like to think so.

Anyway ... it brings us back to the question - why does my meter not show up anywhere ?

Could we try to decrypt every wireless mbus telegram until something is a success ? 😕

Or make a distinct list of all the meters I can find and try to look at them ?

Or does anyone have a better idea?

/C

[pswiatki]

I have been thinking about your case and something struck me - I check my readings from time to time and can see some of the water meters disappear only to appear later (hours, sometimes days). That includes also my own water meter. It has a problem for sure - although it is close to my RTL SDR, the RF level is very low. Still: there are days (many days, even weeks) where daily logs are more or less the same in size, but on occasion, I see shorter log files, e.g. last telegram gets registered @13:00 (1 PM) or so. It is hard for me to believe the signal would suddenly drop well below the threshold, or magically the collision rate skyrocketed. I wonder if the water provider could be remotely doing something to the meters. I recently [physically] saw my neighbour's meters (there are two for his building) and they look identical to mine (which is expected - they are from the same water provider). I am pretty sure the meters I pick up with a superbly high RF level are those two. The situation with them is similar: from time to time their telegrams simply disappear from the logs for some time only to re-appear again (with very high RF levels) later on. I exclude the possibility of my gear being faulty - I get other readings just fine during the same periods of time.

Hope this helps a bit.

[weetmuts]

Could we try to decrypt every wireless mbus telegram until something is a success ?

Great idea! With wmbusmeters you can!

Try this:

rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | wmbusmeters --format=fields --field_found=FOUND --selectfields=found,id,total_m3 stdin:rtlwmbus MyWater auto '*' F7B9C058EF8E3B35E719F08512345678 2>&1 | tee thelog

Then look through thelog for FOUND.

If you are lucky it looks something like this:

Started config rtlwmbus on stdin listening on any
(wmbus) decrypted payload crc failed check, did you use the correct decryption key? 3578 payload crc (calculated 7e7a) Permanently ignoring telegrams from id: 77966720 mfct: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b
(meter) newly created meter (MyWater 77966720 multical21) did not handle telegram!
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 88888888 mfct: (APA) Apator, Poland (0x601) type: Water meter (0x07) ver: 0x05
(meter) newly created meter (MyWater 88888888 apator162) did not handle telegram!
FOUND;76348799;6.408
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 77777777 mfct: (SON) Sontex, Switzerland (0x4dee) type: Water meter (0x07) ver: 0x3c
(meter) newly created meter (MyWater 77777777 supercom587) did not handle telegram!

[cvjensen]

I have been thinking about your case and something struck me - I check my readings from time to time and can see some of the water meters disappear only to appear later (hours, sometimes days). That includes also my own water meter. It has a problem for sure - although it is close to my RTL SDR, the RF level is very low. Still: there are days (many days, even weeks) where daily logs are more or less the same in size, but on occasion, I see shorter log files, e.g. last telegram gets registered @13:00 (1 PM) or so. It is hard for me to believe the signal would suddenly drop well below the threshold, or magically the collision rate skyrocketed. I wonder if the water provider could be remotely doing something to the meters. I recently [physically] saw my neighbour's meters (there are two for his building) and they look identical to mine (which is expected - they are from the same water provider). I am pretty sure the meters I pick up with a superbly high RF level are those two. The situation with them is similar: from time to time their telegrams simply disappear from the logs for some time only to re-appear again (with very high RF levels) later on. I exclude the possibility of my gear being faulty - I get other readings just fine during the same periods of time.

Hope this helps a bit.

Hi , thanks for sharing your experiences . Do you have a multical 21?
There's one thing I simply cannot understand ... If the watermeters should only send telegrams occasionally... how should the water company then could be able to drive by and fetch information on all watermeters ? There has to be some kind of stability , right?..

[cvjensen]

Could we try to decrypt every wireless mbus telegram until something is a success ?

Great idea! With wmbusmeters you can!

Try this:

rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | wmbusmeters --format=fields --field_found=FOUND --selectfields=found,id,total_m3 stdin:rtlwmbus MyWater auto '*' F7B9C058EF8E3B35E719F08512345678 2>&1 | tee thelog

Then look through thelog for FOUND.

If you are lucky it looks something like this:

Started config rtlwmbus on stdin listening on any
(wmbus) decrypted payload crc failed check, did you use the correct decryption key? 3578 payload crc (calculated 7e7a) Permanently ignoring telegrams from id: 77966720 mfct: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b
(meter) newly created meter (MyWater 77966720 multical21) did not handle telegram!
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 88888888 mfct: (APA) Apator, Poland (0x601) type: Water meter (0x07) ver: 0x05
(meter) newly created meter (MyWater 88888888 apator162) did not handle telegram!
FOUND;76348799;6.408
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 77777777 mfct: (SON) Sontex, Switzerland (0x4dee) type: Water meter (0x07) ver: 0x3c
(meter) newly created meter (MyWater 77777777 supercom587) did not handle telegram!

Hi Fredrik , I'll go ahead and test it later .. Right now I'm strugling to get a good test environment up and running. I don't have dedicated hardware so close to the water meter so I just have to be a little creative ! ;)

[pswiatki]

I have been thinking about your case and something struck me - I check my readings from time to time and can see some of the water meters disappear only to appear later (hours, sometimes days). That includes also my own water meter. It has a problem for sure - although it is close to my RTL SDR, the RF level is very low. Still: there are days (many days, even weeks) where daily logs are more or less the same in size, but on occasion, I see shorter log files, e.g. last telegram gets registered @13:00 (1 PM) or so. It is hard for me to believe the signal would suddenly drop well below the threshold, or magically the collision rate skyrocketed. I wonder if the water provider could be remotely doing something to the meters. I recently [physically] saw my neighbour's meters (there are two for his building) and they look identical to mine (which is expected - they are from the same water provider). I am pretty sure the meters I pick up with a superbly high RF level are those two. The situation with them is similar: from time to time their telegrams simply disappear from the logs for some time only to re-appear again (with very high RF levels) later on. I exclude the possibility of my gear being faulty - I get other readings just fine during the same periods of time.
Hope this helps a bit.

Hi , thanks for sharing your experiences . Do you have a multical 21?
There's one thing I simply cannot understand ... If the watermeters should only send telegrams occasionally... how should the water company then could be able to drive by and fetch information on all watermeters ? There has to be some kind of stability , right?..

See the sentence in bold. I believe they might be controlling (en mass, I imagine) the meters. That would mean: (a) meters have RX channel (heavily protected against unauthorized access, presumably), (b) the operator can TX, possibly in a broadcast fashion or directly to a single device if they so choose and change the way the device(-s) behave. For example: WMBus packets TX rate could be manipulated. Who knows.

[cvjensen]

thanks for the answers guys ..

I've tried to start the command that @weetmuts suggested, so now we just try to decrypt every telegram that comes by my rtl-sdr (of course still in the same room as the water meter)

If my watermeter for some reason only sends on certain weeks/months , then I probably have to find another machine/probe to run the tools on... Right now it's my girlfriends laptop running ubuntu from an usb 😆

[pswiatki]

I know ;-). The meters' TX rate rarely remains constant. I have observed my own meters for a long time (>1 year) and found following out:

Same period of observation here (almost exactly 1 year) - however, I am not able to find any sense in what's going on (no discernible logic, or schedule in how these water meters operate in my vicinity). I guess a more rigorous approach would be necessary to make sense of this situation. Not sure if it is worth spending time, though.

[cvjensen]

@weetmuts Hey Fredrik ,

Except the errors I Now I have the following lines in my log:
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?
FOUND;56114888;?total_m3?

Any suggestions?

[weetmuts]

Cool, that is a meter that perhaps decrypts properly, but has no total_m3... weird.
Could perhaps be your meter.

Now do:
rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl_wmbus | wmbusmeters --debug --format=json stdin:rtlwmbus MyWater auto 56114888 F7B9C058EF8E3B35E719F08512345678 2>&1 | tee thelog

Until you can see "yes for me" in the log. Then post the debug log here.

[cvjensen]

thelog.txt

There you go - after a few seconds "yes for me" appeared.

[weetmuts]

Sadly that was a red herring. It is from a heat (energy) meter which is not encrypted..... Nice with a new telegram from a device that I have not seen before, but alas it does not help you.....

[cvjensen]

Alright , what a shame . I'll start the last script again and see if any other meters are showing up .

[cvjensen]

The script has now been running for a week ... and the result is:

Started config rtlwmbus on stdin listening on any
(meter) MyWater: meter detection could not find driver for id: 55594701 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 55594701 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 55594701 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114937 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114937 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114937 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114956 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114956 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114956 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 55935283 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 55935283 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 55935283 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114955 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114955 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114955 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114970 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114970 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114970 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 55594567 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 55594567 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 55594567 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114888 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114888 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114888 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114993 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114993 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114993 auto) did not handle telegram!
(wmbus) decrypted payload crc failed check, did you use the correct decryption key? 4810 payload crc (calculated 3293) Permanently ignoring telegrams from id: 77966720 mfct: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b
(meter) newly created meter (MyWater 77966720 multical21) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114926 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114926 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114926 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114806 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114806 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114806 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114995 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114995 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114995 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56115006 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56115006 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56115006 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114958 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114958 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114958 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114957 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114957 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114957 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 55931802 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 55931802 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 55931802 auto) did not handle telegram!
(meter) MyWater: meter detection could not find driver for id: 56114810 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) please consider opening an issue at https://github.com/weetmuts/wmbusmeters/
(meter) to add support for this unknown mfct,media,version combination
(wmbus) decrypted content failed check, did you use the correct decryption key? Permanently ignoring telegrams from id: 56114810 mfct: (HYD) Hydrometer (0x2324) type: Heat volume at inlet meter (0x0c) ver: 0x20
(meter) newly created meter (MyWater 56114810 auto) did not handle telegram!

Even the 56114888 fails now ... thats a little strange .
Can it really be true that the multical should not even send a single telegram for a whole week... when the papers says that it should be sending every 16 second?

if anyone have any ideas please dont hold back! 😄

[JanGJensen]

Hi

Did you ever get this up running

I'm having the same issue, not recieving any packages from my Multical 21 with com module 66. (I know it is encrypted, according to the 3 lat in the cofiguation)

I´m trying to idetify the meter with Wmbusmeter add on in HA.

I can find my Heat meter on the t1. But do not recieve anything at all on c1.

Using an. im871a m-bus dongle. 2 days old, so I expect the firmware is fairly new.. and actually should support runing both c1 and t1 at the same time.

[cvjensen]

hi @JanGJensen , No we never saw a single message from my multical, so I gave up and bought my own multimeter instead. @weetmuts helped me trying to figure out what was wrong but no luck. In my case there wasnt a single message from the multical.