-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot see my kamstrup multical 21 #25
Comments
I've tried to scan for 24 hours like so 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! |
Hello cvjensen.
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. |
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 |
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:
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. |
{ |
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? |
How should I interpret this? 😃 |
The meter 77966720 looks like a nice standard multical21.
and it will print: So there is only a single link layer address. Wmbusmeters can properly decode telegrams with different LLA and ALAs, Now decrypt the telegram: |
I tried but without luck
|
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 ? 😕 |
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 . |
Chances are they used the proper key then. ...and you've been given some bogus string of HEX numbers. Can this be a possibility? |
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. |
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 . |
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 ? |
Here's some tinfoiled telegrams:
|
The number after the timestamp is the packet_rssi and the number after that is the current_rssi. 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: Or you can print only the rssi columns directly: |
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: Without tinfoil: So I guess that's not my meter... which explains why I cannot decode with my key . 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 |
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. |
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 |
Hi , thanks for sharing your experiences . Do you have a multical 21? |
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 ! ;) |
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. |
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:
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. |
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 😆 |
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. |
@weetmuts Hey Fredrik , Except the errors I Now I have the following lines in my log: Any suggestions? |
Cool, that is a meter that perhaps decrypts properly, but has no total_m3... weird. Now do: Until you can see "yes for me" in the log. Then post the debug log here. |
There you go - after a few seconds "yes for me" appeared. |
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..... |
Alright , what a shame . I'll start the last script again and see if any other meters are showing up . |
The script has now been running for a week ... and the result is:
Even the 56114888 fails now ... thats a little strange . if anyone have any ideas please dont hold back! 😄 |
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. |
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. |
I don't know why I cannot find my multical 21 when I try to scan for it.
What I do know:
I do see alot of T and some few C "packages" - Dont know if packages is the right term.. perhaps frames? I dont know.
My rtl-sdr usb is in the same room when I try to scan.
The water company do drive by reading - they have not been in my house for yeeeears, so the meter MUST send something out.
I've been corresponding with @weetmuts some months ago. He tried to help and I think the hardest part was that we could not tell if my meter was talking on the 868.95M frequency.. BUT! I found an old document, and I guess its some kind of proof, that says:
I'm opening this issue in hope that my meter somehow is getting 'filtered' somewhere in the code.. could that be?
A little help is much appreciated! 👍
The text was updated successfully, but these errors were encountered: