Closed bochelork closed 1 year ago
Je zou tijdelijk debug logging kunnen aanzetten en dan in de log van de datalogger kijken hoe het telegram eruit ziet komende nacht. Ik zou verwachten dat het in het telegram ook zo zit, maar dat is alleen met zekerheid te zeggen wanneer je dat ook in de logs ziet.
Ik heb even de RAW data via MQTT gelogd. Kan je hier iets zinnigs over zeggen? Dit is het tijdstip waar het mis gaat: 2023-05-21 07:46:01 Payload: b'/XMX5XMXABCE000056892\r\n\r\n0-0:96.1.1(31333435393634332020202020202020)\r\n1-0:1.8.1(20285.746kWh)\r\n1-0:1.8.2(21625.177kWh)\r\n1-0:2.8.1(02250.996kWh)\r\n1-0:2.8.2(05209.823kWh)\r\n0-0:96.14.0(0001)\r\n1-0:1.7.0(0000.00kW)\r\n1-0:2.7.0(0000.37kW)\r\n0-0:96.13.1()\r\n0-0:96.13.0()\r\n!' 2023-05-21 07:48:41 Payload: b'/XMX5XMXABCE000056892\r\n\r\n0-0:96.1.1(31333435393634332020202020202020)\r\n1-0:1.8.1(20281.8.2(21625.177kWh)\r\n1-0:2.8.1(02251.014kWh)\r\n1-0:2.8.2(05209.823kWh)\r\n0-0:96.14.0(0001)\r\n1-0:1.7.0(0000.00kW)\r\n1-0:2.7.0(0000.44kW)\r\n0-0:96.13.1()\r\n0-0:96.13.0()\r\n!' 2023-05-21 07:48:45 Payload: b'/XMX5XMXABCE000056892\r\n\r\n0-0:96.1.1(31333435393634332020202020202020)\r\n1-0:1.8.1(20285.746kWh)\r\n1-0:1.8.2(21625.177kWh)\r\n1-0:2.8.1(02251.015kWh)\r\n1-0:2.8.2(05209.823kWh)\r\n0-0:96.14.0(0001)\r\n1-0:1.7.0(0000.00kW)\r\n1-0:2.7.0(0000.44*kW)\r\n0-0:96.13.1()\r\n0-0:96.13.0()\r\n!'
Dit zijn je metingen:
b'/XMX5XMXABCE000056892
0-0:96.1.1(31333435393634332020202020202020)
1-0:1.8.1(20285.746*kWh)
1-0:1.8.2(21625.177*kWh)
1-0:2.8.1(02250.996*kWh)
1-0:2.8.2(05209.823*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(0000.00*kW)
1-0:2.7.0(0000.37*kW)
0-0:96.13.1()
0-0:96.13.0()
!'
b'/XMX5XMXABCE000056892
0-0:96.1.1(31333435393634332020202020202020)
1-0:1.8.1(20281.8.2(21625.177*kWh)
1-0:2.8.1(02251.014*kWh)
1-0:2.8.2(05209.823*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(0000.00*kW)
1-0:2.7.0(0000.44*kW)
0-0:96.13.1()
0-0:96.13.0()
!'
b'/XMX5XMXABCE000056892
0-0:96.1.1(31333435393634332020202020202020)
1-0:1.8.1(20285.746*kWh)
1-0:1.8.2(21625.177*kWh)
1-0:2.8.1(02251.015*kWh)
1-0:2.8.2(05209.823*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(0000.00*kW)
1-0:2.7.0(0000.44*kW)
0-0:96.13.1()
0-0:96.13.0()
!'
Wat voor slimme meter heb je en welke DSMR-versie staat op de meter?
Er lijkt namelijk geen datumtijd in de metingen zelf te staan, dat helpt niet mee. En ik zie ook geen CRC check aan het einde, wat nog kan betekenen dat telegrammen ruis kunnen bevatten, al heb ik nooit eerder gezien dat ruis exact een meterpositie wisselt.
En wat staat er in DSMR-reader bij bovenstaande tijstippen?
Sterker nog, ik zie nu dat je tweede telegram corrupt is: 1-0:1.8.1(20281.8.2(21625.177*kWh)
Twee meterstanden vallen over elkaar heen.
De eerste heeft iets als:
1-0:1.8.1(20285.746*kWh)
1-0:1.8.2(21625.177*kWh)
1-0:2.8.1(02250.996*kWh)
1-0:2.8.2(05209.823*kWh)
De tweede:
1-0:1.8.1(20281.8.2(21625.177*kWh)
1-0:2.8.1(02251.014*kWh)
1-0:2.8.2(05209.823*kWh)
Wel bizar, want ik heb het dus niet eerder gezien dat meterstanden over elkaar heen gaan. Hooguit dat er een bit flipt en de hele regel ongeldig is.
Ik vermoed dat je dan een oude slimme meter hebt met DSMR-versie 2 of 3? De zogenaamde CRC-checks helpen tegen corruptie. DSMR-reader checkt daarop, maar kan dat alleen doen bij meters die dat ondersteunen helaas. Ik heb dan ook geen oplossing voor je.
Hoi, bedankt voor je analyse. Het is inderdaad versie 2 volgens mij. Ik had wel de usb poort van mijn raspberry pi waar de meter is aangesloten ook in docker-compose van Home Assistant gezet. Deze heb ik er nu uitgehaald, voorlopig geen vreemde data, maar het we zijn pas een halve dag verder. Ik hoop dat dat de oorzaak van het probleem is. Over een paar dagen weet ik meer.
Helaas nog steeds buggy data. Ik zal zelf een work-around moeten maken denk ik. Nu zie je in de data dat niet alle verwachte velden data hebben. Is daar niets mee te doen? De heleboel ongeldig verklaren? Of is dat lastig ivm met de verschillende versies en systemen?
Het is lastig om daar iets voor te maken, want nu mis je bijvoorbeeld een meterstand. Maar in het ergste geval wisselen wat bits in een meterstand, waardoor die een heel ander getal wordt.
Je kunt kijken of je P1-kabel vrij hangt en er geen electriciteitskabel tegenaan zit. Dat stoort nog wel eens. Al is het geen garantie dat de kabel dan storingvrij wordt en blijft. Het is eigenlijk de hele reden waarom er in slimme meters tegenwoordig de CRC-checks zitten. Die garanderen telegrammen die ofwel geldig zijn ofwel onbetrouwbaar.
Je kunt nog informeren bij je netbeheerder of je een andere (nieuwere) meter kan krijgen. Maar dat doen ze doorgaans niet tenzij je huidige meter echt niet meer functioneert. En als het al te vervangen is, is het niet perse gratis. Maar informeren kan altijd.
Ik heb nu even een python script gemaakt om de data te valideren. Even snel in elkaar gezet. Dsmr reader stuurt het nu naar een ander pad, het script kijkt op de lengte van het bericht overeenkomt met een minimale lengte(alle geldige data zijn even lang, ik weet niet of dat per definitie zo is. Er komen nu 3 a 4 blokken per dag binnen die korter zijn, je ziet dat er gewoon een blokje bytes ontbreekt. Als de lengte in orde is, wordt de volgende data doorgestuurd naar het originel pad (dsmr/...)
Ja opzich kun je het telegram splitten op \r\n
en dan specifiek de 4 regels in https://github.com/dsmrreader/dsmr-reader/issues/1856#issuecomment-1556269193 checken. Ze hebben allemaal een eigen identifier vooraan en die regels zijn inderdaad altijd even lang.
Echter is het dus geen garantie voor inhoudelijke meterstanden-validatie, maar het fixt wel de gevallen zoals in het tweede code-blok van dat comment.
Description
ip:7777/admin/dsmr_datalogger/dsmrreading/ geeft de volgende data
Om 04:10 wordt er verkeerde data verwerkt. De waarde van electricity 1 bevat de meetwaarde van electricity 2. De waarde van electricity 2 is leeg. Helaas verpest dit op dit moment mijn home assistant grafieken. Dit gebeurt nu 0 tot 2 keer per dag. Waar moet ik beginnen met zoeken? Kan er een sanity-check uitgevoerd worden voordat de data via MQTT wordt verstuurd?
Ik draai DSMR-reader: v5.10.3 in docker op een Raspberry Pi 4. (ghcr.io/xirixiz/dsmr-reader-docker:latest)
DSMR-reader version
5.10.3
DSMR-reader platform
Docker (e.g. Xirixiz)
Debug info dump
No response