Invalid telegram. The CRC checksum '17805' does not match the expected '12832'

yfands commented 2 years ago

Hello, Got a problem with my DSMR, about 3 weeks ago (maybe earlier) I noticed in the llog file that I receive thousands messages a day regarding CRC checksum warnings. Although my energy dashboards works (power delivered and consumed and gas consumed).

All was ok when USB port was configured in YAML, dont know when it 'broke'.

although nothing has changed, I rearranged the P1 Cable, swapped USB ports, reinstalled the integration, but to no success.

Can somebody help me to explain how to debug the usb port and catch the data received. The error below would suggests that the RPI 4 cant cope with the speeds of my DSRM V5 anymore.

Thanks in Advance Frank

There is an error in my log: Logger: dsmr_parser.clients.protocol Source: /usr/local/lib/python3.9/site-packages/dsmr_parser/clients/protocol.py:138 First occurred: 15:38:58 (2 occurrences) Last logged: 15:54:57

failed to parse telegram Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/dsmr_parser/clients/protocol.py", line 134, in handle_telegram parsed_telegram = self.telegram_parser.parse(telegram) File "/usr/local/lib/python3.9/site-packages/dsmr_parser/parsers.py", line 48, in parse self.validate_checksum(telegram_data) File "/usr/local/lib/python3.9/site-packages/dsmr_parser/parsers.py", line 82, in validate_checksum raise ParseError( dsmr_parser.exceptions.ParseError: Failed to perform CRC validation because the telegram is incomplete. The checksum and/or content values are missing.

And a warning with thousands occurrences at the end of the day. Logger: dsmr_parser.clients.protocol Source: /usr/local/lib/python3.9/site-packages/dsmr_parser/clients/protocol.py:136 First occurred: 15:18:59 (181 occurrences) Last logged: 16:03:45

Invalid telegram. The CRC checksum '48812' does not match the expected '3484' Invalid telegram. The CRC checksum '6181' does not match the expected '50447' Invalid telegram. The CRC checksum '55319' does not match the expected '39915' Invalid telegram. The CRC checksum '47198' does not match the expected '48688' Invalid telegram. The CRC checksum '33152' does not match the expected '57677'

My configuration:

System Health

version	core-2021.10.6
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.9.7
os_name	Linux
os_version	5.10.17-v8
arch	aarch64
timezone	Europe/Amsterdam

Home Assistant Community Store

Home Assistant Cloud

Home Assistant Supervisor

Lovelace

yfands commented 2 years ago

Looking back it looks like there is no commitment anymore since may 11th.??? as far as I can see the last 5 issues where never addressed... ;-( anybody ?

lowdef commented 2 years ago

If you send a telegram from your system, somebody might have a look if it is a DSMR Parser Problem. This is not a Home Assistant OS support channel.

yfands commented 2 years ago

Ok my bad, I was send here from where I made my issue at first (https://github.com/dsmrreader/dsmr-reader/issues/761) they told me to address my issue here. I am totally lost now, "send a telegram from my system" ??, Sorry still a beginner here, and absolutely no idea what where who to call if something is wrong.. ;-(

HFugers commented 2 years ago

I also have a CRC-error (on RPI4 too) but It worked just fine for 6 months. I assume a faulty update of the DSMR firmware by the provider. Checking workarounds by extensive retries now.

lowdef commented 2 years ago

@HFugers Could you provide a dsmr telegram that has this problem?

Potential way to do it: cu -l /dev/ttyUSB0 -s 115200 --parity=none

Of course adapt parameters as applicable to your situation.

If you don't have it yet, install with: sudo apt-get install cu

yfands commented 2 years ago

Hai thanks for the reply, Hope that HFugers can supply a dsmr telegram, Iam on default Hassio and cant install packages.

Regards Frank

eavanvalkenburg commented 2 years ago

I'm having this issue as well, this is a record that I get when I run the above command, it is a v5 DSMR in the netherlands:

1-3:0.2.8(50)
0-0:1.0.0(220127110431W)
0-0:96.1.1(4530303534303037363432313534323230)
1-0:1.8.1(009418.807*kWh)
1-0:1.8.2(003309.321*kWh)
1-0:2.8.1(000581.835*kWh)
1-0:2.8.2(001332.223*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.196*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00005)
0-0:96.7.9(00003)
1-0:99.97.0(1)(0-0:96.7.19)(200421120530S)(0000000939*s)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00001)
1-0:52.36.0(00001)
1-0:72.36.0(00001)
0-0:96.13.0()
1-0:32.7.0(236.9*V)
1-0:52.7.0(235.9*V)
1-0:72.7.0(237.3*V)
1-0:31.7.0(002*A)
1-0:51.7.0(001*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.193*kW)
1-0:41.7.0(00.127*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(00.177*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303339303031373434313432303137)
0-1:24.2.1(220127110004W)(09916.665*m3)
!73A4
/ISK5\2M550T-1013

lowdef commented 2 years ago

If you switch of CRC check the telegram just parses fine:

P1_MESSAGE_HEADER:   50 [None]
P1_MESSAGE_TIMESTAMP:    2022-01-27T11:04:31+01:00  [None]
EQUIPMENT_IDENTIFIER:    4530303534303037363432313534323230 [None]
ELECTRICITY_USED_TARIFF_1:   9418.807   [kWh]
ELECTRICITY_USED_TARIFF_2:   3309.321   [kWh]
ELECTRICITY_DELIVERED_TARIFF_1:      581.835    [kWh]
ELECTRICITY_DELIVERED_TARIFF_2:      1332.223   [kWh]
ELECTRICITY_ACTIVE_TARIFF:   0002   [None]
CURRENT_ELECTRICITY_USAGE:   0.196  [kW]
CURRENT_ELECTRICITY_DELIVERY:    0.000  [kW]
LONG_POWER_FAILURE_COUNT:    3  [None]
SHORT_POWER_FAILURE_COUNT:   5  [None]
POWER_EVENT_FAILURE_LOG:         buffer length: 1
     buffer type: 0-0:96.7.19
     event occured at: 2020-04-21T12:05:30+02:00     for: 939 [s]
VOLTAGE_SAG_L1_COUNT:    0  [None]
VOLTAGE_SAG_L2_COUNT:    0  [None]
VOLTAGE_SAG_L3_COUNT:    0  [None]
VOLTAGE_SWELL_L1_COUNT:      1  [None]
VOLTAGE_SWELL_L2_COUNT:      1  [None]
VOLTAGE_SWELL_L3_COUNT:      1  [None]
INSTANTANEOUS_VOLTAGE_L1:    236.9  [V]
INSTANTANEOUS_VOLTAGE_L2:    235.9  [V]
INSTANTANEOUS_VOLTAGE_L3:    237.3  [V]
INSTANTANEOUS_CURRENT_L1:    2  [A]
INSTANTANEOUS_CURRENT_L2:    1  [A]
INSTANTANEOUS_CURRENT_L3:    0  [A]
TEXT_MESSAGE:    None   [None]
DEVICE_TYPE:     3  [None]
INSTANTANEOUS_ACTIVE_POWER_L1_POSITIVE:      0.193  [kW]
INSTANTANEOUS_ACTIVE_POWER_L2_POSITIVE:      0.127  [kW]
INSTANTANEOUS_ACTIVE_POWER_L3_POSITIVE:      0.000  [kW]
INSTANTANEOUS_ACTIVE_POWER_L1_NEGATIVE:      0.000  [kW]
INSTANTANEOUS_ACTIVE_POWER_L2_NEGATIVE:      0.000  [kW]
INSTANTANEOUS_ACTIVE_POWER_L3_NEGATIVE:      0.177  [kW]
EQUIPMENT_IDENTIFIER_GAS:    4730303339303031373434313432303137 [None]
HOURLY_GAS_METER_READING:    9916.665   [m3] at 2022-01-27T11:00:04+01:00

yfands commented 2 years ago

thank you lowdef for your reply, but eh stupid question: how can we switch off CRC checking, no 'CRC switch' in configuration or so..

Regards Frank

lowdef commented 2 years ago

I do not use Home Assistant.

I used following code: (It shows that the parser can parse the telegram.)

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

from dsmr_parser import telegram_specifications
from dsmr_parser.objects import Telegram
from dsmr_parser.parsers import TelegramParser

TELEGRAM = r"""/ISK5\2M550T-1013
1-3:0.2.8(50)
0-0:1.0.0(220127110431W)
0-0:96.1.1(4530303534303037363432313534323230)
1-0:1.8.1(009418.807*kWh)
1-0:1.8.2(003309.321*kWh)
1-0:2.8.1(000581.835*kWh)
1-0:2.8.2(001332.223*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.196*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00005)
0-0:96.7.9(00003)
1-0:99.97.0(1)(0-0:96.7.19)(200421120530S)(0000000939*s)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00001)
1-0:52.36.0(00001)
1-0:72.36.0(00001)
0-0:96.13.0()
1-0:32.7.0(236.9*V)
1-0:52.7.0(235.9*V)
1-0:72.7.0(237.3*V)
1-0:31.7.0(002*A)
1-0:51.7.0(001*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.193*kW)
1-0:41.7.0(00.127*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(00.177*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303339303031373434313432303137)
0-1:24.2.1(220127110004W)(09916.665*m3)
!73A4"""

sample = TELEGRAM.replace('\n', '\r\n')

telegram_specification = telegram_specifications.V5
telegram_specification['checksum_support'] = False

parser = TelegramParser(telegram_specification)
telegram = Telegram(sample, parser, telegram_specification)

print(telegram)

ndokter commented 2 years ago

eavanvalkenburg your telegram seems to work. What serial settings are you using and have you tried different ones? Because i suspect it's related to the way the data is being read

Edit: sorry missed that lowdef checked the exact same thing, but i guess its double checked now

TELEGRAM = (
'/ISK5\\2M550T-1013\r\n'
'\r\n'
'1-3:0.2.8(50)\r\n'
'0-0:1.0.0(220127110431W)\r\n'
'0-0:96.1.1(4530303534303037363432313534323230)\r\n'
'1-0:1.8.1(009418.807*kWh)\r\n'
'1-0:1.8.2(003309.321*kWh)\r\n'
'1-0:2.8.1(000581.835*kWh)\r\n'
'1-0:2.8.2(001332.223*kWh)\r\n'
'0-0:96.14.0(0002)\r\n'
'1-0:1.7.0(00.196*kW)\r\n'
'1-0:2.7.0(00.000*kW)\r\n'
'0-0:96.7.21(00005)\r\n'
'0-0:96.7.9(00003)\r\n'
'1-0:99.97.0(1)(0-0:96.7.19)(200421120530S)(0000000939*s)\r\n'
'1-0:32.32.0(00000)\r\n'
'1-0:52.32.0(00000)\r\n'
'1-0:72.32.0(00000)\r\n'
'1-0:32.36.0(00001)\r\n'
'1-0:52.36.0(00001)\r\n'
'1-0:72.36.0(00001)\r\n'
'0-0:96.13.0()\r\n'
'1-0:32.7.0(236.9*V)\r\n'
'1-0:52.7.0(235.9*V)\r\n'
'1-0:72.7.0(237.3*V)\r\n'
'1-0:31.7.0(002*A)\r\n'
'1-0:51.7.0(001*A)\r\n'
'1-0:71.7.0(000*A)\r\n'
'1-0:21.7.0(00.193*kW)\r\n'
'1-0:41.7.0(00.127*kW)\r\n'
'1-0:61.7.0(00.000*kW)\r\n'
'1-0:22.7.0(00.000*kW)\r\n'
'1-0:42.7.0(00.000*kW)\r\n'
'1-0:62.7.0(00.177*kW)\r\n'
'0-1:24.1.0(003)\r\n'
'0-1:96.1.0(4730303339303031373434313432303137)\r\n'
'0-1:24.2.1(220127110004W)(09916.665*m3)\r\n'
'!73A4\r\n'
)

class TelegramParserTest(unittest.TestCase):
    def test_parse(self):
        parser = TelegramParser(telegram_specifications.V5)
        result = parser.parse(TELEGRAM)
        from pprint import pprint; pprint(result)

bubbamester commented 2 years ago

@ndokter

The Holley DTSD545 meter uses CRC-16/X25. The dsmr_parser code only has the CRC-16/something, maybe ARC (Polynomial: x^16 + x^15 + x^2 + 1 (0xa001)) calculation.

https://github.com/ndokter/dsmr_parser/blob/5c838efbe1826e2c3e717b065af34a562413d587/dsmr_parser/parsers.py#L100

Could X25 be put into dsmr_parser?

Thanks!

My Telegram:

/HLY5/D545-METER

1-3:0.2.8(50)
0-0:96.13.0(FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF/HLY5/D545-METER

1-3:0.2.8(50)
0-0:1.0.0(220203113815W)
1-0:1.8.0(00003668.743*kWh)
1-0:1.8.1(00001737.629*kWh)
1-0:1.8.2(00001931.114*kWh)
1-0:1.8.3(00000000.000*kWh)
1-0:1.8.4(00000000.000*kWh)
1-0:2.8.0(00003468.951*kWh)
1-0:2.8.1(00002533.342*kWh)
1-0:2.8.2(00000934.609*kWh)
1-0:2.8.3(00000000.000*kWh)
1-0:2.8.4(00000000.000*kWh)
1-0:3.8.0(00000019.368*kvarh)
1-0:4.8.1(00000680.772*kvarh)
1-0:5.8.0(00000012.272*kvarh)
1-0:6.8.0(00000007.096*kvarh)
1-0:7.8.0(00000425.904*kvarh)
1-0:8.8.0(00001025.518*kvarh)
1-0:15.8.0(00007137.694*kWh )
1-0:32.7.0(000238.20*V)
1-0:52.7.0(000229.60*V)
1-0:72.7.0(000233.00*V)
1-0:31.7.0(000004.71*A)
1-0:51.7.0(000004.56*A)
1-0:71.7.0(000004.96*A)
1-0:13.7.0(0.999)
1-0:33.7.0(1.000)
1-0:53.7.0(0.995)
1-0:73.7.0(1.000)
1-0:14.7.0(49.97*HZ)
1-0:1.7.0(0000.000*kW)
1-0:2.7.0(0003.310*kW)
1-0:5.7.0(0000.000*kvar)
1-0:6.7.0(0000.000*kvar)
1-0:7.7.0(0000.120*kvar)
1-0:8.7.0(0000.000*kvar)
0-0:42.0.0(0830812100004965)
0-0:96.1.0(0830812100004965)
0-0:96.14.0(01)
0-0:96.50.68(03)
0-0:17.0.0(00050.000)
1-31:4.0.0(00050.000)
1-51:4.0.0(00050.000)
1-71:4.0.0(00050.000)
0-0:98.1.0
(
0-0:1.0.0(220201000000T)
1-0:1.8.0(00003624.904*kWh)
1-0:1.8.1(00001705.795*kWh)
1-0:1.8.2(00001919.109*kWh)
1-0:2.8.0(00003445.867*kWh)
1-0:2.8.1(00002511.258*kWh)
1-0:2.8.2(00000934.609*kWh)
1-0:3.8.0(00000018.937*kVarh)
1-0:4.8.0(00001436.860*kVarh)
1-0:5.8.0(00000011.941*kVarh)
1-0:6.8.0(00000006.996*kVarh)
1-0:7.8.0(00000423.185*kVarh)
1-0:8.8.0(00001013.675*kVarh)
1-0:15.8.0(00007070.771*kwh  )
1-0:1.6.0(004.852*kW)
1-0:1.6.1(004.852*kW)
1-0:1.6.2(004.736*kW)
1-0:2.6.0(003.940*kW)
1-0:2.6.1(003.680*kW)
1-0:2.6.2(003.940*kW)
)
!420B

bucovaina commented 1 year ago

I have this issue when some other process is also trying to use the same /dev/ttyUSB0. I had home assistant running with Portainer as a test. It was configured to use /dev/ttyUSB0. Then at the same time I read DSMR data using a python script also using /dev/ttyUSB0. Roughly 33% of the datagrams come through then.

jpm-wilmes commented 1 year ago

Has the problem eventually been solved? I have the same issue (installation last week). I get all the data I needed despite the many telegram errors. I would assume there's a solution now.

Mosakopter commented 1 year ago

Same problem here: Using HomeAssistant (latest version 2023.3.5), hasos 9.5 running on a raspberry Pi 3B. Meter: Sagemcom, type = T210-D (Enexis), 3-fase, protocol=ESMR5.0, connected from the P1 port via a FTDI USB cable to the Pi. The DSMR integration in HomeAssistant seems to work fine, however the log is flooded (around 9000 lines per day) with CRC mismatch. Not sure since when this happened...

Here is a telegram (captured from the DSMR integration debug in HomeAssistant) which generated a "CRC mismatch warning" (note: the last line in the telegram mentions hex code F780 which is 63360 decimal):

2023-03-21 14:30:04.618 DEBUG (MainThread) [dsmr_parser.clients.protocol] got telegram:

/Ene5\T210-D ESMR5.0

1-3:0.2.8(50)
0-0:1.0.0(230321142950W)
0-0:96.1.1(4530303438303030303331343332353139)
1-0:1.8.1(010318.949*kWh)
1-0:1.8.2(009758.604*kWh)
1-0:2.8.1(000000.097*kWh)
1-0:2.8.2(000000.001*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(02.536*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00111)
0-0:96.7.9(00006)
1-0:99.97.0(1)(0-0:96.7.19)(210401135542S)(0000020946*s)
1-0:32.32.0(00003)
1-0:52.32.0(00004)
1-0:72.32.0(00003)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0()
1-0:32.7.0(231.0*V)
1-0:52.7.0(230 .0*V)
1-0:72.7.0(234.0*V)
1-0:31.7.0(000*A)
1-0:51.7.0(009*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.166*kW)
1-0:41.7.0(02.291*kW)
1-0:61.7.0(00.078*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)
0-1:24.1.0(003)
0-1:96.1.0(473031:24.2.1(230321142500W)(02410.285*m3)
!F780

2023-03-21 14:30:04.626 WARNING (MainThread) [dsmr_parser.clients.protocol] Invalid telegram. The CRC checksum '57986' does not match the expected '63360'

bucovaina commented 1 year ago

For me it was my own fault. I had home assistant running in a venv AND in portainer as a docker container. Both were configured to access /dev/ttyUSB0 which resulted in CRC checksum errors ~50% of the time/frames.

I simply forgot about the portainer instance, hence it took me some time. After shutting down the portainer container, all was instantly well.

Mosakopter commented 1 year ago

I discovered something unexpected: have a close look at my previous posted telegram and look at the line with voltage phase2: (230 .0*V) <- there is an extra space ? Nevermind: I found another failed Telegram, this time I see no unexpected spaces:

2023-03-21 14:29:48.621 DEBUG (MainThread) [dsmr_parser.clients.protocol] got telegram:

/Ene5\T210-D ESMR5.0

1-3:0.2.8(50)
0-0:1.0.0(230321142934W)
0-0:96.1.1(4530303438303030303331343332353139)
1-0:1.8.1(010318.949*kWh)
1-0:1.8.2(009758.593*kWh)
1-0:2.8.1(000000.097*kWh)
1-0:2.8.2(000000.001*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(02.541*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00006)
1-0:99.97.0(1)(0-0:96.7.19)(210401135542S)(0000020946*s)
1-0:32.32.0(00003)
1-0:52.32.0(00004)
1-0:72.32.0(00003)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0()
1-0:32.7.0(230.0*V)
1-0:52.7.0(231.0*V)
1-0:72.7.0(234.0*V)
1-0:31.7.0(000*A)
1-0:51.7.0(009*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.163*kW)
1-0:41.7.0(02.300*kW)
1-0:61.7.0(00.078*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)
0-1:24.1.0(003)
0-1:96.1.0(4730303732303033393333353138383139)
0-1:24.2.1(230321142500W)(02410.285*m3)
!20A4

2023-03-21 14:29:48.634 WARNING (MainThread) [dsmr_parser.clients.protocol] Invalid telegram. The CRC checksum '61920' does not match the expected '8356'

note: hex 20A4 (last line of telegram) = 8356 decimal

ndokter commented 1 year ago

I want to add that i have home assistant running successfully for about a year now, but i get a lot of errors as well. So maybe the connection just isn't 100% reliable as it's trying to output and parse 1 telegram per second. Or maybe my RPI 3b can't always keep up. I don't know

afbeelding

9000 errors a day seems like too much. Maybe the hardware can't keep up or like someone mentioned that 2 processes are fighting for control over the serial port

Mosakopter commented 1 year ago

1304 occurrences over 2 months is something I could live with. I have the config of my DSMR integration in HomeAssistant set at 10 seconds interval update which is fast enough for me. But this did not help. I assume this interval is only towards refreshing entities in Home Assistant. Is there a way to increase the delay between telegrams from 1 sec to every 10 seconds coming from the P1 port?

ndokter commented 1 year ago

I dont believe its possible to change the meter output.

Maybe theres a way for the library to only parse every 10th telegram or so. The TelegramBuffer or some other place could help with that. I believe the HA implementation uses async i think, so not sure how to do that

Mosakopter commented 1 year ago

The OP (yfands) is using a Raspberry Pi4 and also mentions thousands of these messages per day... I am not yet giving up on my Pi3b ;)

bucovaina commented 1 year ago

@Mosakopter : I'd be really surprised if it turns out it's not fast enough to parse the DSMR messages.

Mosakopter commented 1 year ago

Today I discovered that roughly 10% of all telegrams generate this checksum error, which means that 90% of all telegrams are parsed as valid. I have no clue how to investigate further... I have some experience in Python, C++ but it was a long time ago. I am thinking of forking the dsmr_parser for testing purposes and play around with the CRC checksum and I also want to analyse the raw telegrams to see if there is a problem with the incoming data. What is a good starting point, which documentation should I read first?

Mosakopter commented 1 year ago

For the HomeAssistant users that have a similar issue with a lot of these CRC mismatch warnings in their logbook: there is a way to ignore these warnings. Add this to configuration.yaml and restart HomeAssistant:

logger:
  default: info
  logs:
    dsmr_parser: error

The above will tell the logger to keep logging all info messages and up; but for the dsmr_parser in particular: only level "error" and up. This way you will still receive error, cricital and fatal messages coming from the dsmr_parser, but the thousands of CRC warning messages in your logbook are gone. In my case the energy dashboard currently works fine, since 90% of all telegrams are valid. Mind that with a 1 second interval, which most DSMR5.0 meters produce nowadays, your HomeAssistant receives over 86.000 telegrams a day (60x60x24). You can find documentation about the Home Assistant logger; here.

However, I still want to find out why 10% of them fail on the CRC check in my setup. This can be anything from a bad FTDI cable, to a problem in my Raspberry Pi 3b. I need some time to investigate this by setting up a new HomeAssistant instance on my Macbook Air so I can hook up my laptop to the FTDI USB cable and start debugging. Meanwhile my logbook is more quiet and I sleep better ;)

WJ4IoT commented 1 year ago

Experienced more or less the same due to double a DSMR reading; was running DSMR flawlessly in (dockered) Openhab. Installed (dockered) Home assistant on the same device (NUC i5) and could also install DSMR; received here just 1 telegram after that it was failing (Invalid telegram; CRC checksum on roundish 4 seconds interval in log). Openhab continued without a problem receiving till....... (Here comes the slightly important part)

The meter switched from high to low tariff and the DSMR-bridge in Openhab broke. Think the conclusion so far is: 1 so good, 2 is to much.

gaborvar commented 11 months ago

If you wish to experiment with the error rate issue you are welcome to https://github.com/gaborvar/P1_DSMR. In my case it is probably related to electromagnetic noise as stormy weather increases error rate. In normal weather the pattern of error rate suggests human operated noise source in the neighborhood. I found that vast majority of errors do not occur during valuable data transmission but during the silence between or within telegrams which confuses parsers where the content starts. I guess the Open Collector output is more prone to error than other serial technologies. Luckily such errors can easily be corrected. I implemented simple error correction code for telegrams with CRC failure. Currently 0.1 percent of telegrams remain faulty, down from 30% earlier. My electronics is not yet optimised (to say the least) for noise. If further error correction is warranted then there are several methods I considered but not yet implemented.

dupondje commented 8 months ago

This seems to happen when there is some 'packetloss' on the line when receiving telegrams. Most of them are fine, but when the connection breaks, or something doesn't get send correctly, you receive (correctly) a checksum error. This seems not something that is caused by dsmr_parser itself.

ndokter / dsmr_parser

Invalid telegram. The CRC checksum '17805' does not match the expected '12832' #91

System Health