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

[Johove]

Det er best å bruke f,eks. En Uno til debugging, debug trace bruker en del cpu.

jeg har brukt 8mhz med 3,3v med minimalistisk kort for å få ned størelsen, men har ennå ikke hentet strøm fra måleren, men det burde være mulig.

[tronde]

Takk for svar. Da får jeg grave litt mer i koden i morgen kveld nå som det ikke skal være hardware som stopper. Jeg mener å ha funnet de rette switchene, men jeg er ingen racer i programmering...

 

Interfacet gir ut data, og jeg har også tidligere fått det inn som rådata på PC-en, så den delen er nok iorden.

[Johove]

8 timer siden, tronde skrev:

Takk for svar. Da får jeg grave litt mer i koden i morgen kveld nå som det ikke skal være hardware som stopper. Jeg mener å ha funnet de rette switchene, men jeg er ingen racer i programmering...

 

Interfacet gir ut data, og jeg har også tidligere fått det inn som rådata på PC-en, så den delen er nok iorden.

Dersom du bruker koden slik den er i repository og

Kommenter ut:

//#define useMySensors 

Kommenter inn:

#define useSoftSerial  // to debug the code

#define MY_DEBUG1 

Og du har mbus serial koblet til rx(ardiono) -> 8 og Tx -> 7   // kanskje du har byttet disse, det er rx (Arduino) til tx(mbus) 

Du skal i det minste få: "start:" på streamen

 

[Johove]

5 timer siden, Johove skrev:

Dersom du bruker koden slik den er i repository og

Kommenter ut:

//#define useMySensors 

Kommenter inn:

#define useSoftSerial  // to debug the code

#define MY_DEBUG1 

Og du har mbus serial koblet til rx(ardiono) -> 8 og Tx -> 7   // kanskje du har byttet disse, det er rx (Arduino) til tx(mbus) 

Du skal i det minste få: "start:" på streamen

 

 

Du kan også teste oppsette ditt med den litt enklerer koden: Vil lista datene som kommer --

 

/*
  Software serial multple serial test
 Receives from the hardware serial, sends to software serial.
 Receives from software serial, sends to hardware serial.

 The circuit:
 * RX is digital pin 10 (connect to TX of other device)
 * TX is digital pin 11 (connect to RX of other device)

 Note:
 Not all pins on the Mega and Mega 2560 support change interrupts,
 so only the following can be used for RX:
 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69

 Not all pins on the Leonardo and Micro support change interrupts,
 so only the following can be used for RX:
 8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).

 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example
 This example code is in the public domain.
 */
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(57600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }

  Serial.println("Goodnight moon!");

  // set the data rate for the SoftwareSerial port
  mySerial.begin(2400);
}
void loop() { // run over and over
  if (mySerial.available()) {
    int c = mySerial.read();
    if(c<16) Serial.print('0');
    Serial.print(c, HEX);
    if (c==0x7e) Serial.println();
  }
}

 

[tronde]

Begge funker helt fint!

Kan være at jeg tok feil switch i går. Begynte helt på nytt nå for å være sikker.

 

Nå har jeg noe å leke med som jeg trolig kan forstå. Er i første omgang kun ute etter å lese måleren så jeg kan begynne å fordype meg i hvordan de mer fancy grafikktingene funker. Der er jeg enda mer blank... 

[tronde]

@Johove

 

Jeg har prøvd å bli litt klok på koden din.

 

Jeg har debugmodus slik du beskriver, og får ut MeterID, Meter type, OBISVersion, Akiv og reaktiv effekt inn, begge strømmene (jeg har type 6525 trefas IT) og alle tre spenningene med korrekte verdier. Date kommer kun ut som 0-0-0-0-0-0-0-0-0-0-0-0- selv ved timeskiftet som vel skal inneholde dato og klokkeslett pluss akkumulert energi for siste time. Disse kommer ikke ut. Jeg ser at det kommer vesentlig mer data (i bufferstrengen) fra måleren ved timeskiftet, så jeg antar at den gir dem ut.

Det er jo Serial.print for de akkumulerte verdiene, så de burde vel skrives ut?

 

Har du noe forslag?

Endret 9. desember 2019 av tronde
trykkleif

[Johove]

12 timer siden, tronde skrev:

@Johove

 

Jeg har prøvd å bli litt klok på koden din.

 

Jeg har debugmodus slik du beskriver, og får ut MeterID, Meter type, OBISVersion, Akiv og reaktiv effekt inn, begge strømmene (jeg har type 6525 trefas IT) og alle tre spenningene med korrekte verdier. Date kommer kun ut som 0-0-0-0-0-0-0-0-0-0-0-0- selv ved timeskiftet som vel skal inneholde dato og klokkeslett pluss akkumulert energi for siste time. Disse kommer ikke ut. Jeg ser at det kommer vesentlig mer data (i bufferstrengen) fra måleren ved timeskiftet, så jeg antar at den gir dem ut.

Det er jo Serial.print for de akkumulerte verdiene, så de burde vel skrives ut?

 

Har du noe forslag?

Det kan oppstå timingproblemer når mye debugtekst skrives til seriel konsoll mens pakka leses, utskrifen av trace bruker for mye tid, det fører til at det mistes data på slutten av pakka. pass på å ha høy hastighet.

 

Hele pakka leses uten debug.

Prøv å skru på switch for debug3 og skru av den andre, da printer data etter at meldingene er lest, ikke mens de leses.

Dato leses, men jeg har ikke dekodet dataformatet til lesbar dato.

 

Det ligger en eksempelpakke i readme. 

 

Og for å forstå pakkene, og koden,  les siste tabell i Aidospesifikasjone. 

Ref https://www.nek.no/wp-content/uploads/2018/11/Aidon-HAN-Interface-Description-v10A-ID-34331.pdf 

og EXCERPT DLMS UA Blue Book: COSEM interface classes and OBIS identification system, EXCERPT DLMS UA 1000-1 Ed. 12.0.  Du finner den på Internett, dette er spesifikasjonen av struktur, datafelter og OBIS kodesystemet.

 

Denne implantasjonen følger den spesifikasjonen som ligger til grunn for målerens grensesnitt.

[tronde]

Ok, da er det kun de akkumulerte verdiene jeg bryr meg om nå siden dato ikke er dekodet. Skal gjøre noen forsøk med den andre debugen, og også prøve å ta bort en del av de verdiene som skrives ut nå. Jeg er uansett fornøyd, for koden din gir meg noe jeg har bruk for ?  Jeg ville spørre, for å være sikker på at jeg ikke leter etter spøkelser.

[tronde]

Selv 2M baud er tydeligvis for tregt. Jeg tok en annen tilnærming som funker.

 

Der hvor du har Serial.print for verdiene lager jeg i stedenfor et nytt sett variabler som lagres og skrives ut helt først i void loop(). I tillegg deaktiverte jeg utskrift av bufferen. Vet ikke om det har betydning, men jeg behøver den ikke. Det kan være at det er unødvendig komplisert, men det funker i alle fall helt fint for det jeg kommer til å leke med videre. Hvor jeg havner, vil tiden vise... Nå har jeg i alle fall fått de verdiene jeg trenger :-)

[tronde]

Etter å ha fått i gang koden til Johove ble jeg mer inspirert til å se på den manglende strømmen fra Aidon 6525. Jeg har ikke blitt hverken smartere elller klokere siden sist, så strømmen er fortsatt borte...  ? Jeg klarer ikke å se hvordan vi kan finne den med de verdiene vi får ut av måleren, men har ikke gitt opp håpet om at noen kan mer matte enn meg.

 

 

Min tilnærming blir nok å sammenlikne verdiene fra måleren med oppgitt effekt, og finne ut om bergnet strøm er ca. sannsynlig eller ikke. Hvis svaret ligger for langt ute, ser jeg for meg en mulighet til å lage ulike korreksjonsfaktorer basert på data fra måleren som kan brukes for å nærme seg virkeligheten. 

 

 

For å hjelpe meg har jeg laget et regneark som kan mates med nettspenning og belastning som effekt for hver fase. Da får jeg ut alle strømmene i trekanten, pluss linjestrømmene. Jeg har også en beregnet effekt dersom lasten er symmetrisk, slik at man ser hvor langt utenfor man er. Det betyr at man kan bruke regnearket som fasit for egne forsøk på formler for I2.

 

Det er lett å regne ut strømmene med kalkulator som støtter polare koordinater når man kjenner alle forutsetningene, så tallene i regnearket skal være korrekte med mindre jeg har fått inn en trykkleif i en eller annen formel.  

 

 

* - Regnearket baserer seg på at det kun er reistiv last, altså ingen reaktiv effekt. Når vi ikke kjenner hvordan den reaktive effekten fordeler seg mellom fasene er det nytteløst å bruke den fra måleren til noe som helst. Selv om vi har data for aktiv og reaktiv effekt, er det for hele systemet. I virkeligheten vil den fordele seg ulikt, og kan i verste fall være på kun en fase.

* - Jeg ser ingen fornuftig grunn til å regne med ulik spenning på hver fase. Hvis man ikke har svært dårlig nett, skal  ikke spenningen avvike mer enn et par-tre volt opp og ned, og det har ingen praktisk betydning.  

 

* - Strømmene og spenningene fra måleren er aldri helt "ferske" siden de kommer i 10 sek intervaller, og i tillegg er målt over en kort periode. Dette begrenser nytteverdien av høy nøyaktghet. Det mest viktige er å ha en verdi som viser om vi er nær grensen for sikringene, og da bør ca. +/- 1 A være mer enn godt nok.

 

* - Det har ikke så store poenget å mate inn verdier med stort sprang i regnearket. Det er mer viktig å bruke prosentvis store forskjeller i faselasten, for forholdet mellom dem vil gi samme prosentvise feil i I2 enten tallene er store eller  små.

 

 

Jeg legger ved regnearket her hvis noen vil prøve seg. Jeg har lagt inn en del bilder som baserer seg på den norske læreboka, og fått målsatt dem i et cad-program slik at man kan sammenlikne med de verdiene som ligger i regnearket. Det er derfor filen er nokså stor.

 

Regnearket er laget i Excel 2013 og bruker så vidt jeg vet ingen eksotiske funksjoner. Jeg har ikke peil på hvordan andre funker, men Excel regner i utgangspunktet vinkler som radianer, men har en funksjon som gjør det mulig å regne direkte med grader. Kan kanskje krasje i et annet regneark?

 

 

 

 

trefase_trekant_effekt_linjestroemmer_20191216.xlsx

Endret 16. desember 2019 av tronde

[erikolaulvestad]

Jeg klarer ikke å se hvordan vi kan finne den med de verdiene vi får ut av måleren,
...[edit cut]
...
Hvis svaret ligger for langt ute, ser jeg for meg en mulighet til å lage ulike korreksjonsfaktorer basert på data fra måleren som kan brukes for å nærme seg virkeligheten. 

Tabellbasert estimering kan vere eit bra alternativ. Mange algoritmer som har blitt lagt inn som det opp gjennom åra.

Ellers ville eg tru at eit dykk i 3fase teorien (feks https://www.google.com/url?sa=t&source=web&rct=j&url=https://pdhonline.com/courses/e336/e336content.pdf&ved=2ahUKEwigv_mThbvmAhXi5aYKHWJvDusQFjAMegQIARAB&usg=AOvVaw1pFtatj-pOlbg0PYgeOgRS , avsnitt for 3phase unbalanced delta) kan gi svaret?

Sent fra min SM-G960F via Tapatalk

[deve87]

Bare sånn hvis ikke det er sagt. IT-nett med 3 fas, måler kun 2 av fasene og beregner den siste. Så det er ingen data som mangler fra Adion måleren. Du får ampere fra L1 og L3.

 

Har du TN-nett derimot (med null leder). Benytter målere alle 3 faser og beregner null leder.

Endret 16. desember 2019 av deve87

[tronde]

4 timer siden, erikolaulvestad skrev:

 

 

Tabellbasert estimering kan vere eit bra alternativ. Mange algoritmer som har blitt lagt inn som det opp gjennom åra.

Ellers ville eg tru at eit dykk i 3fase teorien (feks https://www.google.com/url?sa=t&source=web&rct=j&url=https://pdhonline.com/courses/e336/e336content.pdf&ved=2ahUKEwigv_mThbvmAhXi5aYKHWJvDusQFjAMegQIARAB&usg=AOvVaw1pFtatj-pOlbg0PYgeOgRS , avsnitt for 3phase unbalanced delta) kan gi svaret?

Sent fra min SM-G960F via Tapatalk
 

Har bladd i den, og boka som den bygger på, mange ganger uten å komme videre. Det er null problem å regne når man har tilgang på strømmene inni trekanten. Det har ikke vi fra måleren.

[tronde]

4 timer siden, deve87 skrev:

Bare sånn hvis ikke det er sagt. IT-nett med 3 fas, måler kun 2 av fasene og beregner den siste. Så det er ingen data som mangler fra Adion måleren. Du får ampere fra L1 og L3.

 

Har du TN-nett derimot (med null leder). Benytter målere alle 3 faser og beregner null leder.

Internt i måleren er det kurant å regne ut absolutt alt ved å måle på to linjer med to-wattmetermetoden, så de verdiene som presenteres er korrekte.

 

Et to-wattmeter er mye mer komplisert enn å måle to strømmer og spenninger. Det tar hensyn til polariteten (øyeblikksverdien) så strømvektorene blir fastslått og da er det kurant. Vi kjenner ikke vektorene. Vi kjenner bare lengden uten retning.

 

Poenget med å kjenne alle tre strømmene er å kunne fordele last best mulig uten å ra sikringene, så det er absolutt interessant.

 

Hvis du sitter på en formel som faktisk gir ut korrekt I2 med de verdiene vi får ut av måleren må du gjerne dele den.

[deve87]

Det gjør jeg dessverre ikke. Har bare prøvd meg fram på summeringsmetoden.

 

Men dette gir neppe noe nøyaktig resultat.

 

 

Endret 17. desember 2019 av deve87

[aulvoy]

Hei

 

Jeg har brukt denne koden i Node-red for å regne meg til I2

 

    var U=(msg.payload.data.U1+msg.payload.data.U2+msg.payload.data.U3)/3;
    var S=Math.sqrt(Math.pow(msg.payload.data.P,2)+Math.pow(msg.payload.data.Q,2));
   
    var newI2={"payload":((S/U/Math.sqrt(3))*3-msg.payload.data.I1-msg.payload.data.I3).toFixed(1)};
    newI2.topic="I2";

 

 

Det blir vel noe som 

 

Gjennomsnitt spenning U=(U1+U2+U3)/3

 

Tilsynelatende effekt S=sqrt(P²+Q²)

 

I2=(S/U/sqrt(3))*3-I1-I3

 

 

Endret 17. desember 2019 av aulvoy

[deve87]

Takk

Endret 17. desember 2019 av deve87

[tronde]

Jeg har lagt inn formelen deres i regnearket. Når det er stor skjevbelastning går det galt. Skjevbelastning er ikke uvanlig i bolig. Jeg har målt alle linjestrømmene samtidig med strømtenger, og det kan godt være både tre og fire ganger forskjell mellom største og minste strøm.

 

Jeg regner kun med aktiv effekt og resistiv last. Det er helt umulig å nyttegjøre seg verdien for reaktiv effekt fordi vi ikke aner hvordan den fordeler seg i lasten. Det skal også prosentvis mye reaktiv effekt til før den får reell betydning for svaret. Den skal tross alt gjøre hypotenusen i trekanten en del større enn kateten for aktiv effekt før den betyr noe. Hvis vi vet at reaktiv effekt er jevnt fordelt, er det OK å regne med den. Hvis ikke er det ren bingo om vi gjør feilen i IL2 enda større eller mindre enn hva den allerede er. 

 

 

Modifisert regneark ligger her. Nå uten bilder.

Sett inn verdier for effekt, og se om feilen er akseptabel for dere. Ingen boliger er like, så det kan godt være at dere kommer greit ut av det med den formelen.

trefase_trekant_effekt_linjestroemmer_20191217_test.xlsx

[aulvoy]

Har dette kun for å ha en pekepinn på strøm i I2. Litt tomt i skjermen når det ikke er verdi der. 

 

 

 

Tall til venstre er målt med strømtrafoer på etter OV, det til høyre er fra AMS via MQTT til Node-red.  Så det blir noe avvik, men det kan jeg leve med. Dette justere seg hele tiden og brukes ikke til noe styring. 

[tronde]

Ja, det kan gå nokså bra hvis lasten ikke er altfor skjev. Når man er klar over at målingene ikke er perfekte vil man forholde seg til det. Problemet er når man tror at utregningen er korrekt, og svaret egentlig er helt borte, slik det faktisk kan være noen ganger.

 

Du er jo heldig som kan måle alternativt, for da får du et godt inntrykk av hvordan akkurat din last fordeler seg over tid, og kan ta hensyn til det hvis du føler for det.

 

Jeg skjønner veldig godt hvorfor de fleste tror at man enkelt kan regne ut manglende strøm, for det er nesten ingen som har lært noe om ubalansert trefase. Det er i hovedsak bare noen relativt få elkraftfolk som behøver å bry seg om det, og da stopper lærebøkene for de andre elektrofagene på balansert. Den læreboka jeg viser utdrag fra, er (var) for teknisk fagskole i elkraft, og det er ikke mye som står i den heller. Neste trinn er elkraft ingeniør, men det er det nesten ingen som studerer nå for tiden.

 

Jeg har heller ikke lært om ubalansert på skolen, men finner mange problemstillinger i et moderne kraftnett som jeg synes det er interessant å vite mer om, og da må jeg lære mer av det enkle også.

[SteinarK]

Litt sent til bordet i denne mega-tråden... Har kjørt med en RPi 3B med HAN usb-dongle mot Aidon i snart et år. Går dønn stabilt. Har programmert i C++ og multithreads. Streamer data over WiFi og pusher de rett inn i en MonetDB-database på en annen maskin. Buffrer data lokalt på RPi'en om nettet går ned, og pusher de i databasen når nettet er oppe igjen (kjører nettet ned om natten).

 

I forbindelse med at jeg nettopp har vært gjennom et prosjekt med å lage en uHAT til RPi, tenkte jeg å lage en RPi HAN uHAT (erstatte usb-dongelen mm). Ser for meg at jeg bytter ut RPi 3B'en med en RPi ZeroW + at data skal streames med MQTT i tillegg (evt kun MQTT). Planlegger også å kjøre det hele i Docker, samt dele imaget på DockerHUB.

 

RPi HAN uHAT'en vil følge uHAT standarden og ha eeprom som setter opp portene iht programvaren + optional Real Time Clock med batteribackup + optional RGB-led for å indikere status. Den skal kunne benyttes på alle RPi med 40 pin header. Benytter vertikal RJ45 kontakt + TSS721 for MBus2TTL på uHAT'en. Utlegget er klart for å sendes til pcb-produksjon.


 

Endret 22. desember 2019 av SteinarK

[SteinarK]

Da var Raspberry Pi HAN-uHAT produsert og testet.  Testet på ZeroW, 3B, 3B+, 3A+ og 4B+. Fungerer utmerket.

 

Test på RPi 3B:

  

 

 

Nesten ingen CPU-last på 3B:

 

 

Fungerer fint med vising av HAN-data i en kombinasjon av Highcharts og eCharts (javascript, nginx, uswgi, REST-api mot monetDB + mqtt for sisteverdier):

 

 

 

Endret 14. januar 2020 av SteinarK

[1v4r]

@SteinarK Dette er jo helt konge. Fikk du hatten produsert ferdig populert og hva ble pris? Selger du?

Endret 16. januar 2020 av 1v4r
Skrivefeil og referanser

[SteinarK]

Foruten selve pcb'et, gjør jeg alt selv (design, utlegg, lodding og montering). Har fått produsert 10 pcb'er. I utgangspunktet har jeg komponenter til 9 kort til , så muligheten til å avse noen burde jo alltids være der (har ikke tatt stilling til evt. pris).

Tenkte ellers å pushe programvaren på RPi'en i et docker-image, slik at en i det minste har muligheten til HAN-data over mqtt (om en har Aidon). I tillegg til HAN-rådata, så beregner jeg gjennomsnitt og standardavvik pr minutt på effekt, strøm og spenning og pusher også de over mqtt.

[1v4r]

@SteinarK Høres spennende ut. Jeg har ikke mye erfaring med populering selv men betaler gjerne litt for jobben om det er mulig å få tilsendt en ferdig hatt om det kan være et alternativ. Docker-image og mqtt passer utmerket.