search

esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 36 forks source link

ESPHome 2024.5.0 + D1 Mini + LD2410 = The connection dropped immediately after encrypted hello #5790

Closed stickpin closed 5 months ago

stickpin commented 5 months ago

The problem

The issue starts to happen after upgrading to ESPHome 2024.5.0. My LD2410 presence sensors are working fine with version 2024.4.2.

The firmware compilation log is attached: logs_bedroom-presence-sensor_run.txt

I will try to rollback now and see if i will be able to recover the sensors.

Which version of ESPHome has the issue?

2024.5.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2024.5.3

What platform are you using?

ESP8266

Board

D1 Mini (https://www.amazon.de/-/en/gp/product/B0754W6Z2F/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1)

Component causing the issue

No response

Example YAML snippet

esphome:
  name: kitchen-presence-sensor
  friendly_name: Kitchen Presence Sensor

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "key"

ota:
  password: "password"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Kitchen-Presence-Sensor"
    password: "password"

captive_portal:

uart:
  id: uart_bus
  tx_pin: GPIO01
  rx_pin: GPIO03
  baud_rate: 256000
  parity: NONE
  stop_bits: 1

ld2410:

binary_sensor:
  - platform: ld2410
    has_target:
      name: Presence
    has_moving_target:
      name: Moving Target
    has_still_target:
      name: Still Target

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    id: wifi_signal_sensor
    update_interval: 60s
  - platform: ld2410
    moving_distance:
      name : Moving Distance
    still_distance:
      name: Still Distance
    moving_energy:
      name: Move Energy
    still_energy:
      name: Still Energy
    detection_distance:
      name: Detection Distance
    g0:
      move_energy:
        name: g0 move energy
      still_energy:
        name: g0 still energy
    g1:
      move_energy:
        name: g1 move energy
      still_energy:
        name: g1 still energy
    g2:
      move_energy:
        name: g2 move energy
      still_energy:
        name: g2 still energy
    g3:
      move_energy:
        name: g3 move energy
      still_energy:
        name: g3 still energy
    g4:
      move_energy:
        name: g4 move energy
      still_energy:
        name: g4 still energy
    g5:
      move_energy:
        name: g5 move energy
      still_energy:
        name: g5 still energy
    g6:
      move_energy:
        name: g6 move energy
      still_energy:
        name: g6 still energy
    g7:
      move_energy:
        name: g7 move energy
      still_energy:
        name: g7 still energy
    g8:
      move_energy:
        name: g8 move energy
      still_energy:
        name: g8 still energy

switch:
  - platform: ld2410
    engineering_mode:
      name: "engineering mode"

number:
  - platform: ld2410
    timeout:
      name: timeout
    max_move_distance_gate:
      name: max move distance gate
    max_still_distance_gate:
      name: max still distance gate
    g0:
      move_threshold:
        name: g0 move threshold
      still_threshold:
        name: g0 still threshold
    g1:
      move_threshold:
        name: g1 move threshold
      still_threshold:
        name: g1 still threshold
    g2:
      move_threshold:
        name: g2 move threshold
      still_threshold:
        name: g2 still threshold
    g3:
      move_threshold:
        name: g3 move threshold
      still_threshold:
        name: g3 still threshold
    g4:
      move_threshold:
        name: g4 move threshold
      still_threshold:
        name: g4 still threshold
    g5:
      move_threshold:
        name: g5 move threshold
      still_threshold:
        name: g5 still threshold
    g6:
      move_threshold:
        name: g6 move threshold
      still_threshold:
        name: g6 still threshold
    g7:
      move_threshold:
        name: g7 move threshold
      still_threshold:
        name: g7 still threshold
    g8:
      move_threshold:
        name: g8 move threshold
      still_threshold:
        name: g8 still threshold

button:
  - platform: ld2410
    factory_reset:
      name: "factory reset"
    restart:
      name: "restart"
    query_params:
      name: query params
  - platform: restart
    name: "Restart"

text_sensor:
  - platform: ld2410
    version:
      name: "firmware version"

select:
  - platform: ld2410
    distance_resolution:
      name: "distance resolution"
    baud_rate:
      name: "baud rate"

Anything in the logs that might be useful for us?

INFO ESPHome 2024.5.0
INFO Reading configuration /config/esphome/kitchen-presence-sensor.yaml...
INFO Starting log output from 10.10.10.154 using esphome API
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.003s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
WARNING Can't connect to ESPHome API for kitchen-presence-sensor @ 10.10.10.154: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0). (HandshakeAPIError)
INFO Trying to connect to kitchen-presence-sensor @ 10.10.10.154 in the background
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.003s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.005s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.004s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.004s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.007s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.005s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.004s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.003s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.005s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.004s
WARNING kitchen-presence-sensor @ 10.10.10.154: Connection error occurred: kitchen-presence-sensor @ 10.10.10.154: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).
INFO Successfully connected to kitchen-presence-sensor @ 10.10.10.154 in 0.004s

Additional information

No response

vasyna commented 5 months ago

disable encryption. This work with esphome 2024.5.0

stickpin commented 5 months ago

@vasyna I don't see any changes related to encryption in esphome 2024.5.0. Do you know why it's not working anymore?

vasyna commented 5 months ago

I can’t say, but the problem is only on devices paired with ESP8266 + LD

CEZ15 commented 5 months ago

Exact same fault here. I have multiple PIR sensors still functioning as intended, but every LD2410 on my network is failing with the same error. Also, seem to be unable to re-flash any of them.

stickpin commented 5 months ago

Disabling encryption doesn't help much.

WARNING bedroom-presence-sensor @ 10.10.10.152: Connection error occurred: [Errno 104] Connection reset by peer
INFO Processing unexpected disconnect from ESPHome API for bedroom-presence-sensor @ 10.10.10.152
WARNING Disconnected from API
INFO Successfully connected to bedroom-presence-sensor @ 10.10.10.152 in 0.003s
WARNING bedroom-presence-sensor @ 10.10.10.152: Connection error occurred: bedroom-presence-sensor @ 10.10.10.152: EOF received
WARNING Can't connect to ESPHome API for bedroom-presence-sensor @ 10.10.10.152: bedroom-presence-sensor @ 10.10.10.152: EOF received (SocketClosedAPIError)
INFO Trying to connect to bedroom-presence-sensor @ 10.10.10.152 in the background
INFO Successfully connected to bedroom-presence-sensor @ 10.10.10.152 in 0.003s
WARNING bedroom-presence-sensor @ 10.10.10.152: Connection error occurred: bedroom-presence-sensor @ 10.10.10.152: EOF received
INFO Successfully connected to bedroom-presence-sensor @ 10.10.10.152 in 0.006s
WARNING bedroom-presence-sensor @ 10.10.10.152: Connection error occurred: bedroom-presence-sensor @ 10.10.10.152: EOF received

It seems also that ESP itself crashes every few seconds:

64 bytes from 10.10.10.152: icmp_seq=88 ttl=255 time=1.802 ms
64 bytes from 10.10.10.152: icmp_seq=89 ttl=255 time=1.832 ms
Request timeout for icmp_seq 90
Request timeout for icmp_seq 91
Request timeout for icmp_seq 92
Request timeout for icmp_seq 93
Request timeout for icmp_seq 94
Request timeout for icmp_seq 95
Request timeout for icmp_seq 96
Request timeout for icmp_seq 97
Request timeout for icmp_seq 98
64 bytes from 10.10.10.152: icmp_seq=99 ttl=255 time=7.991 ms
64 bytes from 10.10.10.152: icmp_seq=100 ttl=255 time=4.053 ms
64 bytes from 10.10.10.152: icmp_seq=101 ttl=255 time=2.823 ms
64 bytes from 10.10.10.152: icmp_seq=102 ttl=255 time=2.566 ms
64 bytes from 10.10.10.152: icmp_seq=103 ttl=255 time=1.733 ms
64 bytes from 10.10.10.152: icmp_seq=104 ttl=255 time=3.615 ms
64 bytes from 10.10.10.152: icmp_seq=105 ttl=255 time=1.739 ms
64 bytes from 10.10.10.152: icmp_seq=106 ttl=255 time=7.335 ms
64 bytes from 10.10.10.152: icmp_seq=107 ttl=255 time=3.053 ms
64 bytes from 10.10.10.152: icmp_seq=108 ttl=255 time=1.981 ms
64 bytes from 10.10.10.152: icmp_seq=109 ttl=255 time=1.718 ms
64 bytes from 10.10.10.152: icmp_seq=110 ttl=255 time=2.065 ms
64 bytes from 10.10.10.152: icmp_seq=111 ttl=255 time=7.496 ms
64 bytes from 10.10.10.152: icmp_seq=112 ttl=255 time=1.872 ms
64 bytes from 10.10.10.152: icmp_seq=113 ttl=255 time=2.688 ms
64 bytes from 10.10.10.152: icmp_seq=114 ttl=255 time=17.936 ms
64 bytes from 10.10.10.152: icmp_seq=115 ttl=255 time=2.205 ms
64 bytes from 10.10.10.152: icmp_seq=116 ttl=255 time=7.058 ms
64 bytes from 10.10.10.152: icmp_seq=117 ttl=255 time=3.146 ms
64 bytes from 10.10.10.152: icmp_seq=118 ttl=255 time=3.399 ms
Request timeout for icmp_seq 119
Request timeout for icmp_seq 120
Request timeout for icmp_seq 121
Request timeout for icmp_seq 122
Request timeout for icmp_seq 123
Request timeout for icmp_seq 124
Request timeout for icmp_seq 125
Request timeout for icmp_seq 126
Request timeout for icmp_seq 127
64 bytes from 10.10.10.152: icmp_seq=128 ttl=255 time=22.357 ms
64 bytes from 10.10.10.152: icmp_seq=129 ttl=255 time=4.699 ms
64 bytes from 10.10.10.152: icmp_seq=130 ttl=255 time=7.547 ms
64 bytes from 10.10.10.152: icmp_seq=131 ttl=255 time=3.332 ms
64 bytes from 10.10.10.152: icmp_seq=132 ttl=255 time=9.029 ms
64 bytes from 10.10.10.152: icmp_seq=133 ttl=255 time=1.700 ms
64 bytes from 10.10.10.152: icmp_seq=134 ttl=255 time=28.088 ms
64 bytes from 10.10.10.152: icmp_seq=135 ttl=255 time=9.253 ms
64 bytes from 10.10.10.152: icmp_seq=136 ttl=255 time=9.000 ms
64 bytes from 10.10.10.152: icmp_seq=137 ttl=255 time=3.907 ms
64 bytes from 10.10.10.152: icmp_seq=138 ttl=255 time=13.005 ms
64 bytes from 10.10.10.152: icmp_seq=139 ttl=255 time=2.124 ms
64 bytes from 10.10.10.152: icmp_seq=140 ttl=255 time=5.171 ms
64 bytes from 10.10.10.152: icmp_seq=141 ttl=255 time=1.697 ms
64 bytes from 10.10.10.152: icmp_seq=142 ttl=255 time=2.213 ms
64 bytes from 10.10.10.152: icmp_seq=143 ttl=255 time=1.680 ms
64 bytes from 10.10.10.152: icmp_seq=144 ttl=255 time=48.704 ms
64 bytes from 10.10.10.152: icmp_seq=145 ttl=255 time=2.110 ms
Request timeout for icmp_seq 146
Request timeout for icmp_seq 147
Request timeout for icmp_seq 148
Request timeout for icmp_seq 149
Request timeout for icmp_seq 150
Request timeout for icmp_seq 151
Request timeout for icmp_seq 152
Request timeout for icmp_seq 153
Request timeout for icmp_seq 154
64 bytes from 10.10.10.152: icmp_seq=155 ttl=255 time=8.204 ms
64 bytes from 10.10.10.152: icmp_seq=156 ttl=255 time=3.114 ms
64 bytes from 10.10.10.152: icmp_seq=157 ttl=255 time=3.757 ms
64 bytes from 10.10.10.152: icmp_seq=158 ttl=255 time=6.943 ms
64 bytes from 10.10.10.152: icmp_seq=159 ttl=255 time=2.637 ms
64 bytes from 10.10.10.152: icmp_seq=160 ttl=255 time=20.420 ms
64 bytes from 10.10.10.152: icmp_seq=161 ttl=255 time=3.163 ms
64 bytes from 10.10.10.152: icmp_seq=162 ttl=255 time=1.991 ms
64 bytes from 10.10.10.152: icmp_seq=163 ttl=255 time=1.954 ms
64 bytes from 10.10.10.152: icmp_seq=164 ttl=255 time=1.977 ms
64 bytes from 10.10.10.152: icmp_seq=165 ttl=255 time=2.005 ms
stickpin commented 5 months ago

Exact same fault here. I have multiple PIR sensors still functioning as intended, but every LD2410 on my network is failing with the same error. Also, seem to be unable to re-flash any of them.

yes, I had to go and reflash it one by one with the cable to the previous fw.

CEZ15 commented 5 months ago

with

Does everything seem to work as intended after the reflash?

Did you have to make any other adjustments?

Sorry for the questions, I'm just getting more and more frustrated with it 😂

stickpin commented 5 months ago

@CEZ15 I did a rollback to ESPHome 2024.4.2 addon from HA backup and installed the firmware on top of the newer one. After that, everything is working as before.

KennoPa commented 5 months ago

ESP8266 + LD2410 : same issue, router shows ip up and running, as I disabled webui for the performance issues, I cannot access via Web server to confirm. I will wait a fix and will not revert esphome version.

MallocArray commented 5 months ago

I don't think it is specific to the LD2410, as others are seeing it without this, but still D1 Minis

benalexau commented 5 months ago

I had the same log messages and an unresponsive device after upgrading to 2024.5.0 on an m5Stack Atom Lite ESP32. To troubleshoot I used https://web.esphome.io/ to view the log. This revealed repeated reboots due to esphome assert failed: vQueueDelete queue.c:2140 (pxQueue). Based on this forum post I resolved the issue by disabling the ESP32 Improv service:

#esp32_improv:
#  authorizer: none
kdelios commented 5 months ago

I had similar behavior with LD1125H and ESP32. No encryption used. I had to revert esphome to 2024.4.2 and re-flash the devices (over the air). Problems fixed.

poudenes commented 5 months ago

Same issue with different board: Revert back and device is working again.

#########################################################
# Below all fixed settings for dressoir PCB
#########################################################
substitutions:
  devicename: meek-dressoir
  friendly: Diningroom
  friendly_switch_1: Dressoir
  friendly_switch_2: Balcony
  ip: 192.168.100.207
  neopixel: GPIO02 # (D4)
  touch_power: GPIO16 # (D0)
  gpio_touch1: GPIO14 # (D5)
  gpio_touch2: GPIO13 # (D7)
  gpio_relay1: GPIO05 # (D1)
  gpio_relay2: GPIO4 # (D2)
  gpio_relay3: GPIO15 # (D8)

#########################################################
# Everything below can be copy/paste without problem
#########################################################
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  reboot_timeout: 0s
  fast_connect: true
  output_power: 20.0
  manual_ip:
    static_ip: ${ip}
    gateway: 192.168.100.1
    subnet: 255.255.255.0
    dns1: 192.168.100.1
  ap:
    ssid: ${devicename}
    password: !secret password
    channel: 4

  on_disconnect:
    - light.turn_on:
        id: neopixel
        red: 1
        green: 1
        blue: 1

    - light.turn_on:
        id: neopixel
        effect: strobe

esphome:
  name: ${devicename}
  on_boot:
    priority: 600
    then:
      - switch.turn_off: touch_power
      - delay: 2s
      - switch.turn_on: touch_power
      - light.turn_on:
          id: neopixel
          red: 1
          green: 1
          blue: 1

esp8266:
  board: esp01_1m
  restore_from_flash: true

api:
  encryption:
    key: !secret api_key
  reboot_timeout: 15min

  on_client_connected:
    - light.turn_on:
        id: neopixel
        red: 1
        green: 1
        blue: 1

    - light.turn_on:
        id: neopixel
        effect: strobe

    - delay: 5s

    - light.turn_on:
        id: neopixel
        effect: none

    - light.turn_on:
        id: neopixel
        red: 1
        green: 0
        blue: 0
        brightness: 100%

    - delay: 5s

    - homeassistant.service:
        service: persistent_notification.create
        data:
          title: "HA - Notification"
          message: "Meek ${friendly} connected again"
          notification_id: "Meek ${friendly}"

time:
  - platform: homeassistant
    id: homeassistant_time

captive_portal:

web_server:
  port: 80

preferences:
  flash_write_interval: 1min

logger:
  level: INFO

ota:
  safe_mode: true
  password: !secret password
  reboot_timeout: 0s

button:
  - platform: factory_reset
    name: "${friendly} - Reset"

switch:
  - platform: safe_mode
    name: "${friendly} - safe mode"
    id: "${friendly}_safe_mode"

sensor:
  - platform: wifi_signal
    id: "wifi_db_signal"
    name: "${friendly} - Wifi Signal"
    update_interval: 5min

  - platform: uptime
    name: "${friendly} - Uptime"
    update_interval: 5min

  - platform: template
    name: "${friendly} WiFi Percentage"
    id: wifi_percentage
    entity_category: diagnostic
    state_class: measurement
    update_interval: 10s
    unit_of_measurement: "%"
    accuracy_decimals: 0
    icon: mdi:wifi
    lambda: >
      auto signal = id(wifi_db_signal).state;
      float perc = 0;
      if (signal < -92.0) 
        perc = 100.0; 
      else if (signal > -21.0) 
        perc = 1.0; 
      else 
        perc = round(( -0.0154 * signal * signal )-( 0.3794 * signal ) + 98.182 );

      if(perc <= 0)
        return 0.0;
      else if(perc >= 100)
        return 100.0;
      else
        return perc;

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${friendly} - IP"
      icon: mdi:lan
    ssid:
      name: "${friendly} - SSID"
      icon: mdi:lan
    bssid:
      name: "${friendly} - BSSID"
      icon: mdi:lan
    mac_address:
      name: "${friendly} - MAC"
      icon: mdi:lan

  - platform: version
    name: "${friendly} - Version"
    hide_timestamp: true

light:
  - platform: neopixelbus
    default_transition_length: 0s
    type: GRB
    variant: 800KBPS
    pin: ${neopixel}
    num_leds: 2
    name: "${friendly_switch_1} - Neopixel All"
    restore_mode: RESTORE_DEFAULT_OFF
    id: neopixel
    effects:
      - strobe:
      - addressable_rainbow:
      - addressable_color_wipe:
      - addressable_scan:
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_flicker:
      - pulse:
          name: "Slow Pulse"
          update_interval: 1s

#########################################################
# Only needed when you use more then 1 neopixel
#########################################################
  - platform: partition
    name: "${friendly_switch_1} - neopixel"
    restore_mode: RESTORE_DEFAULT_OFF
    default_transition_length: 0s
    id: neopixel1
    segments:
      - id: neopixel
        from: 0
        to: 0
    effects:
      - strobe:
      - flicker:
      - addressable_rainbow:
      - addressable_color_wipe:
      - addressable_scan:
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_flicker:
      - pulse:
          name: "Slow Pulse"
          update_interval: 1s
      - addressable_lambda:
          name: "Green Pink"
          update_interval: 100ms
          lambda:
            static int state = 0;
            if (initial_run){
              state = 0;
              it.all() = ESPColor(0,255,0);
            } else {
              it.all() = ESPColor(255, 0, 127);
              if(state==0){
                int i = rand() % it.size();
                it[i] = ESPColor(0,255,0);
                state += 1;
              } else {
                state += 1;
                state = state % 10;
              }
            }

  - platform: partition
    name: "${friendly_switch_2} - neopixel"
    restore_mode: RESTORE_DEFAULT_OFF
    default_transition_length: 0s
    id: neopixel2
    segments:
      - id: neopixel
        from: 1
        to: 1
    effects:
      - strobe:
      - flicker:
      - addressable_rainbow:
      - addressable_color_wipe:
      - addressable_scan:
      - addressable_twinkle:
      - addressable_random_twinkle:
      - addressable_flicker:
      - pulse:
          name: "Slow Pulse"
          update_interval: 1s
      - addressable_lambda:
          name: "Green Pink"
          update_interval: 100ms
          lambda:
            static int state = 0;
            if (initial_run){
              state = 0;
              it.all() = ESPColor(0,255,0);
            } else {
              it.all() = ESPColor(255, 0, 127);
              if(state==0){
                int i = rand() % it.size();
                it[i] = ESPColor(0,255,0);
                state += 1;
              } else {
                state += 1;
                state = state % 10;
              }
            }

switch:
  - platform: gpio
    pin: ${touch_power}
    name: "${friendly} - Touch 1 power"
    icon: mdi:electric-switch
    id: touch_power

  - platform: template
    name: "${friendly_switch_1} - Light Switch"
    icon: mdi:nintendo-switch
    restore_mode: RESTORE_DEFAULT_OFF
    id: switch1
    optimistic: true

  - platform: template
    name: "${friendly_switch_1} - Switch longpress"
    restore_mode: RESTORE_DEFAULT_OFF
    id: switch_longpress1
    optimistic: true
    icon: mdi:nintendo-switch

  - platform: template
    name: "${friendly_switch_2} - Light Switch"
    icon: mdi:nintendo-switch
    restore_mode: RESTORE_DEFAULT_OFF
    id: switch2
    optimistic: true

  - platform: template
    name: "${friendly_switch_2} - Switch longpress"
    restore_mode: RESTORE_DEFAULT_OFF
    id: switch_longpress2
    optimistic: true
    icon: mdi:nintendo-switch

  - platform: gpio
    pin: ${gpio_relay1}
    name: "${friendly_switch_1} - Relay"
    icon: mdi:electric-switch

  - platform: gpio
    pin: ${gpio_relay2}
    name: "${friendly_switch_2} - Relay"
    icon: mdi:electric-switch

binary_sensor:
  - platform: gpio
    pin: ${gpio_touch1}
    name: "${friendly_switch_1} - Touch"
    icon: mdi:gesture-tap-button
    on_click:
      - min_length: 10ms
        max_length: 500ms
        then:
          - switch.toggle: switch1
      - min_length: 1000ms
        max_length: 2000ms
        then:
          - switch.toggle: switch_longpress1

  - platform: gpio
    pin: ${gpio_touch2}
    name: "${friendly_switch_2} - Touch"
    on_click:
      - min_length: 10ms
        max_length: 500ms
        then:
          - switch.toggle: switch2
      - min_length: 1000ms
        max_length: 2000ms
        then:
          - switch.toggle: switch_longpress2
KennoPa commented 5 months ago

I don't think it is specific to the LD2410, as others are seeing it without this, but still D1 Minis

Maybe but same board with cc1101 works fine and did not brake after update. Will wait for the fix

poudenes commented 5 months ago

maybe interesting. This is not the first time that a new update brick the connection/wifi etc. In 2023 I revert 2 or 3 times back to the version I used before the update. (To bad I don't remember the versions anymore)

GLSSoftware commented 5 months ago

Same problem here with Wemos D1 Mini. Reverted to 2024.4.2

Wheemer commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

CEZ15 commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

I found desoldering the RX / TX pins would then allow them to be flashed. Not sure why these pins being connected to sensors stop the device from allowing flashing, but at least you don't need to desolder the entire board

j-f-pinto commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

I found desoldering the RX / TX pins would then allow them to be flashed. Not sure why these pins being connected to sensors stop the device from allowing flashing, but at least you don't need to desolder the entire board

The ESP8266 only have one UART with TX and RX and it is use for flashing. If you have any device attached on those pins it will prevent the flashing.

It is also good practice to add on the Logger: section the command baud_rate: 0. This command disable the log mensagens on the serial port.

Wheemer commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

I found desoldering the RX / TX pins would then allow them to be flashed. Not sure why these pins being connected to sensors stop the device from allowing flashing, but at least you don't need to desolder the entire board

I just tried that and nothing, then I also unsoldered the 5v, still nothing...

Wheemer commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

I found desoldering the RX / TX pins would then allow them to be flashed. Not sure why these pins being connected to sensors stop the device from allowing flashing, but at least you don't need to desolder the entire board

The ESP8266 only have one UART with TX and RX and it is use for flashing. If you have any device attached on those pins it will prevent the flashing.

It is also good practice to add on the Logger: section the command baud_rate: 0. This command disable the log mensagens on the serial port.

Yes logger was already at 0.

j-f-pinto commented 5 months ago

Not sure how to revert the devices since I can't even connect to them. It just keep saying connecting when I try to flash the older version. Grounding d3 doesn't get them into flash mode. Seems I may have to unsolder all connections. What a royal PITA.

I found desoldering the RX / TX pins would then allow them to be flashed. Not sure why these pins being connected to sensors stop the device from allowing flashing, but at least you don't need to desolder the entire board

I just tried that and nothing, then I also unsoldered the 5v, still nothing...

Do you use GPIO0, GPIO2, GPIO12 and GPIO15 pins? Those pins could have influence on flashing processe.

tonertiffi commented 5 months ago

disable encryption. This work with esphome 2024.5.0

disable encryption. This work with esphome 2024.5.0

Don't feel alone here i have the same issue on only the LD2410 sensors connected to an esp8266 just about identical to yours, restored to a version before re flashed them and they working again

tonertiffi commented 5 months ago

will wait for a new version to see if that fixes it

ondoteam commented 5 months ago

Not only with LD sensors. I seeing same behavior with bme680 and not with the board using the LD

vazquezjm commented 5 months ago

Just come to say I'm experiencing the exact same issue but with a Wemos D1 mini and LD2410c

The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.0).

Logger baud rate set to 0:

# Enable logging
logger:
  level: DEBUG
  baud_rate: 0
toogooda commented 5 months ago

Yes also broke my D1 Mini presence sensors no idea how to revert back to an older version of esp home :(

vazquezjm commented 5 months ago

no idea how to revert back to an older version

Neither do I, but at least I was just testing

toogooda commented 5 months ago

Yes also broke my D1 Mini presence sensors no idea how to revert back to an older version of esp home :(

Actually it did an automatic backup when I upgraded and I was just now able to do the partial restore. All working now back on 2024.3.2 Settings->System->Backup

image

Mikescotland commented 5 months ago

Same problem here. Esp8266 and Ld2410, not working but connection OTA to flash works. This update disabled all my presence sensors. Wtf esphome?? Nothing listed in breaking changes..

vazquezjm commented 5 months ago

Settings->System->Backup

image

Thanks. Reverted to 2024.3.2 and now it is working again 👍

arhills commented 5 months ago

Same issues for me as well, reverted to previous version, unsoldered everything and flashed as a new device with usb cable, then flashed the previous yaml. All working fine again.

stoffies00711 commented 5 months ago

Same issues for me as well, reverted to previous version, unsoldered everything and flashed as a new device with usb cable, then flashed the previous yaml. All working fine again.

Exactly the same issue and restore as @arhills above. I used to update my esphome and devices all the time. I guess I'll hold back for while.

marky852 commented 5 months ago

I was running several D1 minis with the LH2410 nice and dandy on 2024.4.2. I upgraded and all hell broke loose. I flashed and reflashed, compiled and recompiled to no avail. The things wouldn’t stay connected. I was on the verge of seeing red, but I was able to go back to 2024.4.2 and all is well. My BME680 was acting weird to with the new upgrade. Had to retrograde that too.

stoffies00711 commented 5 months ago

Here is how I fixed mine to run on 2024.5.0 without having to revert back to the older version

I think the D1 Mini is just that... a "mini". I've always had timeout issues updating it and had to boot to safe-mode just get updates done.

I went through the yaml and hashed out everything except the necessary sensors I needed for my automations to work. Since I use the radartool app to calibrate the ld2410 via bluetooth anyways, I removed all the number and select inputs.
The D1mini now works with the new esphome 2024.5.0 update and updates upload within seconds without timeout. I honestly think that all the sensors, numbers and input selects were just too much for the d1. I will calibrate with the app if needed but have all sensors I need for now. Just leave the bluetooth control in place so that it can be enabled when calibration is needed.

Hope this helps

Below is the list of items I kept. ld2410

marky852 commented 5 months ago

IMG_7574

With ESPHome 2024.4.2 my D1 Mini is running flawlessly with all the bells and whistles and plus some.

The update was giving me connectivity issues.

AdrianGarside commented 5 months ago

I'm seeing something similar with 2024.4.2. I can flash perfectly fine OTA and it will connect fine post-flash and show logs. But as soon as I reboot it, it becomes inaccessible. All I can do at this point is do a reflash:

WARNING Can't connect to ESPHome API for esphome-web-1f07e0 @ 192.168.0.80: esphome-web-1f07e0 @ 192.168.0.80: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.4.2). (HandshakeAPIError)

What's especially weird is that I'm creating a 4th bluetooth repeater. The hardware and the configuration are identical to the other 3 I already have up and running and they are all working fine (and I reflashed them after I updated esphome to 2024.4.2).

Removing the encryption key (that the other 3 bluetooth proxy devices have) got me unblocked - it no longer becomes inaccessible after the first reboot. And HA can connect (albeit unencrypted).

saboaua commented 5 months ago

I have encountered the same issue with only my d1 mini's with LD2410C and the only solution at the moment is to revert to 2024.4.2 and flash one by one connected to the PC to get them working.

I tried deleting the encryption and reflashed, removed the device reinstalled it, and still not working correctly and the log doesn't work on 2024.5 when trying to look and the log for the LD2410C.

"Esphome Connection error occurred EOF received."

TomHBP commented 5 months ago

Also have this problem. D1 mini with LD2410B. I also have 3 LD2410's with the ESP-S2, and these seem to still be working. Restoring to 2024.4.2 did work, and I was still able to reflash OTA, and now it works again.

Mikescotland commented 5 months ago

It looks it's a problem with combination with ESP8266

On Sat, 18 May 2024, 20:00 TomHBP, @.***> wrote:

Also have this problem. D1 mini with LD2410B. I also have 3 LD2410's with the ESP-S2, and these seem to still be working.

— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5790#issuecomment-2118969643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNLFK2HBHAVQLZ6KWYP4KLZC6QORAVCNFSM6AAAAABHXYYO4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJYHE3DSNRUGM . You are receiving this because you commented.Message ID: @.***>

jlt24 commented 5 months ago

Exact same issue here with ld2410 and ESP8266 (not D1 mini). I was eventually able to reflash, I'm not sure what I did besides removing encryption, but it still doesn't work. ESP just keep crashing.

davebeckster commented 5 months ago

Ditto, same issues. Anyone working on it? Restoring backup didn't work for me.

freddujour commented 5 months ago

Here is how I fixed mine to run on 2024.5.0 without having to revert back to the older version

I think the D1 Mini is just that... a "mini". I've always had timeout issues updating it and had to boot to safe-mode just get updates done.

I went through the yaml and hashed out everything except the necessary sensors I needed for my automations to work. Since I use the radartool app to calibrate the ld2410 via bluetooth anyways, I removed all the number and select inputs. The D1mini now works with the new esphome 2024.5.0 update and updates upload within seconds without timeout. I honestly think that all the sensors, numbers and input selects were just too much for the d1. I will calibrate with the app if needed but have all sensors I need for now. Just leave the bluetooth control in place so that it can be enabled when calibration is needed.

Hope this helps

Below is the list of items I kept. ld2410

Worked for me on D1_mini

stoffies00711 commented 5 months ago

https://github.com/esphome/issues/issues/5790#issuecomment-2118419138 The above is a temp fix. You can always enable the LD2410's other features again (if you need them) after the issue has been resolved. Only downside is that you might have to flash them via USB if you already updated. Personally, my sensors are much more responsive now.

playersct commented 5 months ago

This same problem Wemos D1 mini + LD2410B

addon in HA: 2024.4.2 firmware in Wemos D1 mini: 2024.4.2 status: work

addon in HA: 2024.5.0 firmware in Wemos D1 mini: 2024.4.2 status: work

addon in HA: 2024.5.0 firmware in Wemos D1 mini: 2024.5.0 status: error

TwardyBobek commented 5 months ago

This same problem Wemos D1 mini + LD2410B I'm waiting for new update

baldarn commented 5 months ago

This same problem Wemos D1 mini + LD2410B

Wheemer commented 5 months ago

There's a new update out with zero mention of this issue being resolved, disappointing.

Pimentoso commented 5 months ago

@stoffies00711 haven't tried your fix yet but sounds like a performance issue. What could it be in the last release that raised the computational load? Maybe the new event entities support? Also looks like most of the merged PRs are only tested against ESP32 boards. It's a shame since D1 minis are so widely used

stoffies00711 commented 5 months ago

@Pimentoso I agree. Over here the D1 mini is much cheaper and it works well. I own only two ESP32 boards which I bought to experiment with Bluetooth proxy. ESP8266 should be on top if the test-list. I'm guessing that 90% of the 'branded' flashable consumer devices worldwide are 8266 based. The devs are magicians in my eyes. I'm sure this issue is already on their snag-list to resolve.