search

dsmrreader / dsmr-reader

DSMR-telegram reader & data visualizer for hobbyists. Free for non-commercial use.
https://dsmr-reader.readthedocs.io
Other
462 stars 95 forks source link

Meterstanden ontvangen via MQTT #728

Closed hdoedens closed 4 years ago

hdoedens commented 5 years ago

Ik ben aan het migreren van Domoticz naar DSMR-Reader voor inzicht in mijn energieverbruik. Allereerst grote complimenten voor deze software!

Mijn setup is als volgt:

Probleem

Ik zie geen optie om MQTT als bron voor de meterstanden te gebruiken. De enige MQTT gerelateerde uitleg die ik kan vinden gaat om het doorsturen van data. Ik heb juist MQTT als bron nodig, aangezien mijn Rpi niet in de buurt van de meterkast is. Zie ik iets over het hoofd of ontbreekt deze feature?

dennissiemensma commented 5 years ago

Dat klopt helemaal! Momenteel is alleen de export via MQTT en niet de import.

Je kunt echter vrij gemakkelijk de API van DSMR-reader gebruiken om metingen aan te maken. Dit kan door ofwel het hele ruwe telegram op te sturen, ofwel door de velden gesplitst te specificeren (want je gebruikt al iets van JSON).

hdoedens commented 5 years ago

Dank voor je reactie. Aangezien Tasmota niet zomaar custom HTTP requests kan doen moet ik een processje op de pi laten lopen die de berichten van de MQTT broker leest en via HTTP doorstuurt naar DSMR-Reader via de API, zoals jij aangaf. Het zou mooi zijn als DSMR-Reader direct vanuit MQTT kon ontvangen. Is dit iets wat misschien nog toegevoegd gaat worden? Of misschien kun je een paar pointers geven dan kan ik kijken of ik het zelf kan toevoegen.

dennissiemensma commented 5 years ago

Ik zou daar onderzoek naar moeten doen. Wellicht is er wat mogelijk

hdoedens commented 5 years ago

Ik stuur nu met een Python scriptje meterstanden door van een MQTT topic naar DSMR-Reader, maar de berichten worden niet verwerkt. Even een testje gedaan vanuit Postman om te zien of het aan het Python script ligt, maar ook dan worden ze niet verwerkt.

curl -X POST \
  http://192.168.1.28:7777/api/v2/datalogger/dsmrreading \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -H 'postman-token: b87ba177-2d55-bd81-25ac-2f2b158c59dc' \
  -H 'x-authkey: NTJ4NOH4TFB1JS2SXZ7NYHEO1KNHPL4OAMPJTF9WPPUUSR6NIQ79XJQRQO85PTP7' \
  -F electricity_currently_delivered=0.119 \
  -F electricity_currently_returned=0 \
  -F electricity_delivered_1=0 \
  -F electricity_delivered_2=0 \
  -F electricity_returned_1=0 \
  -F electricity_returned_2=0 \
  -F timestamp=2019-10-03T21:08:36

Ik gebruik het Docker image van Xirixiz. In de logging van de container lijkt alles OK. Ik krijg het echter niet voor elkaar specifieke logging te krijgen voor de background processen zoals hier beschreven. Ik pas settings.py aan in de Docker container en start de container opnieuw. post-deploy.sh vanuit de container draaien resulteert in de volgende fout:

 --- Checking whether VirtualEnv is activated.
     [i] ----- Activating 'dsmrreader' VirtualEnv...
./post-deploy.sh: line 10: /root/.virtualenvs/dsmrreader/bin/activate: No such file or directory
     [!] FAILED to switch to 'dsmrreader' VirtualEnv (is it installed?)

Heb je misschien een idee waarom dit niet werkt?

dennissiemensma commented 5 years ago

De API-call zelf lijkt goed. Als ik hem lokaal uitvoer (samen met | python -m json.tool) krijg ik informatie terug:

curl -X POST \
  http://localhost:8000/api/v2/datalogger/dsmrreading \
  -H 'cache-control: no-cache' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -H 'postman-token: b87ba177-2d55-bd81-25ac-2f2b158c59dc' \
  -H 'x-authkey: test' \
  -F electricity_currently_delivered=0.119 \
  -F electricity_currently_returned=0 \
  -F electricity_delivered_1=0 \
  -F electricity_delivered_2=0 \
  -F electricity_returned_1=0 \
  -F electricity_returned_2=0 \
  -F timestamp=2019-10-03T21:08:36 \
   | python -m json.tool
{
    "id": 11487202,
    "timestamp": "2019-10-03T21:08:36+02:00",
    "electricity_delivered_1": "0.000",
    "electricity_returned_1": "0.000",
    "electricity_delivered_2": "0.000",
    "electricity_returned_2": "0.000",
    "electricity_currently_delivered": "0.119",
    "electricity_currently_returned": "0.000",
    "phase_currently_delivered_l1": null,
    "phase_currently_delivered_l2": null,
    "phase_currently_delivered_l3": null,
    "extra_device_timestamp": null,
    "extra_device_delivered": null,
    "phase_currently_returned_l1": null,
    "phase_currently_returned_l2": null,
    "phase_currently_returned_l3": null,
    "phase_voltage_l1": null,
    "phase_voltage_l2": null,
    "phase_voltage_l3": null
}

Krijg je zelf uberhaupt output terug?

dennissiemensma commented 5 years ago

Wat betreft debugging in Docker, je kunt dat het beste even bij Xirixiz zelf vragen. Mijn Docker-kennis is vrij beperkt

hdoedens commented 5 years ago

ik krijg inderdaad ook netjes een bericht terug, maar toch wordt het telegram niet verwerkt.

Ik zal bij xirixiz vragen idd. Ik ben inmiddels met een 2e pi bezig om een losse installatie van DSMR-Reader te doen om te kijken wat er daar gebeurt.

Bedankt voor je hulp.

dennissiemensma commented 5 years ago

Zie je het aantal onverwerkte telegrammen in de Status-pagina oplopen, of zie je geen (nieuwe) gegevens in de interface?

hdoedens commented 5 years ago

het aantal onverwerkte telegrammen loopt op en in de interface staat dat ie geen data heeft

dennissiemensma commented 5 years ago

Kun je via Docker wel bij de Supervisor processen? Mogelijk draait dsmr_backend niet en die verwerkt alle gegevens.

sudo supervisorctl status
hdoedens commented 5 years ago 
4mINFO ] Starting supervisord...
2019-10-08 15:03:23,622 INFO Included extra file "/etc/supervisor.d/supervisord.ini" during parsing
2019-10-08 15:03:23,623 INFO Set uid to user 0 succeeded
2019-10-08 15:03:23,700 INFO RPC interface 'supervisor' initialized
2019-10-08 15:03:23,701 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2019-10-08 15:03:23,702 INFO supervisord started with pid 14
2019-10-08 15:03:24,712 INFO spawned: 'nginx' with pid 16
2019-10-08 15:03:24,722 INFO spawned: 'dsmr_mqtt' with pid 17
2019-10-08 15:03:24,739 INFO spawned: 'dsmr_webinterface' with pid 18
2019-10-08 15:03:24,750 INFO spawned: 'dsmr_datalogger' with pid 19
2019-10-08 15:03:24,762 INFO spawned: 'dsmr_backend' with pid 20
2019-10-08 15:03:25,774 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-10-08 15:03:25,775 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-10-08 15:03:25,776 INFO success: dsmr_datalogger entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-10-08 15:03:25,778 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2019-10-08 15:03:28,115 INFO success: dsmr_webinterface entered RUNNING state, process has stayed up for > than 3 seconds (startsecs)

Dit zie ik in de logging. Ik ga er van uit dat de processen dan draaien. Wanneer ik in de container supervisorctl status doe (sudo bestaat niet in Docker) dan krijg ik de volgende melding unix:///run/supervisord.sock no such file Maar als ik top start dan lijkt het backend proces toch te draaien:

Load average: 0.39 0.41 0.37 5/353 78
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   56    14 root     SN   51168   5%   1   0% python3 -u /dsmr/manage.py dsmr_backend
   55    14 root     SN   50992   5%   0   0% python3 -u /dsmr/manage.py dsmr_datalogger
   57    14 root     SN   51040   5%   3   0% python3 -u /dsmr/manage.py dsmr_mqtt
   14     1 root     S    15780   2%   1   0% {supervisord} /usr/bin/python2 /usr/bin/supervisord -n
dennissiemensma commented 5 years ago

Hmm, in dat geval kun je het beste bij Xirixiz informeren hoe je de logging exact kan inzien. Als die op logging.DEBUG staat, zul je in de log van dsmr_backend namelijk moeten kunnen zien wat die doet.

dennissiemensma commented 5 years ago

Voor je beeld, je krijgt dan zoiets te zien:

 tail -f /var/log/supervisor/dsmr_backend.log

...

[2019-10-08 20:43:29,991] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:31,014] DEBUG    Calling 0 backend service(s)
[2019-10-08 20:43:31,044] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:32,063] DEBUG    Calling 0 backend service(s)
[2019-10-08 20:43:32,095] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:33,115] DEBUG    Calling 0 backend service(s)
[2019-10-08 20:43:33,159] DEBUG     - Processed reading: 11757441 @ 2019-10-08 20:42:07+02:00 (1.416 kW)
[2019-10-08 20:43:33,168] DEBUG     - Processed reading: 11757442 @ 2019-10-08 20:42:17+02:00 (1.642 kW)
[2019-10-08 20:43:33,178] DEBUG     - Processed reading: 11757443 @ 2019-10-08 20:42:27+02:00 (0.265 kW)
[2019-10-08 20:43:33,193] DEBUG     - Processed reading: 11757444 @ 2019-10-08 20:42:37+02:00 (1.395 kW)
[2019-10-08 20:43:33,203] DEBUG     - Processed reading: 11757445 @ 2019-10-08 20:42:47+02:00 (1.636 kW)
[2019-10-08 20:43:33,212] DEBUG     - Processed reading: 11757446 @ 2019-10-08 20:42:57+02:00 (0.251 kW)
[2019-10-08 20:43:33,228] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:34,252] DEBUG    Calling 0 backend service(s)
[2019-10-08 20:43:34,273] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:35,288] DEBUG    Calling 0 backend service(s)
[2019-10-08 20:43:35,307] DEBUG    Sleeping 1 sec(s)
[2019-10-08 20:43:36,332] DEBUG    Calling 0 backend service(s)

...
hdoedens commented 5 years ago

Ok. Ik heb inmiddels een verzoekje bij hem gedropt. Ik ga kijken wat de losse Pi doet, maar waarschijnlijk werkt dat gewoon... Ik laat het weten als ik weet wat er mis ging, ter lering ende vermaek voor anderen misschien :)

hdoedens commented 5 years ago

hmm... bij een verse installatie direct op het OS (Raspbian) krijg ik hetzelfde resultaat. Ik stuur de data via Postman en krijg een 'OK' response net als bij de Docker installatie. Nu kan ik wel in het backend-log kijken (heb het level op DEBUG gezet en post-deploy.sh gedraaid als dsmr user. less /var/log/supervisor/dsmr_backend.log:

[2019-10-08 21:16:10,127] DEBUG    Calling 0 backend service(s)
[2019-10-08 21:16:10,306] DEBUG    Sleeping 1 sec(s)
[2019-10-08 21:16:11,425] DEBUG    Calling 0 backend service(s)
[2019-10-08 21:16:11,605] DEBUG    Sleeping 1 sec(s)
[2019-10-08 21:16:12,727] DEBUG    Calling 0 backend service(s)
[2019-10-08 21:16:12,928] DEBUG    Sleeping 1 sec(s)
[2019-10-08 21:16:14,047] DEBUG    Calling 0 backend service(s)
[2019-10-08 21:16:14,235] DEBUG    Sleeping 1 sec(s)
[2019-10-08 21:16:15,356] DEBUG    Calling 0 backend service(s)
[2019-10-08 21:16:15,540] DEBUG    Sleeping 1 sec(s)

Ook nu loopt het aantal onverwerkte berichten op

dennissiemensma commented 5 years ago

Standaard groepeert de backend metingen per minuut. Zie je na een minuut nog steeds geen andere loglines?

dennissiemensma commented 5 years ago

Wat krijg je hier te zien?

sudo su - postgres
psql dsmrreader

select timestamp, processed from dsmr_datalogger_dsmrreading order by timestamp desc limit 25;
dennissiemensma commented 5 years ago

En wat is de systeemtijd van je Pi/OS?

date
hdoedens commented 5 years ago 
postgres@raspberrypi:~$ psql dsmrreader
psql (11.5 (Raspbian 11.5-1+deb10u1))
Type "help" for help.

dsmrreader=# select timestamp, processed from dsmr_datalogger_dsmrreading order by timestamp desc limit 25;
       timestamp        | processed 
------------------------+-----------
 2019-10-03 20:08:36+01 | f
 2019-10-03 20:08:36+01 | f
 2019-10-03 20:08:36+01 | f
 2019-10-03 20:08:36+01 | f
 2019-10-03 20:08:36+01 | f
(5 rows)

dsmrreader=# quit
postgres@raspberrypi:~$
hdoedens commented 5 years ago

logging is niet verander in de log file en systeemtijd is: 

postgres@raspberrypi:~$ date
Tue 08 Oct 2019 08:30:20 PM BST
postgres@raspberrypi:~$
hdoedens commented 5 years ago

ik heb 5 berichten ingeschoten tot nu toe

dennissiemensma commented 5 years ago

Aah, ik denk dat ik het al weet. Kun je eens een meting inschieten die later is dan de bestaande?

hdoedens commented 5 years ago

yes! dat is het inderdaad. Ik heb eentje ingeschoten met de datum van vandaag, nu zijn alle telegrammen verwerkt. Ook in de Docker container werkt het nu 👍 Het is mis gegaan toen het opzetten van de container niet helemaal goed ging. Toen ben ik overgegaan van het Python script wat actuele data stuurt naar het inschieten met Postman. De container draaide minmiddels goed, maar nu was het testbericht niet goed. Zeer bedankt voor je hulp en nogmaals complimenten voor DSMR-Reader!

dennissiemensma commented 5 years ago

Er zit namelijk een beveiliging in die metingen alleen verwerkt wanneer er nieuwe metingen zijn op de volgende minuut, of later. En dat is omdat sommige slimme meters enkele seconden of zelfs minuten achterlopen en dat het groeperen van metingen op de minuut onbetrouwbaar maakt(e). Dit voorkomt die situatie.

Normaal gesproken krijg je namelijk nooit de situatie die je hebt nagebootst. Als de telegrammen blijven binnenkomen, dan verspringt die vanzelf naar de volgende minuut. En verwerkt die uiteindelijk de metingen.

Als alternatief kun je nog ervoor kiezen om niet te groeperen per minuut, maar dat is afhankelijk van je eigen behoeftes. Voor nu kun je het oplossen door gewoon opvolgende metingen in te schieten. Ik besef me nu dat er nog geen debug-logging is voor die check en die zal ik later toevoegen.

hdoedens commented 5 years ago

Ah. Dank voor de toelichting.

dennissiemensma commented 5 years ago

Fijn om te horen. Voor nu laat ik inkomende data via MQTT dan even voor wat het is. Als er veel vraag naar is kan ik het altijd opnieuw overwegen.

idserda commented 5 years ago

Zie dat dit issue al gesloten is, maar inkomende data via MQTT lijkt mij ook erg handig. Heb hier zelfde situatie als de maker van dit issue. Gebruik nu openHAB om data van MQTT topic om te zetten in HTTP call, maar zou handiger/betrouwbaarder zijn als data uit topic direct opgepakt zou worden.

dennissiemensma commented 5 years ago

Het hangt er ook vanaf welke data dan beschikbaar is. Staat het telegram uit de meter in een topic?

idserda commented 5 years ago

Jep, data op topic ziet er bij mij zo uit:

{
    "CurrentPowerConsumption": 383,
    "CurrentPowerProduction": 0,
    "powerConsumptionHighTariff": 6073483,
    "powerConsumptionLowTariff": 5160270,
    "powerProductionHighTariff": 0,
    "powerProductionLowTariff": 0
}
dennissiemensma commented 5 years ago

Is dat een standaard-formaat/plugin of zelf samengesteld?

idserda commented 5 years ago

Ik heb code in deze repo gebruikt: https://github.com/neographikal/P1-Meter-ESP8266-MQTT

dennissiemensma commented 5 years ago

Ik zal het ticket heropenen voor later. Er moet wel eerst wat meer animo voor zijn en ook duidelijk zijn welke formaten allemaal gehanteerd worden. Uiteindelijk zal er dan 1 gekozen moeten worden en dan doel ik vooral op het formaat van de waardes, want de naamgevingen zijn wel te mappen via een config.

hdoedens commented 5 years ago

Ik gebruik een ander project om te telegrammen op MQTT te plaatsen. Die zien er als volgt uit:

{
    "Time": "2019-10-12T09:58:45",
    "P1GATEWAY": {
        "TS": 1012095935S,
        "T1": 7733.084,
        "T2": 8452.855,
        "T1r": 0.000,
        "T2r": 0.000,
        "TAR": 1,
        "P1": 2.198,
        "Pr": 0.000,
        "GAS": 3235.260
    }
}

Dit komt van dit artikel en deze Tasmota image.. Zoals hierboven is te zien is het JSON bericht niet helemaal valide, er zouden dubbele quotes moeten staan om de waarden, maar ik kan helaas niet bij de sources om het aan te passen.

hdoedens commented 5 years ago

Met de default Tasmota image kan trouwens ook het rauwe telegram op MQTT geplaatst worden. Iedere regel uit het telegram is dan standaard een nieuw bericht op het topic. Zoals hier beschreven.. Met deze oplossing moet het ontcijferen van het telegram in DSRM-Reader gedaan worden, maar dat lijkt me geen probleem.

dennissiemensma commented 5 years ago

Bedankt voor je input. Die JSON is opzich prima qua formaat. Alleen mis ik daarin helaas het tijdstip van de gasstand en mist ook de tijdzone.

Qua rauwe telegrammen heb ik het meeste aan complete telegrammen en het is dan jammer dat die niet beschikbaar is. De regels zijn wel aan elkaar te plakken, maar dat maakt het wat minder triviaal als dat ik had gehoopt.

hdoedens commented 4 years ago

Met een iets andere (bijna default) config in de Tasmota P1 module krijg ik de volgende berichten op MQTT:

{"SerialReceived":"/XMX5LGBBFFB231222256

1-3:0.2.8(42)
0-0:1.0.0(191023212358S)
0-0:96.1.1(4530303034303031363930363534343134)
1-0:1.8.1(007881.115*kWh)
1-0:2.8.1(000000.000*kWh)
1-0:1.8.2(008517.536*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.227*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00015)
0-0:96.7.9(00005)
1-0:99.97.0(5)(0-0:96.7.19)(191001151227S)(0000002058*s)(191001092911S)(0000004972*s)(190929200954S)(0000000475*s)(190929183545S)(000000 ...

{"SerialReceived":"0:32.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(001*A)
1-0:21.7.0(00.227*kW)
1-0:22.7.0(00.000*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303032333430313933343439313135)
0-1:24.2.1(191023210000S)(03247.118*m3)
"}

{"SerialReceived":"!E9E7
"}

Helaas dus 3 MQTT berichten die samen 1 compleet telegram vormen. Ik heb een issue uit staan bij het Tasmota project om dit op te lossen. Dat maakt de implementatie aan de DSMR-Reader kant een stuk makkelijker.

hdoedens commented 4 years ago

hmm... Het voorkomen van het splitsen van het telegram lijkt niet te kunnen met instellingen aan de Tasmota kant. Hoe erg is het dat de telegrammen in drieën worden verstuurd? De drie berichten worden nagenoeg gelijktijdig op het topic geplaatst.

idserda commented 4 years ago

Zo te zien zijn er al diverse implementaties, er lijkt dus niet echt een standaard formaat. Waarom dan als DSMR-reader niet gewoon dat standaard formaat publiceren (alles in 1 telegram) en iedereen die dit wil gebruiken zelf de aanpassingen laten doen?

hdoedens commented 4 years ago

@idserda Ik begrijp niet wat je bedoeld.

Zo te zien zijn er al diverse implementaties, er lijkt dus niet echt een standaard formaat.

Er zijn inderdaad een aantal implementaties voor het versturen van meterstanden naar DSMR. Zowel met EASPEasy als met Tasmota is het mogelijk de meterstanden via een MQTT bericht te versturen. Dat geeft echter 2 nadelen:

Waarom dan als DSMR-reader niet gewoon dat standaard formaat publiceren (alles in 1 telegram)

DSMR-Reader publiceert geen telegrammen. Het formaat voor telegrammen bestaat al en DSMR-Reader kan daar prima mee overweg. Ik kan alleen geen implementatie vinden die de telegrammen in zijn geheel op een MQTT topic kan zetten...

en iedereen die dit wil gebruiken zelf de aanpassingen laten doen?

...als dat wel zou kunnen (via een plugin op een van de bekende platformen) kan DSMR-Reader dat eenvoudig oppikken en omzetten zoals het u ook doet met berichten via serial input of api.

dennissiemensma commented 4 years ago

Bedankt voor jullie input. Het maakt voor mij niet zoveel uit of het ruwe telegrammen of JSON, XML of een ander formaat is. Zolang het maar uniform is en in een enkel bericht.

Want anders moet ik tussen input door staat van inkomende berichten bijhouden, foutafhandeling inbouwen als er delen niet goed binnenkomen (of in verschillende volgorde). Ik wil de MQTT-client/queue zo snel mogelijk houden met zo min mogelijk poespas.

dennissiemensma commented 4 years ago

Ik laat dit voor nu voor wat het is. Ik denk toch dat de huidige input in DSMR-reader afdoende is.

Het project is bedoeld voor directe aansluiting op de slimme meter, met datalogger of op afstand. Dit is zowel via de remote datalogger als de API te realiseren.