Fix for #12: Transition from "Configuring" to "Ready" due to "Configured" event not possible #13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix_issue_12"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This pull request fixes #12.
The root cause was
BLE_HandleCommonEvents()was causing BLE events to be marked as "not new" byBLE_IsPacketNew(), even though these packets were left unhandled by the common event handler.The solution is to separate the querying of whether a packet is new from the marking it as already seen, since we don't want to mark a packet as seen until it has been properly handled. I added the function
BLE_RememberPacket()for the latter purpose.I also cleaned up some of the logging code, now that logging is configurable (on ESP32 platform, anyway).
@ -54,9 +54,6 @@ bool BLE_IsPacketNew(const uint8_t *sender_BD_ADDR,BLE_PacketType_T packet_type,uint8_t event_number){//esp_log_level_set("BLE", ESP_LOG_DEBUG);This can now be done from the serial console for ESP32: see Software/2024A-SW#11.
@ -121,0 +121,4 @@if (result != SYSTEMK_RESULT_EVENT_NOT_HANDLED){BLE_RememberPacket(event_packet->BD_ADDR, BLE_PACKET_TYPE_EVENT, event_packet->event_number);🔑 This is the key: only remember packets that have been handled, so state-specific handlers can still call
BLE_IsPacketNew()and get the correct answer.@ -206,6 +206,8 @@ void HandleBLETagPacket(const BLE_TagPacket_T *const packet){if (BLE_IsPacketNew(packet->BD_ADDR, BLE_PACKET_TYPE_TAG, packet->event_number)){BLE_RememberPacket(packet->BD_ADDR, BLE_PACKET_TYPE_TAG, packet->event_number);Since we split out the functionality of
BLE_RememberPacket()fromBLE_IsPacketNew(), we need to add it back in again everywhere it is needed.And all this time I thought my Konfigurator was broken.