Closed stickpin closed 3 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
Yep, worked for me, my LD2410 + D1 mini combination is working again on ESPHome 2024.5.1 Of course this is temporary, waiting for a real fix.
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.
Hi,
Whats your code for the LD2410?
You'll see it's the standard setup. I just 'disabled' everything I didn't need. I recommend you keep the "control bluetooth" button in case you need to enable it, like I did, so the LD2410 can be discovered via the app.
When the issue with the D1 is resolved you can just remove all the '#' to enable all features again.
Hope it helps
esphome:
name: ensuite-sensor
friendly_name: ensuite-sensor
comment: Ensuite Presence Sensor
platform: ESP8266
board: d1_mini
logger:
baud_rate: 0
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Ensuite-Sensor Fallback"
password: !secret fallback_password
ota:
#web_server:
# port: 80
# version: 2
# include_internal: true
captive_portal:
api:
# services:
# - service: set_ld2410_bluetooth_password
# variables:
# password: string
# then:
# - bluetooth_password.set:
# id: ld2410_comp
# password: !lambda 'return password;'
uart:
id: ld2410_uart
tx_pin: TX
rx_pin: RX
baud_rate: 256000
parity: NONE
stop_bits: 1
ld2410:
uart_id: ld2410_uart
throttle: 1500ms
id: ld2410_comp
#select:
# - platform: ld2410
# distance_resolution:
# name: distance resolution
# baud_rate:
# name: baud rate
# light_function:
# name: light function
# out_pin_level:
# name: out pin level
button:
- platform: ld2410
factory_reset:
name: "LD2410 Factory Reset"
restart:
name: "LD2410 Restart"
# query_params:
# name: query params
#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
# light_threshold:
# name: light threshold
text_sensor:
- platform: ld2410
version:
name: "LD2410 Sensor Version"
mac_address:
name: "LD2410 Sensor MAC Address"
switch:
- platform: ld2410
# engineering_mode:
# name: "engineering mode"
bluetooth:
name: control Bluetooth
- platform: gpio
name: "Blue LED"
pin: GPIO2
id: board_led
inverted: true
- platform: safe_mode
name: Safe Mode Restart
entity_category: diagnostic
binary_sensor:
- platform: ld2410
has_target:
name: "presence"
has_moving_target:
name: "movement"
has_still_target:
name: "still"
# out_pin_presence_status:
# name: out pin presence status
# - platform: gpio
# pin: GPIO13
# id: notify_led
# name: gpio out pin presence
# device_class: presence
sensor:
- platform: ld2410
moving_distance:
name: "Moving distance (cm)"
still_distance:
name: "Still Distance (cm)"
moving_energy:
name: "Move Energy (%)"
still_energy:
name: "Still Energy (%)"
detection_distance:
name: "Distance Detection (cm)"
# 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
# light:
# name: light
- platform: wifi_signal
name: "RSSI"
id: sensor_rssi
update_interval: 300s
entity_category: "diagnostic"
# - platform: uptime
# name: "Uptime"
# id: sensor_uptime
# update_interval: 300s
# entity_category: "diagnostic"
thank you
I think the problem is the mini d1, I have another senor with a dfrobot SEN0395 and it does the same with the 2024.5.0 and with the latest 2024.5.1, on the dfrobot one if I remove the web_server and the http_request, it works, but it takes much longer that the 2024.4. I made bin files of the good 2024 firmware, and I will disable for this sensors the firmware lalue si even if I update the epshome, will not ask to update the firmware on this sensors.
Yes I must take back what I said about the D1 Mini. I have another variant of the board (Lolin or something) and I'm not very impressed with that one. I have 4 Wemos D1 minis and they are awesome.
Since it worked fine with the previous version 2024.4.2 it might be something completely different causing the communication issue. Someone suggested it was the API encryption, someone mentioned modbus with TX/RX pins... I'm just a consumer and do not have enough knowledge on the matter... `
I can no longer install anything to my 2410 D1Mini devices that are using the tx/rx pins. Neither by OTA or USB. Others have stated they had to unsolder from the rx/tx pins to install new firmware. Is that where we are at?? Disassembling our sensors to recover them? I hope I'm just having a "brain fart" and missing something.
On Mon, May 20, 2024 at 12:06 PM Werner @.***> wrote:
Yes I must take back what I said about the D1 Mini. I have another variant of the board (Lolin or something) and I'm not very impressed with that one. I have 4 Wemos D1 minis and they are awesome.
Since it worked fine with the previous version 2024.4.2 it might be something completely different causing the communication issue. Someone suggested it was the API encryption, someone mentioned modbus with TX/RX pins... I'm just a consumer and do not have enough knowledge on the matter... `
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5790#issuecomment-2121035241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN75WI65UQIAIBOQUT2PHYDZDJCSBAVCNFSM6AAAAABHXYYO4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGAZTKMRUGE . You are receiving this because you commented.Message ID: @.***>
Not sure if there is a better way, but unsoldering the pins works for me. PIA.
Same here... Kinda weird you would need to disabled encryption or a bunch of code to get it working again while there were no issues in the previous version
Same here... Kinda weird you would need to disabled encryption or a bunch of code to get it working again while there were no issues in the previous version
Im not that into the code. But first what I think: Memory issue. Not enough memory to store the code and run all the services.
you would think so indeed, but there are no changelogs of anything related on this version that could impact the memory increase on the D1 Mini.
I have 12: ESP-12 ESP8266MOD Wi-Fi Module soldered on a circuit board. They are my wall swiches. (I didn't create them) With latest ESPhome devices went offline. I had this already in past with some versions. Never found what it was. Because a new update later is working again. Beside that. There was a ESPHome version that bricked my whole network. None of the devices were able to connect router. At the end I had to reset my router at all.... (Asus GTAX-11000)
I always have for all my devices a local BIN file to revert back when needed. If a ESPhome version is working for at least 1 month without issues I replace the backup BIN files.
This latest version ESPhome again devices are gone....
that is a good thing to do indeed, maybe I should do the same before updating ESPHome next time... For now I just reverted back to the 2024.4 version which solved the issues for me and I will just hold off on updating the ESPHome add-on until I see it mentioned in the fixes
Two releases since they messed up the code and no fix, is anyone of importance actually checking on these issues reported?
It would seem there is no testing done before code changes are pushed out. Zero actual interaction here is very disconcerting.
same here after upgrading to esphome 24.5 coming from 24.3.2 but I am using an esp8266 nodemcu without sensors (only four buttons and a relay). I can revert using the backup created when I updated esphome within HA...
if needed, I can upload my yaml here, as there are no sensors or hardware needed to test, this could be useful?
ESP Crash as soon as it connects to HA API ESP8266 (Nodemcu) ESPHome 2024.5.2 refrigerator.txt refrigerator_logs.txt
But Same config Works Fine in ESPHome 2024.4.2 with ESP8266 (Nodemcu)
I cannot go back to ESPHome 2024.4.2 recently I deleted restore points
esp32 works fine esp8266 stopped working
I don't think it is only related to ESP8266 + LD devices. I have few setups on ESP-01S, and 2024.5.x
Fight is on. When I collect logs on different versions, I will paste here.
I too have issues with 2024.5.0 and my D1-Mini's w/LD2410C failing and was forced to revert to 2024.4.2. I also noticed my other devices under 5.0 lost their web page content except for the "Scheme" button and 2 headers. When I reverted to 4.2 the web page content was restored. It definitely appears to be a resource issue. I'm concerned there are a lot of ESP-01 and D1-Mini sensors out there which will eventually become unstable or worse inoperable at this SW update rate. So far no mention of a fix in 5.1 or 5.2.
This is my config on an esp8266 nodemcu (do not know how to up yaml, so as txt)... espbad.txt
no sensors, no display. but with esphome 24.5 I can not connect to the API anymore...
@otto2704 👇
esphome:
name: bad_esp
on_boot:
priority: -100
then:
- mqtt.publish:
topic: bad_esp/state/booted
payload: "1"
- deep_sleep.prevent: dsleep
esp8266:
board: nodemcuv2
time:
- platform: sntp
id: sntp_time
timezone: Europe/Vienna
servers:
- 192.168.1.1
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "mysecretkey"
ota:
password: "mypass"
deep_sleep:
id: dsleep
sleep_duration: 0s
wifi:
output_power: 15db
networks:
- ssid: "serverob"
password: !secret serverob_password
- ssid: "speis_ap"
password: !secret speis_ap_password
- ssid: "brando_server"
password: !secret brando_server_password
domain: ".fritz.box"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "toben"
password: !secret ap_mode_password
captive_portal:
mqtt:
broker: mqtt.fritz.box
username: !secret mqtt_username
password: !secret mqtt_password
topic_prefix: bad_esp
client_id: bad_esp
discovery: false
interval:
- interval: 60s
then:
- mqtt.publish:
topic: bad_esp/state/heartbeat
payload: "1"
sensor:
- platform: wifi_signal
name: "signal"
update_interval: 300s
- platform: uptime
name: "uptime"
update_interval: 300s
text_sensor:
- platform: wifi_info
ip_address:
name: ip
ssid:
name: ssid
- platform: mqtt_subscribe
name: "Reboot Trigger"
id: reboot_trigger
topic: "bad_esp/set/reboot"
on_value:
then:
- lambda: |-
if (x == "1") {
id(restartit).press();
ESP_LOGD("bla","Rebooting...");
}
button:
- platform: restart
name: "restartit"
id: restartit
# Enables status LED
status_led:
pin: GPIO2
binary_sensor:
- platform: gpio
id: bad_esp_button01
pin:
number: GPIO5
inverted: true
mode:
input: true
pullup: true
name: "bad_button01"
filters:
- delayed_on: 30ms
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at least 0.2s
then:
- logger.log: "Button 1 Double Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_01
payload: "doubleclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_rechts_doubleclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_rechts_doubleclick
- timing:
- ON for 1s to 2s
- OFF for at least 0.5s
then:
- logger.log: "Button 1 Single Long Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_01
payload: "longclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_rechts_longclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.klovorne_taster_links_longclick
- timing:
- ON for at least 2.2s
then:
- logger.log: "Button 1 Click and Hold"
- mqtt.publish:
topic: bad_esp/state/btn_01
payload: "clickhold"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_rechts_clickhold
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_rechts_clickhold
- timing:
- ON for at most 1s
- OFF for at least 0.5s
then:
- logger.log: "Button 1 Single Short Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_01
payload: "click"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_rechts_click
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_rechts_click
- platform: gpio
id: bad_esp__button02
pin:
number: GPIO4
inverted: true
mode:
input: true
pullup: true
name: "bad_button02"
filters:
- delayed_on: 30ms
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at least 0.2s
then:
- logger.log: "Button 2 Double Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_02
payload: "doubleclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_links_doubleclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_links_doubleclick
- timing:
- ON for 1s to 2s
- OFF for at least 0.5s
then:
- logger.log: "Button 2 Single Long Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_02
payload: "longclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_links_longclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_links_longclick
- timing:
- ON for at least 2.2s
then:
- logger.log: "Button 2 Click and Hold"
- mqtt.publish:
topic: bad_esp/state/btn_02
payload: "clickhold"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_links_clickhold
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_links_clickhold
- timing:
- ON for at most 1s
- OFF for at least 0.5s
then:
- logger.log: "Button 2 Single Short Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_02
payload: "click"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_oben_links_click
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_oben_links_click
- platform: gpio
id: bad_esp__button03
pin:
number: GPIO14
inverted: true
mode:
input: true
pullup: true
name: "bad_button03"
filters:
- delayed_on: 30ms
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at least 0.2s
then:
- logger.log: "Button 3 Double Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_03
payload: "doubleclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_rechts_doubleclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_rechts_doubleclick
- timing:
- ON for 1s to 2s
- OFF for at least 0.5s
then:
- logger.log: "Button 3 Single Long Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_03
payload: "longclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_rechts_longclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_rechts_longclick
- timing:
- ON for at least 2.2s
then:
- logger.log: "Button 3 Click and Hold"
- mqtt.publish:
topic: bad_esp/state/btn_03
payload: "clickhold"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_rechts_longclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_rechts_longclick
- timing:
- ON for at most 1s
- OFF for at least 0.5s
then:
- logger.log: "Button 3 Single Short Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_03
payload: "click"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_rechts_click
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_rechts_click
- platform: gpio
id: bad_esp__button04
pin:
number: GPIO12
inverted: true
mode:
input: true
pullup: true
name: "bad_button04"
filters:
- delayed_on: 30ms
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at least 0.2s
then:
- logger.log: "Button 4 Double Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_04
payload: "doubleclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_links_doubleclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_links_doubleclick
- timing:
- ON for 1s to 2s
- OFF for at least 0.5s
then:
- logger.log: "Button 4 Single Long Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_04
payload: "longclick"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_links_longclick
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_links_longclick
- timing:
- ON for at least 2.2s
then:
- logger.log: "Button 4 Click and Hold"
- mqtt.publish:
topic: bad_esp/state/btn_04
payload: "clickhold"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_links_clickhold
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_links_clickhold
- timing:
- ON for at most 1s
- OFF for at least 0.5s
then:
- logger.log: "Button 4 Single Short Clicked"
- mqtt.publish:
topic: bad_esp/state/btn_04
payload: "click"
- homeassistant.service:
service: input_boolean.turn_on
data:
entity_id: input_boolean.bad_taster_unten_links_click
- delay: 500ms
- homeassistant.service:
service: input_boolean.turn_off
data:
entity_id: input_boolean.bad_taster_unten_links_click
switch:
- platform: gpio
name: "bad_verstaerker"
pin: GPIO13
inverted: False
restore_mode: RESTORE_DEFAULT_OFF
state_topic: bad_esp/state/rel_01
command_topic: bad_esp/set/switch_01
@vazquezjm Thanks! But how did you do this? when I used the code tags, this was... ugly...
@vazquezjm Thanks! But how did you do this? when I used the code tags, this was... ugly...
You have to use code block `` \``` instead of \
`
@vazquezjm Thanks! But how did you do this? when I used the code tags, this was... ugly...
You have to use code block
instead of
Thanks @vazquezjm I also didn't know about the ```
I have the same thing with Sonoff 4ch ESPHome 2024.5.2
INFO Starting log output from 192.168.1.141 using esphome API
INFO Successfully connected to bramah136 @ 192.168.1.141 in 0.014s
WARNING bramah136 @ 192.168.1.141: Connection error occurred: bramah136 @ 192.168.1.141: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.2).
WARNING Can't connect to ESPHome API for bramah136 @ 192.168.1.141: bramah136 @ 192.168.1.141: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.5.2). (HandshakeAPIError)
INFO Trying to connect to bramah136 @ 192.168.1.141 in the background
but sometimes it will connect
Idea ... Something in 2024.5.0 was introduced that corrupted memory maintenance or similar? Or bloated some component? I was able to "capture out of memory" errors, on device with yaml compiled with 2024.5.2.
Example is one at my greenhouse. Device is working ok, with really simple yaml, compiled at 2024.5.0. But I am not able to do OTA via website. YAML has: wifi, web, ota, api, mqtt, one i2c sensor (SHT31D), one Dallas sensor.
Rebooting is not helping. I will downgrade this to 2024.4.2 just directly.
substitutions:
device_name: esp-szklarnia-a14
ip_suffix: "22"
device_comment: "(${ip_suffix}) Szklarnia na działce"
device_friendly_name: "Szklarnia A14"
status_interval: 15min
esphome:
name: $device_name
comment: $device_comment
friendly_name: $device_friendly_name
platform: esp8266
board: esp01_1m # d1_mini, esp01_1m
# Enable logging
logger:
# Enable Home Assistant API
api:
# remote location, disable reboot (MQTT will be used)
reboot_timeout: 0min
encryption:
key: !secret api_encryption_key
mqtt:
broker: !secret mqtt_broker
port: !secret mqtt_port
username: !secret mqtt_username
password: !secret mqtt_password
ota:
password: !secret ota_password
on_begin:
then:
- logger.log: "OTA start"
on_progress:
then:
- logger.log:
format: "OTA progress %0.1f%%"
args: ["x"]
on_end:
then:
- logger.log: "OTA end"
on_error:
then:
- logger.log:
format: "OTA update error %d"
args: ["x"]
wifi:
# Specify target address, for OTA or Logger to connect to
# Needed also when static addresses are present in configuration
#use_address: esphome-01-test.local
#use_address: 192.168.2.101
use_address: 192.168.2.${ip_suffix}
#use_address: 192.168.1.${ip_suffix}
fast_connect: false
#power_save_mode: LIGHT
on_connect:
then:
- logger.log: "Wifi connected."
- script.execute: send_diagnostics
networks:
- ssid: !secret wifi_dzialka_ssid # dzialka, hidden, needs bssid
password: !secret wifi_dzialka_password
hidden: true
bssid: !secret wifi_dzialka_bssid
priority: 3
manual_ip:
static_ip: 192.168.1.${ip_suffix}
gateway: 192.168.1.1
subnet: 255.255.255.0
dns1: 8.8.8.8
dns2: 8.8.4.4
- ssid: !secret wifi_dzialka_ssid # dzialka, visible
password: !secret wifi_dzialka_password
priority: 3
manual_ip:
static_ip: 192.168.1.${ip_suffix}
gateway: 192.168.1.1
subnet: 255.255.255.0
dns1: 8.8.8.8
dns2: 8.8.4.4
- ssid: !secret wifi_dzialka_guest_ssid # dzialka guest, hidden, needs bssid
password: !secret wifi_dzialka_guest_password
hidden: true
bssid: !secret wifi_dzialka_guest_bssid
priority: 2
manual_ip:
static_ip: 192.168.2.${ip_suffix}
gateway: 192.168.2.1
subnet: 255.255.255.0
dns1: 8.8.8.8
dns2: 8.8.4.4
- ssid: !secret wifi_ssid # home
password: !secret wifi_password
manual_ip:
static_ip: 192.168.2.${ip_suffix}
gateway: 192.168.2.1
subnet: 255.255.255.0
dns1: 8.8.8.8
dns2: 8.8.4.4
priority: 1
- ssid: !secret fallback_hotspot_ssid # fallback if exists
password: !secret fallback_hotspot_password
priority: 0
manual_ip:
static_ip: 192.168.1.${ip_suffix}
gateway: 192.168.1.1
subnet: 255.255.255.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: !secret fallback_hotspot_ssid
password: !secret fallback_hotspot_password
captive_portal:
# No configuration variables.
web_server:
port: 80
auth:
username: !secret web_server_user
password: !secret web_server_password
time:
- platform: sntp
servers:
- europe.pool.ntp.org
- tempus1.gum.gov.pl
- tempus2.gum.gov.pl
timezone: "Europe/Warsaw"
on_time_sync:
then:
- logger.log: "Synchronized system clock"
i2c:
# ESP-01: scl: 0, sda: 2
# EPS-12: scl: 5, sda: 4
scl: 0
sda: 2
scan: true
id: bus_a
dallas:
# ESP01 -> SCL -> GPIO0
# ESP01 -> TX -> GPIO1
# ESP12 -> SCL -> GPIO5
# ESP12 -> TX -> GPIO1
pin: 1
update_interval: 1min
id: dallas_set
script:
- id: send_diagnostics
then:
- logger.log: "Sending diagnostics."
- component.update: wifi_signal_dbm
# - component.update: wifi_signal_percent
- component.update: uptime_sensor #tak
# - component.update: uptime_human #tak
- component.update: esp_ip_addr
- component.update: esp_connected_ssid
- component.update: esp_connected_bssid
- component.update: esp_latest_wifi_scan_results
# customizations
- component.update: dallas_set
binary_sensor:
- platform: status
name: "ESP - Status"
entity_category: "diagnostic" # "", "config" , "diagnostic"
text_sensor:
- platform: version
name: "ESP - ESPHome Version"
id: esphome_version
#update_interval: $status_interval
- platform: template
name: "ESP - Uptime"
id: uptime_human
entity_category: "diagnostic" # "", "config" , "diagnostic"
icon: mdi:clock-start
update_interval: $status_interval
- platform: wifi_info
ip_address:
name: "ESP - IP Address"
id: esp_ip_addr
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: $status_interval
mac_address:
name: "ESP - Mac Address"
id: esp_mac_wifi_address
entity_category: "diagnostic" # "", "config" , "diagnostic"
#update_interval: $status_interval
ssid:
name: "ESP - Wifi SSID"
id: esp_connected_ssid
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: $status_interval
bssid:
name: "ESP - Wifi BSSID"
id: esp_connected_bssid
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: $status_interval
scan_results:
name: "ESP - Wifi Scan Results"
id: esp_latest_wifi_scan_results
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: $status_interval
sensor:
- platform: wifi_signal
name: "ESP - WiFi Signal dBm"
id: wifi_signal_dbm
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: $status_interval
- platform: copy
source_id: wifi_signal_dbm
name: "ESP - WiFi Signal %"
id: wifi_signal_percent
entity_category: "diagnostic" # "", "config" , "diagnostic"
#update_interval: $status_interval
filters:
- lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
unit_of_measurement: "%"
- platform: uptime
name: "ESP - Uptime Sensor"
id: uptime_sensor
entity_category: "diagnostic" # "", "config" , "diagnostic"
update_interval: ${status_interval}
on_raw_value:
then:
- text_sensor.template.publish:
id: uptime_human
state: !lambda |-
int seconds = round(id(uptime_sensor).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? to_string(days) + "d " : "") +
(hours ? to_string(hours) + "h " : "") +
(minutes ? to_string(minutes) + "m " : "") +
(to_string(seconds) + "s")
).c_str();
# customized
- platform: dallas
index: 0
name: "Soil Temperature"
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3
- platform: sht3xd
temperature:
name: "Air Temperature"
id: sht_temperature
humidity:
name: "Air Humidity"
id: sht_humidity
address: 0x44
update_interval: 60s
button:
- platform: restart
name: "ESP - Restart"
id: restart1
entity_category: "diagnostic" # "diagnostic" - hides entity in HA
- platform: template
name: "ESP - Send status info"
id: send_status_info
#icon: "mdi:emoticon-outline"
entity_category: "diagnostic" # "diagnostic" - hides entity in HA
on_press:
- logger.log: "Statuses requested."
- script.execute: send_diagnostics
# end of file
Same issue for me with a Localbytes Tasmota uk plug flashed OTA with ESPHOME.
`Working fine until latest ESPHOME version, Message: WARNING localbytes-plug-11 @ 192.168.0.80: Connection error occurred: localbytes-plug-11 @ 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.5.2).
`
My yaml is:
substitutions:
# Device Names
name: "localbytes-plug-11"
friendly_name: "Localbytes Plug 11"
# Icon
main_icon: "power-socket-uk"
# Default Relay State
# Aka: `restore_mode` in documentation
# Options: `RESTORE_DEFAULT_OFF`, `RESTORE_DEFAULT_ON`, `ALWAYS_ON` & `ALWAYS_OFF`
default_state: "RESTORE_DEFAULT_OFF"
esphome:
name: "${name}"
friendly_name: "${friendly_name}"
# Automatically add the mac address to the name
# so you can use a single firmware for all devices
name_add_mac_suffix: False
# This will allow for (future) project identification,
# configuration and updates.
project:
name: localbytes.plug-pm
version: "1.6.3"
on_boot:
priority: 300
then:
#Signal to the template switches that their initial values have been loaded
globals.set:
id: setupComplete
value: "true"
esp8266:
board: esp01_1m
restore_from_flash: true
logger:
dashboard_import:
package_import_url: github://JamesSwift/localbytes-plug-pm/localbytes-plug-pm.yaml@main
ota:
password: !secret localbytes_plug_11_ota_password
wifi:
networks:
- ssid: !secret wholehome_wifi_ssid
password: !secret wholehome_wifi_password
- ssid: !secret wifi_ssid
password: !secret wifi_password
- ssid: !secret garden_wifi_ssid
password: !secret garden_wifi_password
manual_ip:
static_ip: !secret localbytes_plug_11_ip
gateway: !secret wifi_gateway
dns1: !secret wifi_dns
subnet: !secret wifi_subnet
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Localbytes-11 Fallback Hotspot"
password: !secret localbytes_plug_11_wifi_ap_password
output_power: 18db
power_save_mode: light
api:
encryption:
key: !secret localbytes_plug_11_api_key
services:
- service: calibrate_voltage
variables:
actual_value: float
then:
- lambda: |-
id(voltage_multiply) = actual_value / id(voltage).raw_state;
- number.set:
id: voltage_factor
value: !lambda "return id(voltage_multiply);"
- service: calibrate_power
variables:
actual_value: float
then:
- lambda: |-
id(power_multiply) = actual_value / id(power).raw_state;
- number.set:
id: power_factor
value: !lambda "return id(power_multiply);"
- service: calibrate_current
variables:
actual_value: float
then:
- lambda: |-
id(current_multiply) = actual_value / id(current).raw_state;
- number.set:
id: current_factor
value: !lambda "return id(current_multiply);"
# Make calibration factor data readable/setable from home assistant
number:
- platform: template
name: "Voltage Calibration Factor"
id: voltage_factor
icon: "mdi:sine-wave"
min_value: 0
max_value: 10
step: 0.001
entity_category: diagnostic
mode: box
lambda: |-
return id(voltage_multiply);
set_action:
lambda: |-
id(voltage_multiply) = x;
- platform: template
name: "Power Calibration Factor"
id: power_factor
icon: "mdi:flash"
min_value: 0
max_value: 10
step: 0.001
entity_category: diagnostic
mode: box
lambda: |-
return id(power_multiply);
set_action:
lambda: |-
id(power_multiply) = x;
- platform: template
name: "Current Calibration Factor"
id: current_factor
icon: "mdi:current-ac"
min_value: 0
max_value: 10
step: 0.001
entity_category: diagnostic
mode: box
lambda: |-
return id(current_multiply);
set_action:
lambda: |-
id(current_multiply) = x;
binary_sensor:
# Push Button (Toggles Relay When Pressed)
- platform: gpio
pin:
number: GPIO3
mode: INPUT_PULLUP
inverted: true
name: "Button"
on_click:
- max_length: 1s
then:
if:
condition:
switch.is_off: disable_button
then:
switch.toggle: relay
- min_length: 1.5s
max_length: 5s
then:
switch.toggle: disable_led
- min_length: 8s
max_length: 12s
then:
switch.toggle: disable_button
- platform: status
name: "Server Status"
switch:
# Relay (As Switch)
- platform: gpio
name: ""
icon: "mdi:${main_icon}"
pin: GPIO14
id: relay
restore_mode: "${default_state}"
on_turn_on:
if:
condition:
switch.is_off: disable_led
then:
light.turn_on: led
on_turn_off:
- light.turn_off: led
- platform: template
name: "Disable LED"
id: disable_led
icon: "mdi:led-variant-off"
restore_mode: RESTORE_DEFAULT_OFF
optimistic: true
on_turn_on:
- if:
condition:
lambda: 'return id(setupComplete) == true;'
then:
#Flash twice
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
#Final state
- light.turn_off: led
on_turn_off:
- if:
condition:
lambda: 'return id(setupComplete) == true;'
then:
#Flash twice
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 1s
#Final state
- if:
condition:
switch.is_on: relay
then:
light.turn_on: led
- platform: template
name: "Disable Button"
id: disable_button
icon: "mdi:toggle-switch-off-outline"
restore_mode: RESTORE_DEFAULT_OFF
optimistic: true
on_turn_on:
- if:
condition:
lambda: 'return id(setupComplete) == true;'
then:
#Flash thrice
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
#Final state
- if:
condition:
or:
- switch.is_off: relay
- switch.is_on: disable_led
then:
light.turn_off: led
on_turn_off:
- if:
condition:
lambda: 'return id(setupComplete) == true;'
then:
#Flash thrice
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 0.15s
- light.turn_on: led
- delay: 0.15s
- light.turn_off: led
- delay: 1s
#Final state
- if:
condition:
- switch.is_on: relay
- switch.is_off: disable_led
then:
light.turn_on: led
sensor:
# WiFi Signal Sensor
- platform: wifi_signal
name: "WiFi Status"
update_interval: 60s
# Power Monitoring
- platform: hlw8012
sel_pin:
number: GPIO12
inverted: true
cf_pin: GPIO4
cf1_pin: GPIO5
change_mode_every: 3
update_interval: 6s
voltage:
name: "Voltage"
id: voltage
unit_of_measurement: V
accuracy_decimals: 1
filters:
- lambda: return x * id(voltage_multiply);
power:
name: "Power"
id: power
unit_of_measurement: W
accuracy_decimals: 0
filters:
- lambda: return x * id(power_multiply);
current:
name: "Current"
id: current
unit_of_measurement: A
accuracy_decimals: 3
filters:
- lambda: return x * id(current_multiply);
# Total daily energy sensor
- platform: total_daily_energy
name: "Daily Energy"
power_id: power
filters:
# Multiplication factor from W to kW is 0.001
- multiply: 0.001
unit_of_measurement: kWh
time:
- platform: homeassistant
timezone: Europe/London
globals:
- id: voltage_multiply
type: float
restore_value: true
initial_value: "0.3"
- id: power_multiply
type: float
restore_value: true
initial_value: "0.133"
- id: current_multiply
type: float
restore_value: true
initial_value: "0.805"
- id: setupComplete
type: bool
restore_value: no
initial_value: "false"
# Relay State LED
output:
- platform: esp8266_pwm
id: state_led
pin:
number: GPIO13
inverted: true
light:
- platform: binary
output: state_led
id: led
captive_portal:
web_server:
port: 80
still the same problem in 5.3. Here is a video how to back up the firmware before upgrading the v5 or if you already upgraded, how to get back any version of esphome. You can even have the oficial updated and use a legacy for the devices that fail.
Hi, For me, 5.4 update fixed the issue as well as other devices web ui fixes Sensor responded to wireless ota update and started showing sensor data in Home assistant
Hi, For me, 5.4 update fixed the issue as well as other devices web ui fixes Sensor responded to wireless ota update and started showing sensor data in Home assistant
That sounds good. Will wait for others who have positive news about the 5.4 version. Then I will try it here also.
same here. seems to work again wirg 2024.5.4 - weird
It seams issue has been fixed. 5.4
Fixed also on my end. This is the fix: https://github.com/esphome/esphome/pull/6819
Just a side note for this issue......
I have a few ESP01's in places I can not remove and just flash when I feel like it (One example is the front gate).
As for the 2024.5.4, I eventually managed to get it to take the flash (after hours of pushing the flash over OTA), however, it still had the same issues where it would drop off from time to time, was not taking the firmware as it always used to, and just seemed to be completely unreliable and unstable (I am referring to the EPS01's, I can not recall if the ESP8266's were behaving or not after the 2024.5.4, as by this point I had completely Lost My S#!t).
I did however notice that the 4 nodes that were most problematic, were the nodes that contained INA219 modules in them (2 x ESP01's and a further 2 x ESP8266 D1 Mini's, both with 2 x INA219 Modules connected to them)
Thankfully I managed to revert back to a previous version (2024.3) as described elsewhere in this thread, and after Many hours of pushing the firmware to the ESP01 node, it eventually took, and is now back to its previously "Well Behaved" disposition.
I could obviously not remove the gate node as it is one that has been soldered in place due to space constraints, and therefore could only be updated via OTA. (And no, my laptop with win7 on it bombed out recently, so that was not an option with the ftd adapter either).
On a side note, I did notice that all nodes bin files seemed around 30% larger (Even with no additional code, and with just the bare minimum of code it was 517KB+/-) which seemed a bit odd. I can not recall the exact size, however, the one nodes bin file I have on backup with just the bare minimum is 455KB, so I landed up removing virtually everything from the gates code to give it every possible chance of success.
I can only surmise this issue is not resolved as I was still having issues with all the ESP01 nodes that had INA219 modules connected to them, after the supposed fix was released.
In conclusion, with all the frustration that has led me up to this thread, I will not be updating ESPHome again soon, as this is now the second time I have had my fingers burnt to a crisp, and I do not enjoy the bitter taste it leaves in my mouth weeks after the ordeal has passed!
Esphome 5.4 didn't resolve anything. Same error, encryption yada yada.. Esp8266 with LD1410. Time to stop paying for nabu casa, it's been too long and no reply from devs.
On Tue, 28 May 2024, 19:35 Gadget43, @.***> wrote:
Just a side note for this issue......
I have a few ESP01's in places I can not remove and just flash when I feel like it (One example is the front gate).
As for the 2024.5, I eventually managed to get it to take the flash (after hours of pushing the flash over OTA), however, it still had the same issues where it would drop off from time to time, was not taking the firmware as it always used to, and just seemed to be completely unreliable and unstable (I am referring to the he EPS01's, I can not recall if the ESP8266's were behaving or not after the 2024.5, as by this point I had completely Lost My S#!t).
I did however notice that the 4 nodes that were most problematic, were the nodes that contained INA219 modules in them (2 x ESP01's and a further 2 x ESP8266 D1 Mini's, both with 2 x INA219 Modules connected to them)
Thankfully I managed to revert back to a previous version (2024.3) as described elsewhere in this thread, and after Many hours of pushing the firmware to the ESP01 node, it eventually took, and is now back to its previously "Well Behaved" disposition.
I could obviously not remove the gate node as it is one that has been soldered in place due to space constraints, and therefore could only be updated via OTA. (And no, my laptop with win7 on it bombed out recently, so that was not an option with the ftd adapter either.
On a side note, I did notice that all nodes bin files seemed around 30% larger (Even with no additional code, and with just the bare minimum of code it was 517KB+/-) which seemed a bit odd. I can not recall the exact size, however, the one nodes bin file I have on backup with just the bare minimum is 455KB, so I landed up removing virtually everything from the gates code to give it every possible chance of success.
I can only surmise this issue is not resolved as I was still having issues with all the ESP01 nodes that had INA219 modules connected to them, after the supposed fix was released.
In conclusion, with all the frustration that has led me up to this thread, I will not be updating ESPHome again soon, as this is now the second time I have had my fingers burnt to a crisp, and I do not enjoy the bitter taste it leaves in my mouth weeks after the ordeal has passed!
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/5790#issuecomment-2135882262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNLFK2ICDLZOZUAHC2WAZ3ZETE7DAVCNFSM6AAAAABHXYYO4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVHA4DEMRWGI . You are receiving this because you commented.Message ID: @.***>
Confirmed working for my three d1 minis.
Thanks for the fix to all involved. I guess smart alec ain't so smart after all, lol.
EDIT: I've disabled encryption, which may be why it's working for me.
All is working for me again with the newest update, but my BME680 still says IAQ accuracy is uncertain (this didn’t happen under 2024.4.2).
We forge on!
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.
I feel hashing out 95% of your code just to get the node to operate "Sort of" again is kind of counter productive, don't you think?
I actually did remove nearly All the code from the one node before it took on OTA, but in my opinion, removing code that actually served a purpose before this update, just means someone screwed something up.
Eventually, bloat will take over and you will be told that you can't use ESP01's and D1 Mini's, because they don't meet the minimum requirements of Esphome, what then?
I suppose if you earn thousands a month, and can afford to throw out all the 1MB devices, good for you, but all I do with an ESP01 is send battery voltages from my gate, so I don't need a million io pins, or updates every 5 seconds, but I guess that's just my use case scenario 🤷🏼♂️
The only thing I am currently trying to wrap my head around is how this issue has been marked as "Closed" or "Resolved"
@Wheemer
Confirmed working for my three d1 minis.
Thanks for the fix to all involved. I guess smart alec ain't so smart after all, lol.
EDIT: I've disabled encryption, which may be why it's working for me.
Thanks for the side splitting laugh, I enjoyed that after what I was put through!
I really do have to admit, that as funny as that was, myself, not being a coder/programmer, would not want to be the person responsible for having to repair all these errors.
I take a look at some of the code and code fixes on GitHub and my mind boggles at the shear "mass of knowledge" of some of these guys/gals keeping HA afloat, and I very quickly, re-appreciated how much work has gone in to it, and my frustrations and anger subside... Slightly!
It IS extremely annoying landing up with non working nodes after an update, however, lesson learned, and I will be doing the updates after I have done my due diligence, and not just "Assuming All Is Good".
As the saying goes, fool me once, shame on you, fool me twice, shame on Me!
It would be a lot better if more people tested the beta. The developers can't test on the huge variety of hardware people have. Also, you should first test on something serial flashable if possible.
As much as I like running beta software, doing it with ESPHome on a house scale isn't really feasible. Especially when you're compiling it on a Raspberry Pi 5 which takes about 1.5 hours to upload new firmware to all my devices. (Considering that there are multiple beta releases a week)
Also, out of the 50+ devices I have on ESPHome, only a single one of them had this issue so it'll be hard to find on a small scale install (disabling encryption didn't fix it for me, I just ended up reverting to the latest 2024.4 release).
I certainly don't mean to run beta on everything, but a couple of tests of some representative hardware would be helpful. Also, beta is only around a week usually about the second week of the month. You can watch the #beta discord channel to see when it starts.
Well, I also have 25 productive nodes and one had the problem. Plus: many of them are somewhere in the walls and to gaining physical access is lots of work in some cases. I understand that beta testing is important, but I do not really have "representative" hardware. I am having minis, 8266 nodemcus, esp32s and so on. Also the sensors attached are varying. The one I had problems with in this case did not have any special hardware. Just some buttons and a relay...
The one I had issues with only had an IR transmitter with a few template switches/buttons to transmit IR codes
2024.5.4 did solve the issue for me too
The one I had issues with only had an IR transmitter with a few template switches/buttons to transmit IR codes
Just out of curiosity, what type of node did this cause issues on? Mainly i just wanted to see if there was any relevance to my situation where it mainly affected the ESP01-1M and Esp8266's that are most likely clones.
The one I had issues with only had an IR transmitter with a few template switches/buttons to transmit IR codes
Just out of curiosity, what type of node did this cause issues on? Mainly i just wanted to see if there was any relevance to my situation where it mainly affected the ESP01-1M and Esp8266's that are most likely clones.
It was a WeMos D1 Mini (ESP8266). But I have a ton more modes like that and none had the issue
2024.5.4, I'm just now encountering this very issue. Same setup, Wemos D1 Mini (ESP8266), LD2410.
Encryption enabled -> problem seems to persist Encryption disabled -> problem seems to be solved
I don't want to upgrade my home assistant esphome for 2024.4.2 but it seems the devices initialized from esphome-web are now on 2024.5.4 and don't get detected/appear for 2024.4.2?
Edit: Actually, probably user error - I had a second device connected to my PC that I was flashing instead of the one I intended to. And that was already in esphome/home assistant. Sadly, esphome let me add the device manually and quite happily overwrote the original yaml file for that device when I used the same esphome-web-
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
Anything in the logs that might be useful for us?
Additional information
No response