Sensors appear to crash and reboot regularly

GuySie commented 1 year ago

I have just started using my everything presence one sensors (I have 2). As I was trying to set them up I noticed that every so often the sensors and their entities become unavailable in Home Assistant repeatedly, usually disappearing once every few minutes. There doesn't seem to be rhyme or reason for when they start becoming unavailable. To give you an idea, this is what one of the sensor's mmwave entities looks like for me:

After ruling out my USB-C cables and chargers, and not getting much info from the wireless logs, I hooked one of the sensors to my HA server and checked the logs over USB instead. This revealed what appear to be crashes resulting in reboots, for example:

[23:14:11][D][esp-idf:000]: fail to alloc timer, type=6
[23:14:11][D][esp-idf:000]: 
[23:14:11]
[23:14:11]abort() was called at PC 0x401f0c87 on core 1
[23:14:11]
[23:14:11]ELF file SHA256: 0000000000000000
[23:14:11]
[23:14:11]Backtrace: 0x40090060:0x3ffcd1e0 0x400902dd:0x3ffcd200 0x401f0c87:0x3ffcd220 0x401f0cce:0x3ffcd240 0x401f05e9:0x3ffcd260 0x401f06c0:0x3ffcd280 0x401f12c9:0x3ffcd2a0 0x401f1402:0x3ffcd2c0 0x401f152d:0x3ffcd300 0x400dedc7:0x3ffcd320 0x400deddb:0x3ffcd340 0x400df0d8:0x3ffcd360 0x400df28f:0x3ffcd3b0 0x400e71f5:0x3ffcd440 0x400e688d:0x3ffcd480 0x400ee319:0x3ffcd4c0 0x400e6a20:0x3ffcd4e0 0x401fbcf9:0x3ffcd500 0x401fbdd5:0x3ffcd520 0x400ecc26:0x3ffcd540 0x400efbc2:0x3ffcd570 0x400fff34:0x3ffcd590 0x40091352:0x3ffcd5b0
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x40090060: invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
WARNING Decoded 0x400902dd: abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
WARNING Decoded 0x401f0c87: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:112
WARNING Decoded 0x401f0cce: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:112
WARNING Decoded 0x401f05e9: __cxa_allocate_exception at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_alloc.cc:313
WARNING Decoded 0x401f06c0: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc:54
WARNING Decoded 0x401f12c9: __gnu_cxx::new_allocator<char>::allocate(unsigned int, void const*) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h:281
 (inlined by) std::allocator_traits<std::allocator<char> >::allocate(std::allocator<char>&, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/alloc_traits.h:360
 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned int&, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.tcc:157
WARNING Decoded 0x401f1402: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned int, unsigned int, char const*, unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h:281
WARNING Decoded 0x401f152d: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/basic_string.h:281
WARNING Decoded 0x400dedc7: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator+=(char) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Polyfills/safe_strcmp.hpp:21
 (inlined by) ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void>::write(unsigned char) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Serialization/Writers/StdStringWriter.hpp:28
 (inlined by) ArduinoJson6185_D1::CountingDecorator<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::write(unsigned char) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Serialization/CountingDecorator.hpp:17
WARNING Decoded 0x400deddb: ArduinoJson6185_D1::TextFormatter<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::writeRaw(char) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Polyfills/safe_strcmp.hpp:21
 (inlined by) ArduinoJson6185_D1::TextFormatter<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::writeString(char const*) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Json/TextFormatter.hpp:39
WARNING Decoded 0x400df0d8: ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::visitObject(ArduinoJson6185_D1::CollectionData const&) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Polyfills/safe_strcmp.hpp:21
 (inlined by) ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::result_type ArduinoJson6185_D1::VariantData::accept<ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> > >(ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >&) const at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Variant/VariantData.hpp:49
WARNING Decoded 0x400df28f: ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::result_type ArduinoJson6185_D1::variantAccept<ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> > >(ArduinoJson6185_D1::VariantData const*, ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >&) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Polyfills/safe_strcmp.hpp:21
 (inlined by) ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::result_type ArduinoJson6185_D1::VariantConstRef::accept<ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> > >(ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >&) const at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Variant/VariantRef.hpp:245
 (inlined by) ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >::result_type ArduinoJson6185_D1::JsonDocument::accept<ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> > >(ArduinoJson6185_D1::JsonSerializer<ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >&) const at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Document/JsonDocument.hpp:20
 (inlined by) unsigned int ArduinoJson6185_D1::doSerialize<ArduinoJson6185_D1::JsonSerializer, ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator>, ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void> >(ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator> const&, ArduinoJson6185_D1::Writer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void>) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Serialization/serialize.hpp:15
 (inlined by) unsigned int ArduinoJson6185_D1::serialize<ArduinoJson6185_D1::JsonSerializer, ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Serialization/serialize.hpp:22
 (inlined by) unsigned int ArduinoJson6185_D1::serializeJson<ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(ArduinoJson6185_D1::BasicJsonDocument<ArduinoJson6185_D1::DefaultAllocator> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at /data/everything-presence-one-d53318/.piolibdeps/everything-presence-one-d53318/ArduinoJson/src/ArduinoJson/Json/JsonSerializer.hpp:115
 (inlined by) esphome::json::build_json[abi:cxx11](std::function<void (ArduinoJson6185_D1::ObjectRef)> const&) at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/components/json/json_util.cpp:53
WARNING Decoded 0x400e71f5: esphome::web_server::WebServer::switch_json[abi:cxx11](esphome::switch_::Switch*, bool, esphome::web_server::JsonDetail) at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/components/web_server/web_server.cpp:87
WARNING Decoded 0x400e688d: esphome::web_server::ListEntitiesIterator::on_switch(esphome::switch_::Switch*) at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/components/web_server/list_entities.cpp:48
WARNING Decoded 0x400ee319: esphome::ComponentIterator::advance() at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/core/component_iterator.cpp:200
WARNING Decoded 0x400e6a20: non-virtual thunk to esphome::web_server::WebServer::loop()
WARNING Decoded 0x401fbcf9: esphome::Component::call_loop() at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/core/component.cpp:150
WARNING Decoded 0x401fbdd5: esphome::Component::call() at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/core/component.cpp:150
WARNING Decoded 0x400ecc26: esphome::Application::loop() at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/core/application.cpp:74
WARNING Decoded 0x400efbc2: loop() at /config/esphome/.esphome/build/everything-presence-one-d53318/src/esphome/core/gpio.h:62
WARNING Decoded 0x400fff34: loopTask(void*) at /data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:23
WARNING Decoded 0x40091352: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)
[23:14:13]
[23:14:13]Rebooting...

I've attached a log with several such crashes here: logs_everything-presence-one.txt

Would love to know if there's anything this points at that I'm doing wrong or should set up differently. I don't feel like I can trust these sensors right now if they can drop off and become unavailable at any time.

EverythingSmartHome commented 1 year ago

That is strange, are you able to try and reflash the device using the flashing page from the user guide? You will need to re-connect it to WiFi and add to Home Assistant again.

CMDR-Sloma commented 1 year ago

I might have something related, not sure.

Does mmWave LED turns on by default after reboot? Because very often I see the sensor's led being on despite the fact I turned it off already. Also, I can see lots of reports from NMAP about sensor being away now and then. Sensor is located 3-4 meters from my access point in the living room, there is nothing in between them in the straight line.

One last thing I had real nightmare while flashing over Wi-Fi, lots of errors (connection reset by peer). Flashing over USB went without any problems. I have two sensors and both behave in the same manner.

EverythingSmartHome commented 1 year ago

I might have something related, not sure.

Does mmWave LED turns on by default after reboot? Because very often I see the sensor's led being on despite the fact I turned it off already. Also, I can see lots of reports from NMAP about sensor being away now and then. Sensor is located 3-4 meters from my access point in the living room, there is nothing in between them in the straight line.

One last thing I had real nightmare while flashing over Wi-Fi, lots of errors (connection reset by peer). Flashing over USB went without any problems. I have two sensors and both behave in the same manner.

Thanks for the info. Did you reflash recently using the flash page in the user guide? I just updated it to ESPHome 2022.12 to see if that helps.

Can you also confirm what you are using for Access Points? I've spoke to 2 others who have this problem and both are using Unifi UDM Pros with seperate SSIDs for IOT devices. One reported that moving it to their regular SSID made it stable but once they moved it back to the IoT SSID that it would drop again.

Be good to get more information about the network setup to see if there is a common theme - at the moment it seems wireless related in some way.

CMDR-Sloma commented 1 year ago

I have now reflashed sensors over USB to the latest firmware (2022.12).

Reflash over Wi-Fi network was triggering reboot of the sensor evry time for some reason. This was visible in the logbook in the HA when actual was starting, thus resulting in 'reset by peer' error. I am not really sure if it is solved, need to wait and see how sensor behaves with the new firmware.

As for the setup, my network runs on the Mikrotik devices, one main router and one access point centrally managed by CAPsMAN, no vlans, but both sensors are allowed to connect only to the access point because it is in their direct line of sight, no more than 3 meters away.

I have no problems with other ESP devices, update over the network work flawlessly every time. Only ESP Presence sensors are suffering from this problem (reboot). If you need anything else let me know, I will try to help you as much as I can.

EverythingSmartHome commented 1 year ago

Thanks for the detailed information, certainly is useful to narrowing down the bug.

Please let me know how it goes with the new firmware!

GuySie commented 1 year ago

Thanks for the info. Did you reflash recently using the flash page in the user guide? I just updated it to ESPHome 2022.12 to see if that helps.

I updated to ESPHome 2022.12.0 this afternoon and reflashed the sensors. They refused to be flashed OTA, giving reset by peer or time-out errors. I had to hook them up via USB just like @CMDR-Sloma. They seem to have settled down after this, I didn't spot them becoming unavailable for quite a bit now. I haven't tried flashing OTA after this.

Can you also confirm what you are using for Access Points? I've spoke to 2 others who have this problem and both are using Unifi UDM Pros with seperate SSIDs for IOT devices. One reported that moving it to their regular SSID made it stable but once they moved it back to the IoT SSID that it would drop again.

I am using a Unifi AP-AC-Pro and an AP-AC-Lite in my apartment hooked up to a USG, but I am not using any exotic settings. No separate SSID, no separate VLAN, nothing like that. I am using a combined 2.4ghz and 5ghz SSID, I saw a few forum posts that seemed to indicate that might be an issue with some ESPs losing connection randomly. However, all my other ESP devices work perfectly fine with this setup, and none of them have OTA flash issues either.

EverythingSmartHome commented 1 year ago

OK thanks for the info - let me know how 2022.12 goes and if you have any further issues.

I'll keep digging to see if I can figure out what's going on. I have tried and tested a handful of EP1s today and haven't been able to reproduce the problem myself yet.

PeterBurner commented 1 year ago

Same here. Properties in Home Assistant get greyed-out from time to time and LED blinks occasionally event though it was turned off. Please tell if there is anything we can do to help.

EverythingSmartHome commented 1 year ago

Same here. Properties in Home Assistant get greyed-out from time to time and LED blinks occasionally event though it was turned off. Please tell if there is anything we can do to help.

Can you try flashing from the flash page in the user guide to update to 2022.12?

Next steps would be to open a serial log to the device and try to capture the logs before and during a reboot.

What is your network setup also?

EverythingSmartHome commented 1 year ago

@GuySie @PeterBurner @CMDR-Sloma If you are still having problems, please update to the latest firmware available through the flasher. I just updated this right now.

I obtained some logs through one of the members who had this issue in Discord and we managed to capture this when it rebooted:

D][uart_debug:158]: <<< "$JYBSS,1, , , *\r\n"
[D][uart_debug:158]: <<< "$JYBSS,1, , , *\r\n"
[D][uart_debug:158]: <<< "$JYBSS,1, , , *\r\n"
[D][uart_debug:158]: <<< "$JYBSS,1, , , *\r\n"
[D][uart_debug:158]: <<< "$JYBSS,1, , , *\r\n"
[E][json:044]: Could not allocate memory for JSON document! Overflowed largest free heap block: 172 bytes

abort() was called at PC 0x401f089b on core 1

Backtrace:0x40083c19:0x3ffcd6500x4009364d:0x3ffcd670 0x40098d89:0x3ffcd690 0x401f089b:0x3ffcd710 0x401f08e2:0x3ffcd730 0x401f1c59:0x3ffcd750 0x401f02d4:0x3ffcd770 0x401f0ef1:0x3ffcd790 0x401f115d:0x3ffcd7b0 0x400e5ec7:0x3ffcd7e0 0x400e6e9f:0x3ffcd800 0x400dee92:0x3ffcd890 0x400e5e41:0x3ffcd910 0x400e5523:0x3ffcd960 0x400ebca1:0x3ffcd9a0 0x400e559c:0x3ffcd9c0 0x4020b07d:0x3ffcd9e0 0x4020b13d:0x3ffcda00 0x400ea7f0:0x3ffcda20 0x400ed302:0x3ffcda50 0x400fc135:0x3ffcda70 

ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

ESPHome developer Jesse let me know (very kindly!) that the web_server component is often responsible for the json error, so this firmware removes that. The web_server component was used by me for debugging in the past and was never meant to be left in because it uses up a lot of resources.

This firmware should make things run better and hopefully fix the reboot issue - let me know how it goes.

PeterBurner commented 1 year ago

For me installing 2022.12.0 seems to fix the problem. I am using FRITZ!Repeater in AP mode which is connected to the router via LAN. Both 2.4GHz and 5GHz bands are active.

EverythingSmartHome commented 1 year ago

For me installing 2022.12.0 seems to fix the problem. I am using FRITZ!Repeater in AP mode which is connected to the router via LAN. Both 2.4GHz and 5GHz bands are active.

Glad to hear the new firmware helps, thanks for the info!

GuySie commented 1 year ago

@GuySie @PeterBurner @CMDR-Sloma If you are still having problems, please update to the latest firmware available through the flasher. I just updated this right now.

Not sure if still relevant to the troubleshooting, but I just updated to ESPHome 2022.12.1 and tried to update one of my sensors - figured it would pull in both the new ESPHome firmware and the new YAML from your repo. However, OTA again wouldn't take - same reset by peer message.

CMDR-Sloma commented 1 year ago

@GuySie @PeterBurner @CMDR-Sloma If you are still having problems, please update to the latest firmware available through the flasher. I just updated this right now.

Not sure if still relevant to the troubleshooting, but I just updated to ESPHome 2022.12.1 and tried to update one of my sensors - figured it would pull in both the new ESPHome firmware and the new YAML from your repo. However, OTA again wouldn't take - same reset by peer message.

Yup, this still an issue, can't update the sensors over Wi-Fi. Flashed latest firmware over USB, and then I tried reflashing latest firmware again over the network - it didn't work.

EverythingSmartHome commented 1 year ago

@GuySie @PeterBurner @CMDR-Sloma If you are still having problems, please update to the latest firmware available through the flasher. I just updated this right now.

Not sure if still relevant to the troubleshooting, but I just updated to ESPHome 2022.12.1 and tried to update one of my sensors - figured it would pull in both the new ESPHome firmware and the new YAML from your repo. However, OTA again wouldn't take - same reset by peer message.

I don't believe flashing from the dashboard will pull the latest config so you would probably need to use the flash page first.

OTA is hit and miss for me, sometimes it works and sometimes I get the message you are getting too. I think this is an outstanding bug that OTA will sometimes fail when Bluetooth is enabled (which it is for improv setup).

To test this I flashed a very minimal config onto the board and then OTA worked everytime after that

GuySie commented 1 year ago

I don't believe flashing from the dashboard will pull the latest config so you would probably need to use the flash page first.

Ah, I didn't know there was a difference between using the flasher or the dashboard, thought it would do the same. Have just reflashed them both from the flash page instead.

Should I also not adopt the sensors into ESPHome either as we test them now, because it might flash them back to the old yaml?

EverythingSmartHome commented 1 year ago

I don't believe flashing from the dashboard will pull the latest config so you would probably need to use the flash page first.

Ah, I didn't know there was a difference between using the flasher or the dashboard, thought it would do the same. Have just reflashed them both from the flash page instead.

Should I also not adopt the sensors into ESPHome either as we test them now, because it might flash them back to the old yaml?

You should be able to adopt them without any problem so long as you don't install the firmware.

How are your unavailable issues now?

asunners commented 1 year ago

I cam here to see if anyone else was having the same problem with offline/online bouncing. I am seeing it intermittently as well.

I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again.

Is it weird that watching the logs means it doesn’t fail and stopping the logging “causes” it to fail? Any chance that’s related?

EverythingSmartHome commented 1 year ago

I cam here to see if anyone else was having the same problem with offline/online bouncing. I am seeing it intermittently as well.

I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again.

Is it weird that watching the logs means it doesn’t fail and stopping the logging “causes” it to fail? Any chance that’s related?

That is indeed very strange - when you stop viewing the logs, do you unplug from your computer and plug it back into a standalone power source?

Could you possibly try a different power supply and cable?

GuySie commented 1 year ago

I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again.

Are you watching the logs over USB or wirelessly? I think the wireless logs won't show you what happens around the reboots cos it takes down the wifi connection so that data never gets sent. I never got any useful data from the wireless logs, in any case.

asunners commented 1 year ago

I cam here to see if anyone else was having the same problem with offline/online bouncing. I am seeing it intermittently as well. I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again. Is it weird that watching the logs means it doesn’t fail and stopping the logging “causes” it to fail? Any chance that’s related?

That is indeed very strange - when you stop viewing the logs, do you unplug from your computer and plug it back into a standalone power source?

Could you possibly try a different power supply and cable?

I have had it both plugged into the computer directly and have used an external power supply with two different cables. But, I believe I was watching the logs wirelessly. It’s my default connection for my other devices so probably was something I picked without thinking. It seemed like the uart-debug messages came up every second very consistently. I can’t promise I checked every one so will try the same experiment later today both connected directly and connected wirelessly.

asunners commented 1 year ago

I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again.

Are you watching the logs over USB or wirelessly? I think the wireless logs won't show you what happens around the reboots cos it takes down the wifi connection so that data never gets sent. I never got any useful data from the wireless logs, in any case.

I’ll try direct connected later today.

EverythingSmartHome commented 1 year ago

I tried re-flashing from the web page. No effect. Tried a second time, no effect. I then tried re flashing (OTA, successful) from ESPHome in HA, no effect. I then tried to catch the problem by watching the logs and it went for over 15 minutes without failing. I then stopped the logs and within minutes saw the device went offline and it came back up in a matter of seconds. (of course, right? LOL) I then tried watching the logs again for over 30 minutes and it didn’t fail. I stopped the logs again and guess what? Yep, it failed again 1 minute later. It took 2 minutes to come back up again.

Are you watching the logs over USB or wirelessly? I think the wireless logs won't show you what happens around the reboots cos it takes down the wifi connection so that data never gets sent. I never got any useful data from the wireless logs, in any case.

I’ll try direct connected later today.

Ah yes you will need to directly connect via USB to get all of the logs otherwise they won't be available when it reboots and you'll miss if there was a crash.

If you can get the USB logs that would be very useful thanks!

GuySie commented 1 year ago

How are your unavailable issues now?

We're now at 24h without reboots for both sensors, so it looks like your new fw fixed it!

asunners commented 1 year ago

OK, ran a test this morning and let the sensor run no logging for 30 min and saw the device going unavailable in HA as I had previously. I then started collecting logs to see if I got the same weird behaviour as before with the device not going unavailable. Good news, the device still went unavailable - LOL. I was able to capture the connection with HA being reset and reconnecting so it appears it wasn't the device rebooting, but rather the HA connection going offline.

`D][uart_debug:158]: <<< "$JYBSS,0, , , *\r\n"

[D][api:102]: Accepted ::FFFF:10.1.1.227 [D][api.connection:918]: Home Assistant 2022.12.7 (::FFFF:10.1.1.227): Connected successfully

[D][binary_sensor:036]: ' mmWave': Sending state ON

[W][api.connection:081]: Home Assistant 2022.12.7 (::FFFF:10.1.1.227): Connection reset

[D][uart_debug:158]`

and then I saw the connection reset and it reconnected successfully.

`D][uart_debug:158]: <<< "$JYBSS,0, , , *\r\n"

[D][api:102]: Accepted ::FFFF:10.1.1.227 [D][api.connection:918]: Home Assistant 2022.12.7 (::FFFF:10.1.1.227): Connected successfully

[D][binary_sensor:036]: ' mmWave': Sending state ON

[W][api.connection:081]: Home Assistant 2022.12.7 (::FFFF:10.1.1.227): Connection reset

[D][uart_debug:158]`

I haven't seen the HA connection resetting and reconnecting before. Is this something to do with my HA instance, the ESPHome integration, or something else?

asunners commented 1 year ago

Ooops, guess I don't know how to paste code :( Sorry about the formatting. There are line breaks in the attached file.

everything-presence-one-d52998_logs.txt

EverythingSmartHome commented 1 year ago

Ooops, guess I don't know how to paste code :( Sorry about the formatting. There are line breaks in the attached file.

everything-presence-one-d52998_logs.txt

I noted this issue which is pretty recent and seems relevant to what you are experiencing:

https://github.com/esphome/issues/issues/3108

And this comment within that thread that seems to have resolved issues, do you want to give this a try to see if it resolves?

https://github.com/esphome/issues/issues/3108#issuecomment-1079207220

asunners commented 1 year ago

Thanks for those links! I'm diving down the rabbit hole of reconnects and appreciate you pointing me in the right direction.

EverythingSmartHome commented 1 year ago

Thanks for those links! I'm diving down the rabbit hole of reconnects and appreciate you pointing me in the right direction.

No problem, I think this is a different problem you are experiencing but hopefully that link helps!

EverythingSmartHome commented 1 year ago

Closing down now as firmware update disabling web_server seems to have resolved issue.

mister2d commented 12 months ago

@GuySie @PeterBurner @CMDR-Sloma If you are still having problems, please update to the latest firmware available through the flasher. I just updated this right now.

I'm having this issue and I don't know why. My EP1 constantly reboots after being healthy for a period of time. Home Assistant eventually receives enough data via MQTT but the graphs have gaps everywhere due to the restarts. Any suggestions to get my sensors working again? I've tried a second, previously unused, sensor with the same result.

I'm still on Esphome 5.1, but I don't know what this above flasher is due to the page going to 404. Here is my config and associated logs:

substitutions:
  name: ep1-kitchen-294078
  friendly_name: ep1-kitchen
  project_name: "Everything Smart Technology.Everything Presence One"
  project_version: "1.1.6"

packages:
  Everything_Smart_Technology.Everything_Presence_One: github://everythingsmarthome/presence-one/everything-presence-one.yaml@main

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
  project:
    name: ${project_name}
    version: ${project_version}

mqtt:
  broker: mqtt.service.consul

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

[D][mqtt:154]: Resolved broker IP address to 127.0.0.250
[I][mqtt:184]: Connecting to MQTT...
[I][mqtt:224]: MQTT Connected!

abort() was called at PC 0x401f5f33 on core 1

Backtrace:0x40083c19:0x3ffcd7800x4009364d:0x3ffcd7a0 0x40098d89:0x3ffcd7c0 0x401f5f33:0x3ffcd840 0x401f5f7a:0x3ffcd860 0x401f6073:0x3ffcd880 0x401f5fd2:0x3ffcd8a0 0x401f6509:0x3ffcd8c0 0x401f664c:0x3ffcd8e0 0x401f67c9:0x3ffcd920 0x400df7d3:0x3ffcd940 0x400df813:0x3ffcd960 0x400dfa56:0x3ffcd980 0x400dfa32:0x3ffcd9a0 0x400dfa32:0x3ffcd9c0 0x400dfb87:0x3ffcd9e0 0x400e4baf:0x3ffcda60 0x400e565b:0x3ffcdaa0 0x400e56f2:0x3ffcdaf0 0x4021105d:0x3ffcdb10 0x400ed28c:0x3ffcdb30 0x400f014a:0x3ffcdb60 0x40101659:0x3ffcdb80 

ELF file SHA256: 0000000000000000

Rebooting...
[I][logger:262]: Log initialized
[C][ota:469]: There have been 2 suspected unsuccessful boot attempts.
[D][esp32.preferences:114]: Saving 1 preferences to flash...
[D][esp32.preferences:143]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[I][app:029]: Running through setup()...
[I][i2c.arduino:183]: Performing I2C bus recovery
[C][uart.arduino_esp32:077]: Setting up UART...
[C][status_led:055]: Setting up Status LED...
[D][binary_sensor:034]: 'mmWave': Sending initial state OFF
[D][number:012]: 'mmWave distance': Sending state 315.000000
[D][number:012]: 'mmWave off latency': Sending state 15.000000
[D][number:012]: 'mmWave on latency': Sending state 0.000000
[D][number:012]: 'mmWave sensitivity': Sending state 7.000000
[D][number:012]: 'Temperature Offset': Sending state 0.000000
[D][number:012]: 'Humidity Offset': Sending state 0.000000
[E][shtcx:080]: sensor polling failed
[D][sensor:094]: 'Temperature': Sending state nan °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state nan % with 1 decimals of accuracy
[D][number:012]: 'Illuminance Offset': Sending state 0.000000
[C][light:035]: Setting up light 'ESP32 status LED'...
[D][status_led:038]: 'ESP32 status LED': Setting initial state
[D][light:035]: 'ESP32 status LED' Setting:
[D][light:040]:   Color mode: 
[C][light:035]: Setting up light 'mmWave LED'...
[D][light:035]: 'mmWave LED' Setting:
[D][light:040]:   Color mode: 
[C][shtcx:028]: Setting up SHTCx...
[C][shtcx:056]:   Device identified: SHTC3 (0887)
[C][bh1750.sensor:041]: Setting up BH1750 'Illuminance'...
[C][esp32_ble:027]: Setting up BLE...
[D][esp32_ble:043]: BLE setup complete
[D][esp32_ble_server:034]: Setting up BLE Server...
[W][shtcx:073]: Retrying to reconnect the sensor.
[D][esp32.preferences:114]: Saving 1 preferences to flash...
[D][esp32.preferences:143]: Saving 1 preferences to flash: 1 cached, 0 written, 0 failed
[D][shtcx:100]: Got temperature=31.78°C humidity=43.25%
[D][sensor:094]: 'Temperature': Sending state 28.77879 °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state 48.24646 % with 1 decimals of accuracy
[D][switch:016]: 'mmWave sensor' Turning OFF.
[D][switch:055]: 'mmWave sensor': Sending state OFF
[  2008][E][Wire.cpp:513] requestFrom(): i2cRead returned Error 263
[E][shtcx:094]: sensor read failed
[D][sensor:094]: 'Temperature': Sending state nan °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state nan % with 1 decimals of accuracy
[D][uart_debug:158]: >>> "sensorStop"
[D][uart_debug:158]: <<< "sensorStop\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][bh1750.sensor:159]: 'Illuminance': Got illuminance=0.9lx
[D][sensor:094]: 'Illuminance': Sending state 0.90551 lx with 1 decimals of accuracy
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][uart_debug:158]: >>> "setLedMode 1 1"
[D][uart_debug:158]: <<< "setLedMode 1 1\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][esp32_ble_server:071]: BLE server setup successfully
[C][wifi:038]: Setting up WiFi...
[C][wifi:039]:   Local MAC: DE:AD:BE:EF:DE:AD
[D][wifi:387]: Starting scan...
[D][esp32_improv.component:201]: Setting Improv to start
[D][esp32_improv.component:076]: Service started!
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][uart_debug:158]: >>> "saveConfig"
[D][uart_debug:158]: <<< "saveConfig\r\n"
[D][uart_debug:158]: <<< "save cfg complete\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][wifi:402]: Found networks:
[I][wifi:446]: - 'IOTee' [redacted]▂▄▆█
[D][wifi:447]:     Channel: 1
[D][wifi:448]:     RSSI: -67 dB
[I][wifi:446]: - 'IOTee' [redacted]▂▄▆█
[D][wifi:447]:     Channel: 11
[D][wifi:448]:     RSSI: -71 dB
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[I][wifi:258]: WiFi Connecting to 'IOTee'...
[D][switch:012]: 'mmWave sensor' Turning ON.
[D][switch:055]: 'mmWave sensor': Sending state ON
[I][wifi:519]: WiFi Connected!
[C][wifi:363]:   Local MAC: DE:AD:BE:EF:DE:AD
[C][wifi:364]:   SSID: [redacted]
[C][wifi:365]:   IP Address: 127.0.0.6
[C][wifi:367]:   BSSID: [redacted]
[C][wifi:368]:   Hostname: 'ep1-kitchen-294078'
[C][wifi:370]:   Signal strength: -68 dB ▂▄▆█
[C][wifi:374]:   Channel: 1
[C][wifi:375]:   Subnet: 255.255.255.0
[C][wifi:376]:   Gateway: 127.0.0.0
[C][wifi:377]:   DNS1: 127.0.0.6
[C][wifi:378]:   DNS2: 1.1.1.1
[D][wifi:528]: Disabling AP...
[D][uart_debug:158]: >>> "sensorStart"
[C][ota:093]: Over-The-Air Updates:
[C][ota:094]:   Address: ep1-kitchen-294078.home.lan:3232
[W][ota:103]: Last Boot was an unhandled reset, will proceed to safe mode in 8 restarts
[C][api:025]: Setting up Home Assistant API server...
[C][mqtt:029]: Setting up MQTT...
[D][mqtt:121]: Resolving MQTT broker IP address...
[D][uart_debug:158]: <<< "sensorStart\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][mqtt:154]: Resolved broker IP address to 127.0.0.250
[I][mqtt:184]: Connecting to MQTT...
[D][uart_debug:158]: <<< "leapMMW:/>"
[I][mqtt:224]: MQTT Connected!

abort() was called at PC 0x401f5f33 on core 1

Backtrace:0x40083c19:0x3ffcd5500x4009364d:0x3ffcd570 0x40098d89:0x3ffcd590 0x401f5f33:0x3ffcd610 0x401f5f7a:0x3ffcd630 0x401f6073:0x3ffcd650 0x401f5fd2:0x3ffcd670 0x401f6509:0x3ffcd690 0x401f664c:0x3ffcd6b0 0x401f67c9:0x3ffcd6f0 0x400df7d3:0x3ffcd710 0x400df820:0x3ffcd730 0x400dfa56:0x3ffcd750 0x400dfa32:0x3ffcd770 0x400dfa32:0x3ffcd790 0x400dfb87:0x3ffcd7b0 0x400e4baf:0x3ffcd830 0x400e565b:0x3ffcd870 0x400e56a3:0x3ffcd8c0 0x4021105d:0x3ffcd8e0 0x400ee074:0x3ffcd900 0x400f45ea:0x3ffcd930 0x4010164a:0x3ffcdb80 

ELF file SHA256: 0000000000000000

Rebooting...
[I][logger:262]: Log initialized
[C][ota:469]: There have been 3 suspected unsuccessful boot attempts.
[D][esp32.preferences:114]: Saving 1 preferences to flash...
[D][esp32.preferences:143]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[I][app:029]: Running through setup()...
[I][i2c.arduino:183]: Performing I2C bus recovery
[C][uart.arduino_esp32:077]: Setting up UART...
[C][status_led:055]: Setting up Status LED...
[D][binary_sensor:034]: 'mmWave': Sending initial state OFF
[D][number:012]: 'mmWave distance': Sending state 315.000000
[D][number:012]: 'mmWave off latency': Sending state 15.000000
[D][number:012]: 'mmWave on latency': Sending state 0.000000
[D][number:012]: 'mmWave sensitivity': Sending state 7.000000
[D][number:012]: 'Temperature Offset': Sending state 0.000000
[D][number:012]: 'Humidity Offset': Sending state 0.000000
[E][shtcx:080]: sensor polling failed
[D][sensor:094]: 'Temperature': Sending state nan °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state nan % with 1 decimals of accuracy
[D][number:012]: 'Illuminance Offset': Sending state 0.000000
[C][light:035]: Setting up light 'ESP32 status LED'...
[D][status_led:038]: 'ESP32 status LED': Setting initial state
[D][light:035]: 'ESP32 status LED' Setting:
[D][light:040]:   Color mode: 
[C][light:035]: Setting up light 'mmWave LED'...
[D][light:035]: 'mmWave LED' Setting:
[D][light:040]:   Color mode: 
[C][shtcx:028]: Setting up SHTCx...
[C][shtcx:056]:   Device identified: SHTC3 (0887)
[C][bh1750.sensor:041]: Setting up BH1750 'Illuminance'...
[C][esp32_ble:027]: Setting up BLE...
[D][esp32_ble:043]: BLE setup complete
[D][esp32_ble_server:034]: Setting up BLE Server...
[D][esp32.preferences:114]: Saving 1 preferences to flash...
[D][esp32.preferences:143]: Saving 1 preferences to flash: 1 cached, 0 written, 0 failed
[W][shtcx:073]: Retrying to reconnect the sensor.
[  1975][E][Wire.cpp:513] requestFrom(): i2cRead returned Error 263
[E][shtcx:094]: sensor read failed
[D][sensor:094]: 'Temperature': Sending state nan °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state nan % with 1 decimals of accuracy
[D][switch:016]: 'mmWave sensor' Turning OFF.
[D][switch:055]: 'mmWave sensor': Sending state OFF
[  3017][E][Wire.cpp:513] requestFrom(): i2cRead returned Error 263
[E][shtcx:094]: sensor read failed
[D][sensor:094]: 'Temperature': Sending state nan °C with 1 decimals of accuracy
[D][sensor:094]: 'Humidity': Sending state nan % with 1 decimals of accuracy
[D][uart_debug:158]: >>> "sensorStop"
[D][uart_debug:158]: <<< "sensorStop\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][bh1750.sensor:159]: 'Illuminance': Got illuminance=1.0lx
[D][sensor:094]: 'Illuminance': Sending state 1.01870 lx with 1 decimals of accuracy
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][uart_debug:158]: >>> "setLedMode 1 1"
[D][uart_debug:158]: <<< "setLedMode 1 1\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][esp32_ble_server:071]: BLE server setup successfully
[C][wifi:038]: Setting up WiFi...
[C][wifi:039]:   Local MAC: DE:AD:BE:EF:DE:AD
[D][wifi:387]: Starting scan...
[D][esp32_improv.component:201]: Setting Improv to start
[D][esp32_improv.component:076]: Service started!
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][uart_debug:158]: >>> "saveConfig"
[D][uart_debug:158]: <<< "saveConfig\r\n"
[D][uart_debug:158]: <<< "save cfg complete\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][uart_debug:158]: <<< "leapMMW:/>"
[D][wifi:402]: Found networks:
[I][wifi:446]: - 'IOTee' [redacted]▂▄▆█
[D][wifi:447]:     Channel: 1
[D][wifi:448]:     RSSI: -68 dB
[I][wifi:446]: - 'IOTee' [redacted]▂▄▆█
[D][wifi:447]:     Channel: 11
[D][wifi:448]:     RSSI: -71 dB
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[D][wifi:451]: - [redacted] [redacted]▂▄▆█
[I][wifi:258]: WiFi Connecting to 'IOTee'...
[D][switch:012]: 'mmWave sensor' Turning ON.
[D][switch:055]: 'mmWave sensor': Sending state ON
[I][wifi:519]: WiFi Connected!
[C][wifi:363]:   Local MAC: DE:AD:BE:EF:DE:AD
[C][wifi:364]:   SSID: [redacted]
[C][wifi:365]:   IP Address: 127.0.0.6
[C][wifi:367]:   BSSID: [redacted]
[C][wifi:368]:   Hostname: 'ep1-kitchen-294078'
[C][wifi:370]:   Signal strength: -66 dB ▂▄▆█
[C][wifi:374]:   Channel: 1
[C][wifi:375]:   Subnet: 255.255.255.0
[C][wifi:376]:   Gateway: 127.0.0.0
[C][wifi:377]:   DNS1: 127.0.0.6
[C][wifi:378]:   DNS2: 1.1.1.1
[D][wifi:528]: Disabling AP...
[D][uart_debug:158]: >>> "sensorStart"
[C][ota:093]: Over-The-Air Updates:
[C][ota:094]:   Address: ep1-kitchen-294078.home.lan:3232
[W][ota:103]: Last Boot was an unhandled reset, will proceed to safe mode in 7 restarts
[C][api:025]: Setting up Home Assistant API server...
[C][mqtt:029]: Setting up MQTT...
[D][mqtt:121]: Resolving MQTT broker IP address...
[D][uart_debug:158]: <<< "sensorStart\r\n"
[D][uart_debug:158]: <<< "Done\r\n"
[D][mqtt:154]: Resolved broker IP address to 127.0.0.250
[I][mqtt:184]: Connecting to MQTT...
[D][uart_debug:158]: <<< "leapMMW:/>"
[I][mqtt:224]: MQTT Connected!

abort() was called at PC 0x401f5f33 on core 1

Backtrace:0x40083c19:0x3ffcd5500x4009364d:0x3ffcd570 0x40098d89:0x3ffcd590 0x401f5f33:0x3ffcd610 0x401f5f7a:0x3ffcd630 0x401f6073:0x3ffcd650 0x401f5fd2:0x3ffcd670 0x401f6509:0x3ffcd690 0x401f664c:0x3ffcd6b0 0x401f67c9:0x3ffcd6f0 0x400df7d3:0x3ffcd710 0x400df813:0x3ffcd730 0x400dfa56:0x3ffcd750 0x400dfa32:0x3ffcd770 0x400dfa32:0x3ffcd790 0x400dfb87:0x3ffcd7b0 0x400e4baf:0x3ffcd830 0x400e565b:0x3ffcd870 0x400e56a3:0x3ffcd8c0 0x4021105d:0x3ffcd8e0 0x400ee074:0x3ffcd900 0x400f45ea:0x3ffcd930 0x4010164a:0x3ffcdb80 

ELF file SHA256: 0000000000000000

Rebooting...
[I][logger:262]: Log initialized
[C][ota:469]: There have been 4 suspected unsuccessful boot attempts.

EverythingSmartHome commented 11 months ago

@mister2d Since you are using custom firmware (MQTT is not the default), and using MQTT instead of the native API, you may want to check the docs here: https://esphome.io/components/mqtt.html

Note the warning at the top stating you need to disable the API when using MQTT.

mister2d commented 11 months ago

@mister2d Since you are using custom firmware (MQTT is not the default), and using MQTT instead of the native API, you may want to check the docs here: https://esphome.io/components/mqtt.html

Note the warning at the top stating you need to disable the API when using MQTT.

This makes sense but I don't have the API component defined in my configuration, and it's not straightforward how to disable the API from the esphome docs.

EverythingSmartHome commented 11 months ago

@mister2d If I might ask, is there a reason you'd want to use MQTT over the native API if you are using it with HA?

The config you posted above is just the shortened config, under the hood it's still using the full configuration located here

You can see the API line located in that config. If you want to disable the API, you will need to create your own config by coping the contents of the config linked above and making your changes (make sure to add WiFi sections) and then flash the EP1 with it.

mister2d commented 11 months ago

@mister2d If I might ask, is there a reason you'd want to use MQTT over the native API if you are using it with HA?

I have my other sensors posting to MQTT topics and was just making everything consistent with my EP1 sensors. I got it working with MQTT by copying the config contents without the includes. I definitely missed that initially.

While it works with MQTT it seems some entities are missing, so I've reverted to the Home Assistant API.

EverythingSmartHome / everything-presence-one

Sensors appear to crash and reboot regularly #1