[ 12,845 keer bekeken / views ]
Door de jaren heen had ik mijn Slimme Meter uitgelezen met een USB P1 kabel en een Raspberry PI, echter een Raspberry PI moet regelmatige geupdate worden, SD kaartjes gaan kapot, Home Automation software moet regelmatig bijgewerkt worden om van nieuwe functies gebruik te kunnen maken.
Ik was dus op zoek naar een betrouwbare en draadloze manier om mijn Slimme Meter uit te lezen, geheel onafhankelijk van mijn home automation, dat was mijn doel vorig jaar. Toen ik eind vorig jaar de DSMR-logger oplossing van Willem Aandewiel ontdekte was ik gelijk enthousiast. Het project voldeed aan al mijn wensen, een open hardware en open source Slimme Meter uitlees oplossing, die ik zelf naar inzicht kon gaan uitbreiden.
Kort nadat ik het DSMR-logger v4.0 in elkaar gesoldeerd had en de firmware gedownload en gecompileerd en operationeel had was het eerste wat ik deed mijn mindergas.nl integratie (die ik ook al eens gemaakt had voor Domiticz) ontwikkelen voor DSMR-logger. Zo begon mijn eerste bijdrage aan de DSMR firmware, het was even wennen, een actieve bijdrage aan een project is net weer wat anders dan het gebruiken van een project. Na mijn initiële hack van DSMR heb ik met Willem contact opgenomen om hem te vragen of hij de nieuwe integratie in zijn firmware wilde opnemen. Willem reviewde mijn mindergas integratie en vroeg me om het te verbeteren door middel van een Finite State Machine implementatie.
Die kwam uiteindelijk in de code terecht. Door de tijd heen heb ik diverse kleine bijdragen geleverd aan het prachtige project van Willem.
Met release v2.0 is de REST API versie van de DSMR-logger firmware (DSMRloggerAPI) beschikbaar gekomen en daarmee is de eenvoudige integratie op basis van een REST API mogelijk geworden, integratie met de meeste home automation is nu nog verder vereenvoudigd. Daarnaast blijft de MQTT integratie een essentiële optie. Zelf maak ik tegenwoordig gebruik van home assistant en om grafieken te maken van al mijn sensors in mijn huis maak ik gebruik van de combinatie InfluxDB en Grafana. Een zeer krachtige combinatie van een time-series database en een visualisatie tool die me in staat stelt om eenvoudig een dashboard te maken. Het dashboard hieronder heb ik gemaakt in Grafana, waar ik ook de opgewekte energie, alswel de informatie uit de DSMR-logger zichtbaar maak.
Sinds kort beschik ik ook over zonnepanelen met een converter van SolarEdge, het opwekken van energie en het terugleveren aan het inzichtelijk maken is vrij eenvoudig in Grafana, mits je daar de bron informatie in weet te krijgen. Na wat configuratie werk was het zover, een eerste grafiek van mijn opgewekte energie.
Om dit mogelijk te maken heb ik DSMR-logger gegevens via MQTT hub, naar Home Assistant gestuurd, vandaar uit gaat het door InfluxDB, om uiteindelijk in Grafana te visualiseren. Overduidelijk waren er dus meerdere tussenstappen nodig om de informatie op mijn dashboard te krijgen. En zo ontstond het idee om de DSMR-logger een extra feature te geven, en wel de mogelijkheid om rechtstreeks in de influxdb database te laten schrijven. Het bleek een kleine uitbreiding op de DSMRloggerAPI firmware te zijn en intussen logt mijn DSMR-logger alweer een poosje rechtstreeks data naar InfluxDB.
Na overleg met Willem heb ik besloten om op mijn eigen fork van het project DSMRloggerAPI, door te ontwikkelen. De fork is een zelfstandig doorontwikkeling van de firmware, onder de naam DSMRlogger-Next. Het is mijn bedoeling om de firmware nog verder uit te breiden met nieuwe features, te verbeteren en eventuele bugs die ik tegenkom op te lossen.
De influxdb writer feature is te vinden in de nieuwe fork die ik ga onderhouden. Momenteel ben ik mijn influxdb aan het duurtesten en te checken of alles wat ik aangepast heb goed werkt. Naast de nieuwe feature heb ik ook een bug opgelost die ik ontdekte met mijn Slimme Meter met DSMR spec v4.2, zodat ik nu weer om de 10 seconden een telegram kan ontvangen.
Ik heb momenteel mijn eerste release candidate (rc0) hier gepubliceerd:
Als je mij wilt helpen, dan zou ik het prettig vinden als anderen dan de nieuwe feature gaan testen. Bij mij werkt het intussen betrouwbaar met mijn InfluxDB server. Dat wil niet zeggen dat ik niets over het hoofd zie, voorlopig ga ik nog even door met testen van de huidige release candidate.
Deze branch met de feature influxdb writer is na compilatie via de Adruino IDE, eenvoudig te installeren via de OTA update mogelijkheid die ingebouwd is in de DSMR-logger firmware. Zie de documentatie van Willem hierover. Na het inlezen en hernieuwd opstarten zal je de influxdb writer moeten configureren, dat doe je als volgt.
Opmerking: Dit is geen handleiding hoe je InfluxDB en Grafana installeert. Er zijn hier voldoende zeer uitgebreide blogs en video’s op YouTube over te vinden. De volgende beschrijving gaat dus in op hoe je InfluxDB en de DSMRloggerAPI moet configureren.
Eerst de InfluxDB configureren:
- Configureren van een lege influxdb database voor DSMR-logger Ga naar het webinterface van je influxdb (meestal Chornograf), log eerst in, en ga naar InfluxDB Admin.
- In de InfluxDB Admin pagina, maak je een nieuwe (lege) database aan:
- Voer de naam van de nieuwe database in. Het is handig om de hostnaam van de DMSR-logger te gebruiken (te vinden op het instellingen scherm van je logger) en klik op het groen vinkje:
- Je zult dan ter bevestiging de database aangemaakt zien:
- Belangrijk om te onthouden, dit is de Influxdb database. De naam die je gebruikt hebt is “case-senstive”. Deze naam gebruik je later in je DSMR-logger instellingen op exact dezelfde manier.
Bij versie 1.x van InfluxDB is het niet nodig om wachtwoorden en gebruikers aan te maken voor data schrijvers. Je mag dus altijd naar een InfluxDB schrijven, lezen daarentegen is wel afgeschermd met gebruikersnaam en wachtwoorden.
Daarmee is de InfluxDB klaar voor gebruik. Nu de DSMR-logger configureren voor
gebruik:
- In de DSMR Logger software ga je naar de instellingen door op het tandwieltje:
rechts boven in het scherm te klikken. - In het instellingen scherm zijn drie nieuwe InfluxDB instellingen te zien, namelijk:
– Hostname
– Port
– Database name
- In het plaatje hierboven zie je een IP nummer, maar een hostname van je InfluxDB server mag ook. De default poort voor influxDB versie 1.x is 8086. En zoals je bovenaan hebt kunnen zien, heb ik een database aangemaakt met de naam “dsmr-api” (let op: dit is hoofdletter gevoelig, vul dus exact dezelfde naam in als je gedaan hebt bij het aanmaken van de InfluxDB).
- Sla de nieuwe instellingen op, door bovenaan op
te klikken.
En dat is het al… na enkele seconden zal InfluxDB beginnen met het ontvangen van de Telegram waarden. Alleen de meetgegevens worden doorgestuurd en als je in influxDB gaat kijken, dan zul je daar automatisch gegenereerde tags/labels zien verschijnen met data. Na ontvangst van elk nieuwe telegram zal influxDB ook die nieuwe waarde ontvangen, naast het eventueel gebruiken van MQTT of de REST API. Die blijven gewoon werken zoals voorheen.
Nu de gegevens in de influxDB database stromen, kan je ze gebruiken in Grafana om de meetgegevens te tonen in je eigen dashboard.
Ik hoor graag van jullie of dit een nuttige uitbreiding op de firmware is voor de DSMR-logger. Mocht je hiermee aan de slag gaan, laat je eigen ervaringen hieronder in de comment sectie weten. Dit is mijn eerste release candidate, dus ontdekt je bugs, of problemen, laat het me vooral weten als een issue op mijn github repo als een issue .
Feedback is welkom… dus graag hieronder jullie opmerkingen.
Follow
Krijg het helaas niet aan de praat met influxdb v2 cloud.
De post over de influxDB integratie is door Robert van den Breemen geschreven.
Je kunt daarom ook het beste bij hem te raden gaan.
Hey ik kom toevallig nu terecht op je website omdat een gebruiker van mijn product een oplossing zoekt om te loggen in InfluxDB. Heb even naar je code gekeken (niet mijn sterkste kant) en ziet er naar uit dat dat ook op mijn SlimmeLezer werkt (zelfde principe als wat Willem Aandewiel heeft gemaakt). Ga dit gelijk proberen 🙂
Ik zit er over te denken om deze op mijn DSMr-logger te zetten in plaats van de versie van Willem, maar enig idee of deze makkelijk integreert met het nieuwe energie dashboard van Home-Assistant? Het lukt me namelijk niet om de gegevens uit de versie van Willem in dat energiedashboard te krijgen.
Intussen heb ik het Energie Dashboard wel aan de praat met mijn versie DSMRnext en een uitbreiding op de definities die ik gebruik voor de Home Assistant integratie.
Nog steeds weinig tijd gespendeerd aan het bijwerken van DSMRnext, in december heb ik daar wel wat tijd voor gereserveerd. Overigens mijn “dev” branch bevat de laatste versie die ik zelf met succes draai.
Dus laat je vooral niet tegenhouden om die versie in te zetten.
Groet,
Robert
Ik ben een beetje bang om mijn DSMRlogger te flashen met deze versie, want ik heb de laatste versie van Willem 3.0.1 er al opstaan, met de LittleFS ipv SPIFSS filesystem.
Als ik tijd heb zal ik me er eens in verdiepen hoe deze filesystems verschillen.
Otto
Io raad je ook aan te wachten tot ik kans gehad heb om de aanpassingen van Willem te mergen in mijn release.
Groet
Robert
Hoe staat het er voor met het mergen van Willem’s 3.0.2 aanpassingen in jouw -next fork?
Hoi Allemaal,
Het is een beetje stil geweest de afgelopen maanden, omdat ik verzeild ben geraakt in een ander projectje, met de naam: OTGW firmware.
Echter, ik sta open om pull request en uitbreidingen op de Next firmware te maken, accepteren.
Ik ben tegenwoordig te vinden op Discord, het eenvoudigst is als je mij even mailt via: robert@vandenbreemen.net
Dank gaan ik aan de slag met jullie verbeteringen,
Robert
Hallo Robert,
Ik heb een vraag die verband houdt met jouw Mindergas implementatie in de DSMRloggerAPI software.
Ik heb (net als jij las ik) zonnepanelen van SolarEdge. Ik maak gebruik van de SE-monitoring-api om data op te halen voor presentatie in Domoticz. Gaat perfect. Jij doet waarschijnlijk hetzelfde met InfluxDB/Grafana.
Zelf ben ik echter ook tabel-georienteerd en vind de tabellen mbv DSMR RestAPI calls heel duidelijk (en ik wil die tabellen dus uitbreiden met zonnestroom data).
Wat ik zou willen is dat ik in de DSMRloggerAPI software ook de call naar SolarEdge kan doen; identiek aan jouw Mindergas Finite-State-Software.
Ik heb een standalone programma geschreven in Arduino (httpS call) en dat levert mij prima de data op in json format. Ik gebruik daarbij de client.setInsecure() method om de certificaten te skippen.
Zoals dit:
const char* host = “monitoringapi.solaredge.com”;
void SolarEdge()
{ if (!DUE(updateSolarEdge)) return;
// Use WiFiClientSecure class to create TLS connection
WiFiClientSecure client;
client.setInsecure();
//— try to connect to SolarEdge
DebugTf(“Connecting to %s …\r\n”, host);
//— connect over https with solaredge
if (client.connect(host, 443))
{
String url = “/site/XXXXXXX/overview.json?api_key=XXXXXXXXXX”;
Serial.print(“requesting URL: “);
Serial.println(url);
client.print(String(“GET “) + url + ” HTTP/1.1\r\n” +
“Host: ” + host + “\r\n” +
“User-Agent: BuildFailureDetectorESP8266\r\n” +
“Connection: close\r\n\r\n”);
Serial.println(“request sent”);
Als in die software echter in DSMRloggerAPI opneem gaat het fout.
Al bij het connecten krijg ik een abort.
Robert, ben jij ook bezig geweest met https-requests / heb jij enig idee waardoor het hier fout gaat.
mvrgr, Bauke
Bauke,
Sorry, dit bericht aan mij heb ik gemist. En ja, ik heb geprobeerd om https aan de praat te krijgen, maar dat lukte me niet, dus heb ik het opgegeven in 2019. Intussen is het onderliggende sdk van ESF wel flink verbeterd.
Dus dit zou zeker wel de moeite waard zijn om weer eens tijd in te investeren.
Op de backlog van mijn update in december dan maar?
Of is het je intussen gelukt?
Hallo Robert,
Ja, het is me gelukt om periodiek een call te doen naar SolerEdge.
Ik heb ook de nodige aanpassingen gedaan in Willem’s software. Ook de api calls aangepast.
Ik zal je binnenkort een keer de aanpassingen mailen..
Is wel op basis van Willem’s software en dus niet opv jouw fork.
Voor een goed resultaat heb je natuurlijk wel een api-key en site-id nodig van SE maar ik neem aan dat jij die hebt.
Mvrgr, Bauke
Nice, werkt prima!
Benieuwd naar verdere ontwikkelingen.
Ik heb heb ook kort na de error-constatering een logregel toegevoegd:
DebugTln(client.getLastErrorMessage());
Die blijft alleen leeg, gek genoeg. Dus toch geen error?
De oplossing was de validatie-regel weg te halen (111), dus ik denk dat het probleem in de InfluxDB ardiuno library zit.
Ik zoek nog naar een betere oplossing, zal hem hier posten als ik hem vind. Maar voor nu werkt het goed.
De oplossing is inderdaad een betere InfluxDB library, die bugs zijn intussen gefixed zie ik in de library versie info. Maar ik moet zelf hier opnieuw naar kijken.
Backlog items voor december.
Groet,
Robert
Robert,
Heb de fork ook aan de praat, het werkt allemaal perfect, tot op 2 dingetjes na, ik heb een PR jouw kant op gestuurd, de USE_NTP definitie was verkeerd om. Zal in de hooft-versie al gefixed zijn, gok ik.
Ook heb ik een probleem met het connecten naar de influxdb, maar ik zie het probleem niet, influx werkt naar behoren (ook van buitenaf). Op de TCPDump zie ik ook alleen maar goeie dingen:
[18:15:04][ 12352| 11192] handleInflux( 111): InfluxDB connection problem! (foutmelding)
TcpDump:
GET /ping?verbose=true HTTP/1.1
Host: 192.168.1.11:8086
User-Agent: influxdb-client-arduino/3.7.0 (ESP8266 2.7.3-3-g2843a5ac)
Accept-Encoding: identity;q=1,chunked;q=0.1,*;q=0
Connection: keep-alive
Accept: application/json
Content-Length: 0
HTTP/1.1 204 No Content
Content-Type: application/json
Request-Id: e866fcc1-6afa-11eb-8178-000000000000
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.6.4
X-Request-Id: e866fcc1-6afa-11eb-8178-000000000000
Date: Tue, 09 Feb 2021 17:19:03 GMT
En die “No content” is de standaard response van InfluxDB volgens de specificaties.
Thanks, ik ga erna kijken in december.
Groet,
Robert
Hoi Robert,
zo te zien werkt jouw fork perfect. Net alles online gebracht op een 2e DSMR api bordje en parallel aan de originele gezet.
Ik zoek alleen nog waarom het lijkt dat de data in influxDB een timestamp heeft die 10 minuten achter loopt.
Alvast dank voor wat je gemaakt hebt.
Heb ook nog wel paar extra ideeen, bv. 2 extra S0 poorten om kWh meter van zonnepanelen en warmtepomp apart te loggen.
De problemen zijn intussen opgelost. De firmware is doorontwikkeld en stabiel, mede dankzij jou @RobRoos