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.

Flott, da leser den hvertfall data riktig. Reboot er et kjent problem som desverre ikke har en løsning enda: https://github.com/gskjold/AmsToMqttBridge/issues/174

Prøv denne esp8266.zip

Takk @Kardemomme, akkurat den jeg var på jakt etter. Det er nok som @Bjørn Mork nevner her at koden sikkert blir forvirret av null verdiene. Nå har jeg hvertfall noe å teste med

Kan se ut som den ikke får med seg timespakkene. Der hvor det står "2.81kWh" skulle du ha hatt total målerstand, og når den da mangler det etter 12t oppetid så må det være noe data den ikke klarer å tolke fra måleren. Av samme grunn mangler du grafen. Hvis du går på system -> debugging og setter på enten telnet eller serial debugger og bytter level til verbose så kan du ta ut logg med data som mottas via telnet eller serial monitor. Jeg er nysjerrig på dataene som kommer 10s over heltimen.

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

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

Det blir bygget firmware for både ESP32 og ESP8266. https://github.com/gskjold/AmsToMqttBridge/releases Jeg klarer ikke helt å se verdien i å ta inn yr.no eller andre værdata inn i denne firmwaren. Det er litt for langt borte fra hensikten med denne softwaren.

Hadde vært teknisk mulig med ESP32, men ikke ESP8266 på grunn av lite tilgjengelig RAM. Når det gjelder dallas sensor så har den allerede støtte for dette, men kun direkte tilkoblet.

Det du egentlig snakker om nå er vel webhook. Jeg har dette på planen, men har ikke hatt tid til å prioritere dette enda desverre.

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

Det er andre også som har hatt problemer med statisk IP, så åpenbart noe galt der. Du er sikkert inne på noe med lengde. Kjør på meg GitHub issues, så ser jeg på disse tingene ved anledning.

Det er nok samme type bug ja. Åpnet https://github.com/gskjold/AmsToMqttBridge/issues/180 NTP påvirker ikke tidspunktene fra meldingene til MQTT.

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

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?

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?

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.

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

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.

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?

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

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.

Korrekt, det er kun en identifikator av klienten og må være unik for hver klient. Det stemmer egentlig det ja, det er dette som skiller data fra de forskjellige enhetene som sender data til brokeren din. Interessant. Antar du har lastet siden på ny? Prøv CTRL+F5 for å unngå evt browser cache. Skal sjekke dette. Er forøvrig NTP satt opp i config?

Jeg skal ikke gå for dypt inn i hvordan MQTT fungerer her, for internett er full av beskrivelser og videoer om dette, men en kort oppsummering: MQTT er meldingsutveksling og må ikke forveksles med database (som jeg opplever at noen gjør). Det finnes to roller: Broker (server) og Client. Data sendes fra klient til broker og kan mottas av andre klienter som lytter på topic som det sendes data på. Viktig: Client ID på de forskjellige klientene som kobler seg til samme broker MÅ være forskjellig. Publish topic på AMS reader er "stien" (tenk filsystem) den skal publisere data til på MQTT og er det som blir referert til som {root} i wiki. (Skal bytte den til {publish topic} eller noe). Hvis man f.eks. skriver inn "/ams/reader" i publish topic så vil andre klienter som lytter på denne stien motta disse dataene. Hvis man f.eks. kun vil ha det som publiseres på {root}/meter/* så kan en klient i stedet lytte på "/ams/reader/meter". Data format: JSON - Alt kommer som JSON i én melding rett på publish topic Raw - All data publiseres på hver sin topic i ren tallverdi (ikke binært) på topic spesifisert i MQTT config i Wiki under "Topics in raw mode".

Grensen er implementer allerede. Tror det er 35. Du har sikkert HAN på uart2, og gpio17 er tx for uart2, så da er den opptatt. Takk for gode innspill over, notert