serial errors after x minutes

[garageboxnv]

I use the stream server on esphome to readout the dsmr meter and monitor my water usage with an inductive sensor. The stream server is hooked up to the dsmr reader docker what I use for logging my electricity consumption

However since I updated to esphome 2023.2 I get many CRC errors on the dsmr communication I'm not exactly sure if it is caused by the updated esphome or if by updating the firmware I also updated the stream-server

After some debugging I found that the first x minutes after a reflash/reboot the crc errors do not appear, after ~10 minutes they start to appear.

I also tried the update to esphome 2023.3 but this did not fix the problem

`api: logger: level: NONE baud_rate: 0 ota:

external_components: source: github://oxan/esphome-stream-server

uart:

• rx_pin: RX baud_rate: 115200 id: p1_bus rx_buffer_size: 1700

stream_server: uart_id: p1_bus port: 8088`

[LZ7AA]

Hi garageboxnv, can you provide short capture of the stream, one clean (taken during first few minutes) and second with CRC errors? I might not be able to help solve your issue, but we may gather more information to properly diagnose and narrow down the problem. I discovered the latest stream-server probably suffers from buffer overrun or mishandling. This could be caused by hardware MCU overload (more compute heavy libraries) or some bug or bad logic in the algorithm. And in my case this becomes evident by analyzing the output stream.

[garageboxnv]

dsmr_datalogger.log

I attached the logging of the dsmrreader component, the first telegrams of the fine are fine, the last are having errors due to insertion/adaptation of characters

[LZ7AA]

I see your log looks very similar to what I have. This leads me to think the root cause might be the same. At a first glance it looks like baudrate mismatch or insufficient voltage level on the RX pin or heavy noise on the RX line. In my case I have portions of the log which are similar to yours - full of NUL and garbage characters, but I also have portions like this one:

H, , Й€)о74ad3fe26ed","ttl":8000,"type":"alive"} Й€ЮоTION:http://[fe80::962a:2140:3fd2:8c55]:40000/device.xml NT:upnp:rootdevice USN:UUID:D08C54D7-0EE0-4FF3-9BAB-02EA9EE6DF51::upnp:rootdevice

which are not garbage noise but text from some other memory range not belonging to stream buffer. We definitely need help from the developers...

[garageboxnv]

In the mean time, as experiment switched to the core dsmr compenent as test, this runs fine for a day now

I use this a test, hopefully can switch back as now my dsmrreader is not recording data anymore

[oxan]

but text from some other memory range not belonging to stream buffer.

That's suspicious and should never happen, but I don't see any immediate obvious cause. Let me see if I can reproduce this (many of these issues seem to trigger with a DSMR reader for some reason, but I don't have one, so I need to rig up some artifical test case).

[oxan]

Does this happen on an ESP32 or ESP8266?

[LZ7AA]

Hi oxan, with regard to issue #32 it is ESP8266 NodeMCU. I can arrange access to my setup for live debugging if you prefer to have a quick glance at the issue. Just let me know. I noticed how to brake it quickly - just disconnect from the TCP server and reconnect, while the UART is connected and sending data.

[oxan]

@garageboxnv @LZ7AA Could you try #36?

external_components:
  - source: github://oxan/esphome-stream-server@esp8266-disconnects

[garageboxnv]

Does this happen on an ESP32 or ESP8266?

I have this running on a nodemcu esp8266

[garageboxnv]

@garageboxnv @LZ7AA Could you try #36?

external_components:
  - source: github://oxan/esphome-stream-server@esp8266-disconnects

Tried to test but realized that I am unable to connect as mentioned in #37

[garageboxnv]

After manual adding solution #37 the crc errors on the dsmr_datalogger or not appearing Running for 1 hour now

[oxan]

I've merged #37 so this should be resolved now; feel free to reopen if you still discover any problems.

[garageboxnv]

Thx running still fine after 1 day