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

[antonkristensen]

22 minutes ago, Hårek said:

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

 

Hvordan blir lengden til utregningen 208 hvis du dropper frame type og size + fcs?


skal jeg ta med frame typ og fcs?

 

[Hårek]

Ikke droppe frame type. Du begynner første byte etter Flag.

Lengden er gitt av byte 2, 0xD2 = 210. Det er inkludert FCS.

[antonkristensen]

43 minutes ago, Hårek said:

Ikke droppe frame type. Du begynner første byte etter Flag.

Lengden er gitt av byte 2, 0xD2 = 210. Det er inkludert FCS.

 

Er denne checken ikke det samme som crc?
Driver jeg og slår meg i hodet med en pinne?

Har kjørt dette i crc16 checktool... ser veldig lik algorithme når man ser på koden, men får ikke ut korrekt info, blir snart kokos i hoder ?

[Tortho]

Siste fra skagerak nett for oss som er i den regionen:

"

 

Det er bare å beklage men når har vi tekniske problemer fra vår leverandør som gjør at vi ikke får åpnet HAN-port nå i januar som vi først ble forespeilet. Ny info er tidligst i slutten av 1. kvartal. Jeg har satt deg på en liste så du blir kontaktet når alt er i orden.

"

[Hårek]

7 minutes ago, antonkristensen said:

Er denne checken ikke det samme som crc?

Det er en 16-bit CRC. Men det finnes visst mange algorimer for dette. https://stackoverflow.com/questions/45795958/javascript-crc16-sample-code-or-implementation

Har ikke så mye peiling på detaljene, var heldig og fant ferdiglagd kode i Java.

[frodegill]

7 minutes ago, Hårek said:

Det er en 16-bit CRC. Men det finnes visst mange algorimer for dette. https://stackoverflow.com/questions/45795958/javascript-crc16-sample-code-or-implementation

Har ikke så mye peiling på detaljene, var heldig og fant ferdiglagd kode i Java.

 

Mener det var XMODEM vi fant ut ble brukt. Du kan dytte inn dump på https://crccalc.com/ og sammenlikne resultatene.

[antonkristensen]

17 minutes ago, frodegill said:

 

Mener det var XMODEM vi fant ut ble brukt. Du kan dytte inn dump på https://crccalc.com/ og sammenlikne resultatene.

 

Stemte med CRC-16/X-25 for aidon pakken

[Hårek]

Det er den som kommer nærmest, men byttet endian. Får 0xC4E0 istedet for 0xe0c4.

 

[antonkristensen]

1 minute ago, Hårek said:

Det er den som kommer nærmest, men byttet endian. Får 0xC4E0 istedet for 0xe0c4.

 

vil det si at jeg må flippe hele pakken ? ugh, er ikke så flink med bits n' shit

[Hårek]

Aner ikke hvorfor det blir slik. Og JS kan jeg fint lite av. Men hjelper denne? https://stackoverflow.com/questions/5320439/how-do-i-swap-endian-ness-byte-order-of-a-variable-in-javascript

 

[antonkristensen]

20 minutes ago, Hårek said:

Aner ikke hvorfor det blir slik. Og JS kan jeg fint lite av. Men hjelper denne? https://stackoverflow.com/questions/5320439/how-do-i-swap-endian-ness-byte-order-of-a-variable-in-javascript

 

Denne hjelpet, dette ble løst med en funksjon jeg fant en plass og crc check er på plads ? 

[antonkristensen]

Forresten, er det noen her som har nyere kaifa demo pakker til å dele ?, både fra liste 1,2 og 3

[HWal]

Er litt usikker på hva du ønsker, er det telegrammene fra Kaifa på hex-form?

[antonkristensen]

Just now, HWal said:

Er litt usikker på hva du ønsker, er det telegrammene fra Kaifa på hex-form?

 

Stemmer

[HWal]

Hei igjen,

Her er messages fra siste timeskift.

Først Liste3, så 4 x Liste1, så Liste2. 

Meteret mitt er Kaifa MA304H3E 3-fase.

 

CoolTerm Capture 2019-01-29 20-00-10.txt

[tronde]

Kom over en del EN-62056 standarder. 

NEK referer til 62056-1-0:2015. Den er der. 

62056-7-5:2016 som de også referer til er ikke der, men det er en del andre som kanskje sier noe fornuftig.

 

Jeg legger det på volafile som sletter automatisk etter 48 timer. Tror ikke det er så smart å ha dem liggende permanent på forumet.

 

https://volafile.org/r/tt6b75tm

[antonkristensen]

On 29/01/2019 at 10:31, 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 = ?

 

Har du skjønt deg helt på datapakkene? jeg tror jeg har knekket koden, send meg pm om du ønsker mere info ;D

[Hårek]

Har jobbet med OpenMUC jDLMS, Java implementation of the DLMS/COSEM protocol. Trodde det var en god mulighet til å bruke ferdig kode. Men det er 360 filer med veldig lite dokumentasjon, og ikke spesielt godt strukturert. Prøvde å kjøre HDLC frame dekoderen der, men den feiler få LLC Control byte, som er 0x13 på våre data. De vil dekode en FrameType som ikke er definert.

Nå har jeg masse lesestoff som tronde var så vennlig å legge ut, skal jobbe meg gjennom det først.

 

Edit: kom et langt stykke videre med OpenMUC jDLMS. Fant en klasse som kan dekode det meste av innholdet, rekursivt. Nå må jeg prøve å finne ut hvordan det fungerer.

Endret 31. januar 2019 av Hårek

[OlavT]

On 28/01/2019 at 22:51, 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'.

 

Ser ikke noe kapittel 8.4 i den dokumentasjonen. Siste kapittel er 7 så vidt jeg kunne se.

[OlavT]

Noen som har noe kode for å håndtere HDLC "bit-stuffing" av data, slik at data konverteres tilbake på rett måte?

[Hårek]

20 hours ago, OlavT said:

 

Ser ikke noe kapittel 8.4 i den dokumentasjonen. Siste kapittel er 7 så vidt jeg kunne se.

Sorry, feil bok. Det skulle vært Excerpt_GB8.pdf. 

 

Har Java kode som fungerer så langt, men var ikke oppmerksom på at "bit-stuffing" kan forekomme. Noe jeg må se på.

[OlavT]

Har du noe Java kode å dele til inspirasjon? Jeg  tror jeg har skjønt det meste av meldingene nå, men  sliter litt med gode navn på de forskjellige delene.

 

Har kalt hele meldingene som starter og slutter med 0x7e for HDLCFrame. Meldingen som trekkes ut fra HDLCFrame har jeg kalt AidonAPDU (ikke veldig bra navn). Deretter er jeg usikker på terminologien. For eksempel navn på meldingen som starter med 0109 og som innholder 9 meldinger der hver av de 9 meldingene igjen inneholder x elementer.

 

Har du noen bra navn her?

[antonkristensen]

10 hours ago, OlavT said:

Har du noe Java kode å dele til inspirasjon? Jeg  tror jeg har skjønt det meste av meldingene nå, men  sliter litt med gode navn på de forskjellige delene.

 

Har kalt hele meldingene som starter og slutter med 0x7e for HDLCFrame. Meldingen som trekkes ut fra HDLCFrame har jeg kalt AidonAPDU (ikke veldig bra navn). Deretter er jeg usikker på terminologien. For eksempel navn på meldingen som starter med 0109 og som innholder 9 meldinger der hver av de 9 meldingene igjen inneholder x elementer.

 

Har du noen bra navn her?

DLMS/COSEM ?

[OlavT]

Er nesten i mål med rekursiv parsing av Cosem objektene, men sliter litt med å se hvordan 3. elementet i denne linjen skal tolkes (fra Aidon dok., eksempel på melding linje 7:

 

0203 0906 0100010700ff 06 00000552 0202 0f00 161b

 

"0203" = Structure med 3 elementer

    1. element: "0906" = Octet string lengde 6: "0100010700ff"  = OBIS kode

    2. element:  "06" = Double long unsigned: "00000552" = verdien

    3. element "0202" = Structure med 2 elementer? Men, skal det tolkes som "0f" = integer byte og "00" = verdien? og deretter "16" = enum og "1b" = verdien?

 

I Aidon eksempelet er "0f00" og "161b" gruppert sammen. Det får meg til å tro at de ikke skal tolkes som "0f 00" og "16 1b", men på en annen måte.

 

Noen som har knekt denne?

[antonkristensen]

2 minutes ago, OlavT said:

Er nesten i mål med rekursiv parsing av Cosem objektene, men sliter litt med å se hvordan 3. elementet i denne linjen skal tolkes (fra Aidon dok., eksempel på melding linje 7:

 

0203 0906 0100010700ff 06 00000552 0202 0f00 161b

 

"0203" = Structure med 3 elementer

    1. element: "0906" = Octet string lengde 6: "0100010700ff"  = OBIS kode

    2. element:  "06" = Double long unsigned: "00000552" = verdien

    3. element "0202" = Structure med 2 elementer? Men, skal det tolkes som "0f" = integer byte og "00" = verdien? og deretter "16" = enum og "1b" = verdien?

 

I Aidon eksempelet er "0f00" og "161b" gruppert sammen. Det får meg til å tro at de ikke skal tolkes som "0f 00" og "16 1b", men på en annen måte.

 

Noen som har knekt denne?

Ja...

0f står for integer8 00 blir da 0

16 står for enum og 1b blir da W(Active power)