dsmrreader
Piekvermogen uit telegram halen
Gemaakt vanuit #1635
@Tommatheussen:
Ik zit in een Facebook groep waar mensen nu updates hebben doorgekregen aan hun DSMR meter, waarbij sommige waarden ivm het piekvermogen kunnen uitgelezen (ipv berekend) worden.
Indien er besloten wordt om deze waarden in te bouwen in DSMR reader, zou ik toch willen vragen om een fallback te doen op de berekende waarde, aangezien sommige meters geen updates krijgen. Zoals mijn DSMR meter, die kan geen verbinding maken met buitenaf, ik sta dus nog een aantal firmware versies achter...
@Glodenox :
Ik zie inderdaad deze nieuwe waarden nu al, als ik de raw telegram data bekijk (de pijltjes zijn zelf toegevoegd):
/FLU5\253769484_A 0-0:96.1.4(50217) 0-0:96.1.1(3153414733313030303338343634) 0-0:1.0.0(221207100448W) 1-0:1.8.1(014926.618*kWh) 1-0:1.8.2(017371.859*kWh) 1-0:2.8.1(003824.090*kWh) 1-0:2.8.2(001503.592*kWh) 0-0:96.14.0(0001) -> 1-0:1.4.0(00.644*kW) -> 1-0:1.6.0(221206221500W)(07.950*kW) -> 0-0:98.1.0(0)(1-0:1.6.0)(1-0:1.6.0)() 1-0:1.7.0(01.848*kW) 1-0:2.7.0(00.000*kW) 1-0:21.7.0(00.198*kW) 1-0:41.7.0(00.263*kW) 1-0:61.7.0(01.386*kW) 1-0:22.7.0(00.000*kW) 1-0:42.7.0(00.000*kW) 1-0:62.7.0(00.000*kW) 1-0:32.7.0(236.8*V) 1-0:52.7.0(235.5*V) 1-0:72.7.0(232.0*V) 1-0:31.7.0(001.21*A) 1-0:51.7.0(001.59*A) 1-0:71.7.0(006.42*A) 0-0:96.3.10(1) 0-0:17.0.0(999.9*kW) 1-0:31.4.0(999*A) 0-0:96.13.0() !B4B3Aangezien ik de PDF niet kon downloaden van die locatie, heb ik het elders gevonden en als attachment hier toegevoegd: e-MUCS_P1_Ed_1_7_1.pdf
Persoonlijk heb ik in elk geval liever de officiële waarden die de meter aangeeft. Een fallback voor zij op een lagere versie zou inderdaad mooi zijn, aangezien de logica nu toch al bestaat.
Opzich heel mooi dat ze het aan het telegram toegevoegd hebben. Sterker nog, dat is uiteindelijk wel het makkelijkste.
Alleen dit heeft dusdanige gevolgen dat ik even goed moet nadenken wat de eindsituatie is. Het hangt er ook erg vanaf of dit beschikbaar komt voor alle huishoudens die te maken hebben met de piekvermogens van de VREG. Want als dat het geval is, dan neig ik er naar om eigenlijk de complete "handmatig" ontwikkelde opzet te verwijderen bij een toekomstige major release. Ook omdat dit project zoveel mogelijk kijkt naar de slimme meter.
Sterker nog, het feit dat dezelfde gegevens te zien zijn als waar de VREG mee rekent, is nog een extra argument om mijn eigen spiegeling er uiteindelijk weer uit te halen. En omdat het vermoedelijk een onderdeel wordt van de telegramdata die DSMR-reader al kan ontsluiten via MQTT en de API, via nieuwe velden daarbinnen, scheelt het ook weer wat topics (die ik helaas net vorige week heb toegevoegd).
Ik voel er namelijk niets voor om twee mechanismes te ondersteunen. Het gaat of het ene worden of het andere. En DSMR-reader is eenmaal een DSMR reader, dus alles uit de meter heeft de voorkeur.
Overigens heeft dit ook gevolgen voor de parsing zelf. Want dsmr_parser, wat gebruikt wordt in bijv. HA maar ook als kopie binnen DSMR-reader, moet hier ook mee uitgebreid worden.
En het gaat ook nog gevolgen hebben voor #1635, qua openstaande punten. Want eigenlijk is alle tijd die ik besteed aan deze TODO's daar zonde:
- Hoogste waarde per dag opslaan
- Hoogste waarde per dag tonen
- Hoogste waarde per maand tonen
Want als het uit het telegram gaat komen, dan ga ik er sowieso een andere opslag intern voor gebruiken. Plus dat ik nog moet nadenken over welke waarden ik waar opsla (of alleen ontsluit).
Overigens heeft dit ook gevolgen voor de parsing zelf. Want
dsmr_parser, wat gebruikt wordt in bijv. HA maar ook als kopie binnen DSMR-reader, moet hier ook mee uitgebreid worden.
Voor de dsmr integratie gaat dit inderdaad nodig zijn. In de dsmr_reader integratie (die via MQTT de berichten van DSMR Reader ontvangt) wordt dit niet gebruikt en zal ik gewoon de nieuwe topics kunnen toevoegen. Daar verwacht ik weinig tot geen problemen mee.
Eigenlijk is het wat zonde dat er blijkbaar niemand (ik inclusief) aan gedacht had om eens te gaan horen of er sprake was om deze info via P1 te verdelen. Dat had veel moeite en discussie kunnen besparen. Maar dat is achteraf uiteraard altijd makkelijk gezegd.
Eigenlijk is het wat zonde dat er blijkbaar niemand (ik inclusief) aan gedacht had om eens te gaan horen of er sprake was om deze info via P1 te verdelen. Dat had veel moeite en discussie kunnen besparen. Maar dat is achteraf uiteraard altijd makkelijk gezegd.
Volledig akkoord.. ik had daar achter moeten vragen toen ik de vreg om verduidelijking vroeg..
Ik denk dat het verder ook niet zo 1-2-3 te verwachten was dat zoiets ingebouwd zou worden door de beheerder.
Verder denk ik, praktisch gezien, dat de huidige implementatie in DSMR-reader voor de komende tijd afdoende is. Helemaal gezien de deadline van 1 januari is het mooi dat er in ieder geval "iets" te zien is voor huishoudens die voor het piekvermogen gaan betalen.
Dan kan ik kijken of ik de komende maanden de nieuwe telegram data kan ontsluiten.
In DSMR-parser zit nu ondersteuning in die ik tzt kan spiegelen.
- https://github.com/ndokter/dsmr_parser/pull/113
- https://github.com/ndokter/dsmr_parser/pull/113/commits/d05fe2692bce9da5bca4103008a6327b4901106a
Zou het mogelijk zijn om in een volgende release al enkel de parser toe te voegen? Dan zouden we via de dsmrreader api toch al de nieuwe data kunnen uitlezen, alvast bedankt.
Bedankt voor je aanvulling. Ik zal het voor de release na de aanstaande zetten. Het is namelijk wel wat meer dan alleen de parser toevoegen, gezien het ook de API, MQTT en opslag raakt.
De parser in DSMR-reader is al wel bijgewerkt, maar de update maakt iets anders stuk.
Bij latere implementaties hier naar kijken: https://github.com/dsmrreader/dsmr-reader/issues/1799#issuecomment-1412713067
Ook gemeld via https://github.com/dsmrreader/dsmr-reader/issues/1807#issue-1573390174
Zeer benieuwd of dit ooit in een eerdere tussenrelease komt. Echter las ik dat dit voor september zou zijn? Dit zou bij mij ook via Home Assistant kunnen, maar heb graag alles geclubbed binnen DSMR.
Zeer benieuwd of dit ooit in een eerdere tussenrelease komt. Echter las ik dat dit voor september zou zijn?
@Milithor en september is ook nog maar een planning. Oorspronkelijk wilde ik hier in het voorjaar mee bezig, maar sinds december spelen er wat kleine data-bugs in DSMR-reader waardoor de afgeleide gegevens aan het begin en eind van de dag soms afwijken. Dat fixen heeft de hoogste prio. De metingen in DSMR-reader kloppen dus wel, maar de berekeningen daarna zijn niet sluitend. Om dat structureel en eens en voor altijd te fixen, vereist een ingrijpende refactoring van DSMR-reader. Het hangt vooral op tijd, omdat ik hier een paar avonden achter elkaar mee bezig moet (anders had ik het tussendoor gefixt).
Het huidige #1764 issue zal daarom meegaan met de volgende major release (6.x) die incompatible is met 5.x. Ik gooi dan tevens de huidige (handmatige) implementatie van het piekvermogen er dan ook uit om die te vervangen door de info uit de telegrammen.
@wardbeyens normaal gesproken pak ik vooral in de wintermaanden hier veel meer tijd voor, maar ik ben helaas erg druk, dus ik kan geen indicatie geven. Ook omdat een andere bug-issue nog voorrang heeft qua volgorde.
Hoi @dennissiemensma ,
Ik wil dit topic even vriendelijk onder de aandacht brengen. We kijken er nog steeds erg naar uit.
Mocht er iets zijn waar wij kunnen meehelpen dan doen we dat heel graag.
Alvast heel erg bedankt voor al je inzet en tijd!