mirror of
https://github.com/esphome/esphome.git
synced 2025-02-20 20:08:20 +00:00
7963abb27a
There is a race condition where a BedJet unit previously had its BLE "notify" flag enabled, and it continues to broadcast these notify packets even after the ESP32 (and BLEClient) goes away, such as during a crash or unplugging power. BLEClient::setup_priority=AFTER_BLUETOOTH, while BedJetHub::setup_priority=AFTER_WIFI. When the ESP32 starts back up again, BLEClient::setup() happens first and will start receiving the BLE notify packets almost immediately. Since we register the BLEClient child from codegen, BedJetHub is registered as a child already by this point, so BLEClient dispatches the notify status packet (and other gatt events) to the BedJetHub handler, even though BedJetHub::setup() has not been called yet. We initialize BedJetHub::codec_ in setup(), so if BLEClient starts dispatching gatt events before setup() is called, then codec_ will not be initialized yet. This causes BedJetHub's gatt notify handler to call `this->codec_->decode_notify()` on an uninitialized null pointer. Since invoking a method does not have to dereference the pointer, that method invocation is allowed; but later trying to access memory on that instance results in a StoreProhibited panic. Changing the BedJetHub's setup_priority to BLUETOOTH causes it to be setup before BLEClient, so that by the time BLEClient starts to receive BLE packets, BedJetHub is ready to receive them.
ESPHome 
Documentation: https://esphome.io/
For issues, please go to the issue tracker.
For feature requests, please see feature requests.