Closed niekniek89 closed 1 year ago
dennissiemensma
commented
1 year ago Bedankt voor je melding. Je kunt het beste een telegram delen uit: https://dsmr-reader.readthedocs.io/en/v5/explained/about.html#support
In principe is het mogelijk om tegelijkertijd teruglevering en verbruik te hebben, al is dat doorgaans in combinatie met een 3-fasen aansluiting (teruglevering op 1 fase).
Eerder liet DSMR-reader altijd maar 1 zien, maar sinds een paar jaren kan het ook beiden zijn:
niekniek89
commented
1 year ago Goedemorgen,
Ik begrijp inderdaad (en had ook andere topics gelezen op deze GitHub), dat andere dit ook hebben. Echter, ik draai al ruim 3 a 4 jaar DSMR, en voorheen werd dit altijd netjes "verrekend". Zou de energieleverancier (geen idee of dat dat mogelijk is) iets met de meter gedaan hebben (update oid)?
Sinds eind vorige week, lijkt deze niet meer "intern of voor de meter" te salderen. als ik (als voorbeeld) meer terug lever dan verbruik, stond deze normaliter op 0 verbruik. Als ik nu veel verbruik en veel terug lever, lijkt ie dat niet te verrekenen (voor de meter).
Echter blijf ik sinds vorige week altijd een verbruik hebben (dus neem soms meer stroom af, terwijl ik voldoende terug lever om het verbruik te minderen.
Ik zie ook enkele voorbeelden, waar men hetzelfde heeft/had, waarbij de meter uiteindelijk vervangen is:
https://gathering.tweakers.net/forum/list_messages/2126210/0
Blijf het namelijk "vreemd" vinden, dat ik dit pas heb sinds eind vorige week.
niekniek89
commented
1 year ago Telegram:
1-3:0.2.8(42)
0-0:1.0.0(230703082533S)
0-0:96.1.1(4530303330303033373236363532353136)
1-0:1.8.1(010709.329*kWh)
1-0:1.8.2(005495.725*kWh)
1-0:2.8.1(001774.866*kWh)
1-0:2.8.2(004647.530*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.051*kW)
1-0:2.7.0(00.179*kW)
0-0:96.7.21(00003)
0-0:96.7.9(00004)
1-0:99.97.0(4)(0-0:96.7.19)(230619150315S)(0000003634*s)(220215142106W)(0000001771*s)(211012181306S)(0000004778*s)(201027144322W)(0000000354*s)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(001*A)
1-0:51.7.0(001*A)
1-0:71.7.0(001*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.023*kW)
1-0:61.7.0(00.028*kW)
1-0:22.7.0(00.179*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303235303033353134313837383137)
0-1:24.2.1(230703080000S)(06745.831*m3)
!C47D** Tevens contact opgenomen met Enexis, maar volgens hen worden dergelijke zaken niet gewijzigd aan de meter, en verwijzen mij naar de leverancier van de P1 kabel/software (zucht).....
ik zie nu ook dat het "live" verbruik om de 10 sec wijzigt maar het totale verbruik niet wordt aangepast... (volgens MQTT laatst gewijzigd 35 min geleden)..... dus er is wel verbruik? maar rekent dit niet naar het totaal verbruik.... ik ben het spoor een beetje bijster XD
dennissiemensma
commented
1 year ago Aan je telegram te zien, de zes regels bijna onderaan met kW, zie ik wel de balans qua fasen. Als in, 2 fasen verbruiken en teruglevering op de ander. Je kunt eventueel nog vanmiddag een tweede telegram delen om te zien of daar hetzelfde gebeurt, met meer opwekking. Overigens ben ik geen elektricien, dus mijn kennis van hoe dit elektro technisch werkt of zou moeten werken is beperkt.
niekniek89
commented
1 year ago Hierbij een nieuwe van een paar sec geleden:
1-3:0.2.8(42)
0-0:1.0.0(230703124224S)
0-0:96.1.1(4530303330303033373236363532353136)
1-0:1.8.1(010709.329*kWh)
1-0:1.8.2(005497.516*kWh)
1-0:2.8.1(001774.866*kWh)
1-0:2.8.2(004649.219*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.024*kW)
1-0:2.7.0(02.361*kW)
0-0:96.7.21(00003)
0-0:96.7.9(00004)
1-0:99.97.0(4)(0-0:96.7.19)(230619150315S)(0000003634*s)(220215142106W)(0000001771*s)(211012181306S)(0000004778*s)(201027144322W)(0000000354*s)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(006*A)
1-0:51.7.0(001*A)
1-0:71.7.0(004*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.024*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(01.481*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.880*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303235303033353134313837383137)
0-1:24.2.1(230703120000S)(06745.831*m3)
!22D7lever nu zo'n 2300watt terug...
niekniek89
commented
1 year ago Aan je telegram te zien, de zes regels bijna onderaan met kW, zie ik wel de balans qua fasen. Als in, 2 fasen verbruiken en teruglevering op de ander. Je kunt eventueel nog vanmiddag een tweede telegram delen om te zien of daar hetzelfde gebeurt, met meer opwekking. Overigens ben ik geen elektricien, dus mijn kennis van hoe dit elektro technisch werkt of zou moeten werken is beperkt.
Dat begrijp ik volkomen. Ik heb die kennis ook niet, maar vind het wel apart. Vorige week was het verbruik nog 0, en nu blijf ik verbruik houden (hoeveel ik ook terug lever).
Dit is nooit geweest :).
dennissiemensma
commented
1 year ago Je kunt wellicht nog wat oudere data bekijken in DSMR-reader op: /admin/dsmr_datalogger/dsmrreading/
De oorspronkelijke telegrammen worden welliswaar niet opgeslagen, maar de (gebruikte) gegevens wel. Je kunt kijken of een langere tijd terug die verdeling over de fasen destijds ook zo was.
niekniek89
commented
1 year ago Dank voor je antwoord. Ik heb even terug gekeken naar vorig jaar, en volgens mij deed hij dat toen ook al.
De vraag blijft, waarom ik al die tijd bij verbruik 0 heb gezien, en ik nu opeens verbruik en teruglevering zie (tegelijkertijd). Ik kijk dagelijks in DSMR, maar is me sinds afgelopen donderdag/vrijdag pas opgevallen...
dennissiemensma
commented
1 year ago Het is aangepast in release v4.14, maar dat is al een tijd geleden (maart '21), al zul je wellicht pas later die update gedraaid hebben.
niekniek89
commented
1 year ago Zie het inderdaad in de release notes van v4.14, echter zit ik al sinds afgelopen februari op v5.10.3 (net na de official release). Vreemd dat DSMR dit sinds vorige week pas visueel is gaan laten zien??
Volgens de Telegram lijkt dus alles gewoon te kloppen? en gebeurt verbruik en teruglevering altijd al achter de schermen?
Als ik nu bijv. de droger zou aanzetten (+-2000watt), en ik lever 1500watt terug, stond voorheen het verbruik op 500watt, en terugleveren op 0 (wat logisch zou zijn, omdat ik al het opgewekte zelf verbruik???). Nu is dat echter niet meer zo, en heb ik veel verbruik en relatief wat teruglevering... wat mij doet schetsen dat ik meer stroom afneem, terwijl ik in principe aardig voldoende opwek.
dennissiemensma
commented
1 year ago Je kunt het beste weer even terugkijken bij oude metingen en de kW-verbruik en kWh-standen proberen na te lopen. Op een relatief zonnige dag. De twee zijn wellicht verschillende eenheden, maar als je ook daar op 2 van de 3 fasen kW-verbruik ziet (zoals hierboven), dan zou je ook moeten zien dat de kWh-stand van verbruik af en toe (elke minuut ofzo?) langzaam toeneemt.
Als dat zo is, dan is het gedrag van je meter altijd al zo geweest. En dan zou je in DSMR-reader hetzelfde gezien moeten hebben, maar dat is achteraf gezien altijd lastig te zeggen. Zo niet, dan is het de vraag wanneer dat dan veranderd is in je meter. Echter, gezien #1324 aardig overeen komt met jouw situatie, zou ik verwachten dat het altijd al zo werkte.
niekniek89
commented
1 year ago Excuses voor mijn late reactie! Naast DSMR Reader, laat ik alle data via MQTT binnen komen op mijn Home Assistant VM. Ik heb het afgelopen dagen ff in de gaten gehouden, en op een mega zonnige dag:
Ik zie dus inderdaad dat het totaal verbruik weinig tot niks oploopt. Helaas kan ik niet zover terug om de verschillen te checken, maar gedrag lijkt hetzelfde (heb een quoocker, dus om het uur zeker een flinke piek van een paar sec).
Ik weet het niet meer, het zal wel kloppen... blijf het raar vinden dat dit nooit weergegeven werd binnen DSMR... Voor nu dank voor je hulp!!
sjaakvanwijk
commented
1 year ago Volgens mij heb ik hetzelfde probleem, ook ongeveer 2,5 week geleden ontstaan. Voorheen had ik nooit tegelijkertijd Ă©n verbruik Ă©n levering, ik gebruik de DSMR reader software al ruim 6 jaar :-).
Wat ik zie in het xml bericht is het volgende:
1-0:21.7.0(00.051*kW) "Instantaneous active power L1 (+P) in W resolution"
1-0:41.7.0(00.000*kW) "Instantaneous active power L2 (+P) in W resolution"
1-0:61.7.0(00.000*kW) "Instantaneous active power L3 (+P) in W resolution"
1-0:22.7.0(00.000*kW) "Instantaneous active power L1 (-P) in W resolution"
1-0:42.7.0(00.299*kW) "Instantaneous active power L2 (-P) in W resolution"
1-0:62.7.0(00.123*kW) "Instantaneous active power L3 (-P) in W resolution"en:
1-0:1.7.0(00.051*kW) "Actual electricity power delivered (+P) in 1 Watt resolution"
1-0:2.7.0(00.422*kW) "Actual electricity power received (-P) in 1 Watt resolution"De verklaringen tussen quotes achter de meetwaarden komen uit https://www.netbeheernederland.nl/_upload/Files/Slimme_meter_15_a727fce1f1.pdf Het lijkt er dus op dat in 1-0:1.7.0 (verbruik) en 1-0:2.7.0 (levering) de waarden van de 3 fasen ieder afzonderlijk worden opgeteld. Voorheen was dit beslist niet het geval en werden deze 6 meetwaarden tesamen opgeteld. Bij een per saldo verbruik krijgt 1-0:1.7.0 een waarde, bij een per saldo levering krijgt 1-0:2.7.0 een waarde.
Ik heb geen updates van de DSMR software uitgevoerd. Ik heb twee sets zonnepanelen, Ă©Ă©n aangesloten op L2 en Ă©Ă©n aangesloten op L3. Netbeheerder is Enexis.
Ik heb nog even het moment opgezocht wanneer dit issue bij mij voor het eerst is opgetreden: 29-06-2023 13:23. Hieronder 2 afdrukjes bijgevoegd van de betreffende DSM readings.
18236923 @ 2023-06-29 13_23_35+0200 DSMR reading weergeven _ DSMR-reader.pdf 18236922 @ 2023-06-29 13_22_58+0200 DSMR reading weergeven _ DSMR-reader.pdf
dennissiemensma
commented
1 year ago Bedankt voor je aanvulling. In dat geval verklaart dat het waarom het "opeens" anders is. Wellicht gebeurde dit dus al intern in de meters, maar is het nu ook naar buiten toe zichtbaar geworden.
niekniek89
commented
1 year ago Dank voor je aanvulling @sjaakvanwijk. Bij mij was het ook "opeens", terwijl ik al +- 4 jaar DSMR draai, en nooit dit tegelijkertijd gehad heb. Echter laten de telegrammen wel het, voor nu, zichtbare gedrag zien (als ik terug zoek naar het verleden).
Dus de vraag blijft, hoe kan het dat we dit nu pas zien in DSMR (terwijl het blijkbaar altijd zo geweest is) :)?
sjaakvanwijk
commented
1 year ago @dennissiemensma Maar het op enig moment "zichtbaar worden" van een meetwaarde, ook dat kan m.i. niet anders dan door een wijziging in de logica van de slimme meter, aangezien er verder geen wijzigingen zijn uitgevoerd.
De vraag die overblijft is: Wat wil je tonen in het dashboard en in de live grafiek "recent electriciteitverbruik"? Mijn persoonlijke voorkeur is dat je wilt zien of je per saldo levert of verbruikt.
Wat de verschillende fasen doen wordt al prima weergeven in "Recent Fasevermogen".
niekniek89
commented
1 year ago Ik heb ook contact opgenomen met (voor mij Enexis), maar die gaan natuurlijk vingerwijzen, en zeggen dat het niet aan de meter ligt. Die wijzen meteen naar de software, waarmee ik de P1 poort uitlees. Ergens moet vandaan komen, dat dit "opeens" anders weergegeven wordt.
Het rare is, dat in telegrammen uit het verleden, dit volgens mij altijd al zo geweest is.
Ik had ook een artikel op Tweakers gelezen (waar men exact hetzelfde had), en die heeft een nieuwe meter gehad.
dennissiemensma
commented
1 year ago Dank voor je aanvulling @ sjaakvanwijk. Bij mij was het ook "opeens", terwijl ik al +- 4 jaar DSMR draai, en nooit dit tegelijkertijd gehad heb. Echter laten de telegrammen wel het, voor nu, zichtbare gedrag zien (als ik terug zoek naar het verleden).
Dus de vraag blijft, hoe kan het dat we dit nu pas zien in DSMR (terwijl het blijkbaar altijd zo geweest is) :)?
@niekniek89 het kan eigenlijk niet anders zijn dan dat de slimme meter iets anders doorgeeft. Het gelijktijdig tonen van verbruik en teruglevering zit er al lange tijd in.
Ik heb ook contact opgenomen met (voor mij Enexis), maar die gaan natuurlijk vingerwijzen, en zeggen dat het niet aan de meter ligt. Die wijzen meteen naar de software, waarmee ik de P1 poort uitlees. Ergens moet vandaan komen, dat dit "opeens" anders weergegeven wordt.
Het rare is, dat in telegrammen uit het verleden, dit volgens mij altijd al zo geweest is.
Ik had ook een artikel op Tweakers gelezen (waar men exact hetzelfde had), en die heeft een nieuwe meter gehad.
@niekniek89 ik denk dat het dan handig is om te zoeken in de database van DSMR-reader wanneer er voor het eerst tegelijkertijd verbruik en teruglevering gemeten was.
sudo su - postgres
psql dsmrreader
SELECT timestamp, electricity_currently_delivered, electricity_currently_returned FROM dsmr_datalogger_dsmrreading WHERE electricity_currently_delivered > 0 AND electricity_currently_returned > 0 ORDER BY timestamp ASC LIMIT 100;Sterker nog, ik kan je vertellen dat ik hier ook mee te maken heb, terwijl ik geen zonnepanelen heb. Echter incidenteel:
timestamp | electricity_currently_delivered | electricity_currently_returned
------------------------+---------------------------------+--------------------------------
2023-07-12 18:13:55+01 | 0.097 | 0.005
2023-07-12 19:53:48+01 | 0.094 | 0.005
2023-07-13 08:48:31+01 | 0.089 | 0.005
2023-07-13 17:06:41+01 | 0.124 | 0.005
2023-07-13 17:23:43+01 | 0.241 | 0.004
2023-07-13 17:34:55+01 | 0.259 | 0.005
2023-07-13 17:58:58+01 | 2.241 | 0.002
2023-07-13 18:52:04+01 | 0.230 | 0.004
2023-07-13 19:27:08+01 | 0.213 | 0.004
2023-07-13 20:04:43+01 | 0.229 | 0.004
2023-07-14 03:16:25+01 | 0.098 | 0.004
2023-07-14 04:28:24+01 | 0.092 | 0.005
2023-07-14 12:56:55+01 | 0.093 | 0.005
2023-07-14 14:00:43+01 | 0.091 | 0.006
2023-07-14 16:28:11+01 | 0.101 | 0.005
2023-07-14 20:11:28+01 | 0.095 | 0.005
2023-07-14 20:17:09+01 | 0.095 | 0.004
2023-07-14 21:39:18+01 | 0.100 | 0.005
2023-07-15 09:13:22+01 | 0.089 | 0.005
2023-07-15 18:05:47+01 | 0.097 | 0.005
2023-07-16 04:06:29+01 | 0.031 | 0.004
2023-07-16 05:06:17+01 | 0.031 | 0.005
2023-07-16 05:11:57+01 | 0.030 | 0.005
2023-07-16 05:33:20+01 | 0.120 | 0.005
2023-07-16 05:52:42+01 | 0.107 | 0.005
2023-07-16 11:32:33+01 | 0.103 | 0.004
2023-07-16 12:02:57+01 | 0.098 | 0.005
2023-07-16 14:45:37+01 | 0.030 | 0.005
2023-07-16 15:07:09+01 | 0.030 | 0.005
2023-07-16 15:36:33+01 | 0.031 | 0.004
2023-07-16 17:06:14+01 | 0.097 | 0.004
2023-07-16 19:47:03+01 | 0.110 | 0.004
2023-07-17 06:54:44+01 | 0.027 | 0.005
2023-07-17 10:20:59+01 | 0.091 | 0.005
2023-07-17 11:11:55+01 | 0.090 | 0.005
2023-07-17 13:40:43+01 | 0.110 | 0.005
2023-07-17 18:24:17+01 | 0.335 | 0.004
2023-07-17 18:27:48+01 | 0.211 | 0.005
2023-07-18 07:59:16+01 | 0.096 | 0.004
2023-07-18 20:51:39+01 | 0.189 | 0.156
2023-07-18 22:57:44+01 | 0.097 | 0.005
2023-07-18 23:52:01+01 | 0.096 | 0.005
2023-07-19 02:26:50+01 | 0.033 | 0.004
2023-07-19 04:42:46+01 | 0.092 | 0.004
2023-07-19 17:49:31+01 | 0.028 | 0.005
2023-07-19 17:50:51+01 | 0.027 | 0.004
2023-07-19 18:44:38+01 | 0.095 | 0.004
(47 rows)Maar het op enig moment "zichtbaar worden" van een meetwaarde, ook dat kan m.i. niet anders dan door een wijziging in de logica van de slimme meter, aangezien er verder geen wijzigingen zijn uitgevoerd. De vraag die overblijft is: Wat wil je tonen in het dashboard en in de live grafiek "recent electriciteitverbruik"? Mijn persoonlijke voorkeur is dat je wilt zien of je per saldo levert of verbruikt. Wat de verschillende fasen doen wordt al prima weergeven in "Recent Fasevermogen".
@sjaakvanwijk dat is dus juist in #1324 eruit gehaald omdat het niet de werkelijkheid aangeeft. Dus dat blijft zo, zolang de slimme meter dat ook op die manier aangeeft.
Sterker nog, in principe verbloem je anders wat er echt onderwater gebeurt. Zolang je het nog mag salderen maakt het nog niet uit, maar in principe verbruik je wel stroom.
dennissiemensma
commented
1 year ago Nog ter aanvulling over mn eigen metingen, het lijkt er niet op dat de meterstanden voor teruglevering geraakt zijn. Het gaat dan ook over 4 of 5 Watt, maar het lijkt nog steeds nul:
timestamp | electricity_currently_delivered | electricity_currently_returned | electricity_returned_1 | electricity_returned_2
------------------------+---------------------------------+--------------------------------+------------------------+------------------------
2023-07-12 18:13:55+01 | 0.097 | 0.005 | 0.000 | 0.000
2023-07-12 19:53:48+01 | 0.094 | 0.005 | 0.000 | 0.000
2023-07-13 08:48:31+01 | 0.089 | 0.005 | 0.000 | 0.000
2023-07-13 17:06:41+01 | 0.124 | 0.005 | 0.000 | 0.000
2023-07-13 17:23:43+01 | 0.241 | 0.004 | 0.000 | 0.000
2023-07-13 17:34:55+01 | 0.259 | 0.005 | 0.000 | 0.000
2023-07-13 17:58:58+01 | 2.241 | 0.002 | 0.000 | 0.000
2023-07-13 18:52:04+01 | 0.230 | 0.004 | 0.000 | 0.000
2023-07-13 19:27:08+01 | 0.213 | 0.004 | 0.000 | 0.000
2023-07-13 20:04:43+01 | 0.229 | 0.004 | 0.000 | 0.000
2023-07-14 03:16:25+01 | 0.098 | 0.004 | 0.000 | 0.000
2023-07-14 04:28:24+01 | 0.092 | 0.005 | 0.000 | 0.000
2023-07-14 12:56:55+01 | 0.093 | 0.005 | 0.000 | 0.000
2023-07-14 14:00:43+01 | 0.091 | 0.006 | 0.000 | 0.000
2023-07-14 16:28:11+01 | 0.101 | 0.005 | 0.000 | 0.000
2023-07-14 20:11:28+01 | 0.095 | 0.005 | 0.000 | 0.000
2023-07-14 20:17:09+01 | 0.095 | 0.004 | 0.000 | 0.000
2023-07-14 21:39:18+01 | 0.100 | 0.005 | 0.000 | 0.000
2023-07-15 09:13:22+01 | 0.089 | 0.005 | 0.000 | 0.000
2023-07-15 18:05:47+01 | 0.097 | 0.005 | 0.000 | 0.000
2023-07-16 04:06:29+01 | 0.031 | 0.004 | 0.000 | 0.000
2023-07-16 05:06:17+01 | 0.031 | 0.005 | 0.000 | 0.000
2023-07-16 05:11:57+01 | 0.030 | 0.005 | 0.000 | 0.000
2023-07-16 05:33:20+01 | 0.120 | 0.005 | 0.000 | 0.000
2023-07-16 05:52:42+01 | 0.107 | 0.005 | 0.000 | 0.000
2023-07-16 11:32:33+01 | 0.103 | 0.004 | 0.000 | 0.000
2023-07-16 12:02:57+01 | 0.098 | 0.005 | 0.000 | 0.000
2023-07-16 14:45:37+01 | 0.030 | 0.005 | 0.000 | 0.000
2023-07-16 15:07:09+01 | 0.030 | 0.005 | 0.000 | 0.000
2023-07-16 15:36:33+01 | 0.031 | 0.004 | 0.000 | 0.000
2023-07-16 17:06:14+01 | 0.097 | 0.004 | 0.000 | 0.000
2023-07-16 19:47:03+01 | 0.110 | 0.004 | 0.000 | 0.000
2023-07-17 06:54:44+01 | 0.027 | 0.005 | 0.000 | 0.000
2023-07-17 10:20:59+01 | 0.091 | 0.005 | 0.000 | 0.000
2023-07-17 11:11:55+01 | 0.090 | 0.005 | 0.000 | 0.000
2023-07-17 13:40:43+01 | 0.110 | 0.005 | 0.000 | 0.000
2023-07-17 18:24:17+01 | 0.335 | 0.004 | 0.000 | 0.000
2023-07-17 18:27:48+01 | 0.211 | 0.005 | 0.000 | 0.000
2023-07-18 07:59:16+01 | 0.096 | 0.004 | 0.000 | 0.000
2023-07-18 20:51:39+01 | 0.189 | 0.156 | 0.000 | 0.000
2023-07-18 22:57:44+01 | 0.097 | 0.005 | 0.000 | 0.000
2023-07-18 23:52:01+01 | 0.096 | 0.005 | 0.000 | 0.000
2023-07-19 02:26:50+01 | 0.033 | 0.004 | 0.000 | 0.000
2023-07-19 04:42:46+01 | 0.092 | 0.004 | 0.000 | 0.000
2023-07-19 17:49:31+01 | 0.028 | 0.005 | 0.000 | 0.000
2023-07-19 17:50:51+01 | 0.027 | 0.004 | 0.000 | 0.000
2023-07-19 18:44:38+01 | 0.095 | 0.004 | 0.000 | 0.000
(47 rows)Nog een aanvulling op hierboven, het kan zijn dat het al langer speelt maar door dataretentie van een week (die ik hier draai op mn eigen DSMR-reader installatie) worden de metingen natuurlijk flink uitgedund.
En gezien het sporadisch voorkomt (paar keer per dag bij mij) is de kans vrij klein dat de retentie toevallig een meting bewaart die er last van heeft. In mijn geval een kans van 1 op 360 per uur zelfs. Dus mogelijk is het hier ook al langer een issue.
dennissiemensma
commented
1 year ago Hoe dan ook kunnen jullie met https://github.com/dsmrreader/dsmr-reader/issues/1873#issuecomment-1642730545 in de eigen database proberen te speuren naar de eerste meting.
Wat betreft de weergave blijft dat ook zoals het is, omdat het echt is wat de meter toont, doet en aangeeft. En dat is immers de kern van dit project: de slimme meter uitlezen en tonen wat die aangeeft. Plus dat het belangrijker wordt wanneer (administratief) salderen straks afgebouwd wordt komende jaren.
Voel jullie uiteraard vrij voor nieuwe vragen of aanvullingen.
sjaakvanwijk
commented
1 year ago Nog even in de nastoot: Ik heb zelf ook contact gehad met Enexis. Zij verwijzen voor een oplossing naar de leverancier van 'de app die u gebruikt'. De dame van de servicedesk was erg goed op de hoogte en wist precies wat ik bedoelde. Zij bevestigde ook dat beide attributen niet gelijktijdige een waarde kunnen hebben. @dennissiemensma Ik ben het met je eens dat je geen aanpassingen doet, want dat zou de werkelijkheid geweld aan doen. Ik gebruik de 'slimmelezer' voor het uitlezen van de telegrammen. De console van de slimmelezer laat realtime zien wat er over het lijntje komt. Ik denk dat ik de dames en heren van Enexis daarmee ga stalken totdat ze gaan bewegen. Zelf heb ik (nog) geen dynamisch energiecontract, maar ik zou me zomaar kunnen voorstellen dat dan deze attributen belangrijk zijn om te bepalen wat in rekening wordt gebracht.
niekniek89
commented
1 year ago @sjaakvanwijk @dennissiemensma
maak ik hieruit op, dat de meter niet goed meer/naar behoren werkt?? ik heb ook al eens contact opgenomen met Enexis, en verwees mij extract hetzelfde als jou, door naar de leverancier van de app.
sjaakvanwijk
commented
1 year ago @niekniek89 Blijkbaar. Mijn conclusie is dat de lezer software gewoon leest wat de P1 van de meter rapporteert en dat de gemeten waarden niet conform de specificaties zijn. Dan moeten ze niet aankomen met het verhaal dat er iets met de app aan de hand zou zijn. Dit is geen magic hoor. De lezer haalt een telegram met een checksum binnen. Daar kunnen niet zomaar getallen in veranderen! Probleem is alleen dat organisaties zoals Enexis uit kostenoverwegingen geen belang hebben om al te genereus toe te geven dat er een fout in in de meter zit, aangezien ik vast niet de enige ben met dit probleem. De meterstanden zelf zijn ook gewoon correct.
niekniek89
commented
1 year ago Dank @sjaakvanwijk voor je antwoord. Die conclusie snap ik inderdaad, en sluit ik me volledig bij aan. Maar idd, hoe ga je dat Enexis wijsmaken… das wel een dingetje. Zie op Tweakers een aantal met hetzelfde issue, waarbij hij na lang “zeuren/aandringen” vervangen is. Toch ook nog maar eens diverse pogingen wagen.
Zij hadden ook opeens verbruik Ă©n terugleveren tegelijk..
dennissiemensma
commented
1 year ago Als het technisch gezien klopt dat er daadwerkelijk teruglevering is bij 3-fasen, op twee van de drie fasen, dan snap ik persoonlijk wel dat dat nu ook zo getoond wordt. Helemaal in de huidige situatie met dat eigenlijk alles en iedereen gevraagd wordt om zoveel mogelijk de piekbelasting op het net te verminderen, ook voor teruglevering.
Echter als dat al zo is, dan had ik wel wat communicatie verwacht. En opzich kunnen jullie beiden er zelf ook weinig aan doen, want dan zou je een 3-fasen omvormer moeten nemen ofzo (als dat op die manier werkt). Of dat ze (net als in Belgie) gaan afrekenen op piekbelasting per maand.
Ik zou in ieder geval niet verwachten dat ze dit weer zomaar terugdraaien.
niekniek89
commented
1 year ago verwacht inderdaad niet, dat men het dan zal terug draaien. waren ook niet van plan ĂĽberhaupt enigszins Ăets te doen om naar mijn melding te kijken. zal dus niet zomaar opgelost gaan worden/naar gekeken gaan worden.
men wimpelt het erg snel af richting de applicatie, waarmee we de P1 poort uitlezen..... zal dus nog eens een nieuwe poging wagen.
niekniek89
commented
1 year ago inmiddels een paar weken verder, en nog eens contact gezocht met Enexis... maar willen er weinig over weten. is er bij jou @sjaakvanwijk toevallig al meer voortgang, of niet meer geprobeerd?
sjaakvanwijk
commented
1 year ago @niekniek89 Nee. Zodra er significante voortgang is laat ik dit weten.
Description
Goedemorgen,
Sinds een aantal dagen krijg ik “opeens” zowel verbruik als teruglevering te zien (zie screenshot). Dit heb ik in al die jaren dat ik DSMR Reader gebruik, nog nooit eerder gezien. Normaliter werd dit altijd verrekend/van elkaar af getrokken.
Gisterenmiddag liet hij bijv 1800watt teruglevering zien, maar ook 88watt verbruik. Normaal liet hij dat bij verbruik 0 zien, zodra ik voldoende terugleverde. Het raarste is, dat dit pas sinds een aantal dagen terug “opeens” beide laat zien.
Ik draai DSMR Reader in docker, maar aan zowel de container als de linux machine zelf is niks aangepast of ge-update.
Nog meer ter info: gisteren zag ik (tijdens terugleveren) ook live verbruik, maar het totaal verbruik liep NIET op tijdens terugleveren….
DSMR-reader version
5.10.3
DSMR-reader platform
Docker (e.g. Xirixiz)
Debug info dump
DEBUG INFO DUMP
DSMR-READER App / Python / Database v5.10.3 / v3.11.1 / postgresql BE sleep / DL sleep / Retention / Override 1.0s / 0.5s / 4032h / False Latest telegram version read / Parser settings "42" / "4"
DATA Telegrams total (est.) 1500168 Consumption records electricity / gas (est.) 294398 / 29876
POSTGRESQL SIZE OF LARGEST TABLES (> 500 MB) public.dsmr_datalogger_dsmrreading 688 MB