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

[Andreas]

7 timer siden, roarfred skrev:

Da har jeg fått god hjelp av NVE og NTE Nett. Her bekreftes at datastrømmen som jeg mottar er riktig og at denne ikke skal inneholde selve OBIS kodene. De virker litt overrasket over at Kamstrup har disse med, men antar standarden gir frihet til det.

 

Løsningen er dermed at en må implementere tabellene med OBIS koder i software. Basert på OBIS ID (eks. KFM_001 for Kaifa) kan en finne rett tabell, ut fra OBIS List ID finner en så hvilke data som er forventet, hvilken rekkefølge de skal komme i og selve datatypen. Jeg skal forsøke meg på en slik implementasjon.

 

På sikt skulle være mulig å legge en slik definisjon ut på en HTTP-adresse, slik at en har mulighet for å støtte flere målinger, evt. justeringer i data-strømmen uten å måtte uploade ny firmware.

 

NTE Nett var også hyggelige nok til å sende meg en utlisting av HEX koder og deres egen forklaring / dekoding. Hyggelig å se at den lignet veldig på min egen tolkning

Noe du har mulighet til å dele?

[roarfred]

To av de tre dokumentene jeg fikk lå allerede ute på gihub hos meg. Det tredje fikk jegspørsmål om å ikke dele, fordi det var laget uten tanke på det. Det som lå i det siste var en hex-utlisting av data fra han porten, samme som mine filer under samples viser. I tilleg hadde deres fil en liten forklaring til hvert av data-elementene. Jeg skal lage en slik selv, men kan desverre ikke legge ut det dokumentet de sendte meg...

[xibriz]

1 time siden, roarfred skrev:

To av de tre dokumentene jeg fikk lå allerede ute på gihub hos meg. Det tredje fikk jegspørsmål om å ikke dele, fordi det var laget uten tanke på det. Det som lå i det siste var en hex-utlisting av data fra han porten, samme som mine filer under samples viser. I tilleg hadde deres fil en liten forklaring til hvert av data-elementene. Jeg skal lage en slik selv, men kan desverre ikke legge ut det dokumentet de sendte meg...

 

Du får skrive informasjonen med egne ord

 

[roarfred]

Skulle fått til en skjerm på kjøkkenet med en slik rullende over

Media1.mp4

[Marius-H]

Jeg tenkte å koble til en Phillips Hue pære. Så kan den gå i rødt ved toppene.  Burde kanskje hatt en for pris og da? 

[roarfred]

37 minutes ago, Marius-H said:

Jeg tenkte å koble til en Phillips Hue pære. Så kan den gå i rødt ved toppene.  Burde kanskje hatt en for pris og da? 

Du kan jo bare kombinere forbruk * pris, og gå i rødt når ting koster mer enn eks. to kroner per time... Jeg ville da gjerne ventet med å sette på klesvasken og gjerne trykket på knwppen som kobler ut varmtvannstanken i 30 min. (Som egentlig skulle vært autmatisert)

[roarfred]

On 9/22/2017 at 18:51, Andreas said:

Noe du har mulighet til å dele?

Da har jeg lagt ut en komplett oppdeling av de tre listene fra Kaifa måleren, koblet sammen med forklaring fra OBIS-dokumentet. Reagerer litt på at de enhetene i dokumentet fra Kaifa åpenbart må være feil, evt. også har jeg litt problemer med å skjønne hva en double-long-unsigned skal være.

 

Kan mao se ut som verdiene som kommer ut skal multipliseres eller divideres med 10, 100 eller 1000 før de stemmer med den oppgitte enheten. Eks har jeg 2424V og 2182A på den ene linjen min

 

Det hele finnes her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kaifa OBIS breakdown.md

[roarfred]

Har nå lagt til kode for WiFi tilkobling, og rapportering av JSON til MQTT. (Bruker ArduinoJson og PubSubClient for dette)

 

I prinsippet er en dermed i mål med prosjektet, men vil gjøre to forbedringer:

1) Pakke sammen DlmsReader og KaifaHan til et mer generelt Arduino bibliotek

2) Forsøke å få til en mer generell løsning for KaifaHan, slik at vi kan støtte en generisk måler (men minstekrav at Aidon og Kamstrup funker)

[Christian]

Da har jeg bestilt åpning av mitt HAN interface

[roarfred]

1 hour ago, Christian said:

Da har jeg bestilt åpning av mitt HAN interface

Tøft! Ser det er Kamstrup måler du får. Er veldig spent på hvor mye hex kodene hos dem ligner på de som jeg fikk ut. (I følge Kamstrup dokument jeg har, så skulle de være noe annerledes...)

 

PS: Ser i en annen tråd at du hadde en C# utfordring med å lese json... Har litt erfaring med C#/json om du står fast, så gi meg en lyd...

[Tubez]

Jeg sitter å tenker på å lage mitt eget grensesnitt med RPi mot måleren (har en RPi V1 liggende å støve ned), men så har jeg tenkt litt på hvordan jeg fysisk skal utarbeide dette grensesnittet.

 

Etter litt googling så fant jeg at TSS721A brikken kan fungere. Er det en spesiell grunn til at du benytter ESP8622?

[roarfred]

Just now, Tubez said:

Jeg sitter å tenker på å lage mitt eget grensesnitt med RPi mot måleren (har en RPi V1 liggende å støve ned), men så har jeg tenkt litt på hvordan jeg fysisk skal utarbeide dette grensesnittet.

 

Etter litt googling så fant jeg at TSS721A brikken kan fungere. Er det en spesiell grunn til at du benytter ESP8622?

Jeg har også et par slike TI-chipper liggende, kjøpt før jeg forstod hvor enkelt dette kan gjøres :) Den lille kretsen med en op-amp gjør ikke annet enn å omvandle en puls som skifter mellom 27V og 15V til en lik puls som skifter mellom 3.3V og 0V. Derfra kan du behandle signalet som helt "standard" seriell data. Standard i anførselstegn fordi det er helt spesifikt 2400 baud, 8 data bit, even parity og 1 stop bit.

 

Jeg har ikke gjort dette selv, men det ser ut som RPi har en fysisk serieport og at det skal gå fint å programmere mot denne. Det du vil trenge er i prinsippet den logikken som du finner i prosjektet mitt.

 

Fordelen med ESP (evt. annen microcontroller) er at de er super-billige, og du får en dedikert device til å gjøre en dedikert oppgave. I mitt eksempel handler det utelukkende om å dekode HAN signalet til en lesbar JSON og levere denne via MQTT. En annen fordel er stabilitet.

 

Hos meg fungerer dette omtrent slik:

 

En RPi kjører MQTT og fungerer som en HUB for alle devices

Mange ulike ESP devices leser og sender MQTT meldinger

En node.js app og en zwave-usb stick oversetter zwave til og fra MQTT

Node Red kjører på samme RPi. Herfra kan en programmere hvilke meldinger som skal føre til hvilke andre meldinger

Ingen devices vet om at noen andre eksisterer

 

Eks. vises forbruk fra strømmåleren på en annen ESP-koblet device med en OLED skjerm. Denne OLED'en vet ikke om strøm-måleren, men har kun i oppgave å ta i mot meldinger på et bestemt format fra en MQTT. Strøm-måleren vet heller ikke om displayet, den bare sender meldiner om strømforbruk. Node Red er kjernen her som sørger for at en innkommende melding om strømforbruk fører til en ny utgående melding om at en tekst ønskes vist på et display.

 

MQTT er for øvrig linket til IoT Hub i Azure, men det er en helt annen historie. Mesteparten av det vi har gjort på Arduino/ESP ligger ute på github.com/xnsense

[Tubez]

Skjønner, så hvis jeg hadde brukt TSS721A brikken så kunne jeg koblet denne direkte opp mot RPien uten noen ekstra utenom 2k2 motstand for å beskytte portene? Utfordringen blir kodingen, noe som jeg ikke har så altfor mye erfaring med. Nå får vi montert AIDON 6531 måleren, så jeg er spent å se om man mottar samme data fra denne som du har.

 

Jeg har en del utstyr liggende for RPi og Prototype board (https://www.adafruit.com/product/801) som jeg tenkte jeg skulle benytte meg av. 

 

Jeg fant forresten alle objektkodene som OBIS bruker, men den vet du nok sikkert om allerede: http://www.dlms.com/documentation/listofstandardobiscodesandmaintenanceproces/index.html

Her ligger et excel-dokument i en zip fil over alle koder.

[Marius-H]

Da var min hankode aktivert og fra norgesnett. Da er det bare å starte for min egen del og.

 

Ville dere delt målerdataene med strømselskapene om det hadde enablet timesfakturering av selve strømforbruksdelen? Strømselskapene får ikke dataene av nettselskapene før elhub er klart. (generelt sett).Elhub er nok ikke ferdig med det første. 

[roarfred]

5 minutes ago, Tubez said:

Skjønner, så hvis jeg hadde brukt TSS721A brikken så kunne jeg koblet denne direkte opp mot RPien uten noen ekstra utenom 2k2 motstand for å beskytte portene? Utfordringen blir kodingen, noe som jeg ikke har så altfor mye erfaring med. Nå får vi montert AIDON 6531 måleren, så jeg er spent å se om man mottar samme data fra denne som du har.

 

Jeg har en del utstyr liggende for RPi og Prototype board (https://www.adafruit.com/product/801) som jeg tenkte jeg skulle benytte meg av. 

 

Jeg fant forresten alle objektkodene som OBIS bruker, men den vet du nok sikkert om allerede: http://www.dlms.com/documentation/listofstandardobiscodesandmaintenanceproces/index.html

Her ligger et excel-dokument i en zip fil over alle koder.

Jeg tviler egentlig på at du slipper noe billigere unna med TI-kretsen. Når jeg kikket gjennom databladet nå, så kommer jeg på grunnen til at jeg lot den ligge i skuffen var at denne var beregnet på når du skal lage din egen sensor og så koble den til en M-bus. (Litt motsatt av det som er tilfellet her)

 

Så, enkleste veien til målet tror jeg er å benytte en Arduino eller en ESP8266, og en enkel level-converter som den jeg tegnet. Da kan du bruke elektronikk og kode direkte fra meg. Videre installerer du Mosquitto MQTT server på PI'en din, så kan du konsentrere deg om ferdige verdier i Watt, Volt og Ampere, i stedet for å fikle med bits, bytes og manuell sjekking av CRC. De aller fleste programmeringsspråk og automasjonssystemer har gode eksempler på å koble seg til MQTT og å lese JSON. (Nå er det klart at jeg er litt "biased" her, så andre må gjerne skrike ut om de mener det er enklere veier til Rom)

[roarfred]

21 minutes ago, Marius-H said:

Da var min hankode aktivert og fra norgesnett. Da er det bare å starte for min egen del og.

 

Ville dere delt målerdataene med strømselskapene om det hadde enablet timesfakturering av selve strømforbruksdelen? Strømselskapene får ikke dataene av nettselskapene før elhub er klart. (generelt sett).Elhub er nok ikke ferdig med det første. 

Regner med at spørsmålet ditt er veldig hypotetisk, men ja, hvis jeg selv kunne programmere meg fram til tallet jeg ble fakturert for så hadde det vært interessant

Uten verken hasjplantasje eller HB apparat, så ser jeg ikke noen stor grunn til å holde dataene skjult, men etter å ha sett motstanden mot disse målerne, så tror jeg ikke det er "gjengs oppfatning"

 

PS: Hold oss oppdatert på det du får ut av måleren da! (Alt fra første test med voltmeter AC/DC er interessant)

[Tubez]

Å kalkulere seg fram til faktisk kostnad er ikke vanskelig. Utfordringen er å vite hvordan strømleverandøren din kalkulerer seg fram. 

 

Hvis du har strøm til spotpris uten påslag, så er det jo bare å gå inn på nordpoolspot.com og se hva strømmen vil koste neste dag pluss nettleie, avgifter og moms. Har du påslag på strømmen din, enten i form av x øre/kWh eller fastbeløp i måneden, så må dette plusses på. Vær obs på at det er snakk om neste dag, og at prisene er oppgitt i kr/MWh og ikke øre/kWh. På nordpool så har man muligheten til å laste ned dataene for neste dag som excel-dokument, men det er sikkert mulig å hente de ut i form av RSS eller lignende for de som kan det. 

 

Hvis du også ser på statnett.no, så står systemprisen som er akkurat i den inneværende timen, men det er ikke nødvendigvis den strømmen du betaler, for Norge er delt opp i 5 prisområder. 

 

Dermed skal det være en smal sak å regne ut, for i følge det jeg har lest opp til nå, så kan man hente ut forbruket for den gitte timen, og da er det bare å linke den opp mot prisen på nordpool.

 

Eksempel:

 

kl. 07-08 i morgen 27.09.2017 skal strømmen koste 285,38 kr/MWh for Oslo-regionen. 

Ditt forbruk kan vi si er 25(?) kWh. Du har en nettleie og avgifter på 60 øre/kWh (et tall ut av løse luften).

 

Sum: ((285,38/1000) øre/kWh * 1,25 <moms> + 60 øre/kWh) * 25 kWh = 23,918 kr.

 

Korrekt meg gjerne hvis jeg tar feil?

[Marius-H]

36 minutter siden, Tubez skrev:

Å kalkulere seg fram til faktisk kostnad er ikke vanskelig. Utfordringen er å vite hvordan strømleverandøren din kalkulerer seg fram. 

 

Hvis du har strøm til spotpris uten påslag, så er det jo bare å gå inn på nordpoolspot.com og se hva strømmen vil koste neste dag pluss nettleie, avgifter og moms. Har du påslag på strømmen din, enten i form av x øre/kWh eller fastbeløp i måneden, så må dette plusses på. Vær obs på at det er snakk om neste dag, og at prisene er oppgitt i kr/MWh og ikke øre/kWh. På nordpool så har man muligheten til å laste ned dataene for neste dag som excel-dokument, men det er sikkert mulig å hente de ut i form av RSS eller lignende for de som kan det. 

 

Hvis du også ser på statnett.no, så står systemprisen som er akkurat i den inneværende timen, men det er ikke nødvendigvis den strømmen du betaler, for Norge er delt opp i 5 prisområder. 

 

Dermed skal det være en smal sak å regne ut, for i følge det jeg har lest opp til nå, så kan man hente ut forbruket for den gitte timen, og da er det bare å linke den opp mot prisen på nordpool.

 

Eksempel:

 

kl. 07-08 i morgen 27.09.2017 skal strømmen koste 285,38 kr/MWh for Oslo-regionen. 

Ditt forbruk kan vi si er 25(?) kWh. Du har en nettleie og avgifter på 60 øre/kWh (et tall ut av løse luften).

 

Sum: ((285,38/1000) øre/kWh * 1,25 <moms> + 60 øre/kWh) * 25 kWh = 23,918 kr.

 

Korrekt meg gjerne hvis jeg tar feil?

 Det stemmer nok bra. Spotprisen settes dagen i forveien. Så man vet morgendagens priser kl 14 eller noe der omkring. Jeg kan forsøke å sette opp et rest/json api som bruker dataene fra nordpool. Nettprisene er fastsatt av netteier. Kanskje jeg kan finne opp til det og. 

[roarfred]

49 minutes ago, Tubez said:

Å kalkulere seg fram til faktisk kostnad er ikke vanskelig. Utfordringen er å vite hvordan strømleverandøren din kalkulerer seg fram. 

 

Hvis du har strøm til spotpris uten påslag, så er det jo bare å gå inn på nordpoolspot.com og se hva strømmen vil koste neste dag pluss nettleie, avgifter og moms. Har du påslag på strømmen din, enten i form av x øre/kWh eller fastbeløp i måneden, så må dette plusses på. Vær obs på at det er snakk om neste dag, og at prisene er oppgitt i kr/MWh og ikke øre/kWh. På nordpool så har man muligheten til å laste ned dataene for neste dag som excel-dokument, men det er sikkert mulig å hente de ut i form av RSS eller lignende for de som kan det. 

 

Hvis du også ser på statnett.no, så står systemprisen som er akkurat i den inneværende timen, men det er ikke nødvendigvis den strømmen du betaler, for Norge er delt opp i 5 prisområder. 

 

Dermed skal det være en smal sak å regne ut, for i følge det jeg har lest opp til nå, så kan man hente ut forbruket for den gitte timen, og da er det bare å linke den opp mot prisen på nordpool.

 

Eksempel:

 

kl. 07-08 i morgen 27.09.2017 skal strømmen koste 285,38 kr/MWh for Oslo-regionen. 

Ditt forbruk kan vi si er 25(?) kWh. Du har en nettleie og avgifter på 60 øre/kWh (et tall ut av løse luften).

 

Sum: ((285,38/1000) øre/kWh * 1,25 <moms> + 60 øre/kWh) * 25 kWh = 23,918 kr.

 

Korrekt meg gjerne hvis jeg tar feil?

Stilig! Mye spennende en kan få til med litt eksterne APIer...

 

PS: Hvis du refererte til det jeg beskrev tidligere som komplekst, så handlet det ikke om å finne pris, men å finne fram til at det var 627W du hadde i øyeblikksforbruk.

Eks. kan dataene se slik ut fra måleren: 04 34 16 FF 80 00 00 02 01 06 00 00 02 73 55 0B 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 0F 05 04 34 18 FF 80 00 00 02 01 06 00 00 02 72 FD 17 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09

Fra dette er det 627W det ene sekundet og 628W det neste. Prosjektet her handler om å få gjort om dataene fra elektriske bits til tall og tekst i json format, som igjen kan ligge til grunn for nettopp slike løsninger som du skisserer. (no offence, bare ment som en liten oppklaring)

[roarfred]

Prøver å bli litt klok på OBIS koder... Ser ikke ut som det er fantastisk god "semje" mellom de ulike leverandørene:

 

Kamstrup:

 

Kaifa:

 

Aidon:

 

Antall lister varierer, og tidsrommet mellom listene, hvilke data som er med i listene og til slutt også selve OBIS kodene som brukes. Blir mest spennende å se om det nå stemmer at Kamstrup også sender ut hver eneste OBIS kode i forkant av selve dataene (mens Kaifa da er bevist å ikke gjøre dette). Håper det evt. lar seg gjøre å detektere på sikkert vis hva en får ut av hver måler...

 

Selve OBIS inndelingen er beskrevet i den såkalte Blue Book, kapittel 7.2: 

 

 

[Tubez]

Hmm ja... Synes at det er rart at de listene er ulike ettersom de skal bruke OBIS standarden. Som du ser i et av de første innleggene så linket jeg til objektlisten fra de som har utarbeidet standarden. Så tanken min var at jeg skal bruke litt tid på å sammenligne de kodene mot den listen du har.

 

Mest sannsynlig så er de like, bare feil dokumentert? 

Endret 26. september 2017 av Tubez

[Tubez]

5 timer siden, roarfred skrev:

Stilig! Mye spennende en kan få til med litt eksterne APIer...

 

PS: Hvis du refererte til det jeg beskrev tidligere som komplekst, så handlet det ikke om å finne pris, men å finne fram til at det var 627W du hadde i øyeblikksforbruk.

Eks. kan dataene se slik ut fra måleren: 04 34 16 FF 80 00 00 02 01 06 00 00 02 73 55 0B 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09 0F 05 04 34 18 FF 80 00 00 02 01 06 00 00 02 72 FD 17 7E 7E A0 27 01 02 01 10 5A 87 E6 E7 00 0F 40 00 00 00 09 0C 07 E1 09

Fra dette er det 627W det ene sekundet og 628W det neste. Prosjektet her handler om å få gjort om dataene fra elektriske bits til tall og tekst i json format, som igjen kan ligge til grunn for nettopp slike løsninger som du skisserer. (no offence, bare ment som en liten oppklaring)

Hehe no problem var ikke ment som noe stikk. Det jeg prøvde å forklare med utfordrende er at vi er ikke 100 % sikre på hvordan nettselskapet kalkulerer seg fram, dermed blir vår kalkulering kun veiledende. Og det er viktig å påpeke. 

 

Det å skal bruke effekten til å regne ut energiforbruket er noe jeg ikke hadde valgt,  av 2 grunner. Den éne grunnen er at i det skrivet fra NVE så står det at at de anbefaler en oppdateringsfrekvens på 2,5 sekunder. Noe som gjør at du går glipp av 1,5 sekunder med data. 

 

Den andre er selve kalkuleringen. Istedet for å gjøre én beregning i timen med kWh avlesningen man får da, så må man integrere fra 0 til 3600 ganger i timen, 24 timer i døgnet. Og i tillegg får man håndtering av lister/tabeller osv..

 

Det jeg kunne tenkt meg å sett er effekten i øyeblikket, spenning U(1,2,3)-Uj, strøm pr fase, kVAr i øyeblikket, fasevinkel, energiprisen nå og ut resten av døgnet,  en graf med forbruk over dagen og til slutt brukt energi så langt i dag med hva ca. kostnadene har vært. Men det skal sies jeg er litt vell interessert i dette

 

Edit: men ja jeg skjønner veldig godt at utfordringen er å få kontroll på hvilke data man har tilgang til og få dette behandlet. Selve framstillingen kan man diskutere senere

Endret 26. september 2017 av Tubez

[roarfred]

32 minutes ago, Tubez said:

Hehe no problem var ikke ment som noe stikk. Det jeg prøvde å forklare med utfordrende er at vi er ikke 100 % sikre på hvordan nettselskapet kalkulerer seg fram, dermed blir vår kalkulering kun veiledende. Og det er viktig å påpeke. 

 

Det å skal bruke effekten til å regne ut energiforbruket er noe jeg ikke hadde valgt,  av 2 grunner. Den éne grunnen er at i det skrivet fra NVE så står det at at de anbefaler en oppdateringsfrekvens på 2,5 sekunder. Noe som gjør at du går glipp av 1,5 sekunder med data. 

 

Den andre er selve kalkuleringen. Istedet for å gjøre én beregning i timen med kWh avlesningen man får da, så må man integrere fra 0 til 3600 ganger i timen, 24 timer i døgnet. Og i tillegg får man håndtering av lister/tabeller osv..

 

Det jeg kunne tenkt meg å sett er effekten i øyeblikket, spenning U(1,2,3)-Uj, strøm pr fase, kVAr i øyeblikket, fasevinkel, energiprisen nå og ut resten av døgnet,  en graf med forbruk over dagen og til slutt brukt energi så langt i dag med hva ca. kostnadene har vært. Men det skal sies jeg er litt vell interessert i dette

 

Edit: men ja jeg skjønner veldig godt at utfordringen er å få kontroll på hvilke data man har tilgang til og få dette behandlet. Selve framstillingen kan man diskutere senere

Hehe, tror kanskje du er mer interessert enn menig mann ☺

 

Interessant om 2 sek verdien er en øyeblikksverdi eller et gjennomsnitt/integrert verdi... 

[Tubez]

Tipper øyeblikksverdi, mye enklere å håndtere enn å regne ut snittet i tillegg til øvrige kalkuleringer som blir gjort. 

 

Men jeg skal få bestilt opp materiell som at jeg også får gjort noen målinger. I starten blir det kun å skrive alt jeg måler ned i et dokument på RPien. 

 

Logger du alle dataen som du har registrert til nå? 

[roarfred]

59 minutes ago, Tubez said:

Tipper øyeblikksverdi, mye enklere å håndtere enn å regne ut snittet i tillegg til øvrige kalkuleringer som blir gjort. 

 

Men jeg skal få bestilt opp materiell som at jeg også får gjort noen målinger. I starten blir det kun å skrive alt jeg måler ned i et dokument på RPien. 

 

Logger du alle dataen som du har registrert til nå? 

Logger svært lite, men ser at jeg må begynne med det nå. Kom hjem og da stod måleren på 7500W... (Har laget et lite oled display som viser data)