DSMR Smart Meter stops working

Energy
1

Hello,

I’m running HA in a docker environment with DSMR smart meter integration succesfully for more then one year. But the last couple of weeks, DSMR stops receiving data from the P1 meter. Disabling & Enabling the DSMR service solves the issue, but after a couple of days no data is received again. Upgrading from 2024.11.1 to 2024.11.3 did not solve the issue.

I activated debug logging. Around 08:18h DSMR stopped receiving P1 data. The logging shows no errors, just no dsmr lines after the time the issue occured.

2024-12-01 08:18:52.501 DEBUG (MainThread) [dsmr_parser.clients.protocol] got telegram: /Ene5\T211 ESMR 5.0

1-3:0.2.8(50)
0-0:1.0.0(241201081938W)
0-0:96.1.1(4530303632303030303031353133353231)
1-0:1.8.1(005488.495kWh)
1-0:1.8.2(003131.645kWh)
1-0:2.8.1(002514.653kWh)
1-0:2.8.2(005930.684kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.552kW)
1-0:2.7.0(00.000kW)
0-0:96.7.21(00015)
0-0:96.7.9(00006)
1-0:99.97.0(1)(0-0:96.7.19)(231207082657W)(0000000569s)
1-0:32.32.0(00003)
1-0:52.32.0(00003)
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(225.0V)
1-0:52.7.0(226.0V)
1-0:72.7.0(224.0V)
1-0:31.7.0(001A)
1-0:51.7.0(000A)
1-0:71.7.0(000A)
1-0:21.7.0(00.400kW)
1-0:41.7.0(00.000kW)
1-0:61.7.0(00.152kW)
1-0:22.7.0(00.000kW)
1-0:42.7.0(00.000kW)
1-0:62.7.0(00.000kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303539303033383631393537343139)
0-1:24.2.1(241201081500W)(13899.638m3)
!ABEA

2024-12-01 08:18:53.455 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /Ene5\T211 ESMR 5.0

1-3:0.2.8(50)
0-0:1.0.0(241201081939W)
0-0:96.1.1(4530303632303030303031353133353231)
1-0:1.8.1(005488.495kWh)
1-0:1.8.2(003131.645kWh)
1-0:2.8.1(002514.653kWh)
1-0:2.8.2(005930.684kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.551kW)
1-0:2.7.0(00.000kW)
0-0:96.7.21(00015)
0-0:96.7.9(00006)
1-0:99.97.0(1)(0-0:96.7.19)(231207082657W)(0000000569s)
1-0:32.32.0(00003)
1-0:52.32.0(00003)
1-0:72.32.0(00003)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(0000
2024-12-01 08:18:53.503 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: 0)
0-0:96.13.0()
1-0:32.7.0(225.0V)
1-0:52.7.0(226.0V)
1-0:72.7.0(224.0V)
1-0:31.7.0(001A)
1-0:51.7.0(000A)
1-0:71.7.0(000A)
1-0:21.7.0(00.399kW)
1-0:41.7.0(00.000kW)
1-0:61.7.0(00.151kW)
1-0:22.7.0(00.000kW)
1-0:42.7.0(00.000kW)
1-0:62.7.0(00.000kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303539303033383631393537343139)
0-1:24.2.1(241201081500W)(13899.638m3)
!3AED

2024-12-01 08:18:53.503 DEBUG (MainThread) [dsmr_parser.clients.protocol] got telegram: /Ene5\T211 ESMR 5.0

1-3:0.2.8(50)
0-0:1.0.0(241201081939W)
0-0:96.1.1(4530303632303030303031353133353231)
1-0:1.8.1(005488.495kWh)
1-0:1.8.2(003131.645kWh)
1-0:2.8.1(002514.653kWh)
1-0:2.8.2(005930.684kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.551kW)
1-0:2.7.0(00.000kW)
0-0:96.7.21(00015)
0-0:96.7.9(00006)
1-0:99.97.0(1)(0-0:96.7.19)(231207082657W)(0000000569s)
1-0:32.32.0(00003)
1-0:52.32.0(00003)
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(225.0V)
1-0:52.7.0(226.0V)
1-0:72.7.0(224.0V)
1-0:31.7.0(001A)
1-0:51.7.0(000A)
1-0:71.7.0(000A)
1-0:21.7.0(00.399kW)
1-0:41.7.0(00.000kW)
1-0:61.7.0(00.151kW)
1-0:22.7.0(00.000kW)
1-0:42.7.0(00.000kW)
1-0:62.7.0(00.000kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303539303033383631393537343139)
0-1:24.2.1(241201081500W)(13899.638m3)
!3AED

2024-12-01 08:18:54.415 DEBUG (MainThread) [dsmr_parser.clients.protocol] received data: /Ene5\T211 ESMR 5.0

Can anyone help me to fix this?

Thank you in advance!!

2

No information can be found in dsmr debug logging. I found out P1 meter data collection is always stopped in the morning, see below. Is there any way to debug all HA actions?

2024-12-01 08:18:54
2024-12-03 07:34:45
2024-12-04 07:34:10
2024-12-06 07:49:30
2024-12-08 08:29:32

Thank you in advance!

3

Yesterdayevening shut down all containers and power down Raspberry PI4. Disconnect P1 meter. Boot Raspberry PI4 and all containers. Shut down all containers and power down Raspberry PI4 again. Reconnect P1 meter on same USB port. Boot Raspberry PI4 and all containers. No result, still P1 meter stops collecting, everytime around 08:00h.

2024-12-01 08:18:54
2024-12-03 07:34:45
2024-12-04 07:34:10
2024-12-06 07:49:30
2024-12-08 08:29:32
2024-12-12 07:49:41
2024-12-13 07:44:37

Can anybody help me out? I’m running out of options…

4

The P1 is just dumping out a very simple message, you can see the message for yourself using putty and the P1 to USB. Depending on your DSMR version you will to set:
4&5 - 115200 baud 8N1
3 - 9600 baud 7E1

This way you can first test if the P1 is spitting out a correct message all the time and if the P1 to USB cable is good. If it already goes wrong here; 99% its the cable, as the P1 signal is stupid simple and just spits the message out.

5

Thank you for your reply. I will test it, to check the dataintegrity stays correct.

6

Hi Dujith,

The last couple of weeks DSMR stops collecting energy data once of twice a day in Home Assistant. So I’m sure there is an issue at least once a day.

I connected the P1 meter to a stand alone laptop using putty. P1 is sending all energy data every 1 second. Started 27-12 at 16:25h, stopped at 30-12 at 06:50h. Output is not interrupted a single time. I guess this ‘proves’ the hardware is ok.

It resulted in a lot of data (194 Mb). I cannot find any anomalies, but I’m not sure, since the dataset is very big.

Got some idea’s for next steps?

Thank you in advance

Richard

7

It seems the issue is the USB passthrough in your docker setup.
So a bit more information on that will help.

8

Valid point!

I have set up Home Assistant in Docker on a Raspberry Pi 4 (Raspberry OS 64bit running of an ssd on usb). P1 is connected to /dev/ttyUSB0, ssd is connected to /dev/ttyUSB1

I configured passthrough for my zwave device to the zwave container (/dev/ttyAMA0:/dev/zwave). Never the usb passthrough for the P1 meter to HA container, because it always worked ‘straight out of the box’. Now I recreated the HA container with USB passthrough /dev/ttyUSB0:/dev/ttyUSB0.

I think, based on my limited knowledge, this could cause the issue. Everything is working fine now, fingers crossed to see if the issue is resolved.

Thank you for your help!

9

Unfortunately the issue is not resolved :disappointed_relieved:; 31-12-2024 07:14:39 DSMR stopped collecting energy data.

Below the syslog from RPI4

Dec 31 06:59:24 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.f2t1HI.mount: Succeeded.
Dec 31 07:01:24 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.BTQbmM.mount: Succeeded.
Dec 31 07:01:55 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.nipc0o.mount: Succeeded.
Dec 31 07:03:25 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.jlFzhe.mount: Succeeded.
Dec 31 07:04:26 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.GxU7yS.mount: Succeeded.
Dec 31 07:04:56 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.MVzxR2.mount: Succeeded.
Dec 31 07:05:26 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.UOfukw.mount: Succeeded.
Dec 31 07:05:34 RPI4Server NetworkManager[438]: [1735625134.9384] device (wlan0): set-hw-addr: set MAC address to E2:AB:D2:39:5D:2C (scanning)
Dec 31 07:05:34 RPI4Server kernel: [86321.902139] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Dec 31 07:06:27 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.3LbPhJ.mount: Succeeded.
Dec 31 07:07:02 RPI4Server rngd[493]: stats: bits received from HRNG source: 760064
Dec 31 07:07:02 RPI4Server rngd[493]: stats: bits sent to kernel pool: 719968
Dec 31 07:07:02 RPI4Server rngd[493]: stats: entropy added to kernel pool: 719968
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2 successes: 38
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2 failures: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2(2001-10-10) Poker: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2(2001-10-10) Runs: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2(2001-10-10) Long run: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: HRNG source speed: (min=361.335; avg=549.704; max=661.852)Kibits/s
Dec 31 07:07:02 RPI4Server rngd[493]: stats: FIPS tests speed: (min=24.022; avg=32.351; max=77.851)Mibits/s
Dec 31 07:07:02 RPI4Server rngd[493]: stats: Lowest ready-buffers level: 2
Dec 31 07:07:02 RPI4Server rngd[493]: stats: Entropy starvations: 0
Dec 31 07:07:02 RPI4Server rngd[493]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Dec 31 07:08:58 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.NIxwKY.mount: Succeeded.
Dec 31 07:11:29 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.DEoD7t.mount: Succeeded.
Dec 31 07:11:59 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.UCIQ66.mount: Succeeded.
Dec 31 07:12:28 RPI4Server NetworkManager[438]: [1735625548.9255] device (wlan0): set-hw-addr: set MAC address to 92:55:29:D2:2B:EF (scanning)
Dec 31 07:12:28 RPI4Server kernel: [86735.896730] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Dec 31 07:12:28 RPI4Server NetworkManager[438]: [1735625548.9494] device (wlan0): supplicant interface state: inactive → interface_disabled
Dec 31 07:12:28 RPI4Server NetworkManager[438]: [1735625548.9496] device (p2p-dev-wlan0): supplicant management interface state: inactive → interface_disabled
Dec 31 07:12:28 RPI4Server NetworkManager[438]: [1735625548.9500] device (wlan0): supplicant interface state: interface_disabled → inactive
Dec 31 07:12:28 RPI4Server NetworkManager[438]: [1735625548.9501] device (p2p-dev-wlan0): supplicant management interface state: interface_disabled → inactive
Dec 31 07:14:30 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.vCNLdy.mount: Succeeded.
Dec 31 07:15:00 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.xObvyN.mount: Succeeded.
Dec 31 07:17:01 RPI4Server CRON[158467]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Dec 31 07:17:01 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.LyuxsE.mount: Succeeded.
Dec 31 07:17:01 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.49KFaX.mount: Succeeded.
Dec 31 07:17:31 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.hESath.mount: Succeeded.
Dec 31 07:18:02 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.DZ3sJp.mount: Succeeded.
Dec 31 07:19:21 RPI4Server kernel: [87148.893540] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Dec 31 07:19:21 RPI4Server NetworkManager[438]: [1735625961.9160] device (wlan0): set-hw-addr: set MAC address to BA:48:91:A1:BD:CD (scanning)
Dec 31 07:19:21 RPI4Server NetworkManager[438]: [1735625961.9428] device (wlan0): supplicant interface state: inactive → disconnected
Dec 31 07:19:21 RPI4Server NetworkManager[438]: [1735625961.9430] device (p2p-dev-wlan0): supplicant management interface state: inactive → disconnected
Dec 31 07:19:21 RPI4Server NetworkManager[438]: [1735625961.9496] device (wlan0): supplicant interface state: disconnected → inactive
Dec 31 07:19:21 RPI4Server NetworkManager[438]: [1735625961.9497] device (p2p-dev-wlan0): supplicant management interface state: disconnected → inactive
Dec 31 07:20:33 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.5nwoHe.mount: Succeeded.
Dec 31 07:21:03 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.8dWzOU.mount: Succeeded.
Dec 31 07:21:33 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-2ff1082282d97b821a30c889dba30f79c3ad4389044e1a6beb201a92f285f7ce-runc.5oEoXQ.mount: Succeeded.
Dec 31 07:21:33 RPI4Server systemd[1]: run-docker-runtime\x2drunc-moby-83c377f77328137b7ba634687193ded0dc21d360a75a59ba20c6c39768e16727-runc.hHTSrp.mount: Succeeded.

I cannot find any entries regarding the HA container (07ce76b2d432) or USB :face_with_diagonal_mouth:

10

Anybody any idea’s? Energy collecting is now stopped minimal once a day; between 08:00 and 09:00 or between 21:00 and 22:00h. I cannot find any lead to investigate further.

Help is highly appreciated!!

11

I found dmesg errors linked to the issues

[Tue Dec 31 21:47:42 2024] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Tue Dec 31 21:47:42 2024] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Wed Jan 1 21:41:01 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Wed Jan 1 21:41:01 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Jan 4 08:17:04 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Jan 4 08:17:04 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Jan 4 21:45:05 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sat Jan 4 21:45:05 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sun Jan 5 21:21:15 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Jan 6 07:33:07 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Jan 6 21:31:08 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Mon Jan 6 21:31:08 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Tue Jan 7 21:56:09 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Wed Jan 8 07:22:10 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Wed Jan 8 21:33:11 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Wed Jan 8 21:33:11 2025] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

Anybody any idea how to investigate this?

Help is highly appreciated

12

Anybody???

13

I know its advised for usb devices to link the device and not the USB port.
So in my case for the P1 reader instead of:’

/dev/ttyUSB0

I use:

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A16BD3GG-if00-port0

I dont remember the exact reason, but i believe Linux could change the /dev/ttyUSB0 to something else thus breaking the connection.
I’m sure someone will chime in if thats incorrect tho :sweat_smile: