Lesing av AMS data (AMS/HAN -> IoT)

[OlavT]

25 minutes ago, Lundig said:

Jeg forsøker å hente ut data fra Aidon måler.

Bruker:  ./test_rx -x -d /dev/ttyUSB0 -P E.

 

Jeg får da følgende data ut:

 

Hvert  2 sekund:

7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01                    07 00 ff 06 00 00 17 75 02 02 0f 00 16 1b 37 01 7e
{"Date_Time":"",
"Host_Time":1548708199.172,

 

Hvert 10 sekund:

7e a1 0b 41 08 83 13 fa 7c e6 e7 00 0f 40 00 00 00 00 01 0c 02 02 09 06 01 01 00 02 81 ff 0a 0b 41 49 44 4f 4e 5f 56 30 30 30 31 02 02 09 06 00 00 60 01 00 ff 0a 10 37 33 35 39 39 39 32 38 39 30 35 38 32 32 39 37 02 02 09 06 00 00 60 01 07 ff 0a 04 36 35 32 35 02 03 09 06 01 00 01 07 00 ff 06 00 00 14 b4 02 02 0f 00 16 1b 02 03 09 06 01 00 02 07 00 ff 06 00 00 00 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 14 bb 02 02 0f 00 16 1b dd 4c 7e 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 14 ae 02 02 0f 00 16 1b b7 09 7e 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 18 43 02 02 0f 00 16 1b 02 3e 7e 7e a1 0b 41 08 83 13 fa 7c e6 e7 00 0f 40 00
{"Date_Time":"",
"Host_Time":1548708211.549,

 

Hvis jeg kobler Tibber Pulse til HAN får jeg opp forbruk.

Hvis jeg kobler fra MBUS får jeg ingen informasjon.

 

Noen som ser hvorfor jeg ikke får opp noen lesbare verdier?

 

 

 

 

Dokumentasjonen for Aidon har dette som en eksempel melding:

 

7e a0d2 41 0883 13 82d6 e6e700  
  0f 40000000 00  
  0109  
    0202 0906 0101000281ff 0a0b 4149444f4e5f5630303031  
    0202 0906 0000600100ff 0a10 37333539393932383930393431373432
    0202 0906 0000600107ff 0a04 36353135
    0203 0906 0100010700ff 06 00000552 0202 0f00 161b  
    0203 0906 0100020700ff 06 00000000 0202 0f00 161b
    0203 0906 0100030700ff 06 000003e4 0202 0f00 161d
    0203 0906 0100040700ff 06 00000000 0202 0f00 161d
    0203 0906 01001f0700ff 10 005d     0202 0fff 1621  
    0203 0906 0100200700ff 12 09c4     0202 0fff 1623
e0c4 7e

 

Noen som vet hvordan de forskjellige delene dekodes?

 

Dokumentasjone var litt kryptisk.

 

[Hårek]

Jeg holder på med dette nå. Har funnet fram til dekoding av HDLC protokollen, som er første og siste linje.

Så ser jeg OBIS koder inni der, som f.eks fjerde linje "0101000281ff 0a0b 4149444f4e5f5630303031". Det er en String på 11 bytes som sier  AIDON_V0001

Men jeg mangler sammenhengen på det OBIS kodene er 'pakket inn' i.

 

[OlavT]

22 minutes ago, OlavT said:

 

Dokumentasjonen for Aidon har dette som en eksempel melding:

 

7e a0d2 41 0883 13 82d6 e6e700  
  0f 40000000 00  
  0109  
    0202 0906 0101000281ff 0a0b 4149444f4e5f5630303031  
    0202 0906 0000600100ff 0a10 37333539393932383930393431373432
    0202 0906 0000600107ff 0a04 36353135
    0203 0906 0100010700ff 06 00000552 0202 0f00 161b  
    0203 0906 0100020700ff 06 00000000 0202 0f00 161b
    0203 0906 0100030700ff 06 000003e4 0202 0f00 161d
    0203 0906 0100040700ff 06 00000000 0202 0f00 161d
    0203 0906 01001f0700ff 10 005d     0202 0fff 1621  
    0203 0906 0100200700ff 12 09c4     0202 0fff 1623
e0c4 7e

 

Noen som vet hvordan de forskjellige delene dekodes?

 

Dokumentasjone var litt kryptisk.

 

 

Så vidt jeg kan lese Aidon dokumentasjonen så er: " 7e a0d2 41 0883 13 82d6 e6e700" starten på en HDLC frame der:

 

7e = Flag

a0d2 = Frame format

41 = Client address

0883 = Server address

13  = Control

82d6 = HCS

e6e700  = LLC

 

Men, jeg får det ikke til å matche beskrivelsen av HDLC her: https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

 

Noen som kan dette?

Endret 28. januar 2019 av OlavT

[Hårek]

Se RoarFred prosjektet: https://github.com/roarfred/AmsToMqttBridge/tree/master/Documentation
Det er dokumentert i filen Excerpt_GB8.pdf kapittel 8.4

Frame format: 2 bytes. Sier 'frame format 3' (0xA0), og 11 bit 'frame length'.
FCS siste 2 bytes før End Flag. Lokaliseres med 'frame length'.
Verifiser at checksum stemmer - regn ut checksum for alle bytes fram til FCS. Skal være lik FCS. CrC16.cs ligger i Code.
Ekstrakt data blokk, alt mellom 'Frame format' og FCS. 
De 4 feltene 'Dest.address, Src.addres, Control, og HCS' er dokumentert i 8.4.2 MAC addressing.

Adressefeltene kan ha variabel lengde. HCS checksum kan verifiseres. Ekstrakt data blokk, alt etter HCS.
Neste 3 bytes er LLC header. Dokumentert i 8.3.2 LLC PDU format.
Ekstrakt data blokk, alt etter LLC_Quality

Endret 3. februar 2019 av Hårek
Korrigert filnavn

[OlavT]

16 minutes ago, Hårek said:

Se RoarFred prosjektet: https://github.com/roarfred/AmsToMqttBridge/tree/master/Documentation
Det er dokumentert i filen Excerpt_BB12.pdf kapittel 8.4

Frame format: 2 bytes. Sier 'frame format 3' (0xA0), og 11 bit 'frame length'.
FCS siste 2 bytes før End Flag. Lokaliseres med 'frame length'.
Verifiser at checksum stemmer - regn ut checksum for alle bytes fram til FCS. Skal være lik FCS. CrC16.cs ligger i Code.
Ekstrakt data blokk, alt mellom 'Frame format' og FCS. 
De 4 feltene 'Dest.address, Src.addres, Control, og HCS' er dokumentert i 8.4.2 MAC addressing.

Adressefeltene kan ha variabel lengde. HCS checksum kan verifiseres. Ekstrakt data blokk, alt etter HCS.
Neste 3 bytes er LLC header. Dokumentert i 8.3.2 LLC PDU format.
Ekstrakt data blokk, alt etter LLC_Quality

 

Flott! Aner du hva linje 2 og 3 er?

[Hårek]

Nei, det er det jeg sliter med.

Skjønner heller ikke begynnelsen på hver linje med OBIS, eks "0202 0906"

[antonkristensen]

10 hours ago, Hårek said:

Nei, det er det jeg sliter med.

Skjønner heller ikke begynnelsen på hver linje med OBIS, eks "0202 0906"

 

0202 betyr at det er en structure(object) av 2 elementer, altså selve obis koden og så dataen...

 

om det står 0102 da betyr det en array m. 2 elementer.

[Hårek]

OK, det kan stemme med linje 3: 0109 betyr at det som føger er en struktur  array med 9 elementer.

Hvilken standard er dette?

Endret 29. januar 2019 av Hårek

[antonkristensen]

11 hours ago, OlavT said:

0109  
    0202 0906 010100028

Der kan du f.eks lese ut at det er en array m. 9 elementer (fra aidon eksempelet)

 

om du teller obis kodene da skal de stemme med antall obis koder og data med andre tallet der...

Altså etter infoen fra nve så skal det være 3 lister på aidon

en liste på 1 element begynner da med 0x01 0x01
en liste på 13 elementer 0x01 0x0d
en liste på 18 elementer 0x01 0x12

I dette eksempelet da får han ut 0x01 0x09
som da vil fortelle oss at det er en array med 9 elementer...

Jeg har kun igjen å skrape meg igjennom dette :
`

0x0F 0x40 0x00 0x00 0x00 0x00

`
Har sterk tro på at dette er en info header som ikke blir brukt, 0x0F 0x40 0x00 kan hende at er en unix timestamp, er ikke helt sikker på det enda, har ikke kommer dit enda.

Resten tror jeg er noen headere som skal si til om "billing periods" og slike ting som ikke norske leverandører er pliktige til å levere ut av han porten.
Hence the 0xFF i gruppe F på alle OBIS kodene, siden gruppe F skal egentlig si til om billing period og noe slikt. 0xFF betyr at de ikke er i bruk.

Endret 29. januar 2019 av antonkristensen

[Hårek]

Hvordan tolke linje 4?

0202 sier det er en struktur med 2 elementer. Hva er da et element?

0906 - hva er dette?

0101000281ff - dette er "OBIS code - group value". 

0a0b - det som føger er en string på 11 karakterer

4149444f4e5f5630303031 - en string som sier AIDON_V0001

[antonkristensen]

8 minutes ago, Hårek said:

Hvordan tolke linje 4?

0202 sier det er en struktur med 2 elementer. Hva er da et element?

0906 - hva er dette?

0101000281ff - dette er "OBIS code - group value". 

0a0b - det som føger er en string på 11 karakterer

4149444f4e5f5630303031 - en string som sier AIDON_V0001

 

Et element blir da bare et "Object", altså de 2 dataene henger sammen, om det hadde vært en array med 2 elementer da hadde de ikke hadd sammenheng.

 

sorry edit, leste feil;

et element er feks en obis kode, eller et dataset (selve infoen).
infoen som kommer før dataen er kun til å fortelle deg hvilken type data og lengden på dataen...

09 står for "synlig"string, 06 står for at det er 6 elementer, altså obis koden er 6 elementer, 09 er formatet,
Blir kanskje feil å kalle det synlig string... det blir da uint8

0a står altså for en octet string, altså en tekst, bokstaver (utf-->8(octet)<-).
0b står for 11, altså en string med 11 elementer.
 

Endret 29. januar 2019 av antonkristensen

[Hårek]

3 minutes ago, antonkristensen said:

09 står for "synlig"string, 06 står for at det er 6 elementer, altså obis koden er 6 elementer, 09 er formatet,

0a står altså for en octet string, altså en tekst, bokstaver (utf-->8<-).
 

Er vi på "Common data types", Blue Book 4.1.5?

Den sier motsatt.

 

[antonkristensen]

Så f.eks byte #19 vil kunne fortelle oss hvilken liste det er vi håndterer...

for aidon og kaifa vil 

 

byte #19 = 0x01 = liste1
byte #19 = 0x0d = liste2
byte #19 = 0x12 = liste3

for kamstrup er det litt annerledes.

[antonkristensen]

11 minutes ago, Hårek said:

Er vi på "Common data types", Blue Book 4.1.5?

Den sier motsatt.

 

Heh oppdaterte svaret rett før du postet, forvirret meg selv i hodet mens jeg skrev.

 

Ja sorry det stemmer, jeg mixed de opp!

Endret 29. januar 2019 av antonkristensen

[antonkristensen]

32 minutes ago, Hårek said:

OK, det kan stemme med linje 3: 0109 betyr at det som føger er en struktur med 9 elementer.

Hvilken standard er dette?

Dette er DLMS/COSEM, ser ut som nye aidon fw har følgt den helt til punkt og prikke, har ikke sett på kaifa sin, kamstrup ser det ut som de fortsatt skal kjøre sin egen modifiserte standard  så kamstrup må parses litt annerledes, de inkluderer tid i header hver gang.

Skulle gjerne ha budsjettet til å kjøpe inn bøkene for å kunne lese full standard men jeg får bare skrape meg igjennom dette på vanskelige måten...
 

[Hårek]

Dette var nyttig. Det er godt å være på sporet, etter å ha virret rundt i utallige sider dokumentasjon som ikke fører til noe.

 Prøver meg på linje 7: 0203 0906 0100010700ff 06 00000552 0202 0f00 161b

0203 betyr at det er 3 elementer. 

0906 0100010700ff er første element.

06 00000552 er andre element. 06 betyr datatype unsigned32. 00000552 er verdien.

0202 0f00 161b er tredje element. Et objekt av 2 elementer. 0f00 = ?

 

[antonkristensen]

14 minutes ago, Hårek said:

Dette var nyttig. Det er godt å være på sporet, etter å ha virret rundt i utallige sider dokumentasjon som ikke fører til noe.

 Prøver meg på linje 7: 0203 0906 0100010700ff 06 00000552 0202 0f00 161b

0203 betyr at det er 3 elementer. 

0906 0100010700ff er første element.

06 00000552 er andre element. 06 betyr datatype unsigned32. 00000552 er verdien.

0202 0f00 161b er tredje element. Et objekt av 2 elementer. 0f00 = ?

 

hehe, ja jeg brukte hele desember på å skrape meg igjennom all dokumentasjon som var mulig å finne, har i det siste funnet mye fra Saudi-Arabia, strømselskapene der er veldig dyktige på å legge ut info om standarden.

stemmer, tror at det betyr at det da skal ligge en decimal imellom de 2 siste elementene i det tredje elementet.

Endret 29. januar 2019 av antonkristensen

[antonkristensen]

26 minutes ago, Hårek said:

Dette var nyttig. Det er godt å være på sporet, etter å ha virret rundt i utallige sider dokumentasjon som ikke fører til noe.

 Prøver meg på linje 7: 0203 0906 0100010700ff 06 00000552 0202 0f00 161b

0203 betyr at det er 3 elementer. 

0906 0100010700ff er første element.

06 00000552 er andre element. 06 betyr datatype unsigned32. 00000552 er verdien.

0202 0f00 161b er tredje element. Et objekt av 2 elementer. 0f00 = ?

 

Jeg sliter fortsatt noe vanvittig med dette crc checket haha får det ikke til å stemme altså ! haha!

[Hårek]

Hva koder du i? RoarFred har lagt ut en C# implementasjon, jeg fant en i Java som jeg bruker.

 

[antonkristensen]

Just now, Hårek said:

Hva koder du i? RoarFred har lagt ut en C# implementasjon, jeg fant en i Java som jeg bruker.

 

 

javascript... ?har prøvd alle mulige crc16 check pakker og får ikke ut korrekt resultat, tror kanskje det er noe jeg ikke gjør korrekt etter at jeg har fått tilbake crc16 verdien... vet ikke helt... har ikke implimentert det enda så jeg har ikke noe til å vise frem akkurat nå.

[Hårek]

boolean frameOk = false;
int ffb1 = list1.get(0);                                // Read the two Frame Format bytes
int ffb2 = list1.get(1);
if ((ffb1 & 0xf0) == HDLC_FRAME_FORMAT3) {              // Check that we have the Frame Format field, then this is start flag
    int frameLength = ((ffb1 & 0x03) << 8) + ffb2;
    int fcsb1 = list1.get(frameLength - 2);             // Get 2-byte checksum at tail
    int fcsb2 = list1.get(frameLength - 1);
    int fcs = (fcsb1 << 8) + fcsb2;
    frameOk = checkFcs(list1, frameLength - 2, 0, fcs); // Check FCS.
    if (!frameOk) {
        System.out.println("HDLC: CRC fail");
    }
}

private boolean checkFcs(List<Integer> messageData, int length, int offset, int fcsValue) {
    int chksum = GXFCS16.countFCS16(messageData, offset, length);
    return chksum == fcsValue;
}

Her er min kode for å sjekke FCS. 

GXFCS16 på Github: https://github.com/Gurux/gurux.dlms.java/blob/master/development/src/main/java/gurux/dlms/GXFCS16.java

 

[antonkristensen]

3 minutes ago, Hårek said:

Her er min kode for å sjekke FCS. 

GXFCS16 på Github: https://github.com/Gurux/gurux.dlms.java/blob/master/development/src/main/java/gurux/dlms/GXFCS16.java

 

 

 

Kan du kort forklare stegene som må til?

Er det nok å kjøre pakken minus fcs og start end flags igjennom og da skal crc-en stemme med fcs reversed ? eller is there something more to it?

[Hårek]

Hele pakken i et buffer (list1), uten start flag. I Aidon eksemplet begynner den med a0d2.

Framelength = 210. Lengden jeg gir til utregningen er da 208.

FCS = e0c4 Det er veriden jeg får tilbake fra GXFCS16.countFCS16().

 

[antonkristensen]

2 minutes ago, Hårek said:

Hele pakken i et buffer (list1), uten start flag. I Aidon eksemplet begynner den med a0d2.

Framelength = 210. Lengden jeg gir til utregningen er da 208.

FCS = e0c4 Det er veriden jeg får tilbake fra GXFCS16.countFCS16().

 

 

OK, så 7e skal være med i den bufferen på begge endene ?

og fcs-en skal også være med i bufferen?

 

[Hårek]

7E skal ikke være med. Jeg tar heller ikke med FCS.