everything-presence-one
everything-presence-one copied to clipboard
With bluetooth enabled since last update 2023.12.8 causes devices to go into boot loop
Using the below config:
packages:
Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/presence-one/everything-presence-one.yaml@main
# esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
dashboard_import:
package_import_url: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
esphome:
name: ${name}
name_add_mac_suffix: false
project:
name: esphome.bluetooth-proxy
version: "1.0"
esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms
active: True
bluetooth_proxy:
active: true
Will constantly reboot, the logs show:
[14:18:47][C][api:142]: Using noise encryption: YES
[14:18:47][C][improv_serial:032]: Improv Serial:
[14:18:49][D][esp32_ble:255]: Disabling BLE...
][W][ota:107]: Last Boot was an unhandled reset, will proceed to safe mode in 1 restarts
Then reboots, and you will have to physically pull the power and start it again
I'm also having this issue. As of right now I have commented out anything pertaining to BLE on the EP1 and it seems to be okay right now.
This unfortunately started in ESPHome 2023.12.6 I believe (at least that's when we started getting reports) - this would need to be resolved upstream in ESPHome, the EP1 config hasn't changed. Bluetooth isn't enabled in supported config options and there is no issues there, it's just when you are running a custom config with Bluetooth added.
You could also try switching the framework to esp-idf rather than Arduino which is generally recommend for anything Bluetooth
So, the strange thing is. I do not want to point fingers at each project's code, I know the code before the last update of ESPhome had no issues, but the last update, broke things Now I do recall, that you had stated at one time that there would be bluethooth at some point, not that it has been an out-of-the-box experience.
This setup is configured on other ESP32s I use, they are not having this issue. I do wonder if it has something to do with an interaction of the hardware on this EP1. The generic ESP32s I have only have a light sensor and temp sensor configured on them, oh and they are used to manage some LED's converting 12v to 5v. Nothing fancy.
So take my one example as a possibility that there could be something different about the EP1 config compared to just a default ESPhome installed that could be causing a conflict.
BTW, you stated "You could also try switching the framework to esp-idf rather than Arduino" This is defined in your base configuration correct? I don't define esp-idf in my snippet config.
BUT, I do have that in my esp32 configs for the hardware that I mentioned above.
esp32:
board: esp32dev
framework:
type: esp-idf
sdkconfig_options:
CONFIG_LWIP_IPV6_AUTOCONFIG: y
CONFIG_LWIP_IPV6: "2"
CONFIG_LWIP_IPV6_RDNSS_MAX_DNS_SERVERS: "2"
Thanks, keep up the good work I look forward to all of your hardware. I only really bought your hardware to support you and your channel and it really was not the end of the hardware did not work perfectly.
Yes it is most likely more prolific because the EP1 has a lot larger config than most devices and a lot more going on, so possibly rears it's head more. Bluetooth hasn't been enabled on the EP1 by default yet (but of course you are free to add it yourself as you have done) because there have been quite a lot of issues having BLE and WiFi active at the same time (not just on the EP1) and hence it was more reliable to leave it disabled by default and let users enable it if they wished.
Yes, the default framework on the EP1's (and indeed all ESPHome configs unless you specify otherwise like in your snippet above) is to use the Arduino Framework, but the ESP-IDF framework is more performant and seems to handle bluetooth and wifi at the same time much better. I would start with that first!
BTW, you stated "You could also try switching the framework to esp-idf rather than Arduino" This is defined in your base configuration correct? I don't define esp-idf in my snippet config.
BUT, I do have that in my esp32 configs for the hardware that I mentioned above.
esp32: board: esp32dev framework: type: esp-idf sdkconfig_options: CONFIG_LWIP_IPV6_AUTOCONFIG: y CONFIG_LWIP_IPV6: "2" CONFIG_LWIP_IPV6_RDNSS_MAX_DNS_SERVERS: "2"
I think what @pshempel is saying in his comment is that the configuration between esp-idf and Arduino is exposed in his configuration on his own ESP832's.
This configuration, between esp-idf & Arduino, is not available in the EP1's configuration.
That's because it's the non default option. I don't need to manually type out the framework settings for the EP1 because Arduino is the default option, where as if you want to change to esp-idf (like he did for the other device) then you need to specify it manually.
I'm also guessing your using the adopter/imported config and not the full one? If so then that option wouldn't show in the imported config even if it was defined in the main config (at least from memory)
For the record: I haven't read this discussion entirely but mentioned having this issue in another thread. I'm not sure if this has something to do with esphome because if you link to github in the yaml config of your device you will inadvertently always update with the latest from this repository as well. So you might think you are updating esphome but you might be updating two things at the same time. This is what happened to me.
I am still on the latest esphome (I couldn't find an easy way to downgrade it in home assistant) but I have downloaded version of EPO config from 2 weeks ago (b56b71f2ae924af0ee2145df2d8a4864d0bb702b) and sourced it locally. Now my device boots fine, and BLE also works as it did for the past couple of months.
I am using esp-idf.
Possibly but I don't see any changes that would cause it, all very minor. Though it's not impossible.
All of the reports I've had about this (Discord) came when people were already running the latest EP1 version, but updated to ESPHome 2023.12.6+. All were running Bluetooth proxy. I don't believe I've had any reports from users using the official config without modifications (which doesn't have Bluetooth enabled)
You mention your using the EP1 config but using esp-idf which means non standard config (unless your talking about beta perhaps?)
Yeah, I had esp-idf, then after esphome update (and simultaneous update with the latest from this repo) my device started to go into bootloop. So I replaced with arduino, and it was back up again with the latest from the main branch, but then of course BLE stopped working. I needed BLE to operate my switchbot blinds so I started digging and wasn't able to downgrade ESPhome easily so I downgraded EPO instead, with the commit I linked to above. And then switched back to esp-idf. And now my EPO works, and my bluetooth blinds work.
Glad it's working for you now but I don't think it really indicates where the problem is since your not using the standard config. You also said you used the standard config and it worked other than Bluetooth not working (as it's not included) and then switched to esp-idf.
I'm also looking at this recently reported issue and wondering if it's related: https://github.com/esphome/issues/issues/5409
My goal was just to share how I solved my problem, not to indicate to you where the source of your problem is, but I think this extra information should be helpful because it narrows it down - the common denominator being the non-standard esp-idf
Absolutely, I appreciate the info and sorry if it didn't come across that way!
I am still on the latest esphome (I couldn't find an easy way to downgrade it in home assistant) but I have downloaded version of EPO config from 2 weeks ago (b56b71f2ae924af0ee2145df2d8a4864d0bb702b) and sourced it locally.
Thank you very much for this! After going back to version 1.1.8 of this file, my EP1 Bluetooth Proxy also started working perfectly again, I was at a loss for the last 2 weeks or so.
I have hardcoded the version as follows for now in my ESPHome file:
packages: Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/presence-one/[email protected]
^ works for me too! Thanks for the tip
same here latest default cont with btproxy fails to work
same here latest default cont with btproxy fails to work
Are you using the pre-built firmwares?
We obviously have to change the yaml file to enable bluetooth proxy, but apart from that just using the Git version, though now have to downgrade to 1.1.8 .
We obviously have to change the yaml file to enable bluetooth proxy, but apart from that just using the Git version, though now have to downgrade to 1.1.8 .
You don't actually, pre-built configs were added to the installer for Bluetooth proxy already last week - I haven't seen any bootloader loops with those.
Ah, great thanks. Sorry I was not aware of this. Will try and then report back.
same here latest default cont with btproxy fails to work
Are you using the pre-built firmwares?
Yes, I've tried to flash my sensor with your default firmware: https://everythingsmarthome.github.io/everything-presence-one/updating.html
Selected HA, Bluetooth Proxy, Stable
As soon as this is done, does not boot anymore.
I'm not able to re-produce this on my side unfortunately. Can you verify if you get this after a complete power cycle (unplug and replug power cable after flashing)
I'm not able to re-produce this on my side unfortunately. Can you verify if you get this after a complete power cycle (unplug and replug power cable after flashing)
will try again in a few hours and get back to you
same here latest default cont with btproxy fails to work
Are you using the pre-built firmwares?
Yes, I've tried to flash my sensor with your default firmware: https://everythingsmarthome.github.io/everything-presence-one/updating.html
Selected HA, Bluetooth Proxy, Stable
Device gets adopted with this conf:
substitutions:
name: everything-presence-one-d4dc88
friendly_name: Everything Presence One d4dc88
packages:
Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/everything-presence-one/everything-presence-one-ble.yaml@main
esphome:
name: ${name}
name_add_mac_suffix: false
friendly_name: ${friendly_name}
api:
encryption:
key: key_here
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
This seem to work ok after. Sry for the confusion!
I'm using EP1 with SmartThings and having the constant reboot issue. Is there a way to disable bluetooth for that environment?
There was a change in config structure between the config reported as working in https://github.com/EverythingSmartHome/everything-presence-one/issues/141#issuecomment-1913660441 and the latest config so it's hard to say if anything else at play, but at glance what is different in the old (v1.1.8) config is that it doesn't use esp-idf
but arduino
(default) instead.
When I used everything-presence-one.yaml
from the latest commit and added BLE proxy, I got a crash-loop. But as soon as I removed:
framework:
type: esp-idf
it worked.
I just realized there is everything-presence-one-ble.yaml
in main
as well, which I haven't tried yet. But since the difference only in common/bluetooth-base.yaml
, I would expect a crash-loop as well.
I don't experience boot loops on everything-presence-one-ble.yaml. However, there is another problem - no log output from the device when you connect to it. Edit: also, my device now seems to stop responding during OTA update, so the only way to revert is via USB...
I also got the same issue, switching from
packages:
Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/everything-presence-one/everything-presence-one.yaml@main
to
packages:
Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/everything-presence-one/everything-presence-one-ble.yaml@main
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (Scf4h ( 19700) load
I (206) esp_image: segment 2: paddr=0004bd18 vaddr=40080000 size=04300h ( 17152) load
I (213) esp_image: segment 3: paddr=00050020 vaddr=400d0020 size=f4130h (999728) map
I (575) esp_image: segment 4: paddr=00144158 vaddr=40084300 size=19ce4h (105700) load
I (633) boot: Loaded app from partition at offset 0x10000
I (633) boot: Disabling RNG early entropy source...
I (645) cpu_start: Multicore app
I (645) cpu_start: Pro cpu up.
I (645) cpu_start: Starting app cpu, entry point is 0x4008269c
I (636) cpu_start: App cpu up.
I (665) cpu_start: Pro cpu start user code
I (665) cpu_start: cpu freq: 160000000
I (665) cpu_start: Application information:
I (670) cpu_start: Project name: ep1-badezimmer
I (675) cpu_start: App version: 2024.4.1
I (680) cpu_start: Compile time: Apr 23 2024 07:56:17
I (687) cpu_start: ELF file SHA256: 37ed8608c8ad8c9a...
I (693) cpu_start: ESP-IDF: 4.4.6
I (697) cpu_start: Min chip rev: v0.0
I (702) cpu_start: Max chip rev: v3.99
I (707) cpu_start: Chip rev: v3.0
assert failed: s_prepare_reserved_regions memory_layout_utils.c:100 (reserved[i + 1].start > reserved[i].start)
Backtrace: 0x400830ba:0x3ffe3390 0x4009224d:0x3ffe33b0 0x4009844d:0x3ffe33d0 0x40143d1a:0x3ffe34f0 0x4014393a:0x3ffe3850 0x4014182f:0x3ffe3c00 0x40082a29:0x3ffe3c40 0x4007959c:0x3ffe3c80 |<-CORRUPTED
edit: tested it with both a clean install and while switching a working installation over to BLE, both result in the same crash
^^^
Exactly the same here. everything-presence-one.yaml works OK, everything-presence-one-ble.yaml boot loops same as EleRas above.
same as well. unrelated to this project. but when enabling the esp32_ble_tracker component (which is included in the ble configuration u are mentioning) the bootloop occurs
Given there was some fixes for Bluetooth stability in ESPHome 2024.5, can you try the new builds now available on the user guide? Hoping they might help any boot loop issues