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

[Einar]

Ja, du har rett i at det blir litt fikling for å treffe rette spenninger. Og det man kommer frem til vil ikke nødvendigvis funke for et annet FTDI interface.

Men den kretsen du peker til vil jo ha omtrent samme problemet. Ialfall om man bruker de komponentverdiene som er angitt.

 

Akkurat nå har jeg ikke tid til å mekke interface, men når jeg får aktivisert interfacet vil nok prioriteten heves.

Komparatorer har jeg i skuffen, og resten bør da være enkelt.

[roarfred]

4 minutes ago, Einar said:

Ja, du har rett i at det blir litt fikling for å treffe rette spenninger. Og det man kommer frem til vil ikke nødvendigvis funke for et annet FTDI interface.

Men den kretsen du peker til vil jo ha omtrent samme problemet. Ialfall om man bruker de komponentverdiene som er angitt.

 

Akkurat nå har jeg ikke tid til å mekke interface, men når jeg får aktivisert interfacet vil nok prioriteten heves.

Komparatorer har jeg i skuffen, og resten bør da være enkelt.

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.

[Gjelsvik]

On 15.9.2017 at 10:01, roarfred said:

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

Har Aidon fra Hafslund.

 

Har også div nodeMCU, Arduino og et lass med div komponenter. 

[roarfred]

4 minutes ago, Gjelsvik said:

Har Aidon fra Hafslund.

 

Har også div nodeMCU, Arduino og et lass med div komponenter. 

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!

[Gjelsvik]

Ikke sikker på om jeg skjønner alle tegnene på tegningen din.

Kunne du satt opp en liste, så skal jeg se om jeg har det jeg trenger?

Basicly slik?  HAN#2 til GND og HAN#1 pin RX, (etter at spenningen er dratt ned) 

Er det da vanlig Serial.Read() man kan bruke mot en pinne på f.eks arduino?

 

 

 

[roarfred]

17 minutes ago, Gjelsvik said:

Ikke sikker på om jeg skjønner alle tegnene på tegningen din.

Kunne du satt opp en liste, så skal jeg se om jeg har det jeg trenger?

Basicly slik?  HAN#2 til GND og HAN#1 pin RX, (etter at spenningen er dratt ned) 

Er det da vanlig Serial.Read() man kan bruke mot en pinne på f.eks arduino?

 

 

 

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/

Endret 18. september 2017 av roarfred

[Gjelsvik]

Jo har sett på de tegningene, koblingene går hetl fint, det er noen av komponentene jeg ikke er helt med på.. F.eks de diodene du har merket med 12V og 3.9V som har en "vinkel" på den rette streken, det er nytt for meg.

 

Jeg har noen npn transistorer fra tidligere prosjekter, men de er ikke nøyaktig samme (bc337)

 

[Christoffer]

2 hours ago, Moskus said:

Det er slik det skal være, de er pålagt det av NVE.

 

Som du sier er problemet å få snakket med noe som faktisk forstår hva du spør etter. Jeg gruer meg til jeg skal ta denne debatten med Lyse...  

Du får ikke hjelp av Lyse.

Du må snakke med Lyse Elnett på 51908079

[roarfred]

16 minutes ago, Gjelsvik said:

Jo har sett på de tegningene, koblingene går hetl fint, det er noen av komponentene jeg ikke er helt med på.. F.eks de diodene du har merket med 12V og 3.9V som har en "vinkel" på den rette streken, det er nytt for meg.

 

Jeg har noen npn transistorer fra tidligere prosjekter, men de er ikke nøyaktig samme (bc337)

 

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

 

[Gjelsvik]

Skal se om jeg finner ut hva som står på de.

 

Den forenkla kretsen så jo en del enklere ut ja.

Det er vel bare den øverste der vi trenger? Kjører ikke toveis.kom mot HAN?

 

Så, dette er alt man trenger?

 

2x 1k ohm motstand

1x 2k2 ohm motstand.

1x NPN 2n2222

 

Ikke noen kondensatorer eller zenerdioder?

 

 

[roarfred]

1 hour ago, Gjelsvik said:

Skal se om jeg finner ut hva som står på de.

 

Den forenkla kretsen så jo en del enklere ut ja.

Det er vel bare den øverste der vi trenger? Kjører ikke toveis.kom mot HAN?

 

Så, dette er alt man trenger?

 

2x 1k ohm motstand

1x 2k2 ohm motstand.

1x NPN 2n2222

 

Ikke noen kondensatorer eller zenerdioder?

 

 

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

Endret 18. september 2017 av roarfred

[Gjelsvik]

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

Quote

Hei!

HAN-kontakten (RJ45-kontakt) inneholder foreløpig ikke noen forbruksdata, men vil bli forsynt med forbruksdata så snart myndigheten har bestemt seg for en standard protokoll, anslått til 3. kvartal 2018. Kunder som ønsker data strømmet over målerens HAN-kontakt (RJ45-kontakt) må ta kontakt med oss for å få dette slått på, men først etter 3.kvartal 2018.   
Utstyr som skal installeres via HAN-kontakten, leveres av tredjepartleverandører, og ikke direkte fra Hafslund Nett, men ikke før i 3. kvartal 2018.

Ta gjerne kontakt dersom du har flere spørsmål.


Ha en fin dag!

Med vennlig hilsen
Hafslund Nett AS

 

[xibriz]

20 minutter siden, Gjelsvik skrev:

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

 

 

Du får bare vise til dette dokumentet: https://www.nve.no/Media/4307/201603186-1-informasjon-til-kundene-via-han-grensesnittet-i-ams-måleren-obis-koder-1772408_1124902_0.pdf

 

Står klart M-Bus som protokoll.

[Gjelsvik]

Ja, men det er vel bare et infoskriv, ikke et endelig vedtak?

[roarfred]

1 hour ago, Gjelsvik said:

Fikk svar fra Hafslund nå, om at de ikke vil aktivere HAN før senest tredje kvartal 2018, dette fordi myndighetene ikke har bestemt seg for protokoll(?)

 

 

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/

[roarfred]

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

 

[roarfred]

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  

[Einar]

Om det ikke er HDLC så er det tvillingbroren. HDLC må ikke være synkron selv om den ofte er det.

Hvis grunnen til at du spekulerer på det er om du kan gjenbruke HDLC kode du finner på nettet så kan du nok det. Async/sync forskjellen ligger i L1, mens det vi er interessert i er L2. UART dekoder L1 for oss helt automagisk så protokolldekodingen ikke ser forskjell.

 

Om interfacet er åpent hos deg så skal du bare la bjørnen sove. Som tidligere nevnt skal den ikke være åpen før du spør om det. Og iflg. netteier her så skal det skje skriftlig.

[Marius-H]

Hei alle!

Disclaimer. Jeg jobber i Hafslund marked, som nå er en del av Fortum! (Strømselskapet, IKKE nettselskapet Hafslund nett)

 

Vi er nå i undersøkelsesporet i forbindelse med et potensielt testprosjekt som går på bruk av akkurat disse dataene. Som personlig hjemmeautomasjonsnerd, er jeg superinteressert i få dette til å fungere, og la folk fritt få bruke dataene til hva man ønsker selv. For å kunne på en enkel og effektiv måte bistå, er jeg veldig nyskjerrig å vite hva slags ambisjoner folk har i forbindelse med dataene.  Som eksempelvis:

1. Hvorfor ønsker man dataene?

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

 

Under følger et par lenker (som kanskje også har vært lenket til i den tidligere tråden).

 

https://www.hafslundnett.no/kunde/veiledning/15554

https://www.aidon.com/nb/aktuelt/beyond-metering-nyhetsbrev/nyhetsbrev-februar-2015/spesifisering-av-ams-maleres-han-port-grensesnitt-a3-foreligger-na-i-form-av-nek-rapport/

 

Dersom vi får noe interesse rundt dette prosjektet vil det være noe vi vil forsøke å få gjennomført så raskt som mulig. En mulig løsning vil være gjennom HAN interfacet. En annen løsning vil være typisk NILM måling med etterjustering etter faktiske målerdata. Målerene sender allerede timesmålinger til nettselskapene, men etter meg bekjent så deles ikke disse med kundene.

 

Til slutt så bare svarer jeg personlig på spørsmålene over.

 

1. Jeg vil ha dataene fordi jeg vil gjøre hva jeg vil med de. Først og fremst er det noe jeg mangler en god løsning på i min eksisterende løsning. Bruker openenergymeeter inntil videre.

2. Jeg er nyskjerrig på om jeg greier å spare penger dersom jeg hadde blitt fakturert etter timesforbruk. Som ved å kun varme opp varmtvannstanken på natta når strømmen er billig.

3. Jo høyere jo bedre, alltid.

4. Samme som nr 2. Men i tillegg kunne jeg justert kanskje andre type enheter/løsninger etter strømpris og evt forbruk.

5. Kunne tenke meg tilgang til dataene direkte via et API, og kanskje noe ferdigløsninger som er enkle og bruke for basic funksjonalitet.

 

 

[Einar]

Dette tror jeg er verd en ny tråd. Men jeg sluker den her med søkke og snøre.

1. Hvorfor ønsker man dataene?

Hvis jeg ser bort fra nerdefaktoren så er det fordi jeg regner med at effektledd er like rundt hjørnet også for oss som ikke har det allerede.

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

Øker muligheten til å tilpasse forbruket for i størst mulig grad jevne ut forbrukstoppene. Det er vel det de håper på, de som innfører dette? Selv om det bare er et "kjøkkenwattmeter" så vil man kunne bruke det som feedback på om de brytere man skrur på og tidspunktene man gjør det, er fornuftige.

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

En dekade bedre enn oppløsningen i effektledd beregningen.

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

Tilpasse forbruk som jeg like gjerne kan flytte i tid. Elbilen lader jeg om natta, og romtemperatur kan jeg senke om natta. VVB kan jeg styre med en dings. Men i en styringssløyfe er dette bare pådrag. Først når man har en feedback kan man få til en reell styring. Styring basert på antagelser blir aldri bedre enn man er til å gjette.

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

Et åpent API. Jeg liker å ha muligheten til å putte fingern i sausen og smake. Uansett vil det bli laget plugin e.l. til systemene om API og hardware er åpent. Men nettselskapene bør gjeninnføre kjøkkenwattmeteret i en eller annen form om dere skal nå flere brukere. Husautomatisering er i dag et nisjemarked.

 

Ehh... Er min input veldig lik din kanskje?

[roarfred]

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

 

 

 

[roarfred]

Hmm, kom over denne nå: https://www.nve.no/stromkunde/smarte-strommalere-ams/

 

Quote

HAN-porten vil trolig ikke kunne tas i bruk før i løpet av 2018.

 

Sier NVE (skrevet i 2015, men oppdatert i august i år) uten så mye mer forklaring...

[xibriz]

6 timer siden, roarfred skrev:

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

 

Jeg vil anta at det er fordi firmwaren på enkelte målere ikke støtter dette enda og det tar lang til å få dette på plass.

[Moskus]

10 timer siden, Marius-H skrev:

1. Hvorfor ønsker man dataene?

Dette er vel kanskje det mest innlysende. For å følge med på sitt eget forbruk, og å styre huset etter.

Jo mer data, jo smartere hus kan man ha.

 

10 timer siden, Marius-H skrev:

2. Hva slags fordeler eller problemer ville man løst dersom man hadde hatt tilgang til de?

Ikke skriv "dersom", skriv" når".

Jeg ville sluppet en ekstern avleser (siden jeg leser av forbruket allerede), og den nye måleren vil sannsynligvis ha mindre feilkilder (forhåpentligvis), samt avlesing av effektledd (som nevnt av andre).

 

10 timer siden, Marius-H skrev:

3. Hva slags oppløsning bør dataene være i? Type timesverdier, sekundverdier osv.

Hvor mange kan vi få? Hvis kun én, så er det lavest mulig oppløsning som gjelder, så kan det eksterne systemet ta seg av matematikken.

 

10 timer siden, Marius-H skrev:

4. Hvilke muligheter ville kunne det åpnet seg dersom man har tilgang til dataene?

Alene er det ikke så spennende. Men når man vet hvordan forbruket sitt er, kan man bruke historiske forbruksdata og den sannsynlige strømprisen de neste 5, 12 eller 24 timer til å vurdere når det er billigst å gjøre enkelte ting.

 

Klesvask er nevnt, men å vaske klær eller kjøre tørketrommel om natta anbefales selvfølgelig ikke på grunn av brannfaren.

 

 

10 timer siden, Marius-H skrev:

5. Hvis du skulle hatt tilgang til dataene, ville man hatt det via API som man leker med selv, API til favoritt hjemmeautomasjonssystem (eks Telldus), eller som en IOT device? Osv osv.

Det er avhengig av hvor enkelt du kan gjøre det. Personlig ønsker jeg meg en dings som du kobler i M-BUS-porten og som spyr ut ferdig tygde data enten via f.eks Z-wave (som stort sett alle seriøse hjemmeautomasjonssystemer støtter) eller via HTTP eller MQTT. Det er allerede nok av APIer som må settes opp for å få jobben gjort. Jeg vil ha det enklest mulig.

 

Vi vil tross alt gjøre dette tilgjengelig for folk flest, det er jo det hele AMS-innføringen går på: Fordele strømforbruket.

Man får jo egentlig ingen gevinst med AMS hvis folk ikke bruker systemet, og det kommer ikke folk til å gjøre automatisk.

 

Altså trenger de så smått litt hjemmeautomasjon. Og da handler det ikke om å skrive en halv kilometer kode for å få det inn i systemet, da skal det helst være plug'n'play.

 

 

[Hårek]

1: For å ha best mulig oversikt på strømforbruket over tid. Jeg har allerede logget mitt forbruk siden 2008, via puls utgangen.
Vokste opp med kjøkkenwattmeter. Det savner jeg, har derfor laget mitt eget. 

2: Jeg vil ha god oversikt over hva som bruker strøm og når. Kan f.eks sjekke at termostatene fungerer, noe de ikke alltid gjør.

3: Har nå display av effekt for hver puls, og lagrer snitt hvert minutt. 2-sekunder intervall som foreslått er helt OK.

4: Forbedring av eksisterende system, telling av pulser er ikke er helt nøyaktig.

5: Vil ha direkte tilgang til data og leke med de selv.

 

Eksempel på mitt forbruk sist Lørdag: Blå er strøm, oransje er utetemperatur, grønn er atmosfærisk lufttrykk. Brukte ca 38 kWh denne dagen.

• Grunnforbruk ligger på ca 1 kW. Noen PCer, lys, etc.
• De små toppene, mest synlig på natten, er luft-luft varmepumpen.
• De noe større toppene er varmekabel på badet.
• Enda større topper 4-5 ganger om dagen er varmtvann.
• 10:00 er det vaskemaskin, 15:30 tørketrommel.