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

[gskjold]

48 minutes ago, tronde said:

Nå har jeg lagt inn 2.0-rc4 og prøver meg med 125 som multiplier på norske kroner.

 

Da ender jeg opp med dette når jeg åpner vinduet på nytt, og det er denne verdien som brukes i beregningene også.

NO1 blir stående nå, det ser ut til å være fikset.

 

Edit: Det ble litt dårlig kvalitet, men det er helt tydelig at det står 59,464 med komma som desimalskille.

 

 

 

Sikkert en overflow på det feltet, husker ikke helt hvor mange bit jeg valgte der. Hvorfor 125 i multiplier og ikke 1.25? 

[tronde]

gskjold skrev (2 timer siden):

Sikkert en overflow på det feltet, husker ikke helt hvor mange bit jeg valgte der. Hvorfor 125 i multiplier og ikke 1.25? 

Prøvde litt forskjellig for å se hva som kunne skje, og det sto 125 som et eksempel i wikien, så jeg gikk ut fra at det var OK.

 

Ingen sure miner fra meg, jeg bare prøver å følge opp den forrige med euro som jeg ikke klarte å gjenskape.

[gskjold]

8 hours ago, tronde said:

Prøvde litt forskjellig for å se hva som kunne skje, og det sto 125 som et eksempel i wikien, så jeg gikk ut fra at det var OK.

 

Ingen sure miner fra meg, jeg bare prøver å følge opp den forrige med euro som jeg ikke klarte å gjenskape.

Aha, ja da er jeg enig at 125 burde ha vært helt innafor. Jeg har sikkert klart å gjøre en endring et sted, skal se på det

[tronde]

@gskjold

Historikken for månedsforbruket forsvant i løpet av natta.

 

V2.0-rc4 Wemos D1

 

 

 

[gskjold]

16 minutes ago, tronde said:

@gskjold

Historikken for månedsforbruket forsvant i løpet av natta.

 

V2.0-rc4 Wemos D1

 

Ja desverre, det er egentlig relatert til en feil i tidligere kode. Den skal være i orden igjen fra neste døgn

[tronde]

gskjold skrev (3 timer siden):

Aha, ja da er jeg enig at 125 burde ha vært helt innafor. Jeg har sikkert klart å gjøre en endring et sted, skal se på det

Det er nok noe 16-bit inne i bildet. 65.535 er OK, 65.536 gir 0.

Er det noen potensielle bomber hvis strømprisen blir to-sifret? Det går rykter om at det kan skje.

 

[stigvi]

tronde skrev (1 time siden):

Er det noen potensielle bomber hvis strømprisen blir to-sifret? Det går rykter om at det kan skje.

I følge forståsegpåere og politikere var det helt utenkelig så kort tid tilbake som i oktober.

[ArnieO]

12 minutes ago, stigvi said:

I følge forståsegpåere og politikere var det helt utenkelig så kort tid tilbake som i oktober.

😂

[tronde]

Jeg tenkte mest på at adapteret ikke går i vranglås hvis det blir tilført høye verdier på strømprisen. Det vil være dumt hvis selve grunnlaget for styringen konker ut når det behøves mest.

[tronde]

@gskjold

 

ESP32 med 2.0-rc4 har plutselig fått det for seg at jeg har hatt mye eksport i siste døgn, og verdiene er også feil,  mens Wemos D1 med rc-4 ikke gjør det. 

 

Er dette samme feilen som fjernet historikken?

 

Wemos

 

[tronde]

Ny time, og historikken stemmer igjen, men ingen grafikk for siste måned.

 

Endret 6. desember 2021 av tronde

[gskjold]

Interessant. Jeg skal se om jeg klarer å fremkalle denne. Og når det gjelder skyhøye strømpriser så mener jeg koden er dimensjonert for det, men med tanke på en usikker fremtid i strømmarkedet så skal jeg få testet det

[xibriz]

En annen ting, jeg vet at nettselskapet kan bruke AMS-måleren til å se jordfeil. Er dette noe man kan dra ut av HAN-porten?

 

[ArnieO]

3 minutes ago, xibriz said:

En annen ting, jeg vet at nettselskapet kan bruke AMS-måleren til å se jordfeil. Er dette noe man kan dra ut av HAN-porten?

 

Godt spørsmål! Jeg minnes å ha lest noe om det der.

 

Der er ingen data på HAN-porten som (så vidt jeg kan forstå) kan brukes til å detektere jordfeil. Så enten er dette en måling som kun går til nettselskapet, eller så bruker de en kombinasjon av mange målinger til å avdekke hvor i et nabolag jordfeilen er.

[xibriz]

1 minute ago, ArnieO said:

Godt spørsmål! Jeg minnes å ha lest noe om det der.

 

Der er ingen data på HAN-porten som (så vidt jeg kan forstå) kan brukes til å detektere jordfeil. Så enten er dette en måling som kun går til nettselskapet, eller så bruker de en kombinasjon av mange målinger til å avdekke hvor i et nabolag jordfeilen er.

 

Grunnen til at jeg spør er at en slektning ble kontaktet av kraftselskapet om at han hadde jordfeil og måtte fikse det. En elektriker fant jordfeil i en skjøteledning etter 3-4 timers feilsøking.

 

Også leser jeg her: https://www.tromskraftnett.no/privat/ams

 

Quote

• Med AMS installert vil vi kunne oppdage jordfeil og varsle kunden. Vi vil også kunne bistå online med å detektere jordfeil når installatør eller kunde tester kurser i anlegget. 

 

Så da tenkte jeg at kanskje man kunne være preventiv hvis man visste dette så fort som mulig (kanskje man akkurat hadde plugget i noe).

[ArnieO]

Godt eksempel!

Men som sagt... kan ikke se noe som kan brukes til det av det som kommer på HAN-porten.

Dette er dokumentasjonen som er tilgjengelig: https://github.com/gskjold/AmsToMqttBridge/tree/master/doc

[xibriz]

Vi får vente til en kar fra ett kraftselskap med litt teknisk kompetanse stikker innom tråden  

[tronde]

xibriz skrev (7 timer siden):

En annen ting, jeg vet at nettselskapet kan bruke AMS-måleren til å se jordfeil. Er dette noe man kan dra ut av HAN-porten?

 

Ganske sikkert ikke. Aidon har reklamert med at alle deres målere levert i Norge har innebygget sumstrømtrafo for å lese jordfeil, men at den funksjonen selges til nettselskapet som en ekstra tjeneste. Det nevnte rundt 10% påslag i forhold til måler uten aktivert funksjon.

 

Jeg har forstått at målerleverandørene også leverer en god del software til nettselskapene både for rapportering til Elhub, og drift / overvåking av eget nett.

 

gskjold skrev (8 timer siden):

Interessant. Jeg skal se om jeg klarer å fremkalle denne. Og når det gjelder skyhøye strømpriser så mener jeg koden er dimensjonert for det, men med tanke på en usikker fremtid i strømmarkedet så skal jeg få testet det

Finland gikk opp i 1000,07 EUR pr. MWh mellom 0700 og 0800 i dag, så muligheten for to-sifret pris er der.

[tronde]

Strømselskapene har en slags omforent standard for "akseptabel" skjevspenning i et nett som sier at spenning mellom fase og jord skal være 130V +/- 40V.

 

Edit: Denne skjevspenningen gjelder for dem som er koplet til det tradisjonelle norske 230V trefasenettet, også kjent som "IT-nett". For 400V TN-nett gjelder det ikke, men det finnes nok ingen private med 400V som ikke har jordfeilbrytere, så de vil ikke ha skjulte jordfeil slik som i det gamle nettet. Dessuten går sikringen med en gang i et 400V nett hvis det er direkte kortslutning til jord.

 

Jeg vet at stikkontakten er som en magnet på folk med multimeter, men bruk hodet først, og vær sikker på at du faktisk vet hva du driver med før du kopler til. Det er langt fra alle multimetre som overlever å måle kortslutningsstrømmen i ei stikkontakt, for eksempel. Noen ganger kan det bli svidde måledninger også.

 

Dette er noe jeg fant i en SINTEF-rapport, og gjelder for nettleverandører.

 

"Elsikkerhet" som det vises til, er et blad som utgis av DSB, hvor de kommer med sine betraktninger om emnet, og også presiserer hvordan enkelte regler skal forstås. Det er bryet verdt å se i, for dem som er interessert i dette emnet.

 

For øyeblikket er denne linken gyldig

https://www.dsb.no/menyartikler/publikasjoner-og-bibliotek/nyhetsbladet-elsikkerhet/

 

Bladet er gratis på nett, så hvis linken blir endret er google løsningen.

 

Endret 7. desember 2021 av tronde

[tronde]

@gskjold

 

Dette er litt tankespinn, for jeg har ikke helt klart for meg om årsaken er kjent, eller ikke. Jeg forsto fra kamstrup-tråden at det kanskje ikke hadde en innlysende løsning.

 

Noen ganger blir det null i en time

andre ganger alt for lite

 

 

Du nevnte at den hoppet over timespakkene, men det må være noe mer siden det noe ganger blir alt for lite.

 

Jeg kan alt for lite til å liste ut logikken av koden din, men jeg ser at det må være en teller i gang når den starter fra strømløs, for da teller den opp fra 0.

 

 

Denne følger visuelt det som jeg har gjort i arduinokoden som johove publiserte.

 

 

Der regner jeg akkumulert forbruk som aktiv effekt inn x 2,5 sek hver gang det kommer fra måleren, og adderer dette inntil det har gått en time.

 

Den koden leser ikke klokka, men jeg har mekket en del tellere som holder styr på tiden basert på når det kommer data ut av porten. I løpet av et døgn bommer jeg med maks et par hundre Wh. Jeg logget lenge før jeg bestemte meg for den løsningen.

 

Jeg har inntrykk av at din kode bruker nåværende akkumulert inn - forrige akkumulert inn (som måleren gir ut direkte) som grunnlag for timesverdiene, siden manglende time gir dobbelt opp neste time. Det forklarer ikke alt for lav effekt, men det har du kanskje noen tanker om?

 

Du har vel tilgang til tiden hver gang det kommer noe fra måleren, og da kan det kanskje være en løsning å se litt i den retningen som jeg skisserer? Om ikke annet for å ha en slags "sanity check" av om det som vises på skjermen er fornuftig. Det å legge dem ut som gjennomsnittsverdier, slik du nevnte i den andre tråden, kan fort gi veldig feil svar hvis det er noe som brukes til styring.

 

En gevinst av å akkumulere fortløpende, er at man får mulighet til å bruke den verdien som grunnlag for å kutte forbruket hvis man nærmer seg en kritisk grense. Dette kan selvfølgelig gjøres i et automasjonssystem som leser måleren, men da blir det flyttet minst ett ledd ut i kjeden, og muligheten for feil øker.

 

Det er godt mulig at dette blir alt for mye "bloat" til at det lønner seg, så det er bare et mulig forslag til en løsning.

 

 

[gskjold]

Det er en kjent feil ja. Det er en regnefeil i koden som holder styr på dataene, og når den først har kommet ut av telling har den kommet helt på villspor. Det som har skjedd hos deg er at den gir deg kanskje forbruket fra f.eks. 19.50 til 20.00 på time 19, og så får du alt fra 19.00 til 21.00 på time 20. Helt  unyttige data rett og slett. Det er fikset i koden jeg har lokalt, men har ikke lagt ut ny enda. Jeg vil sjekke at jeg har fått kontroll på dagsforbruket først.

 

Den bruker forøvrig timespakkene så lenge den får dem fortløpende, hvis den mangler en eller flere så fordeler den forbruket over de timene der det mangler data. Det er denne koden som har vært på villspor og laget krøll for både deg og andre som tester den koden. Det er mye som skal tas hensyn til her, f.eks. får danskene "Timespakke" hver 10.sek.

 

ESP har intern klokke, så beregningen du ser når den starter fra 0 er effekt multiplisert med millisekund siden forrige gang den fikk gyldig pakke. Avviket er omtrent som du beskriver, maks et par hundre Wh i døgnet.

 

[tronde]

Helt fint.

Det som er problemet når man tester, er å vite hva som er kjent, og hva som ikke er det. Derfor har jeg kanskje vært litt for aktiv med å melde noe.

[gskjold]

Bare kom med alt du måtte finne, jeg vil heller ha det flere ganger enn at det ikke kommer på bordet  Skal prøve å organisere testing og tilbakemelding litt bedre neste gang

[tronde]

@gskjold

Jeg finner ikke hva du fikset i rc6.1, men da jeg byttet ut 6.0 med 6.1 kom det en negativ verdi igjen. Den var positiv før jeg oppgraderte.

 

Wemos D1.

 

 

Et annet spørsmål:

Kan jeg oppdatere ESP32 release candidatene over nett, eller må den flashes? Jeg spør, for jeg har bare en, og jeg vet ikke hvordan jeg evt. kan ta full erase på den slik som på ESP8266 hvis noe skjærer seg. Det er jo også to filer i zip-en.

Endret 9. desember 2021 av tronde

[gskjold]

Merkelig. Kan ikke skjønne hvor den negative verdien kom fra... 

 

Forskjellen mellom rc6 og rc6.1 er bare en endring på dekryptering for danske målere.

 

Ingen problem å flashe via menyen, både med RC og final fra og med 2.x serie på ESP32. Da bruker du kun firmware.bin