* Prep-work for datetime entities
* Fix some includes and remove some restrictions on printing time on displays
* format
* format
* More formatting
* Move function contents
* Ignore clang-tidy
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.
Stefan Rado