mtabu

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

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)

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.

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

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.

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.

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

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.

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.

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.