Hvordan beregne kwH forbruk?

[OlavT]

AMS måleren leverer følgende data ut fra HAN-porten hver time:

 

Cumulative hourly active import energy (A+) (Q1+Q4) Wh
Cumulative hourly active export energy (A-) (Q2+Q3) Wh
Cumulative hourly reactive import energy (R+) (Q1+Q2) VArh
Cumulative hourly reactive export energy (R-) (Q3+Q4) VArh

 

Hvordan bergner jeg kWh forbruket som jeg finner igjen i Elhub portalen?

 

Dersom jeg tar bare med Wh i regnestykket mitt får jeg et lite avvik i forhold til tallet i Elhub.

[Hårek]

Active energy import er det tallet du ser på telleverket på måleren.

[OlavT]

3 hours ago, Hårek said:

Active energy import er det tallet du ser på telleverket på måleren.

Dette tallet stemmer ikke 100% med det som vises på Elhub. Det er et lite avvik.

[Hårek]

Tallet stemmer 100% for min del.

[OlavT]

8 hours ago, Hårek said:

Tallet stemmer 100% for min del.

Hvilken nettleverandør har du?

Endret 7. januar 2022 av OlavT

[OlavT]

Her er et eksempel fra mine data:

 

	7:00	8:00	9:00
Cumulative hourly active import energy (A+) (Q1+Q4)	81288.81	81291.23	81292.31
Cumulative hourly active export energy (A-) (Q2+Q3)	0	0	0
Cumulative hourly reactive import energy (R+) (Q1+Q2)	30332.1	30333.82	30333.82
Cumulative hourly reactive export energy (R-) (Q3+Q4)	1979.08	1979.18	1979.37
Diff		2.42	1.08
Elhub		2.421	1.082

 

Som dere ser så er målerverdiene fra Elhub nesten identiske med differansen i "Cumulative hourly active import energy (A+) (Q1+Q4)", men ikke 100%.

Endret 7. januar 2022 av OlavT

[Hårek]

Vel, var ikke i mine tanker å studere dette på timesnivå. Elhub data er for meg bare interessant på månedsnivå. 

Min Aidon har også en liten differanse på timesnivå når jeg ser på 3 desimaler. 

Antar denne differansen bare har å gjøre med håndtering av desimaler og avrunding. Data til Elhub har et annet format enn det vi får på HAN. Kanskje de leser av 3 desimaler. Kanskje er det også er forskjell på de 3 målertypene.

[OlavT]

56 minutes ago, Hårek said:

Vel, var ikke i mine tanker å studere dette på timesnivå. Elhub data er for meg bare interessant på månedsnivå. 

Min Aidon har også en liten differanse på timesnivå når jeg ser på 3 desimaler. 

Antar denne differansen bare har å gjøre med håndtering av desimaler og avrunding. Data til Elhub har et annet format enn det vi får på HAN. Kanskje de leser av 3 desimaler. Kanskje er det også er forskjell på de 3 målertypene.

Tror ikke det skal være noen avrunding noe sted. Jeg tar data fra HAN porten og deler på 1000 for å få kWh. Tallet er alltid rent og pent med to desimaler. Jeg runder ikke av noe. Det som går ut på HAN porten skal vel være det samme som går til nettselskapet? Jeg har sendt en henvendelse til Elvia og bedt om en forklaring på hvordan de regner ut det som rapporteres til Elhub. Min tanke var om reactive verdiene inngår i regnestykket.

Endret 7. januar 2022 av OlavT

[stigvi]

OlavT skrev (35 minutter siden):

Tror ikke det skal være noen avrunding noe sted.

Sannsynligvis har du det allikevel. 

[Hårek]

1 hour ago, OlavT said:

Tror ikke det skal være noen avrunding noe sted. Jeg tar data fra HAN porten

HAN porten gir deg data på OBIS format. Det er en unsigned integer, med tilhørende metadata som forteller hvordan det skal skaleres. Det er naturlig å konvertere dette til floating point format i brukerkoden. Da blir det opp til brukerkoden å definere hvor mange desimaler som skal presenteres.
Energi import har 2 desimaler i OBIS HAN formatet. Men du ser jo at Elhub bruker 3 desimaler. Du ser også at ditt eksempel viser nøyaktig det samme tallet hvis du avrunder.

Vi vet ikke formatet på data som Elhub mottar. Men vi antar at det ikke er helt det samme som HAN. 

[OlavT]

1 hour ago, Hårek said:

HAN porten gir deg data på OBIS format. Det er en unsigned integer, med tilhørende metadata som forteller hvordan det skal skaleres. Det er naturlig å konvertere dette til floating point format i brukerkoden. Da blir det opp til brukerkoden å definere hvor mange desimaler som skal presenteres.
Energi import har 2 desimaler i OBIS HAN formatet. Men du ser jo at Elhub bruker 3 desimaler. Du ser også at ditt eksempel viser nøyaktig det samme tallet hvis du avrunder.

Vi vet ikke formatet på data som Elhub mottar. Men vi antar at det ikke er helt det samme som HAN. 

Var ikke hele poenget med HAN-porten at forbruker skulle ha tilgang til de samme data for avregining som nettleverandøren? Det har jo noe med å kunne etterprøve faktureringsgrunnlaget for eksempel. Men, det kan se ut som om Elhub opererer med 3 siffer og HAN med 2 siffer bak komma på kWh. Dersom jeg tar siste verdi for en måned og trekker fra første verdi så stemmer det fortsatt ganske bra (et ekstra siffer bak komma på Elhub). Tror nok at konklusjonen kan være at data til nettleverandør og det som kommer ut på HAN-porten er litt forskjellig.

 

Dette er forøvrig koden min for akkurat dette:

 

                CosemUnsigned32 value = (CosemUnsigned32)cosemStructure[1];
                CosemStructure scaleUnitStructure = (CosemStructure)cosemStructure[2];
                CosemInteger8 scale = (CosemInteger8)scaleUnitStructure[0];
                double kwh = value.Value * Math.Pow(10, scale.Value) / 1000;

Endret 7. januar 2022 av OlavT

[Hårek]

Gjør du forsøk på å regne ut strømregningen med egne data på forbruk og timespris? I såfall, blir det noe avvik?

[OlavT]

Nei, hadde ikke tenkt å gå langt enda. Ville bare sjekke om jeg fikk samme tall som på elhub. Men, det kunne jo vært artig å tatt det helt ut til en full avregning.

[Alexander Frøyseth]

OlavT skrev (På 1/7/2022 den 7.10):

Her er et eksempel fra mine data:

 

	7:00	8:00	9:00
Cumulative hourly active import energy (A+) (Q1+Q4)	81288.81	81291.23	81292.31
Cumulative hourly active export energy (A-) (Q2+Q3)	0	0	0
Cumulative hourly reactive import energy (R+) (Q1+Q2)	30332.1	30333.82	30333.82
Cumulative hourly reactive export energy (R-) (Q3+Q4)	1979.08	1979.18	1979.37
Diff		2.42	1.08
Elhub		2.421	1.082

 

Som dere ser så er målerverdiene fra Elhub nesten identiske med differansen i "Cumulative hourly active import energy (A+) (Q1+Q4)", men ikke 100%.

Ut fra dette så vil jeg si at du får de samme tallene, bare med en annen oppløsning (1Wh kontra 10 Wh). Og maks avvik per enkelt time vil da være 5Wh, summert opp for 30 dager så tilsvarer det 3,6 kWh.

Så selv om det urealistisk vil lese av et maks avvik hver time, og bruke dette i en månedsavregning, så vil det fortsatt ikke ha noen betydning 😊 og hvis du tar månedsavregning ved å ta diff total målerstand over måneden, så vil maks avvik mot elhub være 5Wh, altså ubetydelig 😉

 

Matematisk så har du like verdier i elhub og hanport når du tar høyde for antall gjeldende siffer

[OlavT]

On 08/01/2022 at 19:06, Alexander Frøyseth said:

Ut fra dette så vil jeg si at du får de samme tallene, bare med en annen oppløsning (1Wh kontra 10 Wh). Og maks avvik per enkelt time vil da være 5Wh, summert opp for 30 dager så tilsvarer det 3,6 kWh.

 

Dersom dette er avrunder så blir nok summen av timene ganske likt som å ta siste måling for måneden og trekke fra første. Noen ganger vil jo HAN-data for en time ligger under Elhub og andre ganger over så dette jevner seg ut over måneden.

 

Jeg har lagt inn en sak hos Elvia så får vi se hva de svarer. Jeg synes fortsatt det er merkelig at oppløsningen til nettselskapene / Elhub er forskjellig fra HAN-data.

[OlavT]

On 08/01/2022 at 19:06, Alexander Frøyseth said:

Ut fra dette så vil jeg si at du får de samme tallene, bare med en annen oppløsning (1Wh kontra 10 Wh). Og maks avvik per enkelt time vil da være 5Wh, summert opp for 30 dager så tilsvarer det 3,6 kWh.

Så selv om det urealistisk vil lese av et maks avvik hver time, og bruke dette i en månedsavregning, så vil det fortsatt ikke ha noen betydning 😊 og hvis du tar månedsavregning ved å ta diff total målerstand over måneden, så vil maks avvik mot elhub være 5Wh, altså ubetydelig 😉

 

Matematisk så har du like verdier i elhub og hanport når du tar høyde for antall gjeldende siffer

 

Da har jeg fått bekreftet fra Elvia at data som sendes ut på HAN-porten har en presisjon på 10Wh og at data som sendes til HES (Head-end-System) / Elhub har en presisjon på 1Wh. Hva bakgrunnen er for at data sendes ut med forskjellig presisjon har jeg ikke fått svar på enda. Virker litt merkelig.

[The X]

OlavT skrev (13 timer siden):

 

Da har jeg fått bekreftet fra Elvia at data som sendes ut på HAN-porten har en presisjon på 10Wh og at data som sendes til HES (Head-end-System) / Elhub har en presisjon på 1Wh. Hva bakgrunnen er for at data sendes ut med forskjellig presisjon har jeg ikke fått svar på enda. Virker litt merkelig.

Ser for meg 10Wh ikke er det faktiske avviket, men hvilket avvik som tollereres.

Forskjellen på 1Wh og 10Wh kan også som dere har vært inne på være margninen av om det brukes 3 desimaler eller 2 desimaler med avrunding.

Men hadde vært mer beroligende om de hadde oppgitt dette som %...

HAN-port data er "live og rå"...
Elhub data er det som faktureres, og er akumulert og sendt i større bolk som trolig gir et mer nøyaktig snitt pr tidsenhet, en live data fra HAN...
Uansett så små marginer her at det er ikke noe å ha søvnløse netter av.

[stigvi]

Bare til opplysning så sender min måler antall kwh forbrukt med 3 desimaler. Det har kanskje noe med hvilken måler det er.

[OlavT]

1 hour ago, stigvi said:

Bare til opplysning så sender min måler antall kwh forbrukt med 3 desimaler. Det har kanskje noe med hvilken måler det er.

Ut på HAN-porten?

[stigvi]

OlavT skrev (9 timer siden):

Ut på HAN-porten?

Ja

[Hårek]

11 hours ago, stigvi said:

Bare til opplysning så sender min måler antall kwh forbrukt med 3 desimaler. Det har kanskje noe med hvilken måler det er.

Men hvorfor sier du da ikke hvilken måler du har?

[stigvi]

Hårek skrev (13 minutter siden):

Men hvorfor sier du da ikke hvilken måler du har?

Fordi ingen har spurt. Men det er en Aidon 6534

[Hårek]

Aidon HAN Interface Description, Norwegian HAN spesification - OBIS Codes: 16 Active energy import, with resolution of 10 Wh, Format 7.2 ( xxxxxxx.xx kWh)
Det du viser er bare at din utskrift har 3 desimaler.

[stigvi]

Hårek skrev (17 minutter siden):

Det du viser er bare at din utskrift har 3 desimaler.

Nei, ikke bare min, men alle som bruker amstomqttbridge. Jeg tok en rask titt i kildekoden og ser at det som leses fra HAN porten blir konvertert til flyttall og deretter til streng når det sendes til mqtt broker. Ser ikke vekk i fra at 3. siffer etter punktum "bare er der" fordi det går innom et flyttallformat, men det får @gskjold eventuelt svare på.

Increase accumulated values to 3 decimals · gskjold/AmsToMqttBridge@6d12d71 (github.com)

[OlavT]

15 hours ago, stigvi said:

Ja

Utskriften din er jo fra Klepp Energi. Det er jo ikke nødvendigvis det samme som kommer ut på HAN-porten.

Endret 14. februar 2022 av OlavT