roarfred

Hvilken leverandør har du (evt. målertype)?

Mailet litt med NVE, og fikk dette til svar. Valider ser ut til å dekke ganske store deler av landet, så det kan mulig fortsatt være noen som er interessert i dette... Edit: Valider sitt "dekningskart" finnes her: https://www.valider.no/eiere.html

Prøver å ta tilbake tråden Har kikket mer på formatet fra Kaifa måleren, har funnet ut at dette ikke er noe reelt DLSM/COSEM format, men at det følger en viss standard. Hvert andre sekund sendes følgende pakke: E6 E7 00 0F 40 00 00 00 09 0C (09=string, men egentlig en dato her, 0C=lengde, 12 bytes) 07 E1 09 12 01 14 28 36 FF 80 00 00 (Dato: 2017-09-08 01? 20:40:54 ????) 02 01 (Listeindekator, ihvertfall endrer byte # 2 seg for hver variant) 06 00 00 04 D0 (06=integer following, her: 1232W øyeblikksforbruk) Hvert 10. sekund sendes en litt mer avanset pakke: (Hver time også enda en, helt tilsvarende, men med flere entries) E6 E7 00 0F 40 00 00 00 09 0C (string following, 12 bytes, really a date/time) 07 E1 09 12 01 17 00 00 FF 80 00 00 02 0D (list number) 09 07 4B 46 4D 5F 30 30 31 (string: KFM_001) 09 10 36 39 37 30 36 33 31 34 30 31 37 35 33 39 38 35 (string: 6970631401753985, dvs. serienummeret på måleren min) 09 08 4D 41 33 30 34 48 33 45 (string: MA304H3E, dvs. modell på måleren) 06 00 00 04 DB (06 betyr integer, sannsynligvis øyeblikksforbruk) 06 00 00 00 00 06 00 00 00 00 06 00 00 01 22 06 00 00 06 99 06 00 00 0F D6 06 00 00 11 56 06 00 00 09 64 06 00 00 00 00 06 00 00 09 62 Det som faktisk er litt artig er at disse to første listene stemmer med dokumentasjonen her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/NVE_Info_kunder_HANgrensesnitt.pdf Dvs: - Det er ett element i den første listen - Elementet i den første listen er Active Power - Det er 13 elementer i liste #2 - De tre første verdiene i liste #2 er string -Resterende verdier i liste #2 er numeriske Her er dog ingen OBIS koder å spore, og det er ikke engang noen måte å detektere datatype på verdier. Håper vi i fremtiden får mer standardiserte data, men enn så lenge så får en bare bruke tabellen og indeksere datapunktene fra måleren. PS: Artig med den første string som er KFM_001. Google denne, så er eneste relevante treff dette: ...som bare gav en 404 Not Found. En bufret side gav imidlertid noe info, har lagret den under documentation med Kaifa og KFM_001 i navnet Denne infoen antyder svakt at KFM_001 er en slags indikator mot en oppslagstabell, litt som at denne skal kunne angi direkte hva det er for data som følger. Uansett, denne er ikke med i 2s listen, så det ser uansett ikke konsekvent ut.

Hmm, kom over denne nå: https://www.nve.no/stromkunde/smarte-strommalere-ams/ Sier NVE (skrevet i 2015, men oppdatert i august i år) uten så mye mer forklaring...

Hei @Marius-H! Jeg håper starten på tråden beskriver litt hva en ønsker å gjøre. Dvs. lage en generell hardware/software som en bridge mot eks. MQTT. Enkel elektronikk og ardiono kode som kan nyttes av hvem som helst. For dette prosjektet sin del er det nok mer at en ønsker å lage en løsning som tilgjengeliggjør dataene, enn at en ønsker dataene selv. (Som du kanskje har sett, så har jeg forsåvidt data fra HAN porten allerede, men vil gjerne lage en mer generell løsning) Kan forsåvidt svare på spørsmålene i rekkefølge også, som "forbruker": 1. Ønsker data for å se og analysere eget strømforbruk. 2. Svar på spørsmål som hva koster en klesvask, en dusj etc. Alarm på overforbruk grunnet en ovn som ikke var avskrudd etc. Evt. justering koblet til døgn-diffrensiert prising, men det ser jeg egentlig ikke at denne AMS måleren skal kunne hjelpe så mye med 3. Oppløsning trodde jeg nesten var bestemt, men mer og hyppigere data er bedre. Helt klart at en med høy oppløsning kunne drevet litt mønster-gjenkjenning, og detektert ulike apparater (i det minste de mest strømkrevende) 4. Se 2) og 3) 5. I prinsippet ikke viktig, men ser ikke noen fordeler med at dataene skal forlate huset for så å hentes inn igjen. Et API er fint, MQTT er bra det også, og arduino-bibliotek er helt greit. Poenget mitt er at det er viktigere med en åpen og veldokumentert standard, enn selve standarden i seg selv. (Dette prosjektet har til nå vært basert på kvalifisert gjetning, men jeg begynner etterhvert å forstå hvorfor) Har du ellers noen formening eller info om hvilke steg det egenglig er som gjenstår før det er enighet om HAN portens protokoll? Slik jeg forstår det har NEK gitt sin anbefaling til NVE sin velsignelse, tilbake i 2015... Men så sies det fra Hafslund at det ikke er enighet...

Da har jeg fått kode for tolking av DLSM (tror jeg er riktig å si, men er usikker på om det egentlig er HDLC) til å fungere fra windows og fra ESP8266. Kildekode er oppdatert i de to prosjektene her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code Arduino koden er modifisert til å kun logge ut data-innholdet (hver gang en pakke er korrekt detektert med start/stop flag og riktig crc). La inn en logg-fil fra noen minutters kjøring nå: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/ESP 20170918 Raw.txt Da er det bare å krysse fingrene for at ikke også Etne E-lag finner på at HAN porten ikke er klar for bruk og stenger den ned igjen hos meg

For ordens skyd, mye av forhistorien til denne tråden, og litt paralelle diskusjoner har gått her:

Sikkert fornuftig å ta denne diskusjonen videre på egen tråd (ble opprettet for en ukes tid siden):

Hm, jeg prøver å spore litt opp i dette. Har en forespørsel inne til mitt lokale e-lag, ang formatet/protokollen fra Kaifa måleren. Den ble videresendt til Valider... Hadde vært interessant å visst hvordan disse har laget utstyret sitt: https://www.develcoproducts.com/products/meter-interfaces/emi-norwegian-han/

Det skal stemme, men merk at motstandsverdier på inngangen sannsynligvis må justeres litt. Forholdet mellom de to bør være ca. 1:20, så jeg ville prøvd med 22k og 1k (dvs. bytt den på 2k2 med 22k). Du kan fint prøve deg frem etterpå, ved å sette 25V og 15V på inngangen. Disse skal da gi ut 0V og 5V. PS: Merk at dette ikke er helt bulletproof ettersom kretsen vil invertere signalet. Hvis så er tilfellet så kan en inn med en ekstra motstand på emitter og så ta ut spenningen over denne. Edit: I følge disse postene, så 1) Er det viktig å ha rett "Polaritet" på signalet, dvs. at det betyr noe om det er invertert eller ikke. For HAN må det derfor ikke inverteres: http://forum.arduino.cc/index.php?topic=11955.0 2) En "Idle" state på TTL er 5V. Denne er også en logisk "1": https://www.sparkfun.com/tutorials/215 Dette betyr således at en må lage en krets som er ikke-inverterende. Den helt enkleste måten er nok å legge på et ekstra inverterende trinn bakom...

ok Diodene med en vinkel på er zener-dioder. Disse fungerer likt som en diode i ene retningen, men så har de en karakteristikk som gjør at de begynner å lede på en gitt spenning i motsatt retning. Effekten er at en får et spenningsfall over, og du kan se på det som at du subtraherer en gitt spenning. Som du kanskje forstår har hver slik diode en gitt oppgitt verdi i antall volt som skal til før den leder. Mer her: https://en.wikipedia.org/wiki/Zener_diode Hvis du har betegnelsen på din transistor(er) kan jeg godt sjekke om den kan være egnet. Et alternativ kan også være den forenklede kretsen som ble postet tidligere i denne tråden. Se her: https://www.dd-wrt.com/wiki/index.php/Image:LaFonera_Hardware_Serial-Cable-Port_11_simple_schematic.jpg

Mulig det kan hjelpe å se på koblingen på bread-board? Serial.Read() vil lese en byte fra serie-porten på Arduino. Merk at porten må settes opp med 2400 baud, 8 data-bit, Even parity og 1 stop bit. (8E1) Du kan finne eksempler på kode til windows og til arduino (ESP8266) her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Code Her viser også et annet bilde av breadboard, som mulig viser bedre koblingene. Edit: Skal se om jeg får laget en skisse vha. Fritzing senere: http://fritzing.org/

Supert! Se også litt mer info i diskusjonen her: Først må du få åpnet HAN porten hos deg. Det skal din nettleverandør kunne gjøre på forespørsel. Det kunne vært interessant å målt litt på porten før den åpnes. Etter all sannsynlighet har du ca. 25V likespenning mellom pinne 1 og 2 (2 = GND, 1=signal). Etter åpning bør det strømme ut data, hvert 2. sekund. Disse dataene er modulert slik at de gir ca. 12V lavere spenning for en "0" og ca 25V for en "1". Jeg har lagt ut en skisse som fungerer (hos meg) for konvertering til 3.3V TTL nivå her: https://github.com/roarfred/AmsToMqttBridge Kommer du så langt at du får lest ut data, så ligger det noen detaljer om hva som skal være med i de tre ulike data-pakkene fra Aidon her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/NVE_Info_kunder_HANgrensesnitt.pdf Gi en lyd hvordan det går!

Forskjellen blir transistoren. Trikset blir da å få delt ned spenningen slik at 25V/15V havner på hver sin side av 0.6V, slik at en får utnyttet at transistoren kan sperre/lede. Ser jo nå at den kretsen jeg linket til også inverterer slik min aller første skisse gjorde. Er ikke 100% sikker på om det skulle ha noe å bety eller ikke. (Denne er lagt ut som et forslag til en RS232 <> TTL shifter) Men, aller best hvis noen har tilgang til litt komponenter, et oscilloscope el.l. og får koblet opp noe som fungerer for en spesifikk måler. Da kan vi dokumentere litt etter hvert, og forhåpentligvis komme fram til en krets som fungerer for alle.

Jeg tror ikke du klarer dette med et rent motstands-nettverk. Utfordringen er at du får to ulike spenninger ut av porten 25V="1" og 15V="0". Disse ønskes så konvertert til hhv. 3.3V og 0V. Problemet kommer i prinsippet av at skal du dele ned 15V til 0V, så ville også 25V bli 0V (deling med et motstandsnettverk vil alltid være linjær). Her finnes dog "litt å gå på" i CMOS logic levels, noe som betyr at en "0" har lov til å være helt oppe i 0.8V og en "1" kan være helt nede i 2V. Like fullt en utfordring, om 15V deles ned til 0.8V, så blir 25V ikke mer enn 1.33V. Men, så akkurat nå at det selvfølgelig er en enklere måte å gjøre dette på om du har 3.3V tilgjengelig. Dette vil også fungere for 5V: https://www.dd-wrt.com/wiki/index.php/Image:LaFonera_Hardware_Serial-Cable-Port_11_simple_schematic.jpg (Edit: Du trenger kun halvparten av denne siden du kun er interessert i TX -> RX)

Da har jeg laget en klasse som kan brukes for å lese datastrømmen. Denne leser en og en byte og returnerer en "true" om vi er kommet til enden på en pakke og alt av checksummer stemmer osv. Ser nokså tilgivende ut, tanken er å kunne fore denne med data fortløpende og bare behandle vellykkede pakker. (skrives litt om etterhvert til å fungere på Arduino) https://github.com/roarfred/AmsToMqttBridge/blob/master/Code/HanDebugger/HanDebugger/DlmsReader.cs Kjørte gjennom alle pakkene fra sample filen fra ESPen. Her var ingen feil, og 559 pakker ble lest og godkjent. PS: Har sendt en forespørsel til Kaifa ang innholdet som ikke har OBIS info, men er litt usikker på om dette er noe de gjør selv, eller om det er en form for programmering som nettleverandøren våres foretar seg.

Usikker på om den egner seg til dette... Har du en op-amp av noe slag, eks. TL072, LM324, xx741 el.l?

Vil tippe det går helt fint med 1uF. Skal fungere å få noe ut på arduino, men vær obs på at de komponentene som jeg har brukt gir ca. 3.3V nivå. Det passer greit på ESP, men jeg tror den vanlige Arduino vil ha 5V. Dette kan justeres med den zener-dioden på 3,9V. (Bytt den til 5,6V). Egentlig skulle denne kretsen vært bygget med en op-amp, men har ikke helt kommet til det ennå. Den jeg bruker nå er den som jeg har skisse til på github: https://github.com/roarfred/AmsToMqttBridge/blob/master/Electrical/Simple HAN to FTDI Circuit.jpg (100K motstand på toppen er byttet med 1K, i et lite håp om å kunne drifte ESP'en direkte. Det gav jeg fort opp )

Vil tippe at den ikke er aktivert da... Men som sagt, så er ulike multimetre litt ulike på målingene. Skader ikke å ta en AC måling, om den viser noe annet enn 0V er det tegn på at den er aktiv.

Artig, fant nettopp utav CRC kalkuleringen, bare for å finne ut at det hadde du også Så litt på koden din nå, ser bra ut! Merk at header ikke nødvendigvis er en fast størrelse. Hver av adresse-feltene ser ut til å kunne variere i størrelse, og de termineres ved at LSB = 1. Eksempelvis er dest address hos meg 02 01. Jeg mener også det er noe merkelige data som kommer utav Kaifa måleren. Ser du på eksempelet fra Kamstrup PDF som Andreas postet her, så viser noen lignende hex-utlistinger hvor det tydelig fremkommer OBIS koder.

Nice! Denne blir nyttig ☺ Endelig eksempler med hex kode. Stjeler dennne og legger inn under documentation på github

Der er faktisk tre ulike meldinger som kommer, men den siste bare en gang per døgn (like rundt kl. 00:00:00). Jeg har en sample av denne i filen HAN 20170912-3.txt Beskrivelse av hva som skal være med i hver av de tre meldingene ligger i NVE sin beskrivelse, her er også noen detaljer fra hver av de tre ulike målerprodusentene: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/NVE_Info_kunder_HANgrensesnitt.pdf La også opp en dump av data produsert fra ESP-koden. Denne har et enklere format, og det er tydelig å se her at 7E også kan være en gyldig verdi inne i meldingen: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/ESP 20170915.txt (må mulig lastes ned da den er litt stor. Den har data fra ca. kl. 05:06 i morges og fram til nå)

Hva skriver du i/for @Hårek? Noe som kunne vært delt?

Jeg kan evt. sende over om du ikke finner... Transistor kan gjerne være et alternativ, eks. BC547. Gi meg en lyd om du trenger noe! Denne FDTI er det jeg bruker: http://www.ebay.com/itm/5V-3-3V-FTDI-FT232RL-USB-to-TTL-Serial-Converter-Adapter-Module-For-Arduino-TL/372049356941?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D2%26asc%3D41376%26meid%3D8576059d5b204f3e8cf181a866cfbb03%26pid%3D100005%26rk%3D4%26rkt%3D6%26sd%3D230820610037&_trksid=p2047675.c100005.m1851 Begynn med å måle spenning på pin 1-2 på RJ45 kontakten med et multimeter Hos meg lå denne med en likespenning der pinne 1 gav positiv ca +27V. (Pin 2 er oppgitt som jord, men var ikke hos meg jordet mot nettets jord eller mot andre pinner på RJ kontakten) Under måling med multimeter kunne jeg ca. annenhvert sekund se at spenningen falt noen volt. Dette skyldes at pulstoget som kommer ligger ca. 12 under +27 (altså med negativ verdi på ca. +15V og positiv på +27V). Gjennomsnittverdien vil dermed ligge noe lavere mens det sendes data. Merk at ulike multimetre har ulik responstid på slikt, så det er ikke sikkert at dette er synlig overalt. Jeg tror mitt måleapparat er en Fluke12. Uansett, måler du mellom 20 og 30V på de to pinnene og ser en liten dipp hvert annet sekund, så er det sterk antydning på at porten er aktivert og at det kommer data. (Noen har nevnt at noen målere ikke har egen spenning ut, men må tilføres spenning. Synes det høres rart ut, og lurer da på om ikke målerne er kompatible, men er ikke 100% sikker)

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.