tronde

@gskjold Den "gamle" ESP-en sluttet å vise strømpriser ved midnatt (hele grafikken forsvant), mens den nye har hentet inn priser frem til midnatt i morgen. Jeg lar begge gå i fred, så kan du evt. si om det er noe jeg skal prøve. Tidligere har det ikke hjulpet å kutte strømmen. Ved midnatt var dette hva som kom ut av MQTT. Da var det ingen nye priser fra den gamle. Nå, rett før 15 kommer dette ut. Den gamle viser noen priser, men ingen ser ut til å passe. Dessuten viser den laveste priser for den 14. des. mens den nye viser for 15. Begge dytter ut korrekte data for effekten, så MQTT i seg selv ser ut til å være OK. Begge er satt til NO1 med 1 som multiplikator.

Dette innlegget er endret flere ganger, hvis noen har lest tidligere. Nå har jeg funnet en ESP32 til og satt den opp. Den hentet inn dette. Ser nå ut til å være korrekt. Den første ESP32 viser nå dette (kl 22) Dette er loggen for begge mine rett etter kl 23 hvor det tydeligvis ble sendt ut masse nye priser. De var ikke der for den nye før timeskiftet. Går prisene ut hver hele time på MQTT? Den gamle er ikke oppdatert, men den nye ser ut til å stemme med Enstoe. Begge kjører v2.0.1, men den nye ble startet opp rett over 22 nå i kveld.

@gskjold Det er en eller annen bug der. Jeg så det samme enten det var på desktop, et brett eller på telefonen. Dessuten så var tidsintervallet riktig i grafikken, så cache bør det ikke være. Det som er enda mer merkelig, er at MQTT også begynte å sende ut de samme gale prisene en gang etter midnatt. Da satt jeg med androidappen og fikk til å lese strømprisene inn i den, og de var feil til langt utpå formiddagen i dag. Nå viser også grafikken din rett, men kun priser til midnatt. Det gjør også MQTT. Nå er det etter 13, og Enstoe har presentert nye priser i følge grafikken deres, men adapteret viser kun frem til midnatt. Jeg vet ikke om prisene kommer ut på API samtidig som grafikken, men det kan nesten se ut som om adapteret har fått noe ny info, men ikke viser den siden grafikken er endret i verdier, men ikke tid. * Jeg tror jeg forstår hva jeg forvirret meg med MQTT. Jeg hadde fått det for meg at ClientID var det som broker brukte for å sortere meldingene etter, og at Topic var hva som skulle sendes ut (altså at jeg kunne velge hva selv). Slik jeg forstår det nå, så er Topic sett fra broker det som den sorterer etter, og at alle verdiene henges på denne infoen, og at adapteret alltid sender ut alle verdiene, og at alt utvalg skjer i enden hos mottaker. Jeg har i alle fall fått til å plukke ut data både via JSON og Raw nå, så jeg er vel på rett spor. Problemet med det som er enkelt, er at det plutselig blir vrient når man får en liten detalj feil. Siden jeg trodde at ClientID måtte være lik i begge ender for at sender og mottaker skulle "finne hverandre" forstår jeg også hvorfor det ikke gikk så bra å ha begge på samme IP. Det funket når jeg brukte mobilnett og fiber, men det kan være at broker ikke tolket det på samme måten da.

@gskjold Ser ut til å være bug i grafikken for energipriser. Likner mest på gårsdagens. Det jeg får ut som raw på MQTT stemmer med det som Enstoe viser.

Nå er det mulig at jeg er enda mer forvirret enn før, men jeg prøver... Vær snille og bær over med min uvitenhet. Er det slik at "Client ID" egentlig ikke er så viktig? Jeg kan skrive hva som helst der, og det behøver ikke å samsvare med hva jeg har satt opp i klienten der hvor jeg setter opp adressen til broker. Jeg får i alle fall ut data uansett. Er det slik at den Client ID-en egentlig bare har en verdi for meg ved at brokeren skal kunne sende meg data som jeg har mistet, hvis jeg ber om at den skal ta vare på dem? Er det slik at hver eneste tilkopling til en broker skal ha sin unike ID for at den skal kunne skille dem? Og at det som egentlig gir den unike identifikasjonen for min måler er hva jeg velger å skrive inn i feltet for "Publish topic"? Jeg kan for eksempel skrive "trondsaidon" der, og hvis jeg skriver det samme i klienten, så vil klienten finne de dataene hos brokeren, og sende dem til alle som ber om dem, og at Client ID ikke har noe som helst med dette å gjøre? Da er det vel veldig dumt å skrive meter/import hvis dette er en public broker hvis flere med målere gjør det samme? Jeg prøver meg nå bare på de brokerne som ligger åpent på nettet. I den androidappen jeg bruker, får jeg ut en logg over Json hvis jeg setter JsonPath til bare $. Det ser ut som om det er hele datastrømmen, og der finner jeg også client ID som "name="

Fint. Jeg har hittil bare brukt den androidklienten jeg linket til for å se om jeg fikk ut noe på en skjerm. Der funker det med $.data.P for effekten og f.eks $.data.U1 for spenning U1 osv. etter det som står i anførselstegn i denne oversikten over liste 1 til 3. https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats Da er jeg vel på trygg grunn på klientsiden inntil videre. Det som jeg synes er forvirrende her, er at det står ingen ting om "meter/import" under Json i wikien, men det er mange henvisninger til en hierarkisk struktur med blant annet "meter/import" i beskrivelsen over raw mode i denne linken https://github.com/gskjold/AmsToMqttBridge/wiki/MQTT-configuration Når jeg prøvde med klienten uten å aktivere Json, kom det ingen ting selv om det var valgt Raw i adapteret, så det forvirret enda mer. Det ser ut som om om jeg får tak i de verdiene jeg vil med "meter/import", så da har jeg vel gjort ca. rett da, selv om det ble med en ekstra "/" Da kan jeg grave videre i hva for noe fornuftig jeg kan få ut av dette i forvisning om at det grunnleggende er riktig. Selv om jeg skjønner ca. hvordan MQTT er ment å virke, er det alltid noen detaljer som mangler. @gskjold Bug i henting av strømpriser. Morgendagens priser ble ikke hentet inn før jeg tok omstart av interfacet. Det er det interfacet jeg brukte til prøve MQTT, og MQTT var aktiv hele tiden, men jeg vet ikke om det har en sammenheng. API-nøkkel var lagret før jeg tok omstart, så det jeg har gjort med MQTT ser ikke ut til å spise den opp slik GPIO-config noen ganger har gjort. Jeg sjekket at ENSTOE hadde publisert nye priser før jeg tok omstart.

Det jeg savner et klart svar på er hva skal / bør stå i feltet for "Publish topic" for å være sikker på at det sendes ut data som er brukbare, og hva som er korrekt å skrive i feltet for JsonPath i klienten. Etter mye filking satte jeg /meter/import/ i "Publish topic" og payload som Json. Er dette korrekt, eller fornuftig, eller bør det helst stå noe annet der? I klienten fant jeg helt tilfeldig ut (via en uklar side på nettet som jeg ikke finner igjen i farta) at $.data pluss noe mer kunne være en løsning når payload var satt som Json. Jeg hadde da fått ut en strøm i den klienten som jeg tror er Json, og der fant jeg noe som kunne tyde på at dette "noe" kunne være en "P", så jeg prøvde med JsonPath $.data.P, og fikk ut det som ser ut til å være korrekt verdi. I tillegg satte jeg /meter/import/ som Topic i klienten, pluss selvfølgelig at jeg hadde samme ClientID i klienten og adapteret. Jeg mistenker at det bare er et par uklare detaljer som avgjør om det funker eller ikke, så derfor savner jeg en entydig "skriv dette så blir det OK" for å komme gang. Når man først har noe som man er trygg på er korrekt eller fornuftig, er det tid for neste steg som er å fordype seg. Jeg aner ikke om det jeg har gjort er slik det bør gjøres eller ikke, men det funket på et vis.

Det med klient og broker forstår jeg, og det med unik ID er også forstått. Og jeg forstår det med å abonnere på meldinger med ønsket innhold, og at mange kan gjøre det hvis de kjenner den unike ID-en. Men det hjelper ikke noe når det som kommer ut i andre enden i beste fall blir gerblish. Problemet med mange av beskrivelsene på nettet, er at det som virkelig betyr noe, ikke står der, eller ender opp i en masse linker som viser tilbake til noe som heller ikke sier noe for dem som ikke har sett lyset. Dette er noe jeg er veldig godt kjent med fra mitt eget fag som ikke er data/IT; det som synes helt innlysende for meg, er det nødvendigvis ikke for alle andre. * Er det slik å forstå at det som settes inn i feltet for "Publish topic" kan brukes til å filtrere hva som skal sendes ut, slik at man kan velge enten en verdi, flere verdier, eller alle verdiene som det er mulig å sende ut? Jeg fant ut nærmest ved et uhell at $.data.P ga meg filtrert verdi for importert aktiv effekt. Er det den "korrekte" måten å sette JsonPath, eller var det bare flaks? Jeg har en mistanke om at det er flere der ute som ikke har helt kontrollen på dette, så det ville vært fint om noen som forstår kan skrive noen få ord så vi som ikke er flytende i MQTT kan sette opp noe som faktisk vil funke slik det er ment, og ikke bare er et resultat av flaks.

Etter mer knoting får jeg noe på skjermen. Det ser ut som om JsonPath skal være §.data.P for effekten, og at §.data.U1 blir spenningen U1 osv basert på det som står i anførselstegn for liste 1 - 3 her ? https://github.com/gskjold/AmsToMqttBridge/wiki/Message-formats Jeg har fortsatt ikke helt skjønt hva som er korrekt for feltet "Publish topic", men ser at jeg må skrive det samme i begge ender, f.eks. /meter/import/ Litt utbrodering fra noen som skjønner mer av dette ville vært fint, for det kan godt være at jeg bare fikk til noe av ren flaks. Hva er den praktiske forskjellen på payload som raw og Json, rent bortsett fra at jeg ikke ser noe med raw? Er raw binære data?

Jeg prøver med med MQTT, men skaller i veggen. For snart to år siden fikk jeg til noe, men nå er det full stopp... Jeg vil prøve med ekstern broker, for jeg vil vise noe til dem som har fått et adapter av meg. Ingen av brokerne ser ut til å like at mottaker er på samme IP som sender, men det løser seg ved å ha mottaker på mobildata. Da blir i alle fall ingen av dem koplet ned. broker.hivemq.com ser ut til å være samarbeidsvillig. Jeg vet at sender og mottaker må ha samme Client ID. Hva skal jeg sette inn i feltet for "Publish topic" i menyen for MQTT oppsettet? Er det feltet for at jeg kan sende ut bare en verdi, eller et utvalg? Vil ikke MQTT normalt dytte ut alt som finnes? Må jeg ha brukernavn og passord, eller er det valgfritt? Jeg forstår fra wikien at det er valgfritt. Jeg prøver å få til noe med androidappen IoT MQTT Panel https://play.google.com/store/apps/details?id=snr.lab.iotmqttpanel.prod Den funket for meg sist, mener jeg å huske. Jeg får satt den opp til å holde en forbindelse åpen mot broker.hivemq.com som jeg har satt adapteret opp mot, og det viser grønn MQTT-status, så jeg regner nesten med at det grunnleggende funker i bakgrunnen. Jeg ser denne listen over topics, men jeg har vel prøvd det meste av kombinasjoner uten å få til noe. https://github.com/gskjold/AmsToMqttBridge/wiki/MQTT-configuration Er det ikke slik at {root} i listen egentlig representerer Client ID i MQTT? Hva skal jeg skrive i sender og mottaker for å få ut verdien av importert aktiv effekt? Data som raw eller JSON? I appen er et felt for Topic. Det skal vel samsvare med den verdien jeg vil hente fra MQTT, men hva skal stå der? Hvis jeg velger JSON som data, ber den om JsonPath. Der blir jeg enda mindre klok, for det jeg finner på nett sier ikke noe fornuftig til meg.

@gskjold Litt mer å fikse 😊 Da jeg holdt på med GPIO-settingen, var det noen ganger at API-nøkkel for strømprisene ble slettet, uten at jeg helt kan se hvorfor. Minner litt om det som skjedde da den ikke klarte å huske valgt prisområde. Nøkkel ble erstattet med "r" da jeg oppgraderte til V2.0.0. I begge tilfelle forsvant også visningen av prisene. * I den generelle beskrivelsen av prosjektet på Github står det: Later development have added Energy usage graph for both day and month, as well as future energy price. The code can run on any ESP8266 or ESP32 hardware which you can read more about in the WiKi. Selv om det står i wikien, skader det nok ikke å presisere at strømpriser krever ESP32, for det gis inntrykk av at begge ESP-ene gir den funksjonen. * I wikien under "Meter configuration" står det "Substitute missing values - For IT/TT distribution system, calculate current for L2". Den funksjonen er ikke synlig i konfiguarsjonsmeyen. Jeg ser helst at den kommer tilbake, for det ser litt corny ut med negative strømmer som man ofte får når det er skjev belastning i nettet. To desimaler er også i overkant. Null desimaler er nok når svaret stort sett er helt utenfor. * I wikien under "Initial setup" står det "WiFi - SSID and PSK for the network you want your device to connect to. If you also want to set static IP, read more here" Linken til https://github.com/WiFi-Configuration er død.

Nå har jeg testet lysdiodene. Det ser ut som om man ikke kan sette høyere GPIO enn 15? 16 er alt opptatt, så jeg prøvde 17 som er fysisk nær, men det blir bare bare rør, for den lever sitt eget liv. Hvis det er en grense, bør vel det også gjøres kjent.

ESP32: Da fant jeg noen andre DS18B20 som funker, og jeg kan flytte dem rundt til forskjellige GPIO. Da vet vi at det finnes noen som ikke liker 3,3V. Det er nok den typen som kalles "almost similar" der borte i Kina. Jeg forstår at den verdien som vises på hovedskjermen er (valgbart) gjennomsnitt av alle sensorene. Når man kopler bort sensorene (simulerer brudd), blir den verdien stående, mens listen over alle sensorene viser N/A som er korrekt. Hovedskjermen burde vel også vise at noe mangler? Kanskje skrive et par ord i Wikien om dette også?

@gskjold Oppgraderte ESP32 med upgradefunksjonen som fortale at ny versjon var tilgjengelig. Den funket greit, men API-nøkkel for strømpriser ble byttet ut med en "r" så prisene ble selvfølgelig borte. I tillegg er det fortsatt varsel om at ny versjon 2.0.0 er tilgjengelig, selv om det står i toppmenyen at det er v2.0.0 som er installert. Dette varselet vises også for ESP8266.

Ja, jeg har pullup og 3,3V. har brukt DS18B20 flere ganger, og jeg har hatt mine runder med krangling om sensorer som helt utvilsomt er fake, så jeg kjenner problemene med ebay/ali-utgavene. Har blant annet noen som ikke godtar mer enn maks 3 av den typen i samme systemet, men som samtidig funker helt fint med 3 av sine + mange andre av en annen batch i ett system. Skal se om jeg har noen fra en annen bestilling et sted som kan frigjøres. Det kan godt være at den batchen som disse kom i ikke funker med 3,3V. Når du klarer å drive 20, må det gå an å finne en som kan funke alene.

Jeg la inn 6.0 mellom 1300 og 1400 idag, og feilen er etter det. Jeg la inn 6.1 mellom 1700 og 1800 mener jeg å huske. Den er er der fortsatt, selv etter flere omstarter, Nå sitter jeg her og prøver å liste ut litt om GPIO-settingen for ESP32. Det midterste feltet for RGB ser ut til å være data fra HAN, men hva er de to andre? Jeg får ikke DS18B20 til å funke. Er den ekstremt kresen på fake? Mine er helt sikkert fake, men de funker i andre applikasjoner. Må jeg konfigurere noe? Det er et felt for temperatur, men det ser ikke ut til å hjelpe. Er det for analog sensor? Edit: Det plager meg ikke, men ESP vises som grå med ESP32, og grønn for ESP8266,

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

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

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.

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. Finland gikk opp i 1000,07 EUR pr. MWh mellom 0700 og 0800 i dag, så muligheten for to-sifret pris er der.

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

@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

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.

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.