Crisis? What Crisis? (een betere DSMR-logger)

Een nieuwe, betere, modernere Slimme Meter uitlezer

1,980 keer bekeken / views
Laatste update 07-01-2023

Met een energiecrisis die iedereen raakt wordt het “in de gaten houden” van je energie verbruik steeds belangrijker. Daarom is het, na bijna vier jaar, de hoogste tijd om een nieuwe DSMR-logger te ontwikkelen.

De DSMR-logger32 doet en kan hetzelfde als de vorige versie (Rev. 4) maar hij doet dit beter en betrouwbaarder. Bepaalde functionaliteiten zijn niet meer aanwezig. Zo is het voeden van informatie aan mindergas.nl vervallen. Het is gewoon geen kerntaak van de DSMR-logger (en als je het toch belangrijk vindt, dan kun je deze functionaliteit eenvoudig met een Wemos D1 bordje programmeren waarbij je, via een API call, de gegevens uit de DSMR-logger kunt halen en door de esp8266 laten doorsturen naar mindergas.nl. Dat kan met een Wemos D1 bordje zonder extra hardware).

Er is geen ADC interface meer, omdat ik de indruk heb dat er geen gebruik van gemaakt wordt.

Een grote verandering is de mogelijkheid om een shield op de DSMR-logger te prikken waarmee je eigen hardware kunt toevoegen (bijvoorbeeld een ModBus uitbreiding of een relais dat afhankelijk van de surplus aan opgewekte energie bestuurd wordt. Ook een ADC interface behoort dan weer tot de mogelijkheden).

Op veler verzoek krijgt deze DSMR-logger ook een “Secondary P1” poort waar je een andere uitlezer op aan kunt sluiten.

Het blokdiagram (klik voor een grotere versie)

Waarom een ESP32 met PSRAM

Ik heb recent dit project en dit project met de ESP32 Wrover module gemaakt en ben erg onder de indruk van de ESP32 met PSRAM (SPI-RAM geheugen). Het grote voordeel van PSRAM is dat je deze kunt gebruiken om programma variabelen in op te slaan. Normaal nemen deze ruimte van het beschikbare geheugen in waardoor je op enig moment “vast loopt” omdat er simpelweg niet genoeg van is! De ESP32-WROVER modules komen met 4MB PSRAM of zelfs meer (al is er een beperking waardoor op dit moment niet meer dan 4MB PSRAM kan worden gebruikt). In 4MB geheugen kun je echter heel wat gegevens kwijt!!

Makers die zelf de DSMRlogger firmware compileren en flashen en dan inloggen met telnet hebben vast wel gezien dat alle log regels informatie bevatten over de heap. Dat is zinvolle informatie als je de MCU maximaal gebruikt. Want als de heap volloopt crashed de MCU en dan wil je inzicht hebben in waar (welke functie) en wanneer dat gebeurt.


Met de beschikbaarheid van PSRAM geheugen kun je eenvoudig alle groot verbruikers (bijvoorbeeld de telegrammen, de JSON strings en de setting gegevens) in het PSRAM geheugen opbergen waardoor er meer ruimte voor de heap overblijft! De “FreeHeap” wordt niet meer in de log regels getoond omdat deze zelden onder de 200kB komt en het tonen van de FreeHeap dus geen significante informatie meer geeft!

Input P1 Level-Shifter

Voor de invoer van de data uit de Slimme Meter gebruik ik het beproefde schema dat al mijn DSMR-loggers gebruiken (never change a winning team!). Deze maakt gebruik van een NPN transistor (Q101) die het binnenkomende signaal van de Slimme Meter inverteert (“Laag” wordt “Hoog” en vice versa) en het signaal wordt geshift naar 3v3.

Zoals je kunt zien in de tabel wordt het signaal netjes geïnverteerd en ge-level-shift, waardoor [ESP_RX2] netjes tussen GND en 3v3 schakelt.

3v3 Power Regulator

Voor het omzetten van de 5volt uit de Power Jack of de Slimme Meter wordt ook een beproefde schakeling gebruikt. In principe voldoet iedere LDO die ongeveer 500mA kan regelen. Ik heb voor de TC1262-33 gekozen omdat ik daar een voorraad van heb, maar iedere pin-compatible LDO is geschikt.

FTDI Programming Port

Om de ESP32 te kunnen programmeren kies ik (weer) voor een standaard FTDI poort en niet voor een USB poort met CH340C chip. Uiteraard maakt zo’n USB aansluiting het leven wel een stuk makkelijker als je firmware moet flashen, maar laten we wel zijn: dat doe je een paar keer gedurende het leven van de DSMR-logger en dan vaak nog “over the air” met de ingebouwde updateserver. De extra kosten en complexiteit maken het voor mij onzinnig om dit aan het ontwerp toe te voegen. In tegenstelling tot de DSMR-logger Rev. 4 heb ik wel extra componenten opgenomen waarmee het flashen niet meer afhankelijk is van het, in de juiste volgorde indrukken en weer los laten, van de [Flash] en [Reset] switches.

Watchdog

Een Watchdog is een aparte MCU die regelmatig een pulse (heartbeat) van de main MCU (ESP32) krijgt. Stopt de main MCU met het versturen van heartbeats, dan is er iets goed mis en zal de Watchdog, na enige vertraging (misschien komt het nog goed …) de main MCU resetten.

De watchdog is ontworpen rond een ATtiny85. Ik heb hier al eerder een post over geschreven maar wil voor de DSMR-logger32 een iets andere versie maken. Dit is vooral ingegeven door mijn recente ontdekking van NeoPixels! Het leuke van een NeoPixel is dat ze goedkoper zijn dan bijvoorbeeld twee SMD ledjes maar wel alle kleuren van de regenboog kunnen weergeven én dat ze daar maar één data lijn voor nodig hebben. De watchdog zal, afhankelijk van de staat waarin hij verkeert, de NeoPixel als volgt laten branden:

  • Langzaam pulserend groen als alles OK is (er komen regelmatig hartslagen binnen);
  • Korte white flash als er een heartbeat binnen komt;
  • Langzaam pulserend rood als er een bepaalde tijd geen hartslag is ontvangen;
  • Sneller pulserend rood als het kritisch wordt (té lang geen hartslag ontvangen);
  • Rood en daarna wit om aan te geven dat de watchdog de main MCU reset.

De firmware voor de Watchdog kun je hier vinden.

Als je mij wil helpen om meer van dit soort posts te schrijven, overweeg dan om een kleine donatie te geven door op de knop hieronder te klikken.

Secondary P1 poort

Veel gebruikers en makers van de DSMR-logger hebben om een secondary (“Slave” mag vandaag de dag niet meer!) P1 poort gevraagd. Ik heb eerder een post geschreven over een Slimme Meter Poort Extender om aan deze behoefte te voldoen. Maar zo’n extra kastje geeft ook weer extra kabeltjes in de meterkast. Het moge duidelijk zijn dat de nieuwe DSMR-logger32 zo’n poort moet hebben! Al langer speel ik met het idee om een Secondary P1 poort elektronisch en galvanisch gelijk te maken aan de P1 poort van de Slimme Meter zélf (dus een optocoupler met een open collector transistor)!
Ik kom op deze oplossing:

De data van de P1 poort van de Slimme Meter komt binnen op de basis van Q102. Dit is een beproefd model want alle, door mij ontwikkelde, DSMR-loggers doen dat zo.

Q102 inverteert het signaal (hoog wordt laag en vice versa). Dit geïnverteerde signaal (wat eigenlijk het “goede” signaal is) gaat naar pin2 van U102. Een “hoog” signaal laat de led van de optocoupler branden waardoor de (open collector) transistor van de optocoupler gaat geleiden en [Tx_SECONDARY] naar GND getrokken wordt (en dus “laag” wordt). Een “laag” signaal op pin2 doet de led “doven” waardoor de transistor van de optocoupler hoog-ohmig wordt en [Tx_SECONDARY] naar de spanning van een aangesloten apparaat getrokken wordt (en dus “hoog” wordt). Door de manier waarop Q102 en U102 “samen werken” volgt [Tx_SECONDARY] exact de status van [Tx_SM].

Prototype

Klik op het plaatje voor een animatie

Bij het prototype is de Watchdog aangesloten op een ander type NeoPixel (PL9823) dan die ik in het uiteindelijke ontwerp ga gebruiken (WS2812B). Bij de PL9823 zijn Rood en Groen omgewisseld t.o.v. de WS2812B. De Rode led links-onder wordt in het uiteindelijke ontwerp ook vervangen door een NeoPixel. In de animatie van het prototype gaat deze even “aan” als er een telegram binnenkomt.

Het complete schema

Na het bouwen en testen van het prototype ziet het schema er uit zoals in de link hieronder (klik op het plaatje).

Ontwerp Printplaat

De volgende stap is het ontwerpen van een printplaat (PCB). Gelukkig levert KiCad alle tools om dit voor elkaar te krijgen.

Vervolgens de Gerber files naar PCBWay gestuurd en na tien dagen de PCB’s ontvangen. Ze zien er weer goed uit dus snel één bordje stucken en testen.

De Firmware

De DSMRlogger32 firmware heeft als basis de DSMRloggerAPI firmware (versie 3.0.4). De code wordt behoorlijk opgeschoond. Allerhande functies die ik, onder andere, nodig had om zelf JSON strings te maken zijn vervangen door de ArduinoJson 6 library van Benoït Blanchon. Ik kan deze library nu gebruiken omdat de ESP32-WROVER-E PSRAM heeft waar grote, geheugen vretende structuren (zoals die voor het opvragen van bijvoorbeeld historische data nodig zijn) in kunnen worden opgeslagen. De, in eerdere versies van de DSMR-logger gebruikte, ESP8266 heeft geen PSRAM en het was een kunst om alles werkend te houden zonder (al te veel) crashes. Daarbij is veel tijd gestoken in het omzetten van Arduino “String” objecten naar char array’s. Maar door gebrek aan kennis heb ik ook functies geschreven waarmee deze char array’s eenvoudig bewerkt kunnen worden, terwijl veel van deze functies standaard in C/C++ bestaan!

Een aantal gebruikers heeft aangegeven moeite te hebben met de manier waarop in de DSMRloggerAPI firmware de JSON strings zijn opgebouwd (zgn. “Name/Value” pairs). Dit heb ik indertijd zo ontworpen omdat ik onvoldoende kennis had van JSON en dan vooral hoe ik JSON strings in de GUI (Javascript) kon verwerken.
In api versie 1 ziet de uitvoer van ”/api/v1/dev/time” er zo uit:

{"devtime":[
  {"name": "timestamp", "value": "221207120652W"},
  {"name": "time", "value": "2022-12-07 12:06:17"},
  {"name": "epoch", "value": 1670411166},
  {"name": "uptime", "value": "128(d)-18:32(H:m)"},
  {"name": "uptime_secs", "value": 11059921, "unit": "sec"}
]}

De firmware voor de nieuwe DSMR-logger32 stapt af van de “/api/v1” versie. JSON wordt zoals het (blijkbaar) hoort.

Met de ”/api/v2/dev/time” versie van de api ziet bovenstaande JSON string er zo uit:

{
  "devtime": {
    "timestamp": "221207120652W",
    "time": "07-12-2022 12:06:17",
    "time_rev": "2022-12-07 12:06:17",
    "epoch": 1670411166,
    "uptime": "0(d)-00:39(H:m)",
    "uptime_secs": 2386
  }
}

De DSMRloggerAPI firmware heeft de overstap gemaakt van SPIFFS naar het LittleFS. Dit was nodig omdat SPIFFS voor de ESP8266 “depreciated” is. Dus bij het ontwikkelen van de firmware voor de ESP32 ben ik er ook van uit gegaan dat het LittleFS the way to go is! Vervolgens kwam ik erachter dat de HTTPupdateServer geen LittleFS kan flashen! Bummer!
Ik kan ook geen informatie vinden over welke van de twee de voorkeur heeft van de ESP32 Core ontwikkelaars.

Om toch een filesystem met de updateServer te kunnen flashen alles maar terug gezet naar SPIFFS.

Ondertussen draait de firmware stabiel en durf ik hem via github beschikbaar te stellen. De DSMRlogger32 firmware draait in mijn meterkast al enige weken zonder problemen op de DSMR-logger32 hardware.

Veranderingen ten opzichte van DSMRloggerAPI

De settings zijn onderverdeeld in een tab voor “Slimme Meter” settings en voor “Systeem” settings.

Nieuw is de mogelijkheid om (binnen grenzen) zelf te bepalen hoeveel historie er per uur, per dag of per maand moet worden bewaard:

In de maanden tabel worden de afgelopen 12 maanden als totaal opgenomen en het saldo van de gebruikte- en opgewekte energie wordt berekend. Achter de schermen bewaart de DSMRlogger32 firmware alle binnenkomende telegrammen. Hierdoor zie je bij het grafisch opvragen van de “Actuele” data direct de laatste ~150 metingen.

Logging van belangrijke events

Integraal onderdeel van de nieuwe firmware is de SPIFFS_SysLogger bibliotheek. Hierdoor is achteraf nog te achterhalen wat er eventueel mis is gegaan, waarom en wanneer de DSMR-logger32 is ge-reboot en of zich specifieke (fout) situaties hebben voorgedaan.

Standaard worden er 150 regels bewaard voordat de oudste regel wordt overschreven.

Een passende project box

Met behulp van de YAPP-generator heb ik een mooie box voor de DSMR-logger Rev. 5 ontworpen. Over de drie neopixels zijn lichtsluizen geprint die het licht mooi als vierkantjes naast het Oled scherm projecteren. Voor de bediening van de [Reset] en [Flash] knoppen (de laatste heeft een dubbel-functie voor het wakker maken van het Oled scherm) zijn geleiders geprint. Om het Oled scherm te ondersteunen wordt een standaard geprint.

FTDI Programmer

Eén van de redenen waarom de DSMR-logger Rev. 4 geen standaard programmeer header heeft, is omdat ik toendertijd geen éénduidige aansluiting volgorde kon vinden van de verschillende FTDI bordjes. De eenvoudigste oplossing was om alleen TrD en TxD (en GND) te gebruiken en door, in de juiste volgorde de Flash en Reset knopjes in te drukken, de ESP8266 in “Flash Mode” te zetten. Voor veel makers toch een brug te ver. Daarom zijn in het DSMR-logger32 ontwerp twee extra transistoren (Q201 en Q202) toegevoegd (zie hiervoor) waardoor het mogelijk is om, met het juiste FTDI bordje als programmer, de DSMR-logger32 te flashen zónder op knopjes te hoeven drukken (het mág en kán natuurlijk nog steeds wel). Toch schrok ik wel even toen ik de nieuwe DSMR-logger32 voor het eerst wilde flashen, want … dat ging niet! Na veel zoeken en onderzoeken ben ik er achter gekomen wat er niet goed was.

Om te beginnen zat er een fout(je) in mijn ontwerp. De Reset pin naar de Watchdog is aangesloten op GPIO00. GPIO00 is ook verbonden met de collector van Q202 en heeft een belangrijke functie bij het flashen. Helaas is de verbinding tussen GPIO00 en de collector van Q202 in het PCB ontwerp “vergeten” … Daarom moet er in het Rev. 5.0 bordje een draadje gesoldeerd worden tussen Q202 en GPIO00 (die zit wél vast aan SW102, dus dat is een mooi punt om het draadje tussen te leggen). Ook heb ik de waarde van een aantal condensatoren en weerstanden iets aangepast.


Je zou verwachten dat het “bedraad” flashen van de DSMR-logger32 nu zonder problemen zou werken, maar daar zit toch nog een klein probleempje in het feit dat de FTDI bordjes die ik heb wel CTS/DTR naar buiten brengen, maar niet RST! En die is nodig om de ESP32 in “Flash Mode” te krijgen.

Gelukkig had ik nog een paar USB-to-Serial bordjes met een CH340G chip aan boord. De CH340 chip gebruik ik ook in een aantal andere ontwerpen van mij dus de mogelijkheden van deze chip zijn mij bekend. Dit bordje brengt, behalve GND, Tx en Rx ook CTS naar buiten. Wat nog mist is een aansluiting voor RST. Deze heb ik direct op de chip gesoldeerd en alle aansluiting in een 6-polige Pololu housing gestoken. Met dit bordje werkt het flashen probleemloos!

Ook voor de FTDI-programmer een mooi boxje met de YAPP-generator gemaakt!

Maar zoals hiervoor al een keer gemeld kan de DSMR-logger32 óók met een USB to TTL connector worden geflashed (dezelfde die ook voor de vorige versies van de DSMR-logger kan worden gebruikt). Alleen moet je dan, voor het uploaden/flashen, de [Flash] knop indrukken en ingedrukt houden, dan de [Reset] knop indrukken en weer loslaten en dán de [Flash] knop loslaten. Oh ja: zorg er wel voor dat je een 3v3 versie van deze USB to TTL kabel gebruikt!

USB to TTL 3v3

Wrapping it up

Het ontwerpen van de DSMR-logger32 en bijbehorende DSMRlogger32 firmware is uiteindelijk mee gevallen. Alle doelstellingen zijn gehaald en de betrouwbaarheid is vanaf het eerste begin groot gebleken. De enige reboots die ik voorbij heb zien komen hadden te maken met de WiFi verbinding. De DSMRlogger32 firmware heeft het in de gaten als deze wordt verbroken en probeert vervolgens om de verbinding te herstellen. Héél sporadisch lukt dat niet binnen de, in de Watchdog, ingestelde tijd en dan wordt de DSMR-logger32 ge-restart.

Lastig is het dat de Oled schermen geen standaard aansluiting voor GND en Vcc hebben. Ik heb een berg van deze schermpjes in voorraad, veelal bij dezelfde leverancier gekocht, maar toch zit GND bij sommige op pin 1 en bij andere op pin 2. Gelukkig lijken SDA en SCL wél altijd op dezelfde manier aangesloten. In Rev. 5.0 van de PCB ben ik van de volgorde |GND|Vcc|SCL|SDA| uitgegaan en is het Oled scherm op die mannier verbonden. Heb je een schermpje waarbij GND en Vcc zijn omgewisseld dan moet je een print spoortje aan de onderkant van het PCB doorsnijden en twee draadbrugjes aan leggen.

Voor Rev. 5.2 van het PCB heb ik GND en Vcc niet meer standaard doorverbonden en moet je dus, voordat je een Oled schermpje kunt gebruiken altijd zelf draadbrugjes solderen. Dit om te voorkomen dat een Oled schermpje met andere aansluitingen direct bij het in gebruik nemen al kapot gaat!

De officiële documentatie van de DSMR-logger32 kun je hier vinden (let op: Work in progress!).

Ben je, net als ik, enthousiast over deze nieuwe versie van de DSMR-logger32, dan heb ik een aantal PCB’s in voorraad die ik kan verkopen. Zie je op tegen het zelf solderen van de SMD componenten, dan wil ik ook een compleet geassembleerde DSMR-logger32 leveren.
Ik kan ook een mooi bijbehorend kastje voor je in 3D printen!

Als je mij wil helpen om meer van dit soort posts te schrijven, overweeg dan om een kleine donatie te geven door op de knop hieronder te klikken.

This entry was posted in ESP32, ESP8266, Firmware, Hardware, KiCAD and tagged , , , , , , , , , , . Bookmark the permalink.

29 Responses to Crisis? What Crisis? (een betere DSMR-logger)

  1. Deboutte k says:

    Hi
    Weer een mooi project!

    Heb je nog een compleet bordje beschikbaar?

  2. Henk Elzing says:

    Hallo Willem,

    Ik ben zeer geïnteresseerd in deze DSMR logger.

    Heb jij nog een kant en klare set (printje en kastje) liggen?
    Dan zou ik er graag 1 willen kopen.

    • Willem Aandewiel says:

      Henk,

      Leuk dat je enthousiast bent over dit project.

      Ik stuur je een PM.

      • Henk Elzing says:

        Hoi Willem,

        Bedankt voor de DSMR-logger, hij werkt uitstekend.

        Een prachtige toevoeging aan mijn home-domotica.

        “Keep up the good work”

  3. Jochen Korsten says:

    Hoi Willem,

    Een fantastisch mooi DSMR logger project! Ik vraag me af of je nog kant-en-klare printjes incl. kastje over hebt? Dan kan ik mijn bestaande installatie in de meterkast weer eens upgraden 🙂

    Groeten Jochen

  4. Gijs says:

    Hoi Willem,

    Wat een mooi project, hoe is het met de printjes voorraad? Heb je nog geassembleerde printjes? Dat zou heel mooi zijn dan kan ik mijn meterkast daar ook mee verblijden 🙂

    Groeten Gijs

  5. Maarten says:

    Hallo Willem, ik ben bijzonder geïnteresseerd in de ESP32 versie van de DSMR. Al sinds langere tijd loopt bij mij een versie 4.
    Heb je nog printjes over, het liefst met de smd componenten erop.
    Groeten.

  6. Johan says:

    Hoi Willem, Ik stel mijn vraag ook hier nog maar even om anderen erop attent te maken.
    Zoals gezegd in een andere Comment wil ik de tarieven ivm met het prijsplafond voor 2023 aanpassen, maar wat gebeurt er dan met de gegevens van 2022. Je hebt aangegeven dat wanneer ik dit ga aanpassen de gegevens van 2022 dan ook ‘aangepast’ worden (hier ben ik natuurlijk niet blij mee). Kan je dit aanpassen in deze vernieuwde versie, zou mooi zijn. Mijn vraag is nu dan ook aan medegebruikers wat zij hiervan vinden. B.d.w de Logger versie 4 werkt nu ook goed. Gr, Johan.

    • Willem Aandewiel says:

      Hi Johan,

      Het probleem is: hoeveel prijzen zou je willen bijhouden? Heb je een variabel contract dan heb je er misschien wel meerdere per maand nodig. Anderen hebben wellicht genoeg aan vier per jaar. Wanneer gaat zo’n prijs “in”. Allemaal logica die in de GUI moet worden ingebouwd (de DSMRlogger32 doet niets met de prijzen).

      Het is een toevoeging die zeker zinvol is, maar waar ik voorlopig geen tijd voor heb. Eerst maar even zien of er genoeg makers interesse hebben in de DSMR-logger32!

  7. Arie says:

    Hallo Willem,

    Leuk dat de DSMR logger een voortschrijdend (technisch) project blijkt.
    De vorige versies draaien tot volle tevredenheid en ik voorzie op dit moment geen reden om in dit project te stappen.
    Bij Dochter/Schoonzoon met DSMRloggerWS versie mag er zelfs (nog) geen update naar de API versie uitgevoerd worden. Afblijven pap, het werkt! maar ook daar zijn ze druk met de energie en controleren regelmatig hun verbruiksdata via de WS versie.

    In de voorbeeld tabel die je plaatst lees ik wel dat bij jullie de thermostaat ook een graadje lager staat. 2022 – 119 m3 tegen 2021 – 140 m3 😉

    Succes met de verdere uitwerking van versie 5 en ik zal nog regelmatig je website bezoeken.

    • Willem says:

      Hi Arie,

      Joh, je weet niet wat je mist 😉

      Het mooie van de Rev.5 is dat je je “oude” DSMR-logger gewoon in de tweede P1 poort kunt klikken en dan, zolang je dat wilt, beide DSMR-loggers “in de lucht kunt houden” tot je voldoende vertrouwen in de nieuwe hebt!
      Zo heb ik het op het moment ook aangesloten. Niet zozeer omdat ik de Rev.5 niet vertrouw, maar omdat ik zeker wil weten dat beide dezelfde gegevens verzamelen en tonen. Ik merk nu al wel dat de ESP32 een aanzienlijke betere WiFi ontvangst heeft (tien centimeter van elkaar is de RSSI van de Rev.4 rond de -65dB terwijl de Rev.5 rond de -45dB zit!).

  8. Erik says:

    Hoi Willlem,

    Ook bij mij hangt al jaren een voor-vorige versie (meen ik) in de meterkast. En die draait zo soepel dat ik welhaast vergeet dat ik ‘m heb. Nou ben ik handiger met soft- dan met hardware, dus ik vroeg me zo af: kan ik de DSMR logger met ESP32 (liefst kant-en-klaar) bij jou kopen?

    • Willem Aandewiel says:

      Hoi Erik,

      Goed om te lezen dat je tevreden bent met (een vorige versie van) de DSMR-logger!

      Ja, je kunt een “kant-en-klare” DSMR-logger Rev.5 bij mij kopen. Wil je daar ook een ge-3D-print boxje bij?

      Ik stuur je een PM met de kosten!

      Salute!

  9. Johan says:

    Hoi Willem, Misschien een domme vraag maar ik stel hem toch. Kan je de firmware voor
    de DSMRloggerESP32 ook gebruiken voor de DSMRloggerAPI met enige aanpassing natuurlijk ?

    • Willem Aandewiel says:

      Hi Johan,

      Kort antwoord: “Ja” dat kan.
      Moet je wel eerst de ESP8266 vervangen door een ESP32-WROVER module!

      Hm.. misschien kan het dus toch niet ….

  10. Klaas says:

    Hey Willem,
    Weer een mooi project! Ik heb al meer dan twee jaar je oude ontwerp in de meterkast hangen. Werkt prima maar wel met externe voeding, te veel brownouts met de voeding van P1. Waarom gebruik je niet gewoon een all in one esp32 met display? Lekker gemakkelijk met het bouwen en programeren. En met de componenten die je bespaart wellicht ook nog goedkoper. Ik heb diverse projecten gedaan met de TTGO Display. Echt een mooi display en ook twee knoppen. Mogen we ook wensen indienen voor de software? Meer historie! bijvoorbeeld een jaar aan dag info en maand aan uur info. Week info? De spiffs is vrijwel leeg. Je kan de hoeveelheid json data naar de browser afhankelijk maken van een request parameter. De software voor de logger weer in C++ of micropython?

    • Willem Aandewiel says:

      Hallo Klaas,

      Dank voor je comment.

      Ik gebruik geen “kant-en-klaar” bordje omdat het teveel beperkingen geeft. Het lijkt allemaal erg mooi maar ook het bordje waar je naar verwijst heeft zoveel aan boord wat ik niet gebruik en het schermpje is voor mijn, al wat oudere ogen, absoluut ongeschikt. Overigens heb ik het prototype wél met een LiliGo bordje uitgeprobeerd. Daarna omzetten in een “eigen ontwerp” waarbij dan toch weer blijkt dat zaken die met het prototype (LiliGo bordje) wel werkte dat opeens niet meer doet. Ik hou het liever allemaal zelf in de hand! Daarnaast is natuurlijk de lol van deze hobby “om het allemaal zelf te doen“. Soms is dat frustrerend omdat je van alles tegenkomt wat anders werkt dan je had gehoopt maar het uiteindelijke resultaat is zoveel leuker!

      Uiteraard mag je verzoeken voor de software indienen maar mijn uitgangspunt op dit moment is wel de DSMRloggerAPI firmware met iets mínder functionaliteit (mindergas integratie vervalt).

      Overigens is het uitbreiden van de historie eenvoudig één #define _NO_HOUR_SLOTS_ (48 +1) aanpassen. Als je 48 verandert in 96 heb je twee keer zoveel historie over de uren. Maak je er 744 van dan heb je een maand historie!

      En “ja”, nog steeds in C++ (met de Arduino IDE). Ik ben erg nieuwsgierig naar micro Python, maar voor mij nu nog een brug te ver…

      • Klaas says:

        Ik begrijp het, het is maar net wat je uitgangspunt is. Ik heb met de lilygo een leuke thermostaat gemaak met op het display een display wat op een nest thermostaat lijkt. In micropython met een PID ingebouwd. Stuurt de verwarming van mijn werkruimte met MQTT. Wil je meer een “puur” boardje? Overweeg deze dan eens “Wemos S2 Mini esp32 S2“. Leuke van de esp32-s2 is dat de hele serial interface niet nodig is. Als je wat met micropython wil doen dan moet je zeker kijken naar de python asyncio mogelijkheden. Op die manier maak je mooie asynschrone code, is het overzichtelijk en loopt het niet vast. De verhandelingen van Peter Hinch zijn erg goed: Bedankt voor de tip met meer uren, ik ga het eens proberen en ook eens kijken of de week representatie in de html te maken is. Ik beloof niks, ik heb altijd ruzie met javascript 🙂

        • Willem Aandewiel says:

          Hallo Klaas,

          Dank voor de links. Ga ik zeker (een keer) naar kijken.

          Waarom kies je voor een ESP32-S2? Het grote voordeel van de “gewone” ESP32 is dat hij twee cores heeft. De S2 is een uitgeklede versie met maar één core!

          In de nieuwe firmware, voor het Rev. 5 bordje, kun je de historie van de RING bestanden via de GUI vergroten (of verkleinen).

          Wat wil je aan de “representatie in html” aanpassen?
          Voor meer historie hoef je aan de GUI niets aan te passen.

  11. Willem Aandewiel says:

    Hey Johan,

    Het is “een werkende versie in ontwikkeling”.
    Na de werking met het prototype getest te hebben, heb ik de printplaat ontworpen. Omdat het prototype rond een LilyGo bordje is opgebouwd is het altijd de vraag of het met KiCad gemaakte schema (met een “bare” ESP32-WROVER-E processor) en daar van afgeleide printplaat ook precies doet wat ik bedacht heb.
    De grootste uitdaging op dit moment is het geschikt maken van de firmware voor de ESP32.
    Daarnaast heb ik nog wat hardware problemen zoals de FTDI interface die het automatisch flashen nog niet goed doet plus het Heartbeat signaal dat ik hardwarematig bedacht had via GPIO00 te laten lopen, maar dat “werkt niet” (het werkte zo wel bij prototype dat is gemaakt met een LilyGo bordje die dus blijkbaar toch weer rare dingen doet die je niet verwacht!). Dus een spoortje omgeleid en nu komt de hartbeat uit GPIO05.
    En gisteren stopte de NEO pixels met goed werken. Ga ik vandaag uitzoeken.

  12. Johan says:

    Hoi Willem. Het ziet er weer gelikt uit. Is dit nu een werkende versie. Kan me niet voorstellen dat je alles hebt ontworpen met Kicad en vervolgens de printjes klaar hebt, nog aan het testen bent. Deze wordt waarschijnlijk ook mijn volgende project. Eerst de “oude” Hub nog aan de praat zien te krijgen. Johan

  13. Johan Wolbink says:

    Hoi Willem,
    Mooi dat je deze nieuwe uitdaging weer aangaat. Wordt dit project ook weer rond de ESP32 opgezet of zit je ook nog aan andere mogelijkheden te denken. Ga je dit helemaal zelf doen of heb je mensen om je heen die je helpen en ondersteunen ? Veel succes met voorbereiden.
    Gr. Johan.

    • Willem Aandewiel says:

      Hoi Johan,

      De behoefte is eigenlijk ontstaan omdat DSMR-loggers soms niet meer bereikbaar zijn maar nog wel netjes loggen (daarvoor kun je nu al de DSMR-logger één maal per dag, automatisch, laten re-booten) en héél soms gewoonweg “hangen”. Dan worden dus ook de verbruiksgegevens niet meer opgeslagen! Als je dan na een paar dagen wil kijken wat je zonnepanelen de afgelopen dagen hebben gedaan zit je met een grafiek met uitschieters.
      De nieuwe DSMR-logger heeft een hardwarematige Watchdog. De ESP32 stuurt om de paar seconden een hartslag naar de Watchdog. Ontvangt deze een bepaalde tijd géén hartslag dan mag je aannemen dat de ESP32 “ergens” hangt en dan zal de Watchdog de ESP32 resetten.

      Vooralsnog doe ik alles zelf in splendid isolation maar als je wilt helpen dan ben je van harte welkom.

      • Johan says:

        Hoi Willem, Ik zie dat je al heel wat stappen hebt gemaakt, voor mij is het nog even meekijken naar dit nieuwe project. Ik zou je graag willen helpen maar mijn kennis ligt een aantal stappen lager dan die van jou dus zou ik niet weten waarmee ik je op dit moment kan helpen. Ben nu nog met de vorige versie aan het solderen. De Hub ligt klaar nu nog de Logger.

        Blijf je volgen.

Leave a Reply

Your email address will not be published.

The maximum upload file size: 4 MB. You can upload: image, other. Links to YouTube, Facebook, Twitter and other services inserted in the comment text will be automatically embedded. Drop file here

This site uses Akismet to reduce spam. Learn how your comment data is processed.