What is prefered way to receive EventNotifications?

By AndreasAtPowel , 5 November, 2019

Forums

Hi
We're using .NET version of Gurux and trying to do a HES implementation to receive notifications from meters (through a DCU). We looked through examples like the PushListener but it does not seem to work for EventNotifications. We received some data examples from meter manufacturer, see bottom of this message. Please advice how to use Gurux for this scenario.

Example tried code snippet which will cast an invalid cast exception in ParsePushObjects:

var replyData = new GXReplyData();
var notify = new GXReplyData();
var getDataResult = _dlmsClient.GetData(new GXByteBuffer(b), replyData, notify);
var objectArray = notify.Data.Data.ConvertAll(x => (object) x).ToArray();

switch (notify.Command)
{
case Command.EventNotification:
Log.Debug($"Received EventNotification from {_source}");
var objects = client.ParsePushObjects(new object[]{objectArray });
break;
case Command.DataNotification:
Log.Debug($"Received DataNotification from {_source}");
break;
default:
Log.Info($"Received unhandled command: {notify.Command.ToString()} from {_source}");
break;
};

Meter register event:
00 01 00 01 00 01 00 40 c2 00 00 01 00 00 60 0b 64 ff 02 02 04 19 07 e3 0a 0f 02 0d 21 2e ff 80 00 00 0a 12 37 33 35 39 39 39 32 35 34 33 30 30 30 36 31 37 30 31 0a 0c 32 35 34 33 30 30 30 36 31 37 30 31 0a 02 47 33

Event push (This i I suspect is errornous, time value misplaced):
00 01 00 07 00 01 00 1a c2 01 0c 07 e3 09 0b 03 0b 12 1e 00 80 00 00 00 01 00 00 60 0b 33 ff 02 11 01

Data push:
00 01 00 07 00 66 01 0a 0f 80 00 02 28 00 02 03 01 03 02 04 12 00 28 09 06 00 01 19 09 00 ff 0f 02 12 00 00 02 04 12 00 01 09 06 00 00 60 01 00 ff 0f 02 12 00 00 02 04 12 00 07 09 06 01 00 63 01 00 ff 0f 02 12 10 02 09 12 37 33 35 39 39 39 32 35 34 33 30 30 30 36 31 37 30 31 01 02 02 0a 09 0c 07 e3 09 0b 03 0b 00 00 00 80 00 00 11 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 02 0a 09 0c 07 e3 09 0b 03 0b 0f 00 00 80 00 00 11 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 00 2

Thanks in advance!

Hi,

Events are causing some problems because the content might be anything. There is an error in Event push message. You need to ask manufacturer to fix it.

At the moment you need to use GXDLMSTranslator to convert received message to XML.
After that you need to check what data you have received and how to handle it.

Result is something like:

Meter register event doesn't tell anything special if you don't know manufacturer and what it the content.

http://www.gurux.fi/GuruxDLMSTranslator?translate=0001000100010040c2000…

BR,

Mikko

The issue here isn't really

The issue here isn't really the meter register event, instead its the event push message. In the message above we first thought there was an error in the message. I wrote a support request bwhere I explained more about this but I see you removed this. The problem here is that manufacturer put in a flag byte after the C2 byte to indicate wether there are a time tag or not, then in next byte they put lenth of time tag string. Your parser, when calling client.parseReport hecks first byte after C2 byte if this byte==0 not itme tag, if byte > 0 then you assume byte tells size of time tag string. Manufacturer claims this is wrong according to IEC 61334-6-2000.

Message from manufacturer:
@Björn there had description about optional for A-XDR in IEC 61334-6-2000(chapter 6.8 OPTIONAL and DEFAULT components)
6.8 OPTIONAL and DEFAULT components
Any ASN.1 composite type may contain components referenced with the ASN.1 keywords
OPTIONAL or DEFAULT. In the ASN.1 specification, these keywords can be placed after a
component type, and convey a quite intuitive meaning. Components marked OPTIONAL may
be omitted – the component value is not always present in the encoding. (The circumstances
and the significance of the actual omission of these components should be specified by the
designer.)
One reason for making a component optional is to allow it to be omitted when it assumes a
particular value – normally that which occurs most frequently. By this means, the explicit
sending of that value can be avoided. The ASN.1 DEFAULT keyword designates such a default
value for a component.
Note that declaring a component to be OPTIONAL and declaring a DEFAULT value for it are in
general very different (they are mutually exclusive in ASN.1). While OPTIONAL components
can be completely omitted, DEFAULT components are, in fact, always present, because even
their omission is pressed into service to represent a specific value.
A-XDR encoding of an OPTIONAL or DEFAULT component begins with the encoded value of
an additional element (additional to the ASN.1 syntax, which does not specify this element),
called usage flag. This usage flag is typed BOOLEAN; its value indicates whether the value of
the OPTIONAL or DEFAULT component is present in the encoding or not, as follows:
• for OPTIONAL components:
usage flag = TRUE The component is present in the encoding
usage flag = FALSE The component is not present in the encoding

If I convert above message

If I convert above message like (remove the flag tag, your parser parses it just fine):
00 01 00 07 00 01 00 19 c2 0c 07 e3 09 0b 03 0b 12 1e 00 80 00 00 00 01 00 00 60 0b 33 ff 02 11 01

Hi,

I checked this from the standard and it's defined there as the manufacturer says. This is fixed and tests are on progress. We are releasing a new version from this latest on Monday.

BR,

Mikko