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

[tronde]

Du må skille mellom hva som går an å regne ut, dvs. gir et svar som helt sikkert er riktig, og hva som kan gi et fornuftig svar under gitte forutsetninger.

 

At noen ikke opplever problemer, beviser ikke at det er gyldig for alle.

 

Jeg vet at det er moderne i vår tid å velge selv hva man vil tro på, så der står man helt fritt. Jeg er så gammel at jeg velger å tro på etablert kunnskap. Ingen dør av å få feil tall i nettleseren her, så jeg sover ikke dårlig om natten av den grunn.

[stigvi]

gskjold skrev (På 3.1.2022 den 8.44):

Committa bokstavelig talt akkurat fiks på det (08:41), kommer i v2.0.3

Når kommer v2.0.3, da?

[gskjold]

Usikker, holder på med en bug som foreløpig ikke er avklart.

[LarsH]

Veldig stilig konsept! Dette er definitivt et produkt som mangler i markedet.

Det nærmeste jeg har kommet, er analog-versjonen Efergy e2.

Resten er sky/ leverandør/ hjemmeautomasjonbasert. Og det er ikke hva "Tante Agate" vil ha. Hun skal bare ha et wattmeter.

 

Jeg kjører med enkel M-bus<-->TTL -konverter koblet til ESP32 Devkit + v2.0.4

Fikk en ide å bruke TTGO T-Display 16MB + ESPHome for å hente MQTT og vise.

Har du vært inne på tanken om den kombinasjonen?

[ArnieO]

Javisst har jeg vært inne på tanken.

Prototypen er i drift på skrivebordet mitt, nettopp med TTGO T-display som du foreslår.

Displayet er koblet til wifi og henter strømpris på nettet. Den sender også målingene fra strømmåleren videre på MQTT (som kanskje ikke Tante Agathe har, men nyttig for oss andre).

Dette er kun en "proof of concept" sak, vi var blant annet usikre på om det var kurant å svitsje mellom ESP-Now og Wifi; det viste seg imidlertid å gå helt greit. Firmwaren i begge ender trenger massiv opprydding - men virker.

 

Formfaktoren på dette displayet er kanskje ikke ideelt. Jeg har lagt inn et LiPo batteri som kanskje ikke er nødvendig. Jeg tenker meg heller noe som kan passe i ei standard veggramme - og så må strømforsyningsbiten løses.

 

Den som sitter i måleren ("Pow bridge") henter strømmen sin fra HAN-porten.

 

 

[Ingar]

AMSreader v2.0.5:

 

Hva er "Voltage between" og "Current between"?  Betyr det bare at verdien er mellom 0-100%?

Lurer også på L1-L2, L1-L3 osv?  Er det en beregning mellom to ?

 

 

Endret 20. januar 2022 av Ingar

[tronde]

Ingar skrev (På 18.1.2022 den 23.42):

AMSreader v2.0.5:

 

Hva er "Voltage between" og "Current between"?  Betyr det bare at verdien er mellom 0-100%?

Lurer også på L1-L2, L1-L3 osv?  Er det en beregning mellom to ?

 

 

I 230V IT og TT-nett er det ikke fasespennigen(e) som oppgis. Der er det spenningene mellom to og to ledere som oppgis. Disse kalles "linjespenninger" Det er den samme spenningen som man måler med voltmeter i stikkontakten. Måleren har tre ledninger inn, og den gir ut verdien på den spenningen man måler mellom ledning 1 og 2, mellom ledning 1 og 3, og mellom ledning 2 og 3. Disse tre ledningen er fordelt ut på ulike kurser i sikringsskapet etter måleren.

 

Det med "current between" er en feil som er rett opp i 2.0.6.  I et IT / TT-nett er det ikke fasestrømmene som måles, men det som kalles "linjestrømmene". Det er den strømmen du ville målt med amperemeter i hver av de tre ledningene. Måleren gir ikke ut nok data til at man kan beregne fasestrømmene.

 

Noe ble også feil i teksten for 400V TN-nett, hvis det er det du har. Det er også rettet opp.

 

I 400V TN-nettet er det fasespenningene som måles. Der er det fire ledninger inn i måleren, og man måler mellom leding 1 og nøytrallederen (den 4.), mellom ledning 2 og nøytral, og mellom ledning 3 og nøytral. Etter sikringsskapet blir disse delt opp i kurser som er L1 og nøytral, L2 og nøytral, og L3 og nøytral. Spenningen som er oppgitt av måleren er den samme som man måler i stikkontakten for respektive kurser.

 

I 400V TN-nett er det fasestrømmene som måles, og den strømmen som vises, er den man ville målt med amperemeter i ledning 1, ledning 2 og ledning 3. Strømmen i nøytrallederen er ikke oppgitt eller målt, og den er heller ikke 0A i et virkelig nett slik mange tror. Det er fullt mulig å ha last kun på en fase i dette nettet, og da er strømmen i nøytrallederen like stor som strømmen i den ene fasen som blir belastet.

Endret 23. januar 2022 av tronde

[stigvi]

Dette med strøm i nøytral har vært diskutert i Teknisk Ukeblad i forbindelse med lading av bil. Stort sett alle el-biler har kabling internt i bilen som er et TN system. At de allikevel kan lades på et norsk IT nett er fordi ladeboksen kobler bilens nøytral til en av fasene. Dette har skapt utfordring med Renault Zoe som ikke tilliater en slik kobling. Men det som skjer når en lader på denne måten er at en kan få en større strøm i bilens nøytral enn i faseledningene og noen i fagekspertisen mener at vi ikke har noen garanti for at blien er lagd for å tåle en større strøm i nøytral - ergo bør det å lade bil på et IT nett uten egen transformator for å tranformere til et TN nett være forbudt. Men det skjer neppe.

[tronde]

Det problemet der var at noen elektrikere har prøvd å trekke last av to faser fra vårt system for å få større ladeeffekt enn ved enfasekopling. Det er som du sier ikke entydig rett måte å gjøre det på. 

 

Enfaselading er ikke noe problem når det gjelder strøm og kabeltverssnitt, bortsett fra Zoe som sjekker at den faktisk står på et TN-nett som har jord og nøytrallederen koplet sammen i husets inntak. Det er noe med at Zoe bruker viklingen i motoren som en del av laderen, og at det er noen jordstrømmer som kommer på avveie. Renault "løste" problemet med å sende med en tung transformator som setter opp et lokalt TN-nett. 

 

I Europa er det britene, og muligens Sveits og Italia som har full kontroll på hvor nøytrallederen er i en enfaset stikkontakt. De andre bruker enten "vår" Schuko som er upolarisert, eller den med pinnejord (også kalt fransk eller polsk) som er polarisert, men hvor de ikke har klart å bestemme seg for hvilken pinner som er "live" og "nøytral". Derfor er det ikke noen elektrisk fare i å lade enfaset med vårt IT-nett, for de andre vet heller ikke hvor de har nøytrallederen i stikkontakten, og må ha isolasjonsklasse etter det. Det er kun Zoe, og "kreative" forsøk på å få til tofaselading i Norge som er problematiske.

[Ingar]

 

tronde skrev (På 23.1.2022 den 21.04):

I 230V IT og TT-nett er det ikke fasespennigen(e) som oppgis. Der er det spenningene mellom to og to ledere som oppgis. Disse kalles "linjespenninger" Det er den samme spenningen som man måler med voltmeter i stikkontakten. Måleren har tre ledninger inn, og den gir ut verdien på den spenningen man måler mellom ledning 1 og 2, mellom ledning 1 og 3, og mellom ledning 2 og 3. Disse tre ledningen er fordelt ut på ulike kurser i sikringsskapet etter måleren.

 

Det med "current between" er en feil som er rett opp i 2.0.6.  I et IT / TT-nett er det ikke fasestrømmene som måles, men det som kalles "linjestrømmene". Det er den strømmen du ville målt med amperemeter i hver av de tre ledningene. Måleren gir ikke ut nok data til at man kan beregne fasestrømmene.

 

Noe ble også feil i teksten for 400V TN-nett, hvis det er det du har. Det er også rettet opp.

 

I 400V TN-nettet er det fasespenningene som måles. Der er det fire ledninger inn i måleren, og man måler mellom leding 1 og nøytrallederen (den 4.), mellom ledning 2 og nøytral, og mellom ledning 3 og nøytral. Etter sikringsskapet blir disse delt opp i kurser som er L1 og nøytral, L2 og nøytral, og L3 og nøytral. Spenningen som er oppgitt av måleren er den samme som man måler i stikkontakten for respektive kurser.

 

I 400V TN-nett er det fasestrømmene som måles, og den strømmen som vises, er den man ville målt med amperemeter i ledning 1, ledning 2 og ledning 3. Strømmen i nøytrallederen er ikke oppgitt eller målt, og den er heller ikke 0A i et virkelig nett slik mange tror. Det er fullt mulig å ha last kun på en fase i dette nettet, og da er strømmen i nøytrallederen like stor som strømmen i den ene fasen som blir belastet.

 

 Fint og forståelig svar @tronde 👍

[stigvi]

Er det vanlig hos dere andre at en får timer som mangler forbruk?
Min ams2mqttbridge står ca 5 til 10 meter fra måleren og jeg lurer på om det er kabellengden som lager kluss. Kluss = at dette skjer vanligvis 1 - 2 ganger pr døgn hos meg.

Endret 3. februar 2022 av stigvi

[ArnieO]

Interessant feil. Ikke vanlig, nei.
Dersom den mister en Liste 3 (som kommer hver hele time, og inneholder akkumulert målerstand) skal den ved neste hele time midle slik at foregående to timer viser samme verdi. 
Hvilken versjon firmware er dette? 
Restarter den ofte? Det kan muligens lage kluss i så fall.

Endret 3. februar 2022 av ArnieO

[stigvi]

ArnieO skrev (Akkurat nå):

Interessant feil. Ikke vanlig, nei.
Dersom den mister en Liste 3 (som kommer hver hele time, og inneholder akkumulert målerstand) skal den ved neste hele time midle slik at foregående to timer viser samme verdi. 
Hvilken versjon firmware er dette? 

2.0.7

 

Prøvde å dekode det du skrev, men nei, manglet nok nøkkelen. Ved neste time håper jeg du sender videre det samme som måleren rapporterer.

[ArnieO]

Beklager at det ble kryptisk! 😄

Det måleren din sender på HAN porten har ikke alltid samme innhold. Det som sendes «kontinuerlig» er en kort melding som inneholder i hovedsak effekt (kWj. Hver hele time sender den en større melding som også inneholder akkumulert målerstand (total kWh siden måleren var ny). Det er denne siste meldingen som brukes til å regne ut tallet som vises per time i grafen.

Koden tar høyde for at leseren kan gå glipp av heltimes-melding, og skal da midle verdien fra siste lagrede heltimes-melding. Dette ser ikke ut for å fungere slik hos deg, og det har jeg ikke sett før.

Der er en oppetidsteller oppe til venstre. Forsøk å følge med på den for å få en føling med om den restarter ofte.

Hvilken hardvare kjører du på, og hvilken måler har du?

[stigvi]

ArnieO skrev (2 minutter siden):

Beklager at det ble kryptisk! 😄

Det måleren din sender på HAN porten har ikke alltid samme innhold. Det som sendes «kontinuerlig» er en kort melding som inneholder i hovedsak effekt (kWj. Hver hele time sender den en større melding som også inneholder akkumulert målerstand (total kWh siden måleren var ny). Det er denne siste meldingen som brukes til å regne ut tallet som vises per time i grafen.

Koden tar høyde for at leseren kan gå glipp av heltimes-melding, og skal da midle verdien fra siste lagrede heltimes-melding. Dette ser ikke ut for å fungere slik hos deg, og det har jeg ikke sett før.

Der er en oppetidsteller oppe til venstre. Forsøk å følge med på den for å få en føling med om den restarter ofte.

Hvilken hardvare kjører du på, og hvilken måler har du?

Oppetid er på 3 dager. Sannsynligvis fra da jeg la inn 2.0.7. Har ikke opplevd at den tar spontane omstarter. Noe midling av data gjør den ikke. Jeg regner selv ut i Home Assistant forbruket av energi innenfor hver time basert på effekt hvert 2. sekund og forbruket i de to timene som mangler i ams2mqttbridge er ikke null, men omtrent som timen rett før og rett etter. Ams2mqttbridge viser, som er tydelig i skjermbildet ovenfor, et ekstra høyt forbruk i timen etterpå.

Angående denne midlingen: er dette noe som påvirker data sendt til mqtt broker eller er det kun for visning på webside?

Ser at data mangler på det som sendes mqtt også. Ikke uventet.

[ArnieO]

Det som sendes på MQTT er ikke tolket på noen måte, det er verdiene som kommer fra måleren, se https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats

Så utnyttes dataene på antatt best mulig måte for å lage den grafiske visningen.

Ja, det ser ut for at forbruket i den manglende timen kommer som tillegg på timen etter, ingen midling. Det er underlig.

 

Hvilken hardvare kjører du på, og hvilken type måler har du?

 

Sender for øvrig ballen videre til @gskjold .

[stigvi]

ArnieO skrev (8 minutter siden):

Det som sendes på MQTT er ikke tolket på noen måte, det er verdiene som kommer fra måleren, se https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats

Så utnyttes dataene på antatt best mulig måte for å lage den grafiske visningen.

Ja, det ser ut for at forbruket i den manglende timen kommer som tillegg på timen etter, ingen midling. Det er underlig.

 

Hvilken hardvare kjører du på, og hvilken type måler har du?

 

Sender for øvrig ballen videre til @gskjold .

En esp32 standard sak. Har ikke navn på den. 
Aidon 6534

[stigvi]

Nå som Tibber integrasjonen viser hva som er månedens maks forbruk så er det ikke viktig for meg å finne det ut selv. Så da betyr det mindre om en time eller to mangler data.

[erikolaulvestad]

Kan det vere drift i klokke som kan få to telegram til å havne innanfor same time?

Sent fra min SM-G991B via Tapatalk

[tronde]

stigvi skrev (19 timer siden):

En esp32 standard sak. Har ikke navn på den. 
Aidon 6534

Hva slags interface er det du har mellom måleren og ESP-en din? Det en mulig feilkilde som kan gi "hull" i datastrømmen.

[gskjold]

@stigvi Har ikke sett denne før nei. Som @ArnieO nevner her så skulle den ha fordelt den verdien på begge timene når den mistet en pakke. Jeg har litt endringer på gang for v2.1.0, så jeg tror ikke jeg skal grave i den der akkurat nå. Men hvis problemet fortsetter etter v2.1.0 så gi gjerne beskjed.

[OlavT]

On 03/02/2022 at 18:22, stigvi said:

Er det vanlig hos dere andre at en får timer som mangler forbruk?
Min ams2mqttbridge står ca 5 til 10 meter fra måleren og jeg lurer på om det er kabellengden som lager kluss. Kluss = at dette skjer vanligvis 1 - 2 ganger pr døgn hos meg.

Har sett det fra tid til annen på mine målere, men ganske sjeldent. Ikke sikker på årsaken. Jeg ser dette i data som logges rett fra HAN-porten. Har skrevet sw selv.

Endret 7. februar 2022 av OlavT

[ArnieO]

I forbindelse med bytte av Wifi-system i heimen som en periode var ikke-optimalt konfigurert har jeg siste døgnene hatt noen manglende målepunkter for hel time (og sikkert flere innimellom uten å ha lagt merke til det).

 

Observasjoner og hypotese:

1. Jeg hadde flere påfølgende heltimer uten registrert måling. Dette oppdaget jeg ikke før den igjen fikk lest en heltimes måling, fordi følgende skjedde:
   1. Mens dette pågikk så timesgrafen normal ut, det var ikke nullverdier der mens den ventet på neste timesmåling. Usikker på hva det var den viste da, kanskje var det løpende estimater? ( @gskjold?) Eller var det gamle data som vistes i stedet for å vise null (slik det gjøres i månedsgrafen når det mangler data?
   2. Etter noen timer fikk den inn timesmåling, og da viste grafen midling av de foregående timene (identiske verdier).
2. Det store spørsmålet er hva det er som skjer. Hardvaren min har vært i bruk i flere år, og har vært dønn stabil, så jeg tillater meg å friskmelde den.
   Min hypotese:
   Kortet mister kontakt med Wifi-nettet, og står i loop og forsøker å koble seg opp - mens neste datagram passerer ulest.
   Dette kan potensielt forklare lignende fenomener flere brukere har observert, hvor grafene "oppfører seg rart" selv om kortet tilsynelatende har det helt fint (Vcc rett, ingen reboot osv).
   Dersom teorien min holder bør det vurderes om koden kan justeres slik at innkommende datagram avbryter forsøk på Wifi-oppkobling, slik at kortet kan lese og lagre - og så sende igjen når nettet er tilgjengelig.

 

EDIT

Ennå en observasjon, og jeg regner med at "root cause" er den samme som beskrevet (wifi-problemer): I går vistes døgnforbruk null for 4. og 5. februar. Fra i morges (formodentlig fra midnatt) ble det slik:
 

Dette er feil, også som midlet verdi. Så det er nok noe "rusk" i algoritmen her med tanke på å håndtere manglende datapunkter. Som opplagt er krevende å få skikk på, all ære til @gskjold som jobber med dette!

Endret 7. februar 2022 av ArnieO

[gskjold]

1.1: Tipper den viste gamle data.

2: Sannsynlig at den kan miste data mens den prøver å gjenopprette wifi, men dette er utenfor min kontroll desverre. Åpen for forslag hvis noen vet hvordan man evt frikobler dette, men tviler på det går med bare en CPU kjerne. På ESP32 er det en annen sak.

[ArnieO]

OK, skjønner. Så Wifi-re-oppkobling timeout (er vel dette) er en tøff nøtt.

 

Men tror du Wifi-reoppkoblings-timeout potensielt kan forklare en del "diverse" problemer folk strir med?

 

Jeg byttet fra "gammeldags" Wifi router (med dårlig RSSI sikringsskapet) til et moderne mesh-system (med god RSSI) - og oppdaget at det ikke bare er gull og grønne skoger. Det kan se ut for at tilkoblingstiden har økt, men fant en innstilling hvor man kan angi at enheter ikke roamer (stasjonære dingser). Default er at alle enheter som kobles til kan roame mellom nodene - og tilsynelatende øker det oppkoblingstiden.

Ellers har systemet frustrerende lite knapper å skru på i brukerpanelet... så kanskje det var et bomkjøp til tross for strålende reviews...

Denne: https://www.kjell.com/no/produkter/nettverk/mesh/tp-link-deco-m9-plus-mesh-system-ac2200-3-pk.-p61995