core: DSMR sensor no longer updating

The problem

After a random time the DSMR sensors stops updating.

Environment

  • Home Assistant Core release with the issue:
    0.115.3

  • Last working Home Assistant Core release (if known):
    Issue existed in 0.114, didn’t have dsmr reader in earlier versions (had to problem since installing it)

  • Operating environment (OS/Container/Supervised/Core): Hass.io on VMWare

  • Integration causing this issue:
    DSMR

  • Link to integration documentation on our website:
    https://www.home-assistant.io/integrations/dsmr

Problem-relevant configuration.yaml

  - platform: dsmr
    host: 192.168.178.77
    port: 23
    dsmr_version: 5
    reconnect_interval: 30

recorder:
  exclude:
      entities:
          - sensor.energy_consumption_tarif_1
          - sensor.energy_consumption_tarif_2
          - sensor.energy_production_tarif_1
          - sensor.energy_production_tarif_2
          - sensor.gas_consumption
          - sensor.power_consumption

Traceback/Error logs


home-assistant - dsmr debug.log DSMR frozen

Additional information

Restarting home assistant resolved the issue, as does a integration reload. Problem returns after a certain time, can be 10 seconds, can be 3 hours.

If sensor is fronzen, telegram can be read from the web-ui as well as telnet client.

Losing connection to the DSMR reader seems to be related:

  • Physically disconnecting and reconnecthing the DSMR reader causes the same issue.
  • So does a WiFi reset on the DSMR reader.
  • Perhaps the random lose of connection can be explained by unstable WiFi?

Added my (redacted) logfile. It shows the final message recieved from the DSMR parser. Then I left the next message (Waze sensor) in as it just seems to stop without logging a reason or error.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 82 (29 by maintainers)

Most upvoted comments

Hey I just wanted to drop by and report my “solution”, which is actually a workaround, that seems to be working:

So I’ve made the following addition to my configuration.yaml:

rest_command:
  reload_dsmr:
    url: !secret dsmr_reload_url
    method: POST
    headers:
      authorization: !secret rest_token

For this I’ve set up the following parts in my secrets.yaml This requires 1: navigate to \homeassistant.local\config.storage\core.config_entries and grab the entry_id for the DSMR integration 2: a long term token for the RESTfull command (set it up in your profile using the ui)

insert the values from 1 and 2 in the below:

dsmr_reload_url:  'https://myfullhomeassistanturl.duckdns.org:8123/api/config/config_entries/entry/insert_config_id_of_dsmr_integration/reload'

rest_token: Bearer insert_a_long_term_token_here

Last I made a automation that is run every minute, it checks if the sensor has not been updated and if so, restarts the integration. As I have a DSMR version 5, it normally sends updates every second. So no data for 30 seconds means its dead.

- id: ''
  alias: Reconnect the DSMR
  description: ''
  trigger:
  - platform: time_pattern
    minutes: /1
  condition:
  - condition: template
    value_template: '{{ relative_time(states.sensor.power_consumption.last_updated
      | timestamp_local) > ''30'' }}'
  action:
  - service: rest_command.reload_dsmr
    data: {}

Hey I just wanted to drop by and report my “solution”, which is actually a workaround, that seems to be working:

So I’ve made the following addition to my configuration.yaml:

rest_command:
  reload_dsmr:
    url: !secret dsmr_reload_url
    method: POST
    headers:
      authorization: !secret rest_token

For this I’ve set up the following parts in my secrets.yaml This requires 1: navigate to \homeassistant.local\config.storage\core.config_entries and grab the entry_id for the DSMR integration 2: a long term token for the RESTfull command (set it up in your profile using the ui)

insert the values from 1 and 2 in the below:

dsmr_reload_url:  'https://myfullhomeassistanturl.duckdns.org:8123/api/config/config_entries/entry/insert_config_id_of_dsmr_integration/reload'

rest_token: Bearer insert_a_long_term_token_here

Last I made a automation that is run every minute, it checks if the sensor has not been updated and if so, restarts the integration. As I have a DSMR version 5, it normally sends updates every second. So no data for 30 seconds means its dead.

- id: ''
  alias: Reconnect the DSMR
  description: ''
  trigger:
  - platform: time_pattern
    minutes: /1
  condition:
  - condition: template
    value_template: '{{ relative_time(states.sensor.power_consumption.last_updated
      | timestamp_local) > ''30'' }}'
  action:
  - service: rest_command.reload_dsmr
    data: {}

Adding to this, it does not quite work as expected. the relative_time function returns a string consisting of a number followed by " seconds". This causes unexpected behaviour when comparing to “30”. In fact, the automation will execute when the last update is longer than 10 seconds.

I added my automation below, it should be correctly comparing integers and therefore work on slower update rates.

alias: Reconnect the DSMR
description: ''
trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: template
    value_template: >-
      {{ (as_timestamp(now()) -
      as_timestamp(states.sensor.power_consumption.last_updated)) |
      int > 120 }}
action:
  - service: rest_command.reload_dsmr
    data: {}
mode: single

Looks good to me. Will you open a PR on the dsmr_parser repo?

Done (pull request #73)

@hogend That’s plain simple. I agree, with only waiting for data and not sending, it’ll never run in socket timeouts.

@mjkl-gh If we can get that code pushed to the lib, that’s a quite simple and elegant solution (only 10 or so lines of code).

It’s another issue as described here, you are using serial connection. The issue described here is detecting ungraceful disconnect from a TCP/IP connection.

I am a bit late to the show, but I had exactly this problem, which I solved in DSMR_parser/clients/protocol.py. It is fairly easy to set a receive time-out there (patch available if requested). Since the client is listen-only, it will never be able to detect an improper disconnect and keep listening on, essentially, a dead socket. The DSMR sender side, however, will detect the disconnect when it tries to send a new message and happily open a new socket. Since the sender is quite chatty, I set the receive time-out to 60s.

@RobBie1221 I understand, got the same issue. I got a wired (Ethernet) p1 reader which prevents me from long term testing. I am designing a active splitter to connect two reader on one meter, yet that’s a long term project 😅

My Ethernet P1 reader: image

@zuidwijk Thanks (again) for the offer 😃 I preferred investigating other options because this unit would require me to uncouple my own P1 cable, which I rather not do.

It’s also not necessary. I’m able to reproduce the issue. I have Home Assistant running in a Ubuntu VM and a small daemon on the Windows host. What does work is if I kill the daemon, that is detected by the integration. What triggers the hangup is if I cut the network to the VM (which kind of would be similar to a WiFi hickup). In this case, the disconnect is not detected (I’ve waited about 30 minutes after which it still does not work) and updates are stopped until a manual reset is triggered.

Sorry for the confusion. I suggest to update the problem description in first message, because in there it mentions ‘DSMR Reader’ as integration.

It’s not pretty, but I’m pretty happy. Before it was sending me a notification and I was manually reloading it 20 times a day. Trust me, that gets boring really quickly.

No the external power made no difference. I still think its my WiFi connection / router that triggers the problem in the first place.

I’m back to the core integration so if a solution ever becomes available…

Thanks for you effort so far, and thank you @zuidwijk for your assistance as well.

@RobBie1221 he is using my P1 module. This is a Wemos D1 mini with an add-on which is nothing more than a logic inverter and power stabiliser. On the Wemos is esp-link installed which sends the telegrams through telnet.

These issues doesn’t occur when using dsmr-reader (v4.1 and higher). There is the option to connect via web socket and works flawless. Even when the connection drops, it reconnects within a few seconds when the connection is re-established.

In Home Assistant, when the connections is dropped, it won’t reconnect. The Wemos/esp is sending telegrams, you can see them in the uConsole of esp-link and if you telnet to the Wemos/esp. When restarting Home Assistant, it starts work again.

Now I’m not able to test it myself as I’m using an ethernet module and don’t want gaps in my dsmr-reader logging.

The modules are described on my website: https://www.zuidwijk.com/p1-modules/

If you want, I can send you a wifi p1 module so you can test it yourself if you want.