The Lobaro wMbus Parser is used from device Parsers and available as web API at https://platform.lobaro.com/#/wmbus/parser
The following is an example of the parsing result of an encrypted example telegram from the OMS specification:
|
| Field | Description |
|---|---|
IsEncrypted | true if the parsed telegram is still encrypted |
| DecryptionFailed | 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. |
| IsEncrypted | DecryptionFailed | Meaning |
|---|---|---|
| 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 |
There are a many valid combinations of VifUnit & VifQuantity. All possible values are listed below.
Lines without VifUnit have an empty string as Unit.
|
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
{
"mappings":[
{
"comment":"Kampstrup MC603",
"filter":{
"formatSignature":"7869",
"manafacture":"KAM",
"type":"04",
"version":53
},
"heat":{
"currentValueIdx":0,
"flowTemperatureIdx": 5,
"returnTemperatureIdx": 6,
"volumeIdx": 3
}
},
{
"comment":"Diehl Heat Meter",
"filter":{
"formatSignature":"9290",
"manafacture":"DME",
"type":"04",
"version":65
},
"heat":{
"currentValueIdx":0,
"dueDateValueIdx":7,
"dueDateDateIdx":8
}
},
{
"comment":"Engelmann Water Meter",
"filter":{
"formatSignature":"052D",
"manafacture":"EFE",
"type":"07",
"version":0
},
"water":{
"currentValueIdx":19,
"currentDateIdx":18,
"dueDateValueIdx":1,
"dueDateDateIdx":0
}
}
]
} |
The Mapping contains 3 Parts:
Endpoint: POST https://platform.lobaro.com/api/meterData
curl -X 'POST' \ 'https://platform.lobaro.com/api/meterData?raw=44442d2c0198508035048d20aac070c420dd3d967a564c53dfe4dedfbc45e8d41912db6c0973921bef3c2d5dc8d3b6fe01cc272258cd728f825a2d2e76b256fd722680&key=7ADA08C8C89C7D21EAEE6F662BF0A6ED' \ -H 'accept: \ application/json' -H 'Authorization: Bearer eyJh[...]' -H "Content-Type: application/json" -d @domainMappings.json |
Example output of a Kampstrup MC603 with the example Configuration from Mapping Configuration
{
"id": "KAM80509801532022-01-24T14:55:50+01:00",
"type": "HeatMeterReading",
"meterId": "80509801",
"linkLayerId": "80509801",
"meterType": 4,
"manufacturer": "KAM",
"manufacturerLinkLayer": "KAM",
"version": 53,
"versionLinkLayer": 0,
"currentValue": {
"date": "2022-01-24T14:55:50.171063+01:00",
"value": 0,
"unit": "Wh"
},
"flowTemperature": {
"date": "2022-01-24T14:55:50.171063+01:00",
"value": 24.08,
"unit": "°C"
},
"returnTemperature": {
"date": "2022-01-24T14:55:50.171063+01:00",
"value": 23.96,
"unit": "°C"
},
"volume": {
"date": "2022-01-24T14:55:50.171063+01:00",
"value": 0,
"unit": "m^3"
}
} |