logo elektroda
logo elektroda
X
logo elektroda

W-MBUS protocol reading in APATOR water meters - encryption and documentation

mks 48306 70
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #31 17015401
    vania
    Level 24  
    ISTA radio net 3 photos The radio chip is CC1101.
    W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation
  • ADVERTISEMENT
  • #32 17188601
    jupiter95
    Level 9  
    I return to the thread about reading data from the APATOR W-MBUS wireless overlay

    Has anyone managed to identify the data returned by the overlay?
  • #33 17202361
    jupiter95
    Level 9  
    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.
    ?
  • #34 17260844
    COoLoSER
    Level 11  
    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?
  • #35 17266902
    jupiter95
    Level 9  
    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)
  • #36 17268764
    COoLoSER
    Level 11  
    3E - size = 62 bytes, your frame is too short according to what is in the first byte
    44 - frame type
    0106 - 3-letter manufacturer name (APA)
    xxxxxxxx - device id
    05 - version
    07 - device type (water meter)
    7A - header type 7a - short header 4 bytes
    BF - reading counter, grows with subsequent transmission
    00 - status
    0080 - configuration (also encoding here)

    - - decoded message
    2F2F - two "empty" bytes fill the space, with AES coding the first two should be 2f2f
    DIB=0F VIB=68 - DIB=0f indicates manufacturer specific data to the end of the data, so not sure what is going on there.
    89D692900210432E00101C2800007101061B0000DC000000A01A86AF03FFFFFFFFFFFF

    If one had Apator's Inkasent program then maybe it would be possible to decode. Unfortunately, manufacturers use their own algorithms to save the data, and supposedly all comply with OMS
  • #37 17271948
    jupiter95
    Level 9  
    "means manufacturer-specific data to the end of the data, so it's not clear what's going on there. " - well a little bit is known
    In the space marked below is the total water consumption. The value agrees with that shown on the meter digits of the water meter
    3E440xxxxxxxxx105077AD20000802F2F0F6E6C569290020043310010|CE32|00007101061B0000DC000000A01A86AF03FFFFFFFFFFFF
    32CE
    13006

    "Unfortunately, the manufacturers use their own algorithms to save the data, and supposedly all comply with OMS". - HERE'S WHY, in places like electrode, people should be doing reverse-engineering and rubbing the noses of those CEOs of those companies that make life so difficult. Do manufacturers make so much money from their software? I don't think so. (I'm not counting situations where, in a strange way, housing associations choose the water meters of manufacturer e.g. X)

    Added after 10 [minutes]:

    The whole current Internet Of Things revolution is about the emergence of chips with open architecture, with publicly available documentation and running on generally accepted OSes.

    PLCs no longer have this advantage ;) )

    Which is probably not to the taste of those who would like to continue to sell automation systems for astronomical prices. Ok big industry will still rely on them but if it wasn't for IoT there would be no small, cheap and sufficiently stable automation.
  • ADVERTISEMENT
  • #38 17273481
    wochen
    Level 10  
    Hi,

    has anyone had contact with such an overlay from Diehl?
    IZAR RC 868 I R4 PL
    Link .

    And is it possible to read / decode it with this dongle: ARF8020AA? Destination: Domoticz.

    Thanks.
  • #39 17311046
    mks
    Level 11  
    COoLoSER 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
    .

    The Inkasoid has no logic in it to make it readable. It is all in the Incasoid.

    Added after 9 [minutes]:

    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)


    You forgot to mention that you also get paid for reading such a water meter.
  • #40 17453785
    MacieX4Race
    Level 10  
    Hi,

    Refreshing the topic, has anyone succeeded in the art of recovering / reading the current stored encryption key from the AT-WMBUS-16-2 overlay ? I have the possibility to buy a used overlay.
  • ADVERTISEMENT
  • #41 17527128
    cici
    Level 17  
    Gentlemen, on the other hand, maybe someone would like to be the author of the software for such an overlay
    of course not only for points :)
  • #42 17533490
    mks
    Level 11  
    As if anyone was interested in what the Minol Zenner looks like from the inside this is it. The cubes are ADF7012 & MSP430FW429. The principle of operation is completely different from Apator.

    The quartz at the ADF7012 is 7.3728. According to the note 3.6864 is responsible for the 315 MHz transmit frequency. The other values of the quartz (i.e. 4.9152 and 10 MHz) have nothing to do with what is on the board so it seems to me that this overlay is just working at 315MHz. Does anyone have such a water meter and receiver and could check this?

    W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation W-MBUS protocol reading in APATOR water meters - encryption and documentation
  • ADVERTISEMENT
  • #43 17881015
    Macgyver92
    Level 2  
    Hello, I need help. I am in France. I have APATOR water meters and ADEUNIS material for collecting information. I have decripted a part of the frame (Size, type of frame, name of the manufacturer, device identifier, ...), but not the data of the water meter. The frame is simple and short.
    the following frame is :
    Detail Manufacturer SOF Lenght CField MField AField CIField Data
    19/03/2019 10:05:47.03 : -41dBm aPT FF 12 44 14 86 CC D6 13 00 04 11 A06C8A0000 0800030000000005FF02F960 0000A7

    Thanks for your help.
  • #44 17883347
    jupiter95
    Level 9  
    Hi I have a good news for you

    please look at https://github.com/weetmuts/wmbusmeters

    Added after 4 [minutes]:

    jupiter95 wrote:
    Hi I have a good news for you

    please look at https://github.com/weetmuts/wmbusmeters


    Yes there is good news on Apator.

    The project author has added support for the Apator overlay. Data read not only by dedicated WMBUS - USB dongle but also by RTL_SDR.

    Unfortunately, we read only the current consumption (what I described earlier)

    But maybe it will be a contribution to intensify the work on reading the full apator frame.
  • #45 17886644
    bdkacz
    Level 11  
    Is it possible that the overlay does not read the readings "online", but e.g. once a month and broadcasts such readings for the next reading? Because I have a slight "divergence" between the decoded reading and the current indication, hence this suspicion :)
  • #46 17886656
    jupiter95
    Level 9  
    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 :)
    .

    Rather not. At least in my over a year's use I haven't noticed it. Unless you can read the measurement history and maybe it is there.
  • #47 17887052
    Macgyver92
    Level 2  
    Hello, thanks Jupiter95,
    But I still need your help to advance and to identify the encrypted part.
    Please find after here the frame and the detail :
    FF 12 44 86 14 CC D6 13 00 04 11 A06C8A00000800030000000005FF02F9600000A7
    FF = SOF
    12 = Lenght
    44 = CField
    1486 = Manufacturer (Apator)
    13D6CC= Serial number (1300172)
    04 = Version
    11 = Type (cold water)
    and for the rest, I can not find. (encrypted part ?)
    A06C8A00000800030000000005FF02F9600000A7

    Thank you
  • #48 18112678
    zdebel
    Level 15  
    He installed Aquanet (Poznań) at my place recently and unfortunately it is all encrypted, from what I have analysed:
    
    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
    
  • #49 18114758
    maglo18
    Level 11  
    I have two water meters with apator at-wmbus-16-2 overlay. Thanks to the author of the program which has been corrected in the last few days from here Link the values from both overlays are read correctly.

    {"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.
  • #50 18114766
    zdebel
    Level 15  
    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.

    Are these water meters fitted by the operator or your private purchase? Do you know if you have a default encryption key?
  • #51 18119083
    maglo18
    Level 11  
    Counters fitted by the operator. The key I use is 32 zeros. This is what the programme author recommended to me.
  • #52 18291928
    prbhary
    Level 10  
    Hello,
    I have access to the original software and bluetooth radio modules from both Kamstrup (READY) and Diehl (IzarMobile). I would like to read an apator meter with a wmbus 16-2 overlay using either of these, but can't seem to manage. Does anyone have any experience? Greetings
  • #53 18436669
    sholek
    Level 12  
    Apator's software is available for download from their servers http://software.telemetria.eu/inkasentpc3/?ShowAllVersions=1

    After installing Inkasent Pc3, you can see that the water meter transmits also information about errors, e.g. reverse flow, and this information is "kept" in the memory between readings (and these usually occur once or twice a year due to the cost of reading which has to be borne by the community/co-operative).
    With the software from Diehl Izar, I have not been able to read Apator either, although I have an Apator gateway (hunted down once on a classifieds portal). Generally, not many manufacturers have protocols from their competitors stored in their software.
    I am curious if anyone has tried to read water meters with LoRaWan modems. There are more and more of these on the market (Minol Zenner, Maddalena), and I have read that several water supply companies have based their reading system on the LoRa standard, min. Piekary Śląskie (6.5 thousand units, Ząbki).

    P. S.
    If anyone needs a Brunat/ Ista/ Techem /Bmeters overlay to play with, I'd be happy to share.
  • #54 18436717
    TvWidget
    Level 38  
    sholek wrote:
    has anyone tried reading water meters with LoRaWan mods.
    .
    They are not read. They themselves periodically send the measurement results
  • #55 18436859
    sholek
    Level 12  
    TvWidget wrote:
    .
    They are not read out. They themselves periodically send the measurement results
    .

    Since they send the result it can probably be downloaded/read in some way</>:)
  • #56 18437538
    TvWidget
    Level 38  
    Data can be collected but
    - may be sent very infrequently, e.g. once a month
    - may be encrypted
  • #57 18437799
    sholek
    Level 12  
    I ask because I am building a LoRaWan network in Silesia for one of the water meter manufacturers (maybe build is a strong word, we are installing gateways in locations specified by the customer). The network gateways are running 24/7 and the water meter is supposed to give the status daily.
  • #58 18802206
    arekm
    Level 16  
    For https://zpserwis.com.pl/rozwiazania/systemy-odczytu-radiowego-wodomierzy/ what else might be hiding in the frame:

    "Radio readout from Sensus Scout and Apator Powogaz overlays ... allows for:

    1. individual reading and configuration of overlays.
    2. reading from the overlay of, among other things, information on:

    • current water meter status
    interference attempt (disassembly)
    • backflow
    • leakage
    • burst pipe
    • low battery level in cap
    • consumption history (up to 24 months back)."
  • #59 19101847
    matidyba
    Level 10  
    Hello

    I have an APATOR AT-MBUS-04 overlay + MBUS > RS232 converter. I can read BMeters water meters but I can't read APATOR, does anyone know how to send a request and what settings to use?

    Thank you in advance for your help

Topic summary

The discussion focuses on reading W-MBUS (Wireless M-Bus) protocol data from Polish water meters, particularly those manufactured by APATOR. Users report significant variability in frame lengths and note that APATOR employs AES-128 encryption (AES CBC mode) on most or all data fields, except for frame headers and CRC. The AES key for new overlays is often set to 16 zero bytes by default, but suppliers typically do not share encryption keys or detailed protocol documentation, citing security and anti-tampering concerns. Physical access and interference with the overlay hardware may allow key extraction, but this is complex and legally sensitive. Some users have reverse-engineered parts of the frame structure, identifying standard W-MBUS fields (SOF, length, CField, MField, AField, CIField) and manufacturer-specific data blocks containing encrypted consumption and status information. Tools used include ADEUNIS USB WMBUS dongles, RTL-SDR receivers, and software such as Inkasent PC3 and open-source projects like wmbusmeters on GitHub. The SPIRIT1 and CC1101 radio chips are commonly found in overlays. Other manufacturers like BMeters provide OMS-compliant frames, which are easier to interpret. Attempts to read APATOR meters with alternative radio modules (e.g., RFM22, RFM69) and LoRaWAN networks are ongoing. Some users develop custom software APIs in Python and C for frame decoding. Overall, the community faces challenges due to encryption, proprietary data formats, and limited manufacturer cooperation, but progress is made through reverse engineering and open-source tools.
Summary generated by the language model.
ADVERTISEMENT