dsmrreader
Hoogste piekvermogen per dag/maand verbeteren/uitbreiden
Feature
Follow-up van #1084.
- [ ] Hoogste waarde per dag opslaan
- [ ] Hoogste waarde per dag tonen
- [ ] Hoogste waarde per maand tonen
- [ ] Grafiektype aansluiten op bar/line voorkeur
- [ ] Piekvermogen update ontsluiten via MQTT
- [x] Piekwaarden berekenen op basis van interval (kW / interval seconden x 3600) ipv hard op kwartieren
- [x] https://github.com/dsmrreader/dsmr-reader/issues/1084#issuecomment-1186450564
Aanvulling
Ik heb wel een paar opmerkingen over de eenheden:
De waarde die je berekend is in kW (dus niet in kWh of kW/h). In de screenshot zouden de rode vakjes "kW" moeten worden en de blauwe "kWh/15m".
Berekening nu ook aangpast als het niet exact 15m is.
Het resterende werk zit in de grafieken en dagtotalen, dus dat komt later.
Ik denk dat ik de komende release de fixes + grafiek uitbreng, anders blokkeert het redelijk wat en het is opzich ook niet erg om kleinere updates te doen.
De rest blijft gewoon bij de TODO's van dit issue.
Ik was net even de kwartiervermogens aan het bekijken en merk dat in de grafiek de eenheid nog kw/15m is in plaats van kwh/15m zoals reeds aangepast in de configuratie pagina. Gezien het discrete waarden zijn, lijkt het me het ook intuïtiever om hier standaard een bar-chart van te maken. Thanks voor het mooie werk!
Bedankt voor je aanvulling.
- Qua eenheid weet ik niet precies wat je bedoelt. Het is juist aangepast van
kwh/15mnaarkw/15m. Of lees ik er overheen in de screenshot hierboven? https://github.com/dsmrreader/dsmr-reader/issues/1635#issuecomment-1194613971 - Ik zal de grafiektype later aansluiten op de bar/line voorkeur in de Frontend instellingen
Qua eenheid weet ik niet precies wat je bedoelt. Het is juist aangepast van
kwh/15mnaarkw/15m. Of lees ik er overheen in de screenshot hierboven?
Je hebt gelijk, mijn aanvulling hierop is niet correct. Ik heb de website van de netbeheerder er even bijgenomen en de eenheid zou wel kW moeten zijn ipv kW/15m aangezien het over een vermogen gaat en kW/15m een verbruik aangeeft zoals kWh. Edit: op zich lijkt de titel van de grafiek "Kwartiervermogens" wel duidelijk genoeg om de toevoeging van "/15m" te laten vallen zodat de eenheid correct is.
Ook de eenheid van het verbruik is strikt genomen uitgedrukt in kWh ipv kWh/15m maar ik snap wel hoe de benaming tot stand is gekomen.
Op de site van de netbeheerder worden onder de vraag "Wanneer is het piekvermogen gemeten?", de eenheden duidelijk aangegeven: https://www.fluvius.be/nl/veelgestelde-vragen/mijn-fluvius/verbruik
Bedankt voor je update. Het is mij om het even hoe het heet, alleen blijf ik het niet hernoemen ;-). Wellicht kun je met @VBP8501 afstemmen wat de juiste term is, dan houden die uitkomst aan.
Sorry was even op vakantie :)
kW/15min is fout want dat geeft de versnelling van het vermogen aan :D
kW = kiloJoule/s = gelijkaardig aan km/u kWh = kW * uur = gelijkaardig aan km afgelegde weg kW/tijd = gelijkaardig aan in 10s van 0km/u naar 100km/u
Het is ofwel kW ofwel kWh/15min. Maar in de grafiek zou ik het simpel houden en gewoon spreken van kW
Een deel van de wijzigingen gaat mee met v5.7, de rest weer een bump naar de volgende.
Een andere handige toevoeging lijkt me het beschikbaar maken van deze waarden via MQTT. Ik ben alleen niet zeker in welke vorm dit handig zou zijn. "Huidig kwartiervermogen", "Hoogste kwartiervermogen vandaag"?
Ik denk beide. Uiteindelijk zal het hoogste kwartiervermogen onderdeel worden van de dagtotalen en daarmee ook te ontsluiten via het bestaande MQTT model.
Voor de huidige (na opslag) is uiteindelijk wel iets te maken. Eigenlijk net zoals al gebeurt voor de andere datamodellen. Ik heb het aan de lijst toegevoegd voor toekomstige releases. Alleen weet ik niet perse of het wat toevoegt, omdat je als gebruiker bij een hoog kwartiervermogen eigenlijk al te laat bent. Het is dan meer een constatering dan een waarschuwing, afhankelijk van of het volgende kwartier nog hoger wordt. Valt nog wel over te brainstormen, maar ik zet het sowieso onderaan de lijst.
De voornaamste use case lijkt me deze data te gebruiken als waarschuwing wanneer je in de huidige periode boven een vooraf ingestelde waarde gaat. Met een eigen script zou je dan een grote verbruiker kunnen uitschakelen om toch nog onder je limiet te blijven.
Bedankt voor jullie werk hieraan! Het is sowieso een meerwaarde via MQTT de data binnen te krijgen. Vanaf januari beginnen ze ermee hier in België met hun kwartierpiekbeleid helaas, de originele planning was afgelopen zomer, dus ik was in januari al bezig iets in Home Assistant te proberen opzetten om er ons bewuster van te maken.
Ik beschrijf even hoe ik momenteel dergelijke data gebruik: Momenteel hou ik in Home Assistant de hoogste piek bij per maand bij en calculeer zo mijn gemiddelde (met een minimum van 2,5kW). Zo probeer ik mijn gemiddelde zo laag mogelijk te houden op jaarbasis, maar weet ik ook dat ik er minder naar moet kijken als ik al een piek van bvb 4kW gehad heb in de maand (gezien enkel het hoogste kwartier telt).
Ik heb 2 items op men dashboard staan, een live tracker van het huidige kwartier:
En een tabel met alle pieken tot nu in het afgelopen jaar:
Bij een piek over 2,3kW krijgen we al een waarschuwing op Telegram (dan valt er misschien nog iets aan te doen, meestal niet). Aan het eind van het kwartier slaat hij deze waarde op voor deze maand. We krijgen dan geen waarschuwing meer zolang we onder die waarde blijven (want het hoogste kwartier telt voor een maand). Is de waarde toch eens hoger, dan krijgen we terug een waarschuwing en zal hij die maand overschrijven met een hogere waarde. Op die manier weten we ongeveer welke toestel combo's niet goed zijn voor een piek bvb.
Maar mijn huidige implementatie is geprul en buggy (overschrijft soms toch lagere waarde in de maand bvb, die trek ik dan achteraf met de cijfers van Fluvius recht). Via DSMR zou het betrouwbaarder zijn en de implementatie vereenvoudigen.
(moest deze info het topic vervuilen, geef gerust een seintje dan delete ik het weer).
Bedankt voor je aanvulling. Uiteindelijk zal elke kwartierpiek via MQTT ontsloten worden, alleen heb je er vermoedelijk weinig aan omdat het dan al "te laat" is. Plus dat het niet 100% nauwkeurig is, maar hooguit een benadering van wat de netbeheerder doet/berekent.
Je kunt nog overwegen om zelf elke 5 minuten een delta te trekken van de meterstanden via MQTT en daar een 5-minuten piek of iets voor te berekenen. In principe is een hoge piek daar een voorbode voor een mogelijk aanstaande hoge kwartierpiek, maar heb je nog tijd om het wellicht omlaag te drukken voordat het kwartier afgelopen is.
Voor de volgende v5.9 release neem ik weer een (klein deel) mee. Al klaar:
- Uitbreiding REST API voor het opvragen van de "quarter-hour peak electricity consumption" data.
Nog te doen:
- Uitbreiding MQTT voor het doorsturen van diezelfde "quarter-hour peak electricity consumption" data in JSON-formaat en split-topic.
Alle andere zaken zijn naar verwachting veel meer werk omdat die ook de bestaande datastructuren, MQTT en tests raken.
Het MQTT-gedeelte is nu ook klaar. Werkt volgens dezelfde structuur als de andere entiteiten die via MQTT ontsloten worden:
Het is dus de starttijd, eindtijd en het berekende vermogen, zoals ook terug te vinden is in de admin data en grafieken.
Ik zie nog wel een potentieel issue met afronding, 0.1695067264573991074882997054 in mijn live voorbeeld, dus ik check even of ik die gewoon kan afronden/ophalen van database.
Het moment van verwerken in MQTT is namelijk na opslaan in de database, maar het is blijkbaar nog de rauwe in-memory waarde.
Fix gemaakt. Ik zal het allemaal even schaduwdraaien, samen met de rest van de komende v5.9-release. Als er verder geen issues uit komen dan hoop ik het donderdag- of vrijdagavond te releasen als onderdeel van v5.9.
De resterende TODO's in het lijstje bovenaan schuiven weer door.
Bedankt voor je aanvulling. Uiteindelijk zal elke kwartierpiek via MQTT ontsloten worden, alleen heb je er vermoedelijk weinig aan omdat het dan al "te laat" is. Plus dat het niet 100% nauwkeurig is, maar hooguit een benadering van wat de netbeheerder doet/berekent.
Je kan 11 maanden bijsturen na een piek, dus het heeft zeker nut, vandaar dat ik ze per maand bij hou en het gemiddelde :) . En van de netbeheerder krijg je ze maar na het eind van de maand in de portal, dus dat heeft tijdens de maand geen nut.
Bedankt voor de moeite en de mooie release die er aan komt!
@Tommatheussen @Glodenox @VBP8501 dank voor de aanvulling. Ik heb het even verplaatst naar #1764.
Het heeft wel deels te maken met het huidige topic, maar het heeft dusdanig impact dat ik het even los trek. Ook voor het overzicht.
Het huidige issue gaat qua resterende TODO's even ON HOLD. Totdat er een plan in #1764 is.