Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

Ny strømmåler - med HAN-interface


Anbefalte innlegg

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:

Lenke til kommentar
Del på andre sider

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)

Lenke til kommentar
Del på andre sider

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)

 

Lenke til kommentar
Del på andre sider

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

Lenke til kommentar
Del på andre sider

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!

Lenke til kommentar
Del på andre sider

"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 ...

Lenke til kommentar
Del på andre sider

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 av roarfred
Lenke til kommentar
Del på andre sider

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.

 

Lenke til kommentar
Del på andre sider

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 av Hårek
Lenke til kommentar
Del på andre sider

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

Lenke til kommentar
Del på andre sider

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

Lenke til kommentar
Del på andre sider

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 av Hårek
Det var mer enn en feil
Lenke til kommentar
Del på andre sider

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å.

Lenke til kommentar
Del på andre sider

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.

Lenke til kommentar
Del på andre sider

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.