Ny strømmåler - med HAN-interface

[Andreas]

Hei.

Pakkene kommer jo slik de skal, med 2,5s og 10s intervaller.

Men jeg tror det er noe i omformingen din som er feil, ikke sikker på hva..

 

Du kan ikke dumpe en fil med binær-data?

 

Andreas

[roarfred]

Har lett litt mer etter hva dette kan være for data. Protokollen er ikke M-bus, men det er mulig at det fysiske laget er det som er M-bus. Fant at det er noe som heter DLSM, og at denne har "packet-start" og "packet-end" flag som er 0x7E.

 

Et par nyttige ressurser:

• Rikt open-source bibliotek i mange språk: https://www.gurux.fi og https://github.com/Gurux
• Noe mer teknisk dokumentasjon på protokollen: http://dlms.com/documents/Excerpt_GB8.pdf

[roarfred]

8 minutes ago, Andreas said:

Hei.

Pakkene kommer jo slik de skal, med 2,5s og 10s intervaller.

Men jeg tror det er noe i omformingen din som er feil, ikke sikker på hva..

 

Du kan ikke dumpe en fil med binær-data?

 

Andreas

Er litt usikker på hva du mener. Tenker du å skrive ut en ren binærfil der hver byte har den tilhørende hex-verdien? Jeg er rimelig sikker nå på at utlesing av data er korrekt nå, men at protokollen vi må se på er DLMS/COSEM. (Standarden er for elektriske målere, den starter og slutter med 0x7E, klokkeslettet på PC stemmer ca med hex-verdiene jeg får ut etc)

[Andreas]

http://www.gurux.fi/Download

 

Kanskje dette hjelper

[roarfred]

5 hours ago, Andreas said:

http://www.gurux.fi/Download

 

Kanskje dette hjelper

Dette kan bli nyttig... Prøvde å lage en device og sette den opp mot en fiktiv TCP server, og mate ut samme data som fra måleren. (Er på jobb og har ikke måleren tilgjengelig her)

Fikk følgende ut fra loggen:

 

08:50:48 08:50:48.318    Sent    7E A0 08 02 23 21 93 BD 64 7E  ==> Dette er data sendt fra applikasjonen

(...)

08:50:47 08:50:47.819    Received    7E A0 9B 01 02 01 10 EE AE E6 E7 (...) ==> Dette er data jeg responderer

 

I det minste er dette enda en indikasjon på at vi "pisser på rett tre". (Starter og slutter med 7E, byte #2 er adresse og byte #3 angir lengde uten start og slutt-bytes)

 

[Hårek]

Er det HDLC protokoll vi ser? https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

En frame starter og slutter med 0x7e.

[roarfred]

46 minutes ago, Hårek said:

Er det HDLC protokoll vi ser? https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

En frame starter og slutter med 0x7e.

Det stemmer nok, da DLSM bygger på HDLC: https://en.wikipedia.org/wiki/IEC_62056

Det faktum at vi ser diverse OBIS referanser rundt i dokumentasjonen gjør at jeg holder en knapp på DLSM/COSEM

[roarfred]

Fant omsider et utdrag av DLSM Architecture and Protocols, og har sett at de frames jeg mottar gir en viss mening fortsatt.

 

Laget likegodt et prosjekt for dette på github, og viser inndelingen der:

https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/HAN Sample Breakdown.md

 

Skal få inn mer arduinokode og el.nikk schematics osv etter hvert. Fantastisk om noen vil bidra!

[Hårek]

Da trenger vi protokollen for innholdet i Information block. Ser ut som vi trenger DLMS Green Book? Ikke åpent tilgjengelig.

[roarfred]

16 minutes ago, Hårek said:

Da trenger vi protokollen for innholdet i Information block. Ser ut som vi trenger DLMS Green Book? Ikke åpent tilgjengelig.

Er det ikke dette som er omtalt i blue book? Finnes et utdrag her, s17 og utover: http://dlms.com/documents/archive/Excerpt_BB10.pdf

[Hårek]

"the Blue book describes the COSEM meter object model and the object identification system"

"the Green book describes the Architecture and Protocols"

BB10 kan antagelig bli nyttig, men jeg tror vi først må finne hvordan protokollen er. Leter uten å finne ...

[roarfred]

6 minutes ago, Hårek said:

"the Blue book describes the COSEM meter object model and the object identification system"

"the Green book describes the Architecture and Protocols"

BB10 kan antagelig bli nyttig, men jeg tror vi først må finne hvordan protokollen er. Leter uten å finne ...

Det var Green Book jeg fant inndelingen av selve pakken i, men ikke detaljer om selve data-blokken. Ligger en del her: http://dlms.com/documents/archive/

(BB=Blue Book, GB=Green Book osv)

 

Edit: Etter litt gjetting på Urler fant jeg de siste til å være

BB: http://dlms.com/documents/Excerpt_BB12.pdf

GB: http://dlms.com/documents/Excerpt_GB8.pdf

Endret 13. september 2017 av roarfred

[Einar]

Jeg koblet oscilloskapet til på RJ45 uttaket. Det leverer 25V stabilt. Ikke noe signal.

 

I går sendte jeg forespørsel til nettselskapet om HAN interfacet er aktivisert. Svaret var høne pøne. Det virker som det skal hos dem. <Sukk>.

Ny email til dem i dag som forhåpentligvis blir videresendt til en voksen person.

 

[Hårek]

1 hour ago, roarfred said:

Det var Green Book jeg fant inndelingen av selve pakken i, men ikke detaljer om selve data-blokken. Ligger en del her: http://dlms.com/documents/archive/

Du er god. Mye å sette seg inn i .

Kom litt videre etter en rask titt på Excerpt_GB7.pdf, side 32. Stemmer med E6 E7 00
Protocol specification for the LLC sublayer        8.3.2 LLC PDU format
more details, see complete Green Book ....

 

Men ser du har kommet enda lenger.

Endret 13. september 2017 av Hårek

[roarfred]

Oppdaterte nettopp litt på github, med så langt jeg kom i kveld... Har funnet noe data, men lite struktur i det

https://raw.githubusercontent.com/roarfred/AmsToMqttBridge/master/Samples/HAN Sample Breakdown.md

[Hårek]

Har analysert litt på filene du la ut. Alle cheksummer stemmer, og adressedata etc er fast og uforandret. 

Det ser bra ut med tanke på din tolkning av formatet av 41-byte meldingene, gyldige timestamp og effektverdiene ser troverdige ut.

Et lite problem er at monitoren (tipper du bruker HHD Software) noen ganger deler opp meldinger, men det er jo forståelig grunn til det.

Finner også at noen meldinger inneholder 0x7E mellom begin/end flag. Gjør det noe mer problematisk å dekode. Eks:

[2017-09-12 23.21.59.753 - Received 41 (0x29) bytes]
7E A0 27 01 02 01 10 5A  87 E6 E7 00 0F 40 00 00  00 09 0C 07 E1 09 0C 02
17 15 3A FF 80 00 00 02  01 06 00 00 04 1D D5 7E  7E

[roarfred]

3 hours ago, Hårek said:

Har analysert litt på filene du la ut. Alle cheksummer stemmer, og adressedata etc er fast og uforandret. 

Det ser bra ut med tanke på din tolkning av formatet av 41-byte meldingene, gyldige timestamp og effektverdiene ser troverdige ut.

Et lite problem er at monitoren (tipper du bruker HHD Software) noen ganger deler opp meldinger, men det er jo forståelig grunn til det.

Finner også at noen meldinger inneholder 0x7E mellom begin/end flag. Gjør det noe mer problematisk å dekode. Eks:

[2017-09-12 23.21.59.753 - Received 41 (0x29) bytes]
7E A0 27 01 02 01 10 5A  87 E6 E7 00 0F 40 00 00  00 09 0C 07 E1 09 0C 02
17 15 3A FF 80 00 00 02  01 06 00 00 04 1D D5 7E  7E

Rart med disse duplikate meldingene... Mulig det kan ha vært noe med spenningsnivå eller også med koden som leser data. Jeg har endret litt på kretsen og på programmet. Begge deler er lagt ut på github: https://github.com/roarfred/AmsToMqttBridge

 

Har også formatert litt bedre på analysen av dataene: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/HAN Sample Breakdown.md

Si gjerne fra om du finner mer detaljer enn dem jeg har, eller om du ser noe mer galt.

 

Sampler litt fortløpende fra måleren nå med ny krets og kode. Skal legge ut en oppdatert sample på github etterhvert

[Hårek]

Hva legger du i "duplikate meldinger"? Det er ikke dublisert 7E vi ser. Mitt problem er at jeg har valgt feil strategi for dekoding, må gjøre det om.

[roarfred]

Trodde du mente to påfølgende 7E... La uansett ut en ny fil nå, med ca. 40 minutter sampling. Du finner den under Samples/HAN 20170914.txt

[roarfred]

Da er kode/bilder for Arduino/ESP lagt til. En liten forklaring her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code

[Hårek]

Den siste filen har noen få feil, noe data har forsvunnet. Eks:

[2017-09-14 20.03.10.849 - Received 28 (0x1C) bytes]
06 00 00 07 66 06 00 00  09 E3 06 00 00 09 40 06  00 00 00 00 06 00 00 09
4A 45 18 7E

Endret 15. september 2017 av Hårek
Det var mer enn en feil

[Christian]

Da er kode/bilder for Arduino/ESP lagt til. En liten forklaring her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code

Betyr set at når man har laget en sånn kan man få ut data fra de nye strømmålerne


Sent from my iPhone using Tapatalk

[roarfred]

1 hour ago, Christian said:

 

 

Betyr set at når man har laget en sånn kan man få ut data fra de nye strømmålerne


Sent from my iPhone using Tapatalk

 

Det fungerer hos meg, dvs. jeg strømmer data inn på PC eller ESP8266 nå. Men, det betyr også at dette foreløpig er rådata, som siden må parses for å plukke ut aktuelle verdier som ønskes lest. Vi har i prinsippet funnet nok utav strukturen til å plukke ut dato/tid og øyeblikksforbruk (kW) fra meldingene som kommer hvert 2.5s, men her er ikke skrevet noe kode for dette foreløpig.

 

Det kommer også mer kompliserte meldinger hvert 10. sekund og så en enda mer detaljert en gang per døgn. Disse har jeg ikke begynt å se på ennå.

[roarfred]

3 hours ago, Hårek said:

Den siste filen har noen få feil, noe data har forsvunnet. Eks:

[2017-09-14 20.03.10.849 - Received 28 (0x1C) bytes]
06 00 00 07 66 06 00 00  09 E3 06 00 00 09 40 06  00 00 00 00 06 00 00 09
4A 45 18 7E

Godt observert! Håper det er kode hos deg som letet fram dette avviket

 

Det er mange faktorer som kan føre til feil avlesing. Hos meg går jeg med TP kabel fra måleren, via to ulike patche-paneler før jeg når fram til rommet der jeg har "labben". Samtidig er kretsen ikke spesielt godt designet. Denne skulle helt klart ha brukt en op-amp eller en annen form for schmitt-trigger. Om vi likevel klarer å lese ca. 99% av pakkene er det godt nok for en start. De pakkene som er feil kan uansett ekskluderes enkelt ved å kreve først at start/end flagg skal være til stede og deretter sjekke de to checksum-blokkene. Stemmer ikke disse er det bare å forkaste pakken.

[Hårek]

Ja, det er ikke noe å bruke tid på nå, koden min håndterer dette på en grei måte. Det er mye annet av interesse å gripe fatt i.