roarfred

Det kan jo mulig hjelpe å legge ved (eller referere) til dette brevet: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/NVE_Info_kunder_HANgrensesnitt.pdf (Min eneste erfaring er min egen leverandør som ikke stilte et eneste spørsmål, men hadde åpnet porten neste dag)

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

Hvis noen har Aidon eller Kamstrup måler, så er jeg svært interessert i å få ut test-data fra disse. Kan gjerne assistere med måling, elektronikk etc...

Begynner såvidt å ta litt form. Har fått til å lese dataene nå fra ESP'en, så da gjenstår egentlig bare å sy sammen mye av det en har gjort før for å parse ut de aktuelle verdier og poste dem til valgt MQTT: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code

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

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

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

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

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

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

Opprettet prosjekt på GitHub: https://github.com/roarfred/AmsToMqttBridge Foreløpig brukt mest tid på å finne utav protokollen, men har laget en enkel krets som jeg får data inn på PC via en FTDI med.

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!

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

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)

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)

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

114 kWh nå på displayet, siste 2,5s pakke ser slik ut: (Trodde kanskje en skulle funnet 72 her et sted da, men nei...) [2017-09-13 01.32.07.851 - 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 0D 02 01 20 06 FF 80 00 00 02 01 06 00 00 05 23 C1 24 7E Siste 10s-pakke ser slik ut: [2017-09-13 01.33.21.853 - Received 123 (0x7B) bytes] 7E A0 79 01 02 01 10 80 93 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 0D 02 01 21 14 FF 80 00 00 02 0D 09 07 4B 46 4D 5F 30 30 31 09 10 36 39 37 30 36 33 31 34 30 31 37 35 33 39 38 35 09 08 4D 41 33 30 34 48 33 45 06 00 00 05 5A 06 00 00 00 00 06 00 00 00 00 06 00 00 00 78 06 00 00 07 F6 06 00 00 11 A2 06 00 00 12 C1 06 00 00 09 67 06 00 00 00 00 06 00 00 09 64 69 8F 7E

Litt videre progress. Har konkludert med: Det var riktig å invertere signalet Riktig serie-parametre er 2400 baud, even parity, 8 data bit, 1 stop bit Følgende endringer er gjort i kretsen: Ekstra transistortrinn, identisk med eksisterende, med 1k motstand mellom En motstand på 100k inn på 1N4148 dioden, for å unngå å belaste m-bus'en Litt "evidens" i vedlagt fil. I denne er hver mottatte data-pakke listet for seg, og en overskrift viser nøyaktig tidspunkt og antall mottatte bytes. Om en ser nøye etter, så kan en se: Tredje byte viser antall bytes i pakken (minus to) De små pakkene kommer hvert 2. sekund De tre bytene 25-27 ser ut til å være klokkeslett (første tre bytes på linje 2) De fire bytene 37-40 i de små pakkene varierer litt opp og ned, og er sannsynligvis øyeblikksforbruk Jeg får fortsatt ikke dette til å stemme med M-Bus. Kanskje noen kjenner igjen formatet, eller ser noe jeg ikke ser? HAN 20170912-2.txt Edit: Nå kom en sånn times-pakke. Ligger ved som -3. Ser ut til å stemme med alt ovenfor HAN 20170912-3.txt

I følge reglene fra NVE skal nettleverandøren aktivere HAN på forespørsel fra sluttbruker. Det sies også at det skal være deaktivert pr. default. Jeg sendte en e-post, så fikset de det kjapt

Snudde den nå. Fikk andre verdier, men fortsatt my 3F og lite som minner om m-bus. Vet vi noe sikkert om baud rate, paritet osv?

Kom de opp igjen nå?

Mulig problemet kan være at jeg inverterer pulsen. Tenkte det var naturlig ettersom den normalt ligger på +27V og så faller i pulstoget til ca +15V, men er litt usikker...

Gjorde nettopp dette, og fant ca 500us som korteste puls. Skulle ikke være så langt unna 2400 baud

Kan se ut som det er noe galt et sted (eller flere steder...) Hex-kodene som kommer inn stemmer ikke med M-Bus protokollen. Jeg bruker 2400 baud, even parity, 8 data bit og 1 stop bit. Har også forsøkt diverse andre kombinasjoner, uten å få til denne 68 NN NN 68 kombinasjonen. Eksperimenterer litt videre...

Her er tekst-fil fra kjøring ca. 10-15 min. Ettersom data kommer kontinuerlig, så ikke heng deg opp i første byte her. (Jeg kan ha startet midt i et telegram) PS: Mulig også feil i lesing her. Mener at et telegram skal starte med 68 nn nn 68, der nn er antall bytes i datagrammet... Skal sjekke litt nærmere i spec'en til M-Bus HAN 20170912.txt