Gå til innhold
  • Bli medlem
roarfred

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

Anbefalte innlegg

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?

Del dette innlegget


Lenke til innlegg
Del på andre sider

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

Del dette innlegget


Lenke til innlegg
Del på andre sider
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 ;)

 

Del dette innlegget


Lenke til innlegg
Del på andre sider
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)

Del dette innlegget


Lenke til innlegg
Del på andre sider
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

Del dette innlegget


Lenke til innlegg
Del på andre sider

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)

Del dette innlegget


Lenke til innlegg
Del på andre sider
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...

Del dette innlegget


Lenke til innlegg
Del på andre sider

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?

Del dette innlegget


Lenke til innlegg
Del på andre sider
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

Del dette innlegget


Lenke til innlegg
Del på andre sider

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.

Del dette innlegget


Lenke til innlegg
Del på andre sider

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. 

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider
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)

Del dette innlegget


Lenke til innlegg
Del på andre sider
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 :D

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)

  • Like 1

Del dette innlegget


Lenke til innlegg
Del på andre sider

Å 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?

Del dette innlegget


Lenke til innlegg
Del på andre sider
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. 

Del dette innlegget


Lenke til innlegg
Del på andre sider
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)

Del dette innlegget


Lenke til innlegg
Del på andre sider

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

 

Kamstrup:

image.png.928ed0d481cb97c914f1e320c574ae5c.png

 

Kaifa:

image.png.1797bf965e58f085db44aaeece7b44b5.png

 

Aidon:

image.png.b570f6047053210d7d37a93fc9e519d1.png

 

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: 

image.thumb.png.538bd2f820627dccafbc75ebb6388a7a.png

 

 

Del dette innlegget


Lenke til innlegg
Del på andre sider

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 av Tubez

Del dette innlegget


Lenke til innlegg
Del på andre sider
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 :P 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 :P

 

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 av Tubez

Del dette innlegget


Lenke til innlegg
Del på andre sider
32 minutes ago, Tubez said:

Hehe no problem :P 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 :P

 

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

Del dette innlegget


Lenke til innlegg
Del på andre sider

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

Del dette innlegget


Lenke til innlegg
Del på andre sider
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)

Del dette innlegget


Lenke til innlegg
Del på andre sider

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Fjern formatering

  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.


  • Lignende innhold

    • Av Preben
      Hei,
       
      Har mekka litt for å få HAN-data fra Kamstrup-måleren min (1-fas) inn i Home Assistant.
       
      Bruker ESPHome med en ESP32 for å få inn data, forsøkte med en ESP8266, men den var ikke helt glad i software serieport, derfor måtte jeg ty til 32'en.
       
      Koden er ganske stygg foreløpig, men kanskje det kan hjelpe noen andre på vei:)
       
      Parser dataen ved å lese ut OBIS-koder og så hente tilknyttede data. Ingen CRC-sjekk e.l. da dingsen min ikke ser ut til å lese korrupte data i det hele tatt så langt.
       
      Har lånt en del inspirasjon fra RoarFreds HAN-leser, selv om jeg endte opp med noe ganske annerledes etterhvert:)
       
      ESPHome-konfigurasjonsfil:
      esphome: name: ams platform: ESP32 board: nodemcu-32s includes: mbus.h wifi: power_save_mode: light networks: - ssid: "LulzNettOppe" password: ##PASSORD## - ssid: "LulzNettEkstra" password: ##PASSORD## - ssid: "LulzNett" password: ##PASSORD## # Enable logging logger: level: DEBUG # Enable Home Assistant API api: ota: uart: id: uart_bus tx_pin: GPIO17 rx_pin: GPIO16 baud_rate: 2400 # Example configuration entry dallas: - pin: GPIO25 sensor: - platform: dallas address: 0xEA0214808622FF28 name: "Temperature Sikringsskap" - platform: custom lambda: |- auto mbus_reader = new MbusReader(id(uart_bus)); App.register_component(mbus_reader); return {mbus_reader->wattage_sensor, mbus_reader->reactive_power_sensor, mbus_reader->amperage_sensor, mbus_reader->voltage_sensor, mbus_reader->energy_sensor, mbus_reader->reactive_energy_sensor}; sensors: - name: "AMS Wattage" unit_of_measurement: kW accuracy_decimals: 3 filters: - multiply: 0.001 - name: "AMS Reactive Power" unit_of_measurement: VAr accuracy_decimals: 0 internal: true - name: "AMS Amperage" unit_of_measurement: A accuracy_decimals: 2 filters: - multiply: 0.01 - name: "AMS Voltage" unit_of_measurement: V accuracy_decimals: 0 - name: "AMS Hourly Energy" unit_of_measurement: kWh accuracy_decimals: 3 filters: - multiply: 0.01 - name: "AMS Hourly Reactive Energy" unit_of_measurement: kVArh accuracy_decimals: 3 internal: true filters: - multiply: 0.01 mbus.h:
      #include "esphome.h" class MbusReader : public Component, public uart::UARTDevice, public Sensor { public: MbusReader(uart::UARTComponent *parent) : uart::UARTDevice(parent) {} uint8_t temp_byte = 0; uint8_t *temp_byte_pointer = &temp_byte; uint8_t uart_buffer_[512]{0}; uint16_t uart_counter = 0; char uart_message[550]; char temp_string[10]; char obis_code[32]; char temp_obis[10]; uint32_t obis_value = 0; float wattage = 0; float amperage = 0; float voltage = 0; float energy = 0; Sensor *wattage_sensor = new Sensor(); Sensor *amperage_sensor = new Sensor(); Sensor *voltage_sensor = new Sensor(); Sensor *energy_sensor = new Sensor(); Sensor *reactive_power_sensor = new Sensor(); Sensor *reactive_energy_sensor = new Sensor(); void setup() override { } void loop() override { bool have_message = read_message(); } bool read_message() { while(available() >= 1) { read_byte(this->temp_byte_pointer); if(temp_byte == 126) { if(uart_counter > 2) { uart_buffer_[uart_counter] = temp_byte; uart_counter++; uart_message[0] = '\0'; strcpy(uart_message, ""); for (uint16_t i = 0; i < uart_counter && i < 256; i++) { //sprintf(temp_string, "%02X", uart_buffer_[i]); //strncat(uart_message, temp_string, 2); if(uart_buffer_[i-1] == 9 && uart_buffer_[i] == 6) { obis_code[0] = '\0'; strcpy(obis_code, ""); for (uint16_t y = 1; y < 6; y++) { sprintf(temp_obis, "%d.", uart_buffer_[i + y]); strcat(obis_code, temp_obis); } sprintf(temp_obis, "%d", uart_buffer_[i + 6]); strcat(obis_code, temp_obis); ESP_LOGV("uart", "OBIS code found: %s message length: %d", obis_code, uart_buffer_[i + 7]); obis_value = 0; if(uart_buffer_[i + 7] == 6) { for(uint8_t y = 0; y < 4; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((3-y) * 8); } } else if(uart_buffer_[i + 7] == 18) { for(uint8_t y = 0; y < 2; y++) { obis_value += (long)uart_buffer_[i + 8 + y] << ((1-y) * 8); } } if(strcmp(obis_code, "1.1.1.7.0.255") == 0) { ESP_LOGV("uart", "Wattage: %d", obis_value); wattage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.31.7.0.255") == 0) { ESP_LOGV("uart", "Amperage: %d", obis_value); amperage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.32.7.0.255") == 0) { ESP_LOGV("uart", "Voltage: %d", obis_value); voltage_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.1.8.0.255") == 0) { ESP_LOGV("uart", "Energy Usage Last Hour: %d", obis_value); energy_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.7.0.255") == 0) { ESP_LOGV("uart", "Reactive Power: %d", obis_value); reactive_power_sensor->publish_state(obis_value); } else if (strcmp(obis_code, "1.1.4.8.0.255") == 0) { ESP_LOGV("uart", "Reactive Power Last Hour: %d", obis_value); reactive_energy_sensor->publish_state(obis_value); } else { ESP_LOGV("uart", "Unknown OBIS %s, value: %d", obis_code, obis_value); } } //strncat(uart_message, " ", 1); } ESP_LOGV("uart", "%d length received", uart_counter); //ESP_LOGI("uart", "%d length received: %s", uart_counter, uart_message); ESP_LOGV("uart", "Message length: %d", uart_message[3]); uart_counter = 0; uart_message[0] = '\0'; strcpy(uart_message, ""); } else { uart_counter = 0; } } uart_buffer_[uart_counter] = temp_byte; uart_counter++; } return false; } };  
    • Av Robin Smidsrød
      Hei alle sammen!
       
      Etter at jeg har lest gjennom en del poster på forumet her rundt lesing/dekoding av data fra AMS HAN-porten har jeg begynt å lure på hvor sensitiv målepunkt-ID-en er. Hvis man kobler den sammen med navn på abonnent og adresse er det sannsynligvis relativt sensitivt, men hvis den står alene i en binærdump, hvor mye skade kan en ondsinnet person gjøre hvis de har kjennskap til en målepunkt-ID?
       
      Grunnen til at jeg spør er fordi jeg har laget en dekoder[1], og jeg tenkte at det kunne være nyttig å legge ved eksempler på dump-filer fra forskjellige målere. Men hvis kjennskap til målepunkt-ID kan brukes til noe (f.eks. bestille eller avslutte tjenester som koster penger) uten å kjenne navnet på abonnenten tenker jeg at de ikke burde gjøres tilgjengelig på internett.
       
      Jeg leste et eller annet sted at NVE sammenligner målepunkt-ID med personnummer, og skatteetaten sier at personnummer ikke er sensitivt, men det er personopplysninger. Folk flest gir ikke fra seg personnummeret sitt til hvem som helst som spør om det, selv om skatteetaten sier som over.
       
      Jeg vet at målepunkt-ID består av landskode, kraftverk-ID, løpenummer og kontrollsiffer, som i seg selv ikke kan identifisere brukeren direkte.
       
      Så i bunn og grunn, hvis man har en målepunkt-ID, hva kan man gjøre med den?
       
      1: https://github.com/robinsmidsrod/ams-han-decoder
    • Av Torbjørn
      Da har jeg fått installert det meste på en litt eldre raspberry.
      Koblet til USB-MBUS slave modul, følgt guiden jeg fant her til å sette opp influxdb, grafana og node-red.
      Når jeg kjører test_rx fila i han-port mappa får jeg dette:
      root@raspberrypi:/home/pi/src/han-port# ./test_rx num args: 1 read serial: 1 read socket: 0 read file: 0 write file: 1 serial_device: /dev/ttyUSB0 fname: empty key: host: undefined port num: 10001 decrypt: 0 open_serial OK: 4 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 c8 02 02 0f 00 16 1b e8 a5 7e Date Time: , Items: 0 7e a0 2a 41 08 83 13 04 13 e6 e7 00 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 cc 02 02 0f 00 16 1b 9e ca 7e Date Time: , Items: 0 Leste i en annen trår her at på Aidon måler fungerer et python script til å gjøre samme jobb.
      Men her fikk jeg ikke helt rette verdier tror jeg:
      ./aidon_test.py /dev/ttyUSB0 {'p_act_in': 1046} {'p_act_in': 1036} {'p_act_in': 1032} {'p_act_in': 1032} {'p_act_in': 1052} {'p_act_in': 1040} {'p_act_in': 1040} {'p_act_in': 1050} {'p_act_in': 1050} {'p_act_in': 1066} {'p_act_in': 1076} {'p_act_in': 1052} {'p_act_in': 1052} {'p_act_in': 1062} I node-red står det bare å blinker "connecting" under alle AMS boksene.
       
       
      Noen som har fått til Aidon målerene som Lyse bruker, som kan hjelpe litt?
    • Av roy
      Jeg har en Kamstrup AMS fra Norgesnett med åpen HAN-port. For å lese disse DLMS OBIS datapush-meldingene har jeg en USB-til-MBUS-slave-modul koblet til en Raspberry Pi. Jeg skrev noen få linjer med Python for å skrive ut meldingene som kommer, og dette ser i utgangspunktet ut til å fungere stabilt og som forventet.
       
      Det jeg lurer på er om noen kan hjelpe meg å tyde/forklare meldingene til meg, fordi de later til å være mye kortere (145-160 bytes) enn det jeg har sett eksempler på her på forumene. Etter å ha lest hundrevis av meldinger og side opp og side ned her inne + lest kode og eksempeldata på spesielt https://github.com/roarfred/AmsToMqttBridge/ så skjønner jeg bare ikke hva det er med meldingene jeg får.
       
      Meldingene kommer hvert 10. sekund som forventet, og hver time kommer det en bittelitt lenger melding (den også mye kortere enn forventet). Det er som om OBIS-kodene ikke er med i meldingene.
       
      Start og slutt med byten E7 er alltid til stede og CRC for hvertfall header har stemt de gangene jeg har sjekket den.
       
      Her er eksempler på noen meldinger jeg får:
      2019-01-20T21:50:11.195980 - 155 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFBFE06C006E006F089C7FE74080600F80906F13AC60600FC4A6414DF100600FC89C7FE12C0BD4250B8FF3BE61200EB090601E1901200EB11CB7E 2019-01-20T21:50:21.194220 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126D18000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FFFFFF06C006E006F00906F17408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FCFF12C02FC8505807FC1200EC090601F1D81200EE88D47E 2019-01-20T21:50:31.194745 - 154 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126F4800080FBB6FE682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017EF10A1236383431313331424E323433313031303430090681F9FF0680FF06C006E006F00906C1FF7408FF0600F85F2150FE3AC40600FC4B7FDF07FC0600FC12C02FC8505CFF07FC1200EC090601F1D81200EE13D47E 2019-01-20T21:50:41.189758 - 156 bytes: 7EA0E22B2113239AE6E7000F0000F8BF60D9509126A58000F0FF682A566B1797AE17AE650582828A4A641428FE0A1135372036353627323132343834373536090601017CF10A1236383431313331424E323433313031303430090681F9FF0680FF96C828FF06C0FF06E006F089C7FE74080600F80906F13AC40600FC4A6414DF100600FCFF12C02FC85058FF3BE61200EC090601F1D81200EB3DC07E Hvis jeg tar f.eks. den siste meldingen over og bruker mye av kunnskapen fra https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/readme.md og https://github.com/roarfred/AmsToMqttBridge/blob/master/Samples/Kamstrup/obisdata.md så tolker jeg det som noe slikt som under. Jeg har brukt linjeskift ved de typiske separatorene bare for å prøve å finne mønster, men det vil nok ofte være helt feil ettersom jeg ofte ikke får ting til å stemme med "02 - one byte following 06 - long (4 bytes / 32 bits) 12 - int (2 bytes / 16 bit) 09 - string, first byte is length (could it be a byte array?) 0A - string, first byte is length" uansett.
       
      7E <-- Frame Start flag A <-- 4 bits, A = Frame Format Type 3 0E2 <-- 12 bits, Frame size: 0xE2 (226 bytes!?, excluding start/end flags) 2B <-- Destination Address 21 <-- Source Address 13 <-- Control Field 239A <-- Gyldig CRC-16/X-25 E6 <-- Destination LSAP E7 <-- Source LSAP 00 <-- LLC Quality 0F <-- Information, n*8 bits? 0000F8BF60D95 <-- Hva er dette? Ofte(?) likt 09 12 6A58000F0FF682A566B1797AE17AE650582828A4A641428FE 0A 1135372036353627323132343834373536 <-- Gyldig målernummer i ASCII (NB: jeg endret noen sifre her, så evt påfølgende checksum vil feile) 09 06 01017CF1 <-- Hva er dette? Alltid likt 0A 12 36383431313331424E323433313031303430 <-- Alltid likt = ASCII 6841131BN243101040 <-- 684113 = måler-type 09 06 81F9FF 06 80FF96C828FF 06 C0FF 06 E0 06 F089C7FE7408 06 00F897C8287E 09 06 F13AC4 06 00FC4A6414DF10 06 00FCFF 12 C02FC85058FF3BE6 12 00EC <-- 236 (Volt? (L2?)) 09 06 01F1D8 <-- Hva er dette? 12 00EB <-- 235 (Volt? (L3?)) 3DC0 <-- Checksum? 7E <-- Frame End flag  
      Oppsettet for avlesingen er slik jeg hadde forventet det å være:
      ser = serial.Serial( port='/dev/ttyUSB0', baudrate=2400, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10)  
      Håper noen har noen tips eller innspill til meldingene. 🙂
       
    • Av aleks
      Usikker på hvor overrasket jeg er? Til Hafslund:
       
       
×
×
  • Opprett ny...