ArnieO

Det er den, ja - for å kalibrere ADCen på den ESP8266en som sitter på kortet ditt. Dersom hovedskjermen viser mer enn 3,3V (det gjør den som regel) justerer du litt ned. Om det allerede står 0.97 der så har den antakelig lagt inn justeringen jeg gjorde ifm testingen - og da skal det være greit.

OK - det var den vanligste feilen. Kan du sjekke System / GPIO? Det skal se slik ut, bortsett fra at "Multiplier" er kalibrering av ADC for å vise rett Vcc, så den tilpasses på hvert kort: (Med "Factory reset" forsvant det som var forhåndsinnstilt her)

Kan det tenkes at du ikke har satt rett paritet (skal være 8N1)?

Vet du mer om dette? Jeg bruker fast IP med APen sin IP spesifisert. I mitt mesh system er dette hovednodens IP så jeg ser ikke umiddelbart at det kan gjøres annerledes - med mindre der er en nettverksopsjon i ESPen jeg ikke er kjent med.

Tusen takk for mye god informasjon! Dette moderne mesh-systemet er forenklet/fordummet så mye at det meste av nyttige knapper å skru på ikke eksisterer. Det er ditt siste tips der som jeg har som backup plan dersom det ikke blir stabilt på annen måte. Problemet er at det vil bli wifi-baserte IoT dingser spredt rundt om i heimen etter hvert, og da blir det igjen problemer med dekningen fra et enkelt aksesspunkt. Jeg hadde håpet at et solid mesh system skulle dekke det behovet...

Det kan godt tenkes at ditt problem ikke har noe med dette å gjøre, men la meg forklare litt bedre hvorfor lang re-oppkoblingstid kan gjøre at man mister nettopp timesverdien. Eksempel: Kamstrup måler: Norske målere er satt opp slik at de sender "Liste 2" hvert 10 sekund, og hver hele time kommer en mer omfattende "Liste 3". Denne Liste 3 erstatter imidlertid ikke Liste 2, den kommer innimellom. Det vil si at det der er et kortere tidsintervall mellom datagrammene fra måleren enn det er resten av tiden. Dette kan potensielt føre til at lang re-oppkoblingstid til Wifi gjør at leseren mister timesmålingen. I Danmark er det gjort litt enklere, der er det kun Liste 3 som kommer hele tiden, med 10 sek intervall. (Innholdet i Liste 2 og Liste 3: https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats)

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

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: 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: 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? Etter noen timer fikk den inn timesmåling, og da viste grafen midling av de foregående timene (identiske verdier). 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!

Har du satt rett paritet? Skal være 8N1: https://github.com/gskjold/AmsToMqttBridge/wiki/Known-hardware-configurations Om du viser hva du har på System/GPIO og Config/Meter så tenker jeg vi skal finne ut av det.

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 .

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?

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.

På mitt kort (en tidlig versjon av det som nå er Pow-K) er den like stabil som tidligere versjoner. Jeg har aldri opplevd reboot med kort powret fra måleren. Jeg ville forsøkt å slette flash på ESPen helt, og laste opp binærfila på nytt.

Takk, det er hyggelig å høre! (Det er meg som står bak Pow-U som jeg selger fra min nettbutikk amsleser.no.) Jeg valgte bort temperatursensor på Pow-U men om du er fingerferdig med loddebolten skal det være fullt mulig å få klemt den inn et sted. Firmwaren kan håndtere både digital sensor Dallas 18B20 og analog temp sensor som leses med ADC. Det enkleste er nok 18B20. Den er enkel i bruk. En pinne til GND, en pinne til 3,3V og en datapinne som kobles til en ledig GPIO. Under System/GPIO på Pow-U velger du så den GPIOen du bruker på «Temperature». Datapinnen trenger en 4,7kohm pullup motstand, som du setter inn mellom 3,3V og datapinnen. Om du er fingernem lodder du den sammen med sensoren. Så gjelder det å finne et egnet sted å lodde seg inn på GND og 3,3V. Dersom du velger bena på den store kondensatoren så vær forsiktig med å ikke varme for lenge, kondensatoren liker det ikke. Gå i så fall inn nederst mot kortet. Jeg sitter ikke ved PCen nå, så husker ikke alle ledige GPIOer, men GPIO5 skal i hvert fall være ledig. Ta evt kontakt med meg på [email protected] om du trenger mer informasjon. PS Vær forsiktig med utendørs bruk, største risiko ligger nok i at fuktighet fra luft kan kondensere på elektronikken ved brå temperaturendringer kombinert med høy luftfuktighet.

Litt haltende sammenligning - men med kun hysterese blir det litt som når du skal opp i en viss hastighet i bilen - og gjør det slik: Du trykker bånn pinne til du har passert fartsgrense+"hysterese", slipper gassen inntil du ligger "hysterese" under - og så videre.

PID regulering hvor effekten (i dette tilfellet vel duty cycle) varieres.

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.

Hei @monsivar I følge denne siden https://www.foie.no/stromforbruk/han-port har ikke strømmålerne til de som bor i Ringerike eller Hole HAN-port. De må bytte målere, og er tomme for målere med HAN-port. Så er det jo et spørsmål om denne informasjonen er upresis - siden du allerede har en Kamstrup med 6-pins kontakt bak dekselet (som er kontakten Pow-K plugges inn i). Man kunne tenke at det "kun" trengs selve HAN-modulen og eventuelt en firmware oppgradering i måleren. Men i og med at de sier at selve måleren må byttes er det kanskje ikke så enkelt. Her blir min gjetning like god eller dårlig som din! Du bør eventuelt kontakte Føie og dobbeltsjekke (og håpe at de teknisk vet hva de svarer på...).

Jeg gjorde noe litt lignende for et par år siden. Styrte VVB med timer slik at den kun varmet om natta, og estimerte varmetapet ved hjelp av observert temperaturfall i perioder hvor det ikke ble tappet vann. Fant at størrelsesorden daglig varmetap tilsvarte (veldig) omtrentlig en god dusj. Det gikk da opp for meg at det kan være vel verd når VVB iblant må byttes å velge en litt dyrere modell med bedre isolasjon. Jeg hadde neppe tenkt den tanken. En dusj i døgnet, hver døgn hele året... blir penger av det. PS: Dersom VVB står i rom som i vinterhalvåret uansett skal varmes (f.eks. vaskerom hvor det tørkes klær) er det reelle årlige energitapet betydelig lavere.

Det er jeg som selger Pow-U og Pow-K på amsleser.no. Det er ikke mulig å lage Pow-U uten ekstern power med ESP32. Det skal være mulig å lage Pow-K med ESP32, det vil nok komme etter hvert (men det er mye annet som tar tid i livet mitt for tiden! 😄)

FWIW: Jeg kjører 2.0.2 med statisk IP uten problemer. Men det kan tenkes @dagb er inne på noe her: Jeg har nettet mitt på 10.0.0.x, så min statiske IP har få tegn: "10.0.0.6"

God idé dette! 👍 Men jeg mener å ha lest et sted at det da er en minste tillatte innkoblingstid man må forholde seg til. Det er sikkert andre brukere her som vet mer om dette. Så vidt jeg vet driver induksjons-koketopper en form for pulsbredde-modulering, men minste tidsavstand mellom inn/utkobling er da en god del sekunder i hvert fall. Og koketopp brukes ikke permanent slik som en VVB. Det er ikke bare kontaktoren (nå SSR) som stresses av stadige inn/utkoblinger men også alle kontaktforbindelser hvor der vil være en (liten) overgangsmotstand som medfører en (liten) temperatursykling ved hver av/på syklus. Temperatursyklinger vil stresse kontaktovergangene litt hver gang - og over lang tid kan ting utvikle seg til dårlig kontakt. VVBer er ulikt konstruert, jeg hadde en relativt ny 10A OSO bereder hvor kabelen hadde støpsel i ene enden og også en koblings-stikkontakt (altså ikke fastmontert) i enden mot berederen. Andre beredere er nok mer robuste på disse punktene. Dersom VVBen brukes på "vanlig måte" vil jo termostaten uansett koble av/på en god del ganger hvert døgn, så jeg tenker at så lenge man praktiserer veldig langsom pulsbredde-modulasjon skal det være uproblematisk. Målet er jo først og fremst å holde seg unna timelastgrensene som (enig med vurderingen din!) vil komme på ett eller annet tidspunkt.

Jeg opplever nøyaktig det samme på v2.0.2, men har ikke testet 2.0.1. Hardware: En eldre Pow-K med HAN på UART0. Måler: Kamstrup

For så vidt korrekt at firmwaren ikke gjør noe med den blå delen av en RGB LED. På Pow-U og Pow-K er den blå delen av LEDen direkte koblet til innkommende HAN linje slik at den blafrer i når datagrammet ankommer fra måleren. Det gir en god visuell indikasjon på at måleren er åpnet og at datagrammene kommer som de skal.

Ja i og med at man ikke på forhånd vet hvordan prisvariasjonene vil bli resten av måneden så blir det krevende å få til en optimal algoritme som både tar hensyn til kapasitetsleddet i nettavgiften og strømprisen neste døgn.