The Lobaro wMbus Parser is used from device Parsers and available as web API at https://platform.lobaro.com/#/wmbus/parser
Response (Lobaro wMbus JSON)
The following is an example of the parsing result of an encrypted example telegram from the OMS specification:
|true if the parsed telegram is still encrypted|
true if the parser tied to decrypt the telegram without success.
Can be used in conjunction with IsEncrypted to detect if the telegram was encrypted (see below).
|PayloadKnown||If the payload of the telegram (related to the CI field) is known to the parser and can be parsed|
|BodyParseError||Error while parsing the payload body|
|FormatSignature||Unique signature of the DifVif structure of all DataRecords. If any DifVif changes, the FormatSignature does change as well.|
|true||true||No valid key|
|false||false||Telegram not encrypted|
|true||false||Telegram is encrypted but parser can not decrypt it (e.g. unknown algorithm)|
|false||true||Plain telegram where decryption failed - should not happen|
VifUnit & VifQuantity
There are a many valid combinations of VifUnit & VifQuantity. All possible values are listed below.
Lines without VifUnit have an empty string as Unit.
Domain Model Mapping Extention
When Using wMbus/OMS Telegrams there is a Problem: The Telegrams are self describing in a way that they describe values as "this is a Volume in m³" "this is a Date with Time" but they dont include the information about the businesses meaning if the value.
For example in the following "heat cost" device we got several H.C.A Values and 3 Date informations:
When we want to create a heating bill for tenants we need to know the meaning because we want to use a Due Date and the Value for that due Date or we want to use the actual H.C.A Value with the it is from.
The problem here is: The order and meaning of these Values differ widely. Sometimes the actual Value is the first one, sometimes the last one, Sometimes Due Date values of the last 12 months are presented in descending order sometimes in ascending order. Sometimes the date information regarding due dates are grouped next to the duedate values some times values and date information are kept in 2 blocks. So we want to archive a a way to configure the logical meaning for different devices so we can produce a general usable format containing the meter data usable by billing software.
Configures how telegrams are mapped to the Domain Model.
Example Configuration for Kampstrup MC603, a Diehl Heat Meters and a Engelman Water Meter
The Mapping contains 3 Parts:
- A comment so humans can identify the mappings.
- A filter part to select telegrams that the mapping shall be applied to. The mapping is applied if all filters match true.
- A object "heat" or "water" defining which values of the telegram shall be mapped in to which Field of a Domain Model output.
- curl Example: (With mapping from: domainMappings.json File)
- Method: POST
- Path: /api/meterData
- URL Params:
- raw: Raw OMS/WMBUS Telegram in Hex: e.g. 44442d2c0198508035048d20aac070c420dd3d967a564c53dfe4dedfbc45e8d41912db6c0973921bef3c2d5dc8d3b6fe01cc272258cd728f825a2d2e76b256fd722680
- key: decryption key as Hex String e.g. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
- Body: Type: application/json with a Mapping Configuration as described on this Page.
- Response: With Domain Data described under "Metering Domain Model" on this Page.
- Authorization: Header ("Authorization") with Bearer Token from the Platform: https://platform.lobaro.com/#/organisation/integrations/rest/
Endpoint: POST https://platform.lobaro.com/api/meterData
Metering Domain Model
Example output of a Kampstrup MC603 with the example Configuration from Mapping Configuration