Dsmr-reader: Support for exporting data via API

[dajappie]

Hi Dennis,

Recent hebben we hier een slimme meter en een Nest v3, en de meter lees ik naar grote tevredenheid uit met de DSMR-reader via m'n RPi. Top! Nu heeft de Nest een relatief eenvoudige API om binnentemperatuur e.d. uit te lezen. De API loopt via de Firebase-client waarvoor ook een standaard Python versie is. Evt. kan zelfs via eenvoudige HTTP POST data als JSON worden opgehaald als de API niet mogelijk is. Nu gaat dit qua opzet wat verder dan alleen het doel van DSMR uitlezen natuurlijk, maar het lijkt me een mooie toevoeging om m.n. gerelateerd aan het gasverbruik en de buitentemperatuur de huidige en ingestelde binnentemperatuur, de CV aan/uit en huidige luchtvochtigheid te kunnen uitlezen in een paar extra grafieken. Helaas ben ik zelf niet thuis in Python anders zou ik zelf een proof of concept doen.... Zou voor mij een mooie feature zijn!

Gr Jasper

[dennissiemensma]

Bedankt voor je verzoek en goed om te horen dat je zo tevreden bent!

Wat betreft een koppeling met Nest, ik begrijp de toepassing en opzich snap ik ook wel het nut ervan. Alleen beperkt dit project zich, sowieso de komende tijd, op alleen het uitlezen van de slimme meter en de gegevens daaruit.
Achteraf gezien had ik de huidige temperatuurmetingen (via Buienradar) er ook niet in moeten bouwen. Ze geven immers een te beperkt beeld.
Ik kan je wel aanraden om bijvoorbeeld de koppeling met MinderGas te gebruiken, omdat zij goede ondersteuning voor graaddagen lijken te hebben.

Zie ook soortgelijke tickets zoals #145. De DSMR-gegevens exporteren naar een andere dienst is een ander verhaal, mocht je daar ook mee geholpen zijn.

[dajappie]

Logisch, pakket moet doen waar het voor gemaakt is. Home Assist en Domoticz kunnen evt. ook maar zijn behoorlijk zwaar/overkill voor alleen monitoring/enkele grafieken. Denk dat ik dan misschien via een nog te maken export de DSMR-gegevens exporteer naar bv. een InfluxDB en dan met Grafana de gecombineerde grafieken in elkaar ga zetten. Misschien dat een export-API daarvoor dan wel handig is om van een periode alle telegrammen uit te kunnen lezen.

[dennissiemensma]

Wellicht ben je dan nu nog het meeste geholpen met een combinatie van dit API-push-script en (bijvoorbeeld) ndokter/dsmr_parser.
Je zou dan de ruwe telegrammen kunnen doorpushen naar dsmr-reader en daarnaast, in dat script, zelf nog die andere parser gebruiken. Vervolgens kun je dan ook de gegevens uit de parser pushen naar bijvoorbeeld InfluxDB.

Een export-API is zeker mogelijk en lijkt me ook wel iets voor een latere release.

[dajappie]

Cool! Overigens kan Grafana ook dashboards samenstellen uit diverse bronnen, naast InfluxDB ook vanuit Postgres. Als ik vanuit de DSMRreader database de ruwe meterstanden lees (dsmr_consumption_electricityconsumption/dsmr_consumption_gasconsumption) en separaat de Nest-data schrijf naar een InfluxDB (of ook Postgres, maar andere db dan dsmr) dan zijn we er al. Is ook geen export-API nodig want anders blijf je data dupliceren.

[dajappie]

Hi Dennis, heb nog even wat verder zitten kijken, maar Grafana ondersteunt geen Postgres alleen als config-opslag. Als je toch de export mogelijk gaat heroverwegen dan is misschien een generieke export van data naar bv. StatsD een optie. Als je na het parsen van het P1-telegram en/of op het moment van een db-insert van de gecalculeerde gas/elektra de waardes naar StatsD kan sturen, kan je vanuit StatsD met alle z'n eigen exports zelf bepalen wat er verder mee gebeurt (bv. Telegraf --> InfluxDB --> Grafana). StatsD is ook lekker licht en eenvoudig aan te roepen op een UDP-poortje. Het voordeel van een export van bv. een telegram vanuit DSMRreader is dat er maar 1 lock op serial device /dev/ttyUSB0 kan zijn, dus meerdere loggers/parsers naast elkaar kan al niet. En DSMRreader heeft al een goede parser in huis, en aggregeert ook al wat van de ruwe data. Just my 2 cents.

[dennissiemensma]

Ik begrijp dat het makkelijk is om support voor een specifieke tool te krijgen, alleen probeer ik juist een zo generiek mogelijke groep te ondersteunen.

Je zult daarom het uitlezen van je meter en de parser van dit project los moeten zien. Juist met de eerder aangegeven tip trek je dat los en heb je ook geen last van de serial locking. Het mooie aan de parser van ndokter is ook dat je zelf bepaalt welke velden je nodig hebt.

Vandaar dat ik denk dat je eerlijk gezegd het meeste geholpen bent met het apart uitlezen van de kabel en vervolgens die data zowel naar dsmrreader stuurt als door de parser van ndokter, zodat je die vervolgens naar elke backend kan duwen die je maar wil.

[dajappie]

Bedankt voor alle input. Heb inmiddels de datalogger vervangen door je example clientscript met de API-call, nog beetje aanpassen met de code van Nigel Dokter voor het parsen. Voor zover ok. Echter de CPU-load is enorm omhoog geschoten op het dsmr_datalogger proces. De supervisor-logs van dsmr_datalogger worden nu niet meer gevuld met de ruwe telegram data, maar met "Starting INFINITE command loop...". Kan het datalogger proces volledig uit nadat deze vervangen is door een remote datalogger? Zoja, in de supervisor configuratie kan ik deze niet vinden.

[dennissiemensma]

Ja dat proces kan uit als je zeker weet dat datalogging via de API goed werkt. Je kunt hem in de eerste instantie uitzetten in Supervisor met:

• sudo supervisorctl
  Als het goed is zie je ergens dsmr_datalogger met RUNNING
• stop dsmr_datalogger
• Wanneer je hierna nog steeds telegrammen ziet binnenkomen in de applicatie, werkt het naar behoren.

Vermoedelijk komt de hoge load doordat ze constant lopen te concurreren met elkaar om de seriale poort.

Als je de datalogger permanent uit Supervisor wil halen (hij blijft starten na een rPi restart), dan moet je hem uit de config halen. Die ziet er zo uit en staat in /etc/supervisor/conf.d/dsmr-reader.conf. Je kunt daar regel 1 tot en met 18 weghalen of uitcommenten.

Vervolgens doe je: sudo supervisorctl reread en sudo supervisorctl update. Als je dan sudo supervisorctl status doet zou je hem niet meer moeten zien.

[dajappie]

Opgelost, zoals verwacht idd de datalogger. Had in de DSMRreader config de P1 check al uitgezet, maar die zet niet zoals ik dacht de datalogger uit. Misschien ideetje om die paar regels voor het handmatig uitzetten nog in de documentatie op te nemen? Enorm bedankt voor de hulp!

[dennissiemensma]

Goed om te horen, ik ga nog wat instellingen documenteren in #232, dus wellicht dat ik daar nog iets over neerzet.

[FutureCow]

Ik dacht toen ik API zag staan in de documentatie, dat dit al ging om gegevens te exporteren. Helaas kan de API alleen gebruikt worden om gegevens te importeren. Dus ook hier behoefte aan het exporteren van de gegevens.

Wellicht gewoon een simpel xml met:
<consumption>
<electricity>
<electricity_delivered_1>153.90</electricity_delivered_1>
<electricity_delivered_2>138.70</electricity_delivered_2>
<electricity_delivered_today_1>4.90</electricity_delivered_today_1>
<electricity_delivered_today_2>1.70</electricity_delivered_today_2>
<electricity_currently_delivered>0.789</electricity_currently_delivered>
</electricity>
<gas>
<gas_delivered>53.78</gas_delivered>
<gas_delivered_today>1.79</gas_delivered_today>
<gas_currently_delivered>0.023</gas_currently_delivered>
</gas>
</consumption>
<returned>
<electricity_returned_1>23.90</electricity_returned_1>
<electricity_returned_2>4.70</electricity_returned_2>
<electricity_returned_today_1>0.90</electricity_returned_today_1>
<electricity_returned_today_2>0.00</electricity_returned_today_2>
<electricity_currently_returned>0.245</electricity_currently_returned>
</returned>

Dit lijkte natuurlijk al veel op http://ip/admin/dsmr_datalogger/dsmrreading/

[Jeltel]

Ik ben ook geïnteresseerd in het ophalen van data via een API. Dat mag een eenvoudige api zijn die via xml output levert.
Zoiets als hierboven, maar dan voor een te kiezen tijdstip.
Een beetje zoals via de admin console kan. maar daar kun je ze alleen inzien en verwijderen. En ook alleen per 10seconden.
Ik stel me zo voor dat je kunt kiezen uit 15 minuten, uur en dag ofzo.

Zie ook de api's van de professionele ODA's.
https://www.ealyze.nl/api/

[jwveldhuis]

Same here, ik gebruik OpenHAB als domotica systeem en zou graag daar in die interface wat statistieken willen tonen, zoals actueel gebruik en dagtotalen voor gas en elektriciteit. Een simpele GET REST XML/JSON API is wat mij betreft OK.

[dennissiemensma]

Bedankt voor alle suggesties. Ik zal in dat geval in een release zorgen voor (JSON) API functionaliteit. Dat is waarschijnlijk niet de aankomende (1.6) maar de release erna.

[pyrocumulus]

Hierbij ook de vraag naar een JSON API voor gegevensexport. Ik begrijp je terughoudendheid wel met het inbouwen van allerlei koppelingen die niet noodzakelijk met de slimme meter zelf te maken hebben. DSMR is juist zo fijn omdat het zich focust op uitsluitend de slimme meter.

Een export API samen met de in #9 genoemde koppeling met PVOutput zou voor mij genoeg analysemogelijkheden bieden. PVOutput voor een goed beeld van mijn zonnepanelen en verbruik, net zoals Mindergas werkt voor een goede analyse met graaddagen.

Ga zo door :+1:

[dennissiemensma]

Bedankt voor je input. Uiteindelijk komt er zeer waarschijnlijk toch een API voor het exporteren van de data. En mogelijk ondersteuning voor MQTT.

[ThinkPadNL]

+1 voor een API om gegevens uit dsmr-reader te halen. Ik zou in m'n domoticapakket graag wat zaken zoals actuele verbruik (Watt) en huidige dagtotalen (kWh / m3) willen tonen. MQTT zou daar wellicht een goede mogelijkheid voor zijn idd.

[dennissiemensma]

Bedankt voor je input. Inmiddels heb ik al een groot deel van de API klaar. Ik zal sowieso een endpoint maken die van elk type (bijvoorbeeld meting, dagtotalen) de laatste teruggeeft, zodat die makkelijk op te vragen is.
Momenteel hangt dit verhaal op de documentatie voor de API. Ik had gehoopt om die automatisch te kunnen laten genereren, maar dat valt momenteel helaas wat tegen.

[dennissiemensma]

Ik heb inmiddels een POC werkend voor de nieuwe API om gegevens er uit te halen en metingen aan te maken zonder telegram. Er zijn nog wel wat issues die opgelost moeten worden en waar nog werk inzit:

• Voor velden met een datetime geeft het API-framework dat ik gebruik (Django REST Framework), standaard tijden terug in UTC. Er wordt aangewerkt, maar is nu nog geen oplossing voor.

• Het automatisch genereren van API documentatie lukt niet met de juiste authenticatie (ik wil dezelfde behouden als de v1 API, om verwarring te voorkomen). Dus die mag ik zelf schrijven.

• Tests schrijven (zoals ik al doe voor de meeste code), zodat ik kan garanderen dat het blijft werken bij toekomstige wijzigingen.

Zoals het er nu uitziet komen er deze calls in de eerste instantie beschikbaar:

• POST /api/v2/datalogger/dsmrreading - Aanmaken meting zonder telegram (alleen de datavelden).
• GET /api/v2/datalogger/dsmrreading - Ophalen/zoeken naar metingen.
• GET /api/v2/consumption/electricity - Ophalen/zoeken naar electriciteitsverbruik (= afsplitsing van oorspronkelijke meting), zoals op Dashboard getoond.
• GET /api/v2/consumption/gas - Ophalen/zoeken naar gasverbruk (= afsplitsing van oorspronkelijke meting), zoals op Dashboard getoond.
• GET /api/v2/statistics/day - Ophalen/zoeken naar geaggregeerde daggegevens, zoals bijvoorbeeld in archief getoond (datumselectie).
• GET /api/v2/statistics/hour - Ophalen/zoeken naar geaggregeerde uurgegevens, zoals bijvoorbeeld in archief getoond (detailgegevens per uur bij datumselectie).

Alle GET calls zijn doorzoekbaar op hun primaire tijdveld, bijvoorbeeld het moment van de meting of de dag van dagstatistieken. Daarnaast is het aantal resultaten (limiet) en sortering aan te geven. Het API framework geeft zelf al per response aan hoeveel resultaten er zijn (ongeacht wat je limiet is) en eventuele follow-up calls. Het is daardoor mogelijk om door de resultaten heen te itereren, via een offset parameter.

Hieronder wat voorbeelden voor een indruk. LET OP dat de uiteindelijke release en documentatie leidend is, al verwacht ik verder geen grote wijzigingen in onderstaande structuur:

Ophalen van dagtotalen voor 1 specifieke dag (nieuwjaar hier):
GET /api/v2/statistics/day?day=2017-01-01

{   'count': 1,
    'next': None,
    'previous': None,
    'results': [   {   'average_temperature': '1.2',
                       'day': '2017-01-01',
                       'electricity1': '6.843',
                       'electricity1_cost': '1.22',
                       'electricity1_returned': '0.000',
                       'electricity2': '0.000',
                       'electricity2_cost': '0.00',
                       'electricity2_returned': '0.000',
                       'gas': '5.729',
                       'gas_cost': '3.45',
                       'highest_temperature': '2.6',
                       'id': 654,
                       'lowest_temperature': '0.1',
                       'total_cost': '4.67'}]}

Ophalen van de meeste recente metingen, dus simpelweg omgekeerd sorteren op tijdstip en limiteren op klein aantal (hier twee voor de leesbaarheid):

GET /api/v2/datalogger/dsmrreading?ordering=-timestamp&limit=2

{   'count': 4188117,
    'next': 'http://*******/api/v2/datalogger/dsmrreading?limit=2&offset=2&ordering=-timestamp',
    'previous': None,
    'results': [   {   'electricity_currently_delivered': '0.059',
                       'electricity_currently_returned': '0.000',
                       'electricity_delivered_1': '1811.669',
                       'electricity_delivered_2': '1696.969',
                       'electricity_returned_1': '0.000',
                       'electricity_returned_2': '0.000',
                       'extra_device_delivered': '1960.880',
                       'extra_device_timestamp': '2017-04-11T03:00:00Z',
                       'id': 4188179,
                       'phase_currently_delivered_l1': '0.022',
                       'phase_currently_delivered_l2': '0.036',
                       'phase_currently_delivered_l3': '0.000',
                       'timestamp': '2017-04-11T03:59:32Z'},
                   {   'electricity_currently_delivered': '0.134',
                       'electricity_currently_returned': '0.000',
                       'electricity_delivered_1': '1811.669',
                       'electricity_delivered_2': '1696.969',
                       'electricity_returned_1': '0.000',
                       'electricity_returned_2': '0.000',
                       'extra_device_delivered': '1960.880',
                       'extra_device_timestamp': '2017-04-11T03:00:00Z',
                       'id': 4188178,
                       'phase_currently_delivered_l1': '0.098',
                       'phase_currently_delivered_l2': '0.035',
                       'phase_currently_delivered_l3': '0.000',
                       'timestamp': '2017-04-11T03:59:22Z'}]}

En hierbij zijn alle tijden dus in UTC (Z+00), waar ik dit uiteindelijk graag in onze eigen tijdzone wil laten tonen, net zoals de applicatie nu al doet in de interface. Waarschijnlijk ga ik niet wachten totdat/of dit opgelost wordt. Op het moment dat ik de rest klaar heb, maak ik de beslissing.

Dus in het kort, ik ben er nog steeds actief mee bezig, maar achteraf gezien kost het mij veel meer tijd dan verwacht.

[dennissiemensma]

Ik ben eindelijk klaar! Zojuist is ook de laatste documentatie bijgewerkt en vertaald (op dev-versie docs).

De API is momenteel alleen nog beschikbaar in de toekomstige-release-branch. Komende dagen ga ik nog wat dingen uitproberen en nalopen, maar daarna kan ik het eindelijk releasen.

[jwveldhuis]

Wow! Heb enkel je documentatie bekeken, maar wat een werk moet dat zijn geweest. Erg grondig aangepakt!
Ik wacht even op de officiële release voordat ik het op mn domoticasysteem ga aansluiten.

[dennissiemensma]

Bedankt voor jullie geduld, eindelijk is het zover, v1.7 is uit met de API. Neem wel de release notes in acht.

Vermoedelijk komen er nog wel kleine dingetjes of wensen voor eventuele uitbreiding voort uit deze release. Ik zie die graag tegemoet via een nieuw ticket. Mogelijk bundel ik die dan later weer met andere wensen voor de API. Hetzelfde geldt wanneer de voorbeelden uit de documentatie niet afdoende zijn, ik hoor het graag. :]

[mkruiver]

Gaaf, bedankt! Ik kan niet wachten op de PVO koppeling ;)

[pyrocumulus]

Heel vet. Zodra ik hobby tijd vind, ga ik met de API aan de slag. Bedankt!

On Fri, 5 May 2017, 17:39 mkruiver, [e-mail] wrote:

Gaaf, bedankt! Ik kan niet wachten op de PVO koppeling ;)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dennissiemensma/dsmr-reader/issues/230#issuecomment-299499023,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpEJgj9D2__fvTicJCbMvk0qSBDvd1jks5r20KcgaJpZM4Lhpys
.

>

Sent from Samsung Galaxy.

[dennissiemensma]

Het lijkt erop dat het onderliggende API-framework eindelijk dit issue heeft opgelost.

Wanneer ik een nieuwe versie van dat framework probeer, falen mijn tests. Er komt nu eindelijk gelokaliseerde tijd mee:

AssertionError: '2017-01-01T01:00:00+01:00' != '2017-01-01T00:00:00Z

Ik controleer of alles klopt en dan neem ik het mee in de volgende v1.9 release.