Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamjupiter95 wrote:I am returning to the thread about reading data from the wireless APATOR W-MBUS overlay
Has anyone managed to identify the data returned by the overlay?
jupiter95 wrote:jupiter95 wrote:jupiter95 wrote:I am returning to the thread about reading data from the W-MBUS wireless APATOR overlay
Has anyone managed to identify the data returned by the overlay?
I am bumping up the topic again. But maybe someone has information e.g. data sent in the overlay frame APATOR W-MBUS
?
And you can paste such a frame, then I will try to describe it.
The wmbus frames are standard, 11 bytes of header if no CRC, or 13 with CRC. The first byte contains the size of the rest.
In addition, depending on the receiver you are using, you may have extra bytes on the front and back. For example, mine has FF on the front and RSSI on the back in one byte.
I am now struggling with BMETERS, they have encoding but not the standard mode 5 AES128+CBC.
Does anyone have a description of the bmeters frames?
COoLoSER wrote:jupiter95 wrote:.jupiter95 wrote:jupiter95 wrote:I am returning to the thread about reading data from the wireless APATOR W-MBUS overlay
Has anyone managed to identify the data returned by the overlay?
I am bumping up the topic again. Maybe someone has information e.g. data sent in the frame of the APATOR W-MBUS overlay.
?
And you can paste such a frame, then I will try to describe it.
The wmbus frames are standard, 11 bytes of header if no CRC, or 13 with CRC. The first byte contains the size of the rest.
In addition, depending on the receiver you are using, you may have extra bytes on the front and back. For example, mine has FF on the front and RSSI on the back in one byte.
I am now struggling with BMETERS, they have encoding but not the standard mode 5 AES128+CBC.
Does anyone have a description of the bmeters frames?
The read frame after decryption the AES key as already written here with the newly purchased overlay is zeros.
Start collecting data:
DIF F VIF 68 msg: 3E|44|0106|xxxxxx|05|07|7A|BF|0000802F2F0F6889D692900210432E00101C2800007101061B0000DC000000A01A86AF03FFFFFFFFFFFFFFFFFFFF
instead of the overlay ID I entered xxxxxxxx
I would be grateful for a description, because so far I have only been able to read the total consumption (the most important value, but others would also be useful)
IZAR RC 868 I R4 PLCOoLoSER wrote:.If one had Apator's Inkasent program it might be possible to decode. Unfortunately the manufacturers use their own algorithms to save the data, and supposedly all comply with OMS
jupiter95 wrote:"Unfortunately, pproducers use their own algorithms to save the data, and supposedly they are all OMS compliant." - HERE'S WHY, in places like electrode, people should be doing reverse-engineering and rubbing the noses of those CEOs of these companies who make life so difficult. Do manufacturers make so much money from their software? I don't think so. (I'm not counting the situation when, in a strange way, housing associations choose the water meters of manufacturer e.g. X)
jupiter95 wrote:
bdkacz wrote:.Is it possible that the overlay does not read the reading "online" but e.g. once a month and such a reading is broadcast for the next reading? Because I have a slight "divergence" between the decoded reading and the current reading, hence this suspicion![]()
LINK LAYER (DLL)
l-field 3e - 62 bajty BEZ crc
c-field 44 - SND_NR (send, no response)
m-field 01 06 - "APA"
a-field xx xx xx xx 05 07
crc-field b8 7b
APPLICATION LAYER (APL)
ci-field 7a - "M-Bus Response from device with short header", pierwsze 4 bajty to naglowek (access no.[0], status[1], signature[2,3])
access number 6b - ile pakietow wyslane
state of meter 00 - stan licznika, 0 - brak errorow, 0x04 - low battery
cw[0] 30 - 3 zaszyfrowane bloki
cw[1] 85 - (0x80 = bidyrekcjonalny) | (0x05 - AES CBC with IV)
8f 69 e3 4b 72 ee c7 79 3f 6a da d9 61 86 4b 8c
e1 99 5b 97 3f cc c0 9a 9b 3b 97 7c a0 6b da d7
eb ca fe 7b 0d d0 41 b3 90 85 15 0c 94 0a 6f 88
AES IV = m-field + a-field + access_no x8
dla tego pakietu
AES IV = 01 06 xx xx xx xx 05 07 6b 6b 6b 6b 6b 6b 6b 6b
{"media":"water","meter":"apator162","name":"MyTapWater","id":"00974713","total_m3":74.309,"timestamp":"2019-08-14T12:51:44Z"}
{"media":"water","meter":"apator162","name":"MyTapWater","id":"00975567","total_m3":271.33,"timestamp":"2019-08-14T12:51:04Z"}maglo18 wrote:I have two water meters with apator at-wmbus-16-2 overlay. Thanks to the author of the program, which was corrected in the last few days from here Link correctly read the values from both overlays.
.{"media":"water","meter":"apator162","name":"MyTapWater","id":"00974713","total_m3":74.309,"timestamp":"2019-08-14T12:51:44Z"}
.{"media":"water","meter":"apator162","name":"MyTapWater","id":"00975567","total_m3":271.33,"timestamp":"2019-08-14T12:51:04Z"}
I used a DVB-T RTL2832U Tuner on USB for the reading.