Gekke spannings/vermogens pieken uit de slimme meter

[maarten_NL]

Ik heb al jaren een Raspberry met Node Red aan de slimme meter hangen en houd daar diverse parameters bij om zo hier en daar wat slimme dingen te doen en de spanning op het net tov de oplevering van de panelen/verbruik op de aansluiting in de gaten te houden. Al jaren zie ik daar geen gekke dingen, tot ik begin deze week een trigger kreeg dat er meer dan 15kW import op de (3x25A) netaansluiting werd gevraagd.

Dus ik ging in de grafieken kijken en daar zag ik zelfs een piek van 23.3kW import Op dit moment was de EV aan het pre-conditionen dus het was logisch dat er wat werd verbruikt, maar 23kW is wel heel veel.



Op de gegevens per fase zie je hetzelfde gebeuren. de 3 fases gaan tegelijkertijd door het plafond. Dus dan zou ik zeggen dat het geen bugje in de verwerking van de P1 telegram is.



Nu was ik ook even naar de voltages op de fases (de blauw/geel/groene) tov import/export op de aansluiting (rode lijn) aan het kijken en daar zie ik gekke spanningspieken van 460 tot 900v), die soms samen vallen met de vermogens pieken:



Ik dacht natuurlijk eerst aan de EV, maar ik zie het ook gebeuren als de EV niet aan de paal hangt. Zijn het dan andere apparaten die voor deze piekspanningen zorgen? De pieken zijn ook op tijden dat ik nog lig te slapen of niet thuis ben. Ik zie verder geen verlichting ineens feller worden of dat er opladers ontploffen, dus is hier de spanningsmeting van de slimme meter de oorzaak? Herkent iemand dit?

Ik heb de netbeheerder maar even gebeld en die hebben er een lage prio case voor ingezet.

[MSXBas]

metertje kapot?

met pieken van 460-900v zou ik denken dat er heel veel apparatuur in huis kapot moet zijn gegaan.

Zie je het verbruik/ piek ook terug als je de gegevens van de slimme meter op een andere manier opvraagt (app/ energieleverancier)?

[maarten_NL]

Ik heb er de vinger nog niet achter maar het lijkt alsof de waardes van de 3 fases, na het verwerken van de P1 telegram, bij elkaar op worden geteld.

De piekwaardes zijn elke keer precies het 2-3-4 voudige van de waardes er omheen.

Dat is vreemd wat ik doe helemaal geen berekeningen op de waardes en pomp die 1:1 over naar de influxdb en het draait zo al jaren, zonder die gekke pieken.

Ik heb nu een aantal debug "taps" in de flow gezet, nu even wachten op weer een piek en dan terug kijken in de actuele input/output.

[DexterDee]

Als ik naar je vermogensgrafiek per fase kijk, dan zie ik dat alle fases op +/- 10 watt na hetzelfde vermogen rapporteren op een heel klein stukje na. Dat is vreemd, want in een normale situaties zijn de verbruikers in huis verdeeld op 1 van de 3 fasen. Zelfs 3 fase gebruikers hebben vaak geen gebalanceerd verbruik (bijvoorbeeld een inductiekookplaat). De fasen onderling zouden in gebruik dus veel meer moeten afwijken van elkaar.

Lijkt me dus dat de meetgegevens verkeerd geïnterpreteerd worden.

[maarten_NL]

DexterDee schreef op vrijdag 9 december 2022 @ 13:40:
Als ik naar je vermogensgrafiek per fase kijk, dan zie ik dat alle fases op +/- 10 watt na hetzelfde vermogen rapporteren op een heel klein stukje na.

Ik denk dat de de schaal verkeerd interpreteert. 10w verschil zie je op deze schaal niet maar op de 3 fases zit door sluipverbruik tot zo'n 100w verschil.

De EV laad met een heel constante en gelijke belasting op de 3 fases. Daarnaast zie je dat de lijnen niet helemaal op elkaar liggen (het verschillende verbruik op de 3 fases door de rest van het huis) en dat op diverse plekken flink afwijken, bijvoorbeeld als de boiler in slaat.

In de tap (net voor de injectie op de influxdb) naar een csv zie ik het probleem al optreden, 2 regels van metingen 10s na elkaar:

code:

phases,type=Watt p1=10210,usageph1=3390,usageph2=3534,usageph3=3291,returnph1=-0,returnph2=-0,returnph3=-0,voltph1=221,voltph2=219,voltph3=221,returnday=859   

phases,type=Watt p1=20390,usageph1=6768,usageph2=7050,usageph3=6568,returnph1=-0,returnph2=-0,returnph3=-0,voltph1=442,voltph2=438,voltph3=442,returnday=859

Alles behalve de returnday is verdubbeld. Nu nog terug zoeken waar dit nu vandaan komt.

[ThinkPad]

Waarmee lees je de P1-poort uit? Checkt je code ook op de CRC van de telegrammen om op die manier corrupte berichten te skippen? (mits je slimme meter >= DSMR4 is, DSMR2 had nog geen CRC erin zitten).

[ Voor 21% gewijzigd door ThinkPad op 09-12-2022 15:03 ]

[maarten_NL]

ThinkPad schreef op vrijdag 9 december 2022 @ 15:02:
Waarmee lees je de P1-poort uit? Checkt je code ook op de CRC van de telegrammen om op die manier corrupte berichten te skippen? (mits je slimme meter >= DSMR4 is, DSMR2 had nog geen CRC erin zitten).

Mijn code checkt de CRC niet. Om de telegram te valideren heb ik de tap op in input en de output gezet. Net na de serial read en net voor de inject naar de database:

In dit geval zijn de waardes x3:



Maar de bron ziet er dus wel goed uit.

De flow:



De verdubbelde data komt uit de code in de read telegram function node.

Een stukje log van de output uit de function node:

code:

"energy":{"usage":5550,"return":4798,"usagel":2724.126,"usageh":2826.901,"returnl":1585.236,"returnh":3213.539},"phases":{"voltph1":223,"voltph2":220,"voltph3":220,"usageph1":3454,"usageph2":3532,"usageph3":3402,"returnph1":0,"returnph2":0,"returnph3":0},"p1":10380,"gas":{"value":3586138}}
2022-12-09T15:04:30.132Z
2022-12-09T15:04:31.132Z
2022-12-09T15:04:32.132Z
2022-12-09T15:04:33.132Z
2022-12-09T15:04:34.132Z
2022-12-09T15:04:35.131Z
2022-12-09T15:04:36.132Z
{"energy":{"usage":11100,"return":9596,"usagel":5448.252,"usageh":5653.844999999999,"returnl":3170.472,"returnh":6427.078},"phases":{"voltph1":446,"voltph2":440,"voltph3":440,"usageph1":6892,"usageph2":7078,"usageph3":6794,"returnph1":0,"returnph2":0,"returnph3":0},"p1":20760,"gas":{"value":3586138}}
2022-12-09T15:04:37.147Z
2022-12-09T15:04:38.147Z
2022-12-09T15:04:39.147Z
2022-12-09T15:04:40.146Z
2022-12-09T15:04:41.147Z
2022-12-09T15:04:42.147Z
{"energy":{"usage":5550,"return":4798,"usagel":2724.126,"usageh":2826.941,"returnl":1585.236,"returnh":3213.539},"phases":{"voltph1":223,"voltph2":220,"voltph3":220,"usageph1":3446,"usageph2":3537,"usageph3":3400,"returnph1":0,"returnph2":0,"returnph3":0},"p1":10380,"gas":{"value":3586138}}

Maar waarom zo ineens, aan die code is al 2 jaar niks veranderd

Ieder geval is het goed om te weten dat het dus niet in de meter zit en er teveel kWhs worden gemeten

[ThinkPad]

Ik zou check op de CRC sowieso toevoegen, kan geen kwaad. Methode die gebruikt wordt is 'CRC16' meen ik, zie ook Slimme meter uitlezen via P1-poort