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.

1 minute ago, goodfidelity said:

Lurte på hvis det er mulig for denne AMS leser å hente inn data fra webben via en API? For eksempel hvis det er mulig å hente utendørstemperaturen fra yr.no en gang i timen for en gitt lokasjon? Alternativt hatt en annen arduino på samme nettverk med en dallas sensor, og da hente temperturen fra denne via WiFi?

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.

1 hour ago, goodfidelity said:

Hva er mulighetene for å få brukt POST funksjonen hos HTTP for å sende disse timesverdier opp på en ekstern server?

Ser at det blir brukt MQTT, men jeg lurer på hvis det er mulig å få det med HTTP?

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.

45 minutes ago, ThomasE said:

Kan dette være relatert til denne buggen? 

https://github.com/gskjold/AmsToMqttBridge/issues/43

 

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?

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?

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.

On 12/12/2021 at 23:44, tronde said:

Er det slik at hver eneste tilkopling til en broker skal ha sin unike ID for at den skal kunne skille dem?

Korrekt, det er kun en identifikator av klienten og må være unik for hver klient.

On 12/12/2021 at 23:44, tronde said:

Og at det som egentlig gir den unike identifikasjonen for min måler er hva jeg velger å skrive inn i feltet for "Publish topic"? 

Det stemmer egentlig det ja, det er dette som skiller data fra de forskjellige enhetene som sender data til brokeren din.

7 hours ago, tronde said:

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.

Interessant. Antar du har lastet siden på ny? Prøv CTRL+F5 for å unngå evt browser cache.

On 12/12/2021 at 20:27, tronde said:

Bug i henting av strømpriser. Morgendagens priser ble ikke hentet inn før jeg tok omstart av interfacet.

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

7 minutes ago, tronde said:

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.

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