mtabu

6 timer siden, tronde skrev:

Jeg tror jeg forstår hvorfor det blir feil.

 

Fasestrømmene er 120⁰ innbyrdes forskjøvet så lenge det er resistiv last, men siden linjestrømmene er et resultat av sett med to-og-to fasestrømmer som har ulik størrelse, vil vektorene som representerer linjestrømmene ikke være 120⁰ innbyrdes forskjøvet.

 

Det er synlig i lærebokeksempelet, men siden de linjestrømmene er nokså like, er det ikke utpreget. Jeg har lagt til en figur som ble oversett, og der er det lett å måle.

Målt med transportør på figuren får jeg 105⁰, 120⁰ og 135⁰. Selv om vinklene er ulike, er vektorsummen av de tre strømmene null slik den skal være.

 

 

Jeg har også lekt litt med et regneark hvor jeg lot de tre strømmene være forskjøvet 120⁰. Når alle linjestrømmene er like, vil summen av momentanverdiene bli null, men når forskjellen i styrke øker, vil også avviket fra null øke kraftig. Dette bekrefter at linjestrømmene ikke har lik innbyrdes vinkel.

 

Da er vel spørsmålet om vi har nok data til å regne ut den siste strømmen. Det går kanskje an å finne en slags korreksjonsfaktor som gir et akseptabelt avvik baset på de verdiene vi kjenner?

 

Jeg benytter denne:

 

Eller for å bli litt mer i samsvar med læreboka.

Figuren over parallellforskyver vektorene slik at de danner en trekant.  De "virkelige" vektorene finner du i figuren under.

Vinkelen til vektorene finner jeg ikke, bare lengdene. (Negativ vektor vises i rødt.) 

35 minutter siden, tronde skrev:

Nå har jeg etter beste evne målt med litt ulik belastning. 

 

Vi ser at strøm målt med strømtang avviker noe fra det som måleren gir ut. Jeg legger ved data som *.xlsx også.

 

Strømtang er ikke veldig nøyaktig hvis man ikke legger i en god slump penger, men siden tallene fra måleren også står i tabellen går det an å korrigere verdiene fra tanga.

 

https://www.kew-ltd.co.jp/en/products/detail/00030/

 

...

Aidon_strøm_fase.xlsx

 

En kolonne med mine beregninger av i2.  Ikke helt samsvar, men ikke helt på jordet heller. Har du med reaktiv last også? Siste kolonne har jeg byttet ut med kyoritsu i1 og i3

Jeg får en desimal mindre presisjon på strøm og kW fra min måler (den er også Aidon 6525)

17 timer siden, tronde skrev:

 

Jeg har ikke prøvd å regne på tallene dine, men hvor havner du hvis du bruker tallene fra lærebokeksempelet? Du kan jo regne med to fritt valgte av strømmene og se om det går opp.

U=380V.

IL1=15,5A

IL2=22A

IL3=19,5A

P=12350W.

 

Jeg er helt enig i at det mest viktige er ca.-verdi for å beholde sikringene hele. Det vil helt sikkert være ulik reaktiv last i alle fasene, og det tviler jeg på at man kan regne ut noe nøyaktig med.

 

Jeg tror heller ikke at vi behøver å regne med ulik spenning på hver fase. Hva med enten største verdi, eller gjennomsnittet av de tre verdiene? Svaret vil uansett ikke bli 100% når vi ikke kjenner hvordan den reaktive lasten er plassert. I tillegg vil det flyte reaktiv last ut (eller inn) siden nettet vil prøve å fasekompensere seg selv. Hvis du har induktiv last, og naboen kapasitiv last, vil disse prøve å balansere seg --> kaos. Vi har heller ingen mulighet til vite hva vi har, for reaktiv effekt kommer uten fortegn ut av HAN-porten.

 

Hvis andelen reaktiv last er lav, vil tallene stemme mer enn godt nok slik jeg ser det, gitt at formelen din er OK. Hvis det skal være stor andel reaktiv last, bør det helst være når det ikke er særlig annen last, og da er nok ikke den totale strømmen kritisk stor heller.

 

Det er jo mulig å regne ut cos(fi) når vi kjenner aktiv og reaktiv effekt, selv om det vel også forutsetter at alle fasene er like reaktive, og hvis cos(fi) kryper for langt under 1 er det en indikasjon på at strømmene blir mer usikre. Om det har noen fornuft i seg å gjøre det, kan sikkert diskuteres. Tallene dine tyder på at det ikke er bryet verdt.

 

Når vi ikke får ut mer fra måleren enn det vi gjør, kan vi ikke gi tallene våre en nøyaktighet vi ikke kan forsvare heller. Da er det like greit å vedta at lasten kun er aktiv.

 

Ved å legge inn tallene fra boken får jeg ved å holde en av linjestrømmene "ukjent":

ved "ukjent IL1", beregner jeg denne til 15.3A

Ved "ukjent IL2" beregner jeg denne til 21.8A

Ved "ukjent IL3" beregner jeg denne til 19.3A

(Dvs. konsekvent 0.2 for lite - kan være relatert til avrunding. Om jeg legger inn IL1 og IL2 med 0.1 lavere, får jeg korrekt IL3).

Min metode finner også fase-strømmene og avrunder til en desimal. Deretter beregnes linje-strømmen som også avrundes. Så det gir god mulighet til å aggregere avrundingsfeil.

 

Vi får reaktiv + og reaktiv - som forskjellige verdier, og power og power -

 

Det ser også ut til at verdien ikke er helt i synk.  Ved dropp i effekt, kan det se ut til at effekten henger litt etter. Under har jeg benyttet effekten fra forrige måling for å beregne de ukjente, og treffer ganske godt med forrige beregning. Jeg tror det er en vaskemaskin som er ferdig..

 

Det er en del reaktiv last. Her er fra en times-melding (47327 kWh, -0kWh, 7kVArh og -11 318 kVArh)  (blir det kVArh?)

 

Jeg hadde foresten byttet om fase-strømmenespenningene, men som du sier har det nok ikke så mye å si.

På 18.2.2019 den 22.38, tronde skrev:

@mtabu

 

Det står litt stille i toppen for øyeblikket, men det ser ut som om de bruker det som er kjent som "to-wattmetermetoden".

Vi vet at Kaifa gjør det, selv om de gir ut alle tre strømmene.

 

https://circuitglobe.com/two-wattmeter-method-of-power-measurement.html#MeasurementofPowerbyTwoWattmeterMethodinDeltaConnection

 

Denne beskrivelsen viser egentlig wattmetre slik de var i gamle dager hvor det var en strømspole og en spenningsspole i ett viserinstrument som ga ut svaret i watt. I eksemplet har vi måleverdiene for begge wattmetrene, mens vi bare har en verdi fra Aidon siden de regner internt. Jeg synes vi mangler noe for å finne alle tre strømmene. Vi må huske på at det er 120° faseforskjell mellom dem, og det betyr at de ikke er der samtidig.

 

 

Med det som kommer ut av Aidon ser det vel slik ut, hvor det er blå I1, I2 og I3 som er interessante å finne siden de er strømmen i sikringene.

 

.. snipp ..

Resten av læreboka hos Nasjonalbiblioteket

 

Nytt forsøk.  

 

Jeg prøver meg med at strømmene står 120° på hverandre. Dette gir en likningen:

 

I1 * I1 = I12 * I12 + I12 * I13 + I13 * I13

 

Med litt fikling får jeg formelen: (jeg prøver å utlede alle strømmene som funksjon av en av fase-strømmene - og ender opp med en 2. grads likning med).

 

power = i * spenning1 - (i - Sqrt(4 * strømL1 ^2 - 3 * i ^2)) / 2 * Spenning2 - (i - sqrt(4 * strømL3^3 - 3 * i ^ 2)) / 2 * spenning3

(Jeg kan ha byttet om på spenning1, spenning2 og spenning3 - jeg må sjekke dokumentasjonen hvilken fase de representerer).

 

Jeg Itererer i mellom 0 og størst av StrømL1 og StrømL3, og beregner effekten.  

 

Den effekten som er nærmest rapportert den rapporterte effekten (sqrt(ActivePower ^2 + ReactivePower ^2)) velger jeg.

 

Valgt i benytter jeg til å beregne de to andre fasene:

En av de andre fasene: (i - Sqrt(4 * strømL1 ^2 - 3 * i ^2)) / 2

Den siste fasen: (i - sqrt(4 * strømL3^3 - 3 * i ^ 2)) / 2

 

Linjestrømmen for L2 blir da

sqrt ( strøml2l3 ^ 2 + strøml2l3 * strøml1l2 + strøml1l2 ^ 2)

 

Under viser jeg dump fra mitt lille program som forbruker mqtt meldinger sendt fra min 8266 og beregner L2 og fase-strømmene. (Jeg har ikke sjekket om jeg har sortert korrekt alle strømmer og spenninger, så den kan være litt feil)

 

Jeg vil tippe strømmene ikke er helt korrekt pga. den reaktive strømmen (jeg vil jo tro denne ikke er jevnt fordelt utover fasene, og kan ha mer å si for et av bidragene enn de andre, og jeg vil tro at det da blir umulig å løse korrekt - er det en korrekt antakelse?)

 

Bildet viser et tidspunk jeg skrur på bil-lading på fasen l1 l3. Den skal kunne trekke maks 32A, men laderen rapporterer 6,7kW lading (dvs. ikke fult 32A, men ca. 30,8A)

alt med (ber) eller (b) er beregnede kolonner.

 

Om resultatet ikke er helt rett, så er ikke det veldig viktig. Det jeg synes er viktig er å kunne sette ca. begrensning på fase-strømmene, slik at ingen av linje-strømmene overgår hovedsikring, og at de blir så lik som mulig (dvs. at lader blir styrt til å benytte den fasen som har minst belastning).

 

Det virker jo som at det er noen her som har kunnskapen til å kunne si om jeg er helt på jorde (igjen), eller inne på noe  .

 

Om jeg er inne på noe, finnes det en vanskelig ligning å løse også.

På 17.2.2019 den 4.32, tronde skrev:

Jeg kan svare meg selv, for det gikk an å kopiere ut all teksten fra pdf-en.

 

 

 

Spørsmålet blir hvordan det skal forstås, og om det i det hele tatt kan brukes til noe fornuftig. Må sove litt på det.

 

Siden det er strømmen vi skal regne ut, bør vi helst ta utgangspunkt i tilsynelatende effekt, og ikke aktiv effekt.

Den er til å regne ut når vi kjenner aktiv effekt (P) og reaktiv effekt (Q).

 

 

 

 

Er det noen som har data fra et system med varmepumpe og / eller el-billadere som kan si noe om hvor mye reaktiv effekt det er realistisk å ha i en bolig?

Dette var vel akkurat den jeg trengte..

 

S = SQRT(Q ^ 2 + P ^ 2).

 

Det er vel P og Q som kommer i meldingene?

 

For meldingene en mottar, må en vel muligens gjøre noe slikt

SQRT([Q+]^2 + [Q-]^2 + [S+]^2 + [S-] ^2)

 

I de meldingene jeg har sett blir aldri både [Q+] og [Q-] fylt ut, eller [S+] og [S-].

 

Strømmene om blir målt er I1 og I3 (i følge Obis kodene). 

 

Måten å finne I2:

 

I1 sin strøm går noe til I2 og resten til I3.  

For I3 sin strøm går noe mot I1 og resten mot I3.

 

For beregningen under:

Spenningen mellom L1-L2 : U12

Spenningen mellom L2-L3 : U23

Spenningen mellom L1-L3 : U13

Strøm mellom L1 og L2: I12

Strøm mellom L2 og L3: I23

Strøm mellom L1 og L3: I13

 

S = I12 * U12 + I23 * U23 + I13 * U13

(Bruk formelen over til å finne S)

 

I1 = I12 + I13

I3 = I13 + I23

 

Finner en I13, vil en finne alle de andre ukjente (og I3).

I13 = (S - I1 * U12 - I3 * U23 ) / (U13 - U12 - U23)

I12 = I1 - I13

I23 = I3 - I13

I2 = I12 + I23

(Er jeg inne på noe?)

 

Jeg formaterer meldingene jeg får fra måleren via Obis kodene, eksponent (-1 for amp og V og +1 for wh) og enumene (W,VAr,A, V etc..) jeg mottar.:

{

 "ObisIdent":"AIDON_V0001", 

 "MeterId":"***",

 "MeterType":"6525",

 "ActivePower":"7067W",

 "ActivePowerMinus":"0W",

 "ReactivePower":"0VAr",

 "ReactivePowerMinus":"555VAr",

 "CurrentL1":"24.9A",

 "CurrentL3":"8.0A",

 "ULN1":"223.3",

 "ULN2":"222.6V",

 "ULN3":"223.2V"

}

 

De korte meldingene ser slik ut:

{"ActivePower":"7101W"}

 

Timesmeldingen har aggregerte felt for ActivePower og ReactivePower i tillegg (med begge fortegn).

 

Ved lesing av rådata fra måleren, lar jeg leseren få timeout dersom den ikke mottar flere tegn til meldingen innen 600 millisekunder (muligens er det slik at meldingen må mottas i sin helhet innen 600ms).  Dette gjør at dersom lesingen begynner i midten av en melding, får den en timeout, og neste melding blir ok.

 

Jeg har planer om å lage en algoritme som gjør at melding med og uten escape-håndtering (0x7e + 0x7d) kan håndteres.  Dvs tolk meldingen først som om den ikke benytter escape. Om ikke neste tegn er 0x7e, eller om ikke CRC er ok, behandle meldingen som at den er escapet etter spesifikasjonen.

13 minutter siden, xibriz skrev:

Dere kan prøve må endre `MQTT_MAX_PACKET_SIZE` til f.eks. 512 i PubSubClient.h 

 

Ref. punkt 2 i Limitations: https://github.com/knolleary/pubsubclient

 

Dette er sikkert også en begrensning jeg ikke tror vises på din melding (meldingen ville bli kuttet kort).

Mitt problem relaterte seg til størrelsen på StaticJsonBuffer som gjorde at ikke alle elementene i listen kom med i json.

 

I forhold til problemet her.  Se i AmsToMqttBridge.ino linje 223.

For Kamstrup brukes Static Json buffer med 500 tegn som maks.  I Kaifka er det byttet til "DynamicJsonBuffer" - sikkert fordi deler av meldingen forsvant. 

 

Bytt til DynamicJsonBuffer eller øk bufferen. Bufferen inneholder både json og objektene som skal til for å holde strukturen til json, så den trenger å være større enn meldingen.

På 29.4.2018 den 20.48, LenothX90 skrev:

Hei,

Jeg flashet til "AmsToMqttBridge.ino" idag, men får ikke ut mer enn "P"  ?

Kaifa måler, Haugaland Kraft.

Hvert 10 sek, når den skulle ha kommet, stopper bare mqtt'en som vist nedenfor: 

Ams {"id":"5C::BF","up":25926618,"t":1525033904,"data":{"P":2472}} 
Ams {"id":"5C::BF","up":25928552,"t":1525033906,"data":{"P":2469}} 
Ams {"id":"5C::BF","up":25930558,"t":1525033908,"data":{"P":2471}}
- pause 
Ams {"id":"5C::BF","up":25935160,"t":1525033912,"data":{"P":2482}} 
Ams {"id":"5C::BF","up":25936554,"t":1525033914,"data":{"P":2456}} 
Ams {"id":"5C::BF","up":25938599,"t":1525033916,"data":{"P":2470}} 
Ams {"id":"5C::BF","up":25940524,"t":1525033918,"data":{"P":2469}}
- pause
Ams {"id":"5C::BF","up":25945126,"t":1525033922,"data":{"P":2472}} 
Ams {"id":"5C::BF","up":25946519,"t":1525033924,"data":{"P":2462}} 
Ams {"id":"5C::BF","up":25948565,"t":1525033926,"data":{"P":2461}} 
Ams {"id":"5C::BF","up":25950582,"t":1525033928,"data":{"P":2464}}
- pause 
Ams {"id":"5C::BF","up":25955104,"t":1525033932,"data":{"P":2470}}
Ams {"id":"5C::BF","up":25956566,"t":1525033934,"data":{"P":2461}} 
Ams {"id":"5C::BF","up":25958621,"t":1525033936,"data":{"P":2465}} 
Ams {"id":"5C::BF","up":25960546,"t":1525033938,"data":{"P":2467}}

 

How to correct ? 

 

Jeg har hatt et lignende problem ved generering av json.  Mitt problem var at bufferen for å lage json var for liten.

Målerdata fra Hafslund måler (Aidon). 

 

Jeg får ikke ampere til å stemme overens med forbruket. Spesielt posisjon 0x40 gir altfor høy ampere. Summen av de tre fasene burde være under 10A.

 

De første 16 tegnene er målernummeret som ascii (0x30 = "0")

Det vil vel da også si at det ikke er noe start-tegn for pakken, men at pakken kun blir terminert av 0xc0, og at den må være 100 tegn lang.

 

Tidspunktet som vises er i Zulu tid, og er tatt fra en ntp server.

Jeg har fulgt SLIP dekodingen, og kan ikke se å ha fått problem med noen ekstra tegn / feil tegn.

 

Jeg har hatt måleren en stund (1,5 år).

 

6 timer siden, frodegill skrev:

* Måleren ble installert i starten av mars, men det er interessant å se om det er en teller av noe slag. Skal følge med på den.

 

Nå har jeg litt mer data.

24.4 15:46: 149111

23.4 22:30: 146914

 

Det gir ca. økning på ca 128 pr. time. Teller en tilbake til 0 får en 6.3.18 19:52 

Det er sikkert en teller for antall timer måleren har vært tilkoblet strøm.

Ikke nødvendigvis så veldig nyttig. 

Jeg får se om jeg får koblet opp noe mot min egen måler for å sammenligne. Jeg har noen op-amp'er og en drøss med motstander liggende et sted, så jeg burde klare å få til et-eller-annet.

3 minutter siden, frodegill skrev:

 

* Først og fremst ser det ut til at du har fått presentert en datapakke mens den var i ferd med å fylles. Der må jeg gjøre noe, takk for å ha gjort meg oppmerskom på det!

* Jeg gjør veldig lite parsing nå. Baserer meg kun på en melding fra cpu22 her inne. 0xdb håndterer jeg ganske enkelt med å fjerne etterfølgende byte. I bufferen du ser har det derfor blitt fjernet en byte mellom 0xdb og 0xc0. Fint at du linker til protokoll. Skal lese den og se om jeg må gjøre tilpasninger..

* Måleren ble installert i starten av mars, men det er interessant å se om det er en teller av noe slag. Skal følge med på den.

* Frekvensen er på listen min over merkelige ting. Fint hvis det viser seg å ha en enkel løsning. (listen toppes forøvrig av "sjekksum er IKKE OK". Jeg vet at crc16-koden skal fungere og gi riktig verdi, men i og med at jeg har kuppet serial1 er det litt problematisk å debugge på nodemcu''en jeg bruker. Kommer nok snart til å dukke opp litt debug-informasjon rett i datapakke-presentasjonen)

* Om akkumulert forbruk er MWh eller kWh er vel helt irrelevant? Det står i MWh (uten desimaler) på display på måleren. Og forbruket skal vel ikke være Wh? Jeg er ingen elektriker, men forbruket er vel Watt, og Wh forutsetter vel at jeg holder jevnt forbruk en hel time (eller i hvert fall over en tidsenhet)?

Jeg klarte å få en pakke til som ser ut til å slutte på 0xc0, så jeg tror min antakelse er rett. Det ser ut til at pakken alltid blir fylt før den blir presentert til klient.

Mitt poeng er at endrer du MWh til kWh, så vil den vise korrekt. Det vil stemmer godt overens med forbruk * tid. Med forbruk på ca. 3kW økte akkumulert forbruk med litt over 1 på 25 minutter. 

 

For debugging på 8266, lar jeg nodemcu logge over tcp/ip (benytter asynctcp) til egen server / loggeprogram.

På 17.4.2018 den 9.44, frodegill skrev:

FWIW: Jeg har nå koblet opp nodemcu og "TSS721 Module Board M-BUS To TTL" fra aliexpress mot min Aidon AMS fra Hafslund, der Hafslund insisterer på at porten ikke er aktiv. Kan bare bekrefte alt cpu22 allerede har funnet ut. Med 9600 baud, SERIAL_8N1, mottas 100(/101) bytes hvert minutt. Hvis noen har interesse av det er siste buffer løpende tilgjengelig på https://gill-roxrud.dyndns.org:8207/ (som sagt er det en nodemcu i andre enden, så vær snill med request-størrelse..)

 

Jeg fikk denne: ca. 21:50:

0x00: 0x37 0x33 0x35 0x39 0x39 0x39 0x32 0x39 0x30 0x35 0x33 0x32 0x31 0x34 0x38 0x34
0x10: 0x9A 0x09 0x58 0x00    Akkumulert forbruk: 5769.63MWh
0x14: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE6 0x3D 0x02 0x00 0x00 0x00 0x00 0x00 0xDB 0xC0
0x30:    Forbruk: 0W
0x34:

...
 

Noen viser til at dette er SLIP data.  I dette tilfellet kommer det en 0xdb [Frame escape] med en 0xc0  [Frame end].  Det skal i så fall tolkes som 0xc0 og ikke som [Frame End]. 0xdb 0xdb skal tolkes som 0xdb

https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

 

posisjon 0x20 ser ut til å ha en teller av noe slag. Den økte med ca 73 i løpet av en time. Ble måleren installert i slutten av januar? 

 

posisjon 0x5e er frekvens * 100. (gir ca. 50)

 

Akkumulert forbruk bør vel ha kWh som benevning. Forbruket ser ut til å være angitt som Wh

 

Mitt forsøk på å lage egen ams leser.

 

Resten av komponentene må bare komme seg fra Kina først. RJ45, diverse motstander, ic'er, transistorer, kondensatorer. Det er mitt første forsøk på SMD

 

Jeg har ingen hastverk med å bli ferdig siden jeg har Hafslund uansett.