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

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

 

 

 

 

 

[gskjold]

Satte på en ESP32 i går, ser ut som jeg får samme feilen. Skal se på det etter hvert, men får ikke tid før tidligst en gang i neste uke.

[tronde]

gskjold skrev (2 timer siden):

Satte på en ESP32 i går, ser ut som jeg får samme feilen. Skal se på det etter hvert, men får ikke tid før tidligst en gang i neste uke.

Vet ikke om det har noe å si, men jeg skriver litt her som referanse.

 

Ny dag, og begge ble enige. Grafikken kom også tilbake. Prisene stemmer med grafikken hos Enstoe etter et par minutter. Rett over midnatt ville den nye ESP-en også vise time 32 og 33 i MQTT, men de forsvant etter få minutter. Grafikken viste dem ikke.

 

 

 

 

Nå rett over midnatt.

 

 

[frodegill]

Vet ikke om det er relevant, men i min ENTSO-E-kode har jeg fått dette i loggen de siste dagene: "Tag mismatch in line 8 column 6". Riktig pris kommer inn etterhvert. Jeg har lagt inn kode som skal logge selve XMLen hvis parsing av den feiler, men inntil feilmeldingen dukker opp igjen kan jeg bare spekulere i at ENTSO-E av og til sender ut invalid XML.

[gskjold]

@frodegill Mistenker at det kanskje er fordi APIet til ENTSO-E gir HTTP status 200 når prisene ikke er tilgjengelige enda? Jeg mener å huske at den ga en 5xx status tidligere, men kanskje jeg tar feil...

 

@tronde Takk for input, jeg tror det er endringen jeg nevner over som har forårsaket feilen, får det endelige svaret etter 13.00 i dag antar jeg. Den passerer hvertfall midnatt uten problemer nå.

[tronde]

@gskjold

Jeg oppdaterte den ene til 2.0.2 rett før midnatt. Den viste korrekte priser før, og helt feil etter.

 

Den andre oppdaterte jeg et par minutter etter midnatt. Den viste ingen priser før, og de samme gale som den første etter oppdateringen.

 

Nå 0130 slettet jeg API nøkkel i den ene, og la den inn på nytt. Da hentet den inn korrekte priser. Da gjorde jeg det samme på den andre, som også viser korrekte priser nå.

 

For meg ser det ut som om et eller annet minne henger. Hvor ofte spør den etter nye priser?

 

Jeg skal gjerne være med å teste hvis det er noe du vil prøve ut, men jeg er ikke i stand til å se fra koden hva jeg bør være på jakt etter. Jeg har levd av feilsøking på andre ting, så jeg har stor tålmodighet med testing når det ser ut til å ha en hensikt, og jeg har to ESP32 som går parallelt som kan konfigureres ulikt.

 

Gale priser NO1:

 

Korrekte priser NO1:

 

[gskjold]

Den henter priser rett etter at den har fått NTP eller klokke fra måleren. Deretter henter den for neste dag kl13, eller evt med en gang hvis tidspunktet allerede er passert 13. Det virker for meg som om den ikke har rotert prisene ved midnatt som den skal. Foreslår at du setter debuggeren til debug level og rebooter. Rett etter den får klokke så skal du få ut "Setting midnight millis xxxxx" som er millisekund fra tidspunktet ESPen startet og frem til midnatt. Del dette tallet på 3600000 så skal du få hvor mange timer det er til midnatt. Ved midnatt flytter den morgendagens priser til dagens. Jeg har forøvrig tatt med klokken ut i GUI, ser den riktig ut?

[tronde]

gskjold skrev (7 timer siden):

Den henter priser rett etter at den har fått NTP eller klokke fra måleren. Deretter henter den for neste dag kl13, eller evt med en gang hvis tidspunktet allerede er passert 13. Det virker for meg som om den ikke har rotert prisene ved midnatt som den skal. Foreslår at du setter debuggeren til debug level og rebooter. Rett etter den får klokke så skal du få ut "Setting midnight millis xxxxx" som er millisekund fra tidspunktet ESPen startet og frem til midnatt. Del dette tallet på 3600000 så skal du få hvor mange timer det er til midnatt. Ved midnatt flytter den morgendagens priser til dagens. Jeg har forøvrig tatt med klokken ut i GUI, ser den riktig ut?

Hvilke andre valg i debuggeren skal jeg velge? Jeg må velge noe mer enn bare error ser jeg nå. Jeg krysset av for begge, men skjønner ikke hva jeg gjør.

 

Det er en bug, som jeg ikke fikk lagret. Jeg så begge via telefonen, og begge viste feil priser igjen rett før 12. Da viste også den ene som jeg leser via MQTT feil priser. Når nye priser kom, ble de korrekte igjen.

 

Klokka ser ut til å være riktig, men jeg la ikke merke til hva den viste da jeg så feilen. Alt for liten skjerm til å feste meg med alle detaljene i farta.

Endret 20. desember 2021 av tronde

[gskjold]

Huk av for "Serial debugger" og velg "Debug" i level dropdown. Koble kortet til USB og åpne seriemonitor og trykk reset på kortet og sjekk output.

[tronde]

gskjold skrev (21 minutter siden):

Huk av for "Serial debugger" og velg "Debug" i level dropdown. Koble kortet til USB og åpne seriemonitor og trykk reset på kortet og sjekk output.

Skal det komme noe hele tiden? Det kom noe, som ikke hadde rett baudrate, og etter at jeg begynte med å prøve andre, kommer ingen ting.

 

@gskjold

 

Nå får jeg ut noe. Hva skal jeg gjøre med det?

 

 

Endret 20. desember 2021 av tronde

[gskjold]

Rart, 115200 stemmer, så det skulle ha kommet ut noe. Må tenke litt på den..

[tronde]

gskjold skrev (1 minutt siden):

Rart, 115200 stemmer, så det skulle ha kommet ut noe. Må tenke litt på den..

Jeg får ut noe nå.

Hva mer?

 

[tronde]

@gskjold

 

Dette får jeg ut. Fra 1547 - 1605

Ser ikke annet enn klokka i WEB-GUI.

 

 

debug_2.txt

[gskjold]

Ser jo ut som klokka er OK hvertfall. Jeg klarer ikke helt å koble hva som skjer der. Jeg må nesten sette opp en automatisert test slik at jeg får sjekket den flere ganger i døgnet. 

[tronde]

@gskjold

 

En eller annen gang før 0200 i natt fikk den jeg logger det for seg å kun vise forbruk for ett døgn siste måned. Den andre viser OK.

 

Jeg legger ved loggen for den som strekker seg fra i går kveld til nå.

 

Begge hentet inn prisene kl 1300 i dag.

 

 

 

Endret 23. januar 2022 av tronde

[Ingar]

Versjon 2.0.2 sender ikke time verdier.  Dato står som 01.01.1970 og oppdaterer seg ikke.

Bruker PowU på Aidon.  Har lastet opp versjon 2.0.1 igjen og denne virker fint.

[gskjold]

41 minutes ago, Ingar said:

Versjon 2.0.2 sender ikke time verdier.  Dato står som 01.01.1970 og oppdaterer seg ikke.

Bruker PowU på Aidon.  Har lastet opp versjon 2.0.1 igjen og denne virker fint.

Kan du utdype litt? Er det klokken i GUI? I så fall ble denne først introdusert i 2.0.2 og finnes ikke i tidligere versjoner. Antar det kanskje er noe annet du snakker om?

[Ingar]

Klokken i GUI viste 01.01.1970 og ingen verdier ble sendt for /meter/clock i rådata.

Her pleier det å komme dato og tid en gang i timen + akkumulert verdi (/meter/import/active/accumulated).  Ventet over 3 time passeringer uten at disse verdiene dukket opp.  Er det kanskje endret på adressene til disse i den nye versjonen ?

 

[gskjold]

Imgen endringer på dette mellom de to versjonene. Det høres ut som den har gått glipp av pakkene av en eller annen grunn. Hvilken måler har du? Og hardware?

[ArnieO]

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

Endret 21. desember 2021 av ArnieO

[Ingar]

Hardware:  PowU Amsleser

Måler: Aidon

[gskjold]

Takk. Har du satt fast IP? Har du i så fall spesifisert en gyldig DNS? Hvis den ikke har DNS så forklarer hvertfall det klokken, men ikke hvorfor den mister timespakker

[Ingar]

Har fast IP.  Har nå lagt til DNS så klokken er ok nå.  Kanskje time pakken kommer nå ?

 

[Ingar]

Ser ut til at DNS gjorde susen 😀  Time pakken kom som den skulle nå.

[tronde]

@gskjold

 

ESP32:

 

AP button har GPIO0 som standard etter flashing. Det er ikke alle kort som har den som egen pinne. Wiki sier GPIO4 som ser ut til å være et bedre valg, selv om GPIO0 er tilgjengelig rett på modulen.

 

Endret 25. desember 2021 av tronde