totaalverbruik laat nog per fase verbruik zien, terwijl teruglevering hoger is.

[spiralshapeturtle]

Via mijn zonnepanelen website lees ik de API uit voor gegevens vanuit DSMR reader. Daar gaat nu iets mis, sinds kort. Voorheen kon ik altijd keurig zien wat mijn panelen terugleveren waar dan de verbruikte stroom van het huis (servertjes etc) al afgetrokken was.

Sinds een paar weken blijft de teller, ondanks de zonnepanelen teruggave, toch verbruik tonen over een fase. Zie hieronder het voorbeeld. Voorheen stond hier in het rood 0 en was het getal wat nu in het rood stond waarschijnlijk van het groene getal afgetrokken.

Zou hier eens naar gekeken kunnen worden, ook voor de terug gaven via MQTT naar het nieuwe Home Assistant Energy dashboard zou ik graag een "totaal som" zoals vroeger gebruiken.

Overigens allemaal de laatste versie.

[spiralshapeturtle]

DSMR-READER
    App / Python / Database                                                     v4.16.3 / v3.6.9 / postgresql
    BE sleep / DL sleep / Retention / Override                                     1.0s / 0.5s / 168h / False
    Latest telegram version read / Parser settings                                                 "42" / "4"

DATA
    Telegrams total (est.)                                                                              82006
    Consumption records electricity / gas (est.)                                                79280 / 23630

UNRESOLVED ISSUES
    Database groeit gestaag: 985 MB, overweeg dataopschoning (indien nog niet ingeschakeld)                                      nu

POSTGRESQL SIZE OF LARGEST TABLES (> 500 MB)
    public.dsmr_consumption_electricityconsumption                                                     919 MB

Ook een leuke, de rode banner blijft over de DB size meldingen geven terwijl "opschoning" al geactiveerd is.

[dennissiemensma]

Bedankt voor je melding. Heb je een paar weken terug dan ook de update gedaan of draai je deze versie al langer? En zie je het verbruik ook in de grafieken van de fasen? En heb je ook het inhoudelijke telegram bekeken wat daar in staat?

[dennissiemensma]

Ook een leuke, de rode banner blijft over de DB size meldingen geven terwijl "opschoning" al geactiveerd is.

Als de opschoning pas later is ingeschakeld is hier na een tijd alsnog een eenmalige actie nodig. Namelijk een vacuumdb op de database, die alle ongeschoonde ruimte vrijgeeft en daarmee die melding als het goed is ook oplost.

Afhankelijk van hoelang de opschoning al draait, kun je dit sowieso proberen:

• https://dsmr-reader.readthedocs.io/nl/latest/how-to/database/postgresql-resolve-size-warnings.html

Dit kan even duren, afhankelijk van de hardware en hoeveel die moet opschonen (in jouw geval valt het reuze mee).

[spiralshapeturtle]

Bedankt voor je melding. Heb je een paar weken terug dan ook de update gedaan of draai je deze versie al langer? En zie je het verbruik ook in de grafieken van de fasen? En heb je ook het inhoudelijke telegram bekeken wat daar in staat?

Goede vraag de PV website draait al geruime tijd hetzelfde. DSMR update ik frequently. Stedin geeft geen antwoord of er wijzigingen zijn uitgevoerd. Dan is dit het last resort, en de meest hulpvaardige 👍

Welke IDs zijn relevant uit het datagram?

KFM5KAIFA-METER

1-3:0.2.8(42)

1-0:1.8.1(012188.333*kWh)
1-0:1.8.2(009783.201*kWh)
1-0:2.8.1(001910.294*kWh)
1-0:2.8.2(004527.433*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.118*kW)
1-0:2.7.0(02.745*kW)
0-0:96.7.21(00004)
0-0:96.7.9(00004)
1-0:99.97.0(5)(0-0:96.7.19)(210404115344S)(0000004978*s)(191122084555W)(0000002077*s)(181215181128W)(0000000208*s)(181026100610S)(0000002253*s)(000101000144W)(2147483647*s)
1-0:32.32.0(00000)
1-0:52.32.0(00001)
1-0:72.32.0(00001)
1-0:32.36.0(00001)
1-0:52.36.0(00001)
1-0:72.36.0(00001)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(000*A)
1-0:51.7.0(001*A)
1-0:71.7.0(011*A)
1-0:21.7.0(00.009*kW)
1-0:41.7.0(00.110*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(02.748*kW)
0-1:24.1.0(003)
0-1:96.1.0(KNIP)
0-1:24.2.1(210807130000S)(04163.235*m3)
!A308 

[spiralshapeturtle]

Ook een leuke, de rode banner blijft over de DB size meldingen geven terwijl "opschoning" al geactiveerd is.

Als de opschoning pas later is ingeschakeld is hier na een tijd alsnog een eenmalige actie nodig. Namelijk een vacuumdb op de database, die alle ongeschoonde ruimte vrijgeeft en daarmee die melding als het goed is ook oplost.

Afhankelijk van hoelang de opschoning al draait, kun je dit sowieso proberen:

• https://dsmr-reader.readthedocs.io/nl/latest/how-to/database/postgresql-resolve-size-warnings.html

Dit kan even duren, afhankelijk van de hardware en hoeveel die moet opschonen (in jouw geval valt het reuze mee).

Top, opgelost. Zou misschien goed zijn deze commando’s in de rode banner op te nemen. Of automatiseren. Tnx!

[spiralshapeturtle]

1-0:21.7.0(00.008*kW)
1-0:41.7.0(00.110*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(02.824*kW) 

Found it. Vroeger stond dan “ teruglevering 2706” in de DSMR gui. Kan mij niet voorstellen dat ik de enige ben met deze uitdaging bij Stedin.

[dennissiemensma]

Dit is de moment opname van de meter en staat als het goed is bovenaan je dashboard:

1-0:1.7.0(00.118*kW)
1-0:2.7.0(02.745*kW)

https://github.com/dsmrreader/dsmr-reader/blob/v4/dsmr_parser/obis_references.py#L18-L19

---

Dit is per fase en daar zie je ongeveer hetzelfde bij de grafieken:

1-0:21.7.0(00.009*kW)
1-0:41.7.0(00.110*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(02.748*kW)

https://github.com/dsmrreader/dsmr-reader/blob/v4/dsmr_parser/obis_references.py#L38-L43

DSMR-reader toont wat je meter aangeeft. Als er niet alleen teruglevering is, dan wordt ook verbruik getoond, want dat geeft de meter immers door.
Er staat me wel wat bij dat dat in een oude versie van DSMR-reader niet was, alleen was dat destijds juist de bug die naar voren kwam, omdat ik ooit de aanname deed dat er alleen of-of was met teruglevering. Dat bleek in de praktijk niet te kloppen en is rechtgetrokken. En volgens mij telde DSMR-reader het toen ook niet bij elkaar op.

Ik kan alleen niet meer zo snel vinden in welke versie dat was en welk issue. Ik dacht wel in de 4.x serie.

[dennissiemensma]

Ah het was in v4.14 met nog wat rework daarna: #1324 (comment)

[spiralshapeturtle]

Ah het was in v4.14 met nog wat rework daarna: #1324 (comment)

Ja precies wel recent dus, was dat gevoel toch goed.

Is het mogelijk hier iets nieuws voor te bouwen? Via API(website) en MQTT(homeassistant). Ik zou graag zien wat het totaal doet. Immers SolarEdge update elke 15 minuten en dit was juist zo fijn om de teruglevering te zien op 10sc basis.

[dennissiemensma]

Ik heb nog even nagezocht. In de API van DSMR-reader is als het goed is niets veranderd, puur in het dashboard.

• 290894c#diff-13e07ca1d321a138f09534695563d4bed44724387663f6819b4c3bd5e17b52dbL13

De API geeft (nog steeds) terug hoe de slimme meter het doorgeeft. Als je die zelf verrekend wilt hebben, zul je dat na het ophalen uit de API moeten doen.

[spiralshapeturtle]

@dennissiemensma de website ontwikkelaar heeft de gesuggereerde som ingebouwd, het probleem is opgelost. Blijft voor mij alleen nog steeds het raadsel bestaan: waar is dit nu ontstaan...

[dennissiemensma]

Oke fijn om te horen!

Wellicht zat of zit er wat ruis in de intepretatie van de gegevens. Ik kan er verder ook niets anders van maken als dit is wat de slimme meters teruggeven.

[jvanderzande]

De aanname was dat 1 van de 2 velden een waarde zou bevatten en de ander op 0 zou staan. Misschien is dit nu veranderd, maar de aanpassing was redelijk eenvoudig.

[dennissiemensma]

@jvanderzande bedankt voor de aanvulling! Dat was exact dezelfde aanname die DSMR-reader ook deed, totdat in #1324 gemeld werd dat deze aanname niet klopte (ik heb zelf namelijk geen teruglevering en ben afhankelijk van wat gebruikers aanleveren).

Dat verklaart ook de melding van het huidige issue, waarbij het niet helemaal duidelijk was hoe het zat. Het komt er dan waarschijnlijk op neer dat zowel jij als ik eerder bovenstaande aanname deden. Ik verwacht dat ze nu weer overeen komen.

Let wel dat als je ze met elkaar verrekent, dit goed gaat zolang er gesaldeerd kan worden. Als dat in de toekomst verandert (geen idee wanneer), dan kunnen ze afwijkende tarieven hebben. Voor nu is het dus prima, maar wees daar alert op als die situatie ooit verandert. In bijvoorbeeld Belgie, verandert dat (deels) volgend jaar: #1084

Voor de duidelijkheid, het is (voor zover ik zo kon terugvinden) alleen in de weergave in DSMR-reader veranderd. Ik had gisteren nog even gekeken naar het specifieke endpoint, maar die is al lange tijd niet meer aangepast (qua output). Idem voor de fixtures.

[jvanderzande]

Let wel dat als je ze met elkaar verrekent, dit goed gaat zolang er gesaldeerd kan worden. Als dat in de toekomst verandert (geen idee wanneer), dan kunnen ze afwijkende tarieven hebben. Voor nu is het dus prima, maar wees daar alert op als die situatie ooit verandert. In bijvoorbeeld Belgie, verandert dat (deels) volgend jaar: #1084

@dennissiemensma, Helemaal duidelijk en ik ben bekent met de plannen rond de salderingsregeling in Nederland na 2023. In de zonnepanelen website, waar @rodeho het probleem had, wordt deze waarde alleen maar gebruikt om de huidige totaal waarde van verbruik/terug-leveren te laten zien en is alleen maar een moment opname wat iedere 10 seconden wordt aangepast. Verder doe ik niets met kosten berekeningen en is het puur cosmetisch. :)
Voorbeeld: verbruik:

Leveren:

Ik gebruik zelf geen DSMR en haal de P1 Data uit Domoticz, dus heb geen idee hoe lang dit al een "probleem" was voor DSMR data.