amiplus frames not decoded

[xaelsouth]

amiplus frames not decoded

[xaelsouth]

Ok, after spinning around a little bit I got it, at least I hope so. First two datagrams below are from unrelated water meter - as you said - just ignore them. The last two are from your electricity meter.

Please note, the electricity meter datagram is different to that you have got from rtl_433! (Data Length: 95 Data : 5c4401068120018602027a000050050c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f7731f7d)

The L(ength) field = 0x5c must be wrong in the rtl_433's output. You can verify it yourself be calculating the checksums. For T1 mode rtl_wmbus always checks both - 3outof6 encoding and checksums. On success that results in T1;1;1 at the start of every line.

cat rtlsdr_868.95M_1M6_amiplus_notdecoded.bin | build/rtl_wmbus

T1;1;1;2024-05-09 21:25:54.000;36;32;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94

T1;1;1;2024-05-09 21:25:54.000;26;24;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94

T1;1;1;2024-05-09 21:25:54.000;124;105;86012081;0x5e4401068120018602027a000050050c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f773

T1;1;1;2024-05-09 21:25:54.000;129;149;86012081;0x5e4401068120018602027a000050050c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f773

[xaelsouth]

Thank you too for pointing out the bug!

L(ength) field for T1/C1 frame format A (your case) is always given without CRC bytes included. So it must be 0x5e. I don't know, if rtl433 does verify any checksums, so you may ask rtl433 guys about it. Or even notify them that this is needed before somebody is going to use values out of invalid datagram.

rtl_wmbus has implemented two independent decoders (run length algorithm and time2 algorithm) which work simultaneously. Ideally, every decoder will print the same line makes two lines per received datagram in total. If you really want to avoid duplicates, then start rtl_wmbus with "-r 0" or "-t 0" argument to prevent executing of run length or time2 method respectively. You can play with arguments and check which method performs better for you.

I close this issue here as it works for you now.

[nestorayuso]

{
"Raw": "0x5c4401068120018602027a000050050c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f7731f7d",
"RawWithCrc": null,
"FrameFormat": "Unknown",
"Length": 92,
"CField": "0x44",
"CFieldString": "0x44 (SND_NR)",
"MField": "0x0106",
"MFieldCodeString": "APA",
"MFieldLongString": "Apator SA, Poland, Europe",
"Id": 2248220801,
"IdString": "86012081",
"Version": 2,
"Device": "0x02",
"DeviceString": "Electricity",
"CiField": "0x7a",
"HeaderKnown": true,
"PayloadKnown": true,
"CrcValid": false,
"HasCrc": false,
"SourceType": "WMBUS",
"IsCompactFrame": false,
"FormatSignature": 30256,
"FormatFrame": "0x1f00",
"ParserVersion": "1.9.0",
"Header": {
"Serial": 0,
"IdString": "",
"ManufacturerCode": 0,
"MFieldCodeString": "",
"MFieldLongString": "",
"Version": 0,
"DeviceType": "0x00",
"DeviceString": "",
"EncryptionMode": 5,
"EncryptionModeString": "AES with CBC",
"EncryptedBlocks": 5,
"HopCount": 0,
"IsAccessible": true,
"IsBidirectionalMode": false,
"IsSynchronous": false,
"ReservedBit": false,
"TelegramType": 0,
"AccessNumber": 0,
"StatusByte": 0,
"ConfigField": [
80,
5
]
},
"Ell": null,
"Afl": null,
"Body": {
"Raw": "0x0c0b9cf0f94e1fe6999ff82b6a92b2c89a333185193d7f66b8d4af75b12f688acbbe8d3dc994ee43cd1eb2b7ae42326d188c2dbed49ca6b3c85b35f2d07ea99982bd697261de298d516c25c6e410f7731f7d",
"DataRecords": [
{
"DifDataLength": 0,
"DifFunctionString": "Manufacturer specific data + more in next telegram",
"DifDataFormat": "special function",
"DifSubunit": 0,
"VifUnit": "",
"VifQuantity": "",
"VifExponent": 0,
"VifEDescription": "",
"Value": 0,
"ValueScaled": 0,
"ValueString": "0",
"Tariff": 0,
"StorageNo": 0,
"DifVif": "0x1f",
"Data": "0x7d"
}
],
"PayloadKnown": true,
"IsEncrypted": true,
"DecryptionFailed": true,
"BlockCiField": 0
}
}

[xaelsouth]

Hello kosma,

please check out with the new version of rtl_wmbus. Got this output with the file you attached.

cat rtlsdr_868.95M_1M6_amiplus_notdecoded.bin | build/rtl_wmbus
T1;1;1;2024-05-09 16:07:27.000;36;32;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94
T1;1;1;2024-05-09 16:07:27.000;26;24;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94

[kosma]

Still no electricity meter detected. The two telegrams received are from unrelated water meters.

kosma@banana:~/scratchpad/rtl-wmbus$ /usr/local/bin/rtl_wmbus < ~/rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
T1;1;1;2024-05-09 16:15:29.000;36;32;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94
T1;1;1;2024-05-09 16:15:29.000;26;22;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94
kosma@banana:~/scratchpad/rtl-wmbus$ build/rtl_wmbus < ~/rtlsdr_868.95M_1M6_amiplus_notdecoded.bin
T1;1;1;2024-05-09 16:15:35.000;36;32;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94
T1;1;1;2024-05-09 16:15:35.000;26;24;19131290;0x4e44b4099012131913077a790040057eda852abb08c480d64db9d22a3c1098b0873e3227280131a7a952005eee56a7ebdea93b2d2b93e9bdfd66b35fcbc6d2c3842e323e98528acadf710d035dbc94

[kosma]

Thanks so much, it seems this has done the trick. As for the length field - I think 5c is without checksum, 5e is with checksum?

Also: it seems the telegram is decoded twice. I can't tell if it's present twice in the file, or is it a bug?