API mogelijkheid voor ophalen 'dashboard' waarden

[pyrocumulus]

Ik ben een beetje aan het spelen met de API om te kijken of ik het kan gebruiken om mijn energieverbruik te uploaden naar PVOutput, om zo een totaalbeeld te krijgen. Nu werkt de API maar ik mis wat waarden die ik niet, zonder wat trucs, kan achterhalen vanuit de API.

Wat ik graag zou willen ophalen vanuit de API zijn de waarden die je toont op het Dashboard, te weten:

• Huidig verbruik
• Huidige teruglevering
• Vandaag verbruikt daltarief
• Vandaag verbruikt piektarief
• Vandaag teruggeleverd daltarief
• Vandaag teruggeleverd piektarief
• Vandaag verbruikt gas
• (evt. kosten van vandaag per tarief, maar is minder interessant)

Wat ik nu van plan ben om te doen is (en je moet maar zeggen als je een beter manier weet) het volgende:

1. Nu actuele meting ophalen via /api/v2/datalogger/dsmrreading
2. Op basis daarvan, middels timestamp filtering, de eerste meting van vandaag ophalen

Via deze twee telegrammen kan ik middels het verschil in meterstanden volgens mij uitrekenen wat de 'Vandaag'-waarden zijn en heb ik tevens de actuele status. Maar een API ingang als:

/api/v2/statistics/today

Zou best wel fijn zijn denk ik en het een stukje makkelijker maken :)

[pyrocumulus]

Ik zie nu dat mijn methode nog een extra moeilijkheid heeft, ik moet rekening houden met tijdzones/DST. De volgende request:

http://pi/api/v2/datalogger/dsmrreading?limit=1&timestamp__gte=2017-06-26 00:00:00

Levert namelijk een result met als timestamp:
"timestamp": "2017-06-25T22:00:00Z",
"extra_device_timestamp": "2017-06-25T21:55:03Z",

Niet de eerste meting van de dag dus maar twee uur eerder. Dat is ongetwijfeld de nu huidige afstand tot UTC in onze zomertijd. De tijd verhogen naar 2 uur 's nachts levert dan wel de juiste meting op maar dat moet ik niet vergeten in oktober weer te corrigeren dan :)

[dennissiemensma]

Bedankt voor je verzoek.

• Ik denk dat het zeker wel mogelijk en nuttig is om een endpoint te maken die alles van de huidige dag ophaalt. Het zal overigens wel even duren voordat ik daar aan toekom.

• Wat betreft de tijdzones, dat is een bekende 'bug', en zit helaas in het onderliggende framework. Zie ook dit comment van #230. Het gelinkte ticket daarin is helaas nog niet opgelost in het framework.

[pyrocumulus]

Over punt 1, no problemo. In tussentijd hobby ik zelf lekker met de api.

Verder: ben ik een tijd aan het knoeien met mijn eigen oplossing, herinner ik me ineens dat je die tijdzones een bug noemde. Ik kreeg mijn eigen 'Dashboard'-waarden maar niet gelijk aan die van DSMR maar dat komt dus omdat ik die 2 uur er bij op telde zoals ik zei. Doh. Als ik dat niet doe krijg ik dezelfde waarden als DSMR toont.

Kan ik concluderen dat het verbruik wat DSMR op het Dashboard toont dus ook een beetje teveel is (als je echt strict vandaag wilt weten) omdat er dus één of twee uren (afhankelijk van DST) teveel meegenomen worden? Ik wil het voor m'n upload naar PVOutput wel goed zetten namelijk :)

[dennissiemensma]

Er zijn twee methodes om te voorkomen dat de zomer-/wintertijd in de weg zit:

• Alles omzetten naar UTC (GMT)
• Alle tijden opslaan met de tijdzone van dat moment

Dit project doet het eerste en degene die PostgreSQL gebruiken als opslag, profiteren tevens van het tweede.
Dat is tevens de reden dat ik MySQL niet meer primair ondersteun, ondanks dat MySQL (met wat handwerk) ook soort van ondersteuning voor tijdzones heeft.

Tevens zorgt het onderliggende framework (Django) telkens onderwater voor de omrekening wanneer het nodig is. Voor het dashboard vraag ik expliciet om de lokale tijdzone 'versie' van de laatste meting (om de huidige dag te bepalen).

Voor PVOutput is het overigens nog wel een dingetje. Ik ben al begonnen aan #9, maar ik zie dat de API call geen DST (zomer/wintertijd) parameter heeft. Het opsturen van de data in de Nederlandse tijdzone, gaat dan twee keer per jaar een afwijking vertonen. Ik moet me daar overigens nog verder in verdiepen.

[pyrocumulus]

Bedankt, ik denk dat ik er met die lokale tijdzone code wel uit ga komen als ik verder ga. Wel tof dat je al met #9 bezig bent! Wellicht moet ik eigenlijk ook niet al te moeilijk doen en jouw implementatie gewoon afwachten.

Over PVOutput en tijdzones, dat is wel interessant inderdaad. Mijn inverter pusht automatisch zijn data naar PVOutput, ik vraag me af hoe die dat dan doet. Die koppeling was er al sinds voor de zomertijd en ik heb eerlijk gezegd geen afwijking gezien op de PVOutput website. Misschien gaat PVOutput ervan uit dat de tijd altijd de lokale tijd is van de plaats van de installatie? Dan zou jij namelijk niets bijzonders hoeven te doen. Als ik er achter kom dan koppel ik dat nog wel terug naar je middels #9

edit:
Als ik https://pvoutput.org/help.html#live-settings-timezone lees trouwens, dan is mijn aanname hierboven correct. Je geeft voor je installatie de tijdzone op en zolang het apparaat dat de data pusht zijn tijd zelf goed bijwerkt volgens DST, gaat het goed.

[dennissiemensma]

Bedankt voor je toelichting. In dat geval scheelt dat weer!

Het zal wel even duren voordat de PVOutput integratie klaar is, dus ik raad je vooral aan er zelf ook mee te spelen als je dat leuk vindt. :]

[pyrocumulus]

Ik kan mezelf waarschijnlijk toch niet inhouden ;]

On Thu, 29 Jun 2017, 19:36 Dennis Siemensma, ***@***.***> wrote: Bedankt voor je toelichting. In dat geval scheelt dat weer! Het zal wel even duren voordat de PVOutput integratie klaar is, dus ik raad je vooral aan er zelf ook mee te spelen als je dat leuk vindt. :] — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#337 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpEJvz0T8Voxyd63SXTSzFuwEDqYX42ks5sI-CkgaJpZM4OF3dr> .

-- Sent from Samsung Galaxy.

[dennissiemensma]

Ik heb e.e.a. toegevoegd aan de API, zie de toekomstige docs voor meer informatie: http://dsmr-reader.readthedocs.io/en/development/api.html#get-consumption-today

{
    "day": "2017-09-28",
    "electricity1": 0.716,
    "electricity1_cost": 0.12,
    "electricity1_returned": 0,
    "electricity2": 3.403,
    "electricity2_cost": 0.63,
    "electricity2_returned": 0,
    "gas": 0.253,
    "gas_cost": 0.15,
    "total_cost": 0.9,
}

Het ophalen van het huidige verbruik en teruglevering kan alleen via de al bestaande datalogger/dsmrreading call.