Faster connect - no permanent connection

[henfri]

Hello Dirk,

I must admit that I am a bit cut-off the improvements of the past years (I use the latest code, but still a very early yaml file (added below for reference).
In https://www.mikrocontroller.net/topic/458856#8056425 there is a recent development, that allows a faster connection and this way does not require the permanent connection anymore, whilst still ensuring very rapid reaction.

am meisten hat beim connect ausgemacht, dass man nicht wartet. das 
schloss scheint hier nicht nach dem BT-standard zu arbeiten, und liefert 
nach dem connect keine Meldung dass man mit weiteren Befehlen loslegen 
könnte. Damit läuft das in ein timeout, es machen die BT-libraries aber 
erst nach 10sec Timeout (oder höher) weiter.
Das ausschlaggebende war dann der lib mitzugeben dass man keinen 
Response erwartet, explizit beim connect.

From command to lock moving it takes 2 seconds.

It would be great if we could have this in the esphome version as well.

esphome:
  name: esphome-eqiva-lock-hintertuer
  friendly_name: Eqiva Hintertuer




esp32:
  board: esp32dev
  framework:
    type: esp-idf
    # Uncomment below for ESP32-C3 if you have unexpected reboots when encrypting data
    # sdkconfig_options:
      # CONFIG_BOOTLOADER_WDT_TIME_MS: "60000"
  
# Enable logging
logger:
  
# Enable Home Assistant API
api:
  encryption:
    key: "/gpvP8+BDJuyMBhFE="

ota:
  - platform: esphome
    password: ""

web_server:
  include_internal: true
  local: false
  port: 80

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Eqiva-Wemos-Hintertuer"
    password: "x"
  # Activate scan only after wifi connect, see https://github.com/esphome/issues/issues/2941#issuecomment-1842369092
  on_connect:
    - esp32_ble_tracker.start_scan:
       continuous: true
    - eqiva_key_ble.connect:
       mac_address: !lambda 'return id(mac_address).state;' 
       user_id: !lambda 'return id(user_id).state;'
       user_key: !lambda 'return id(user_key).state;'
  on_disconnect:
    - esp32_ble_tracker.stop_scan:

      

#button, number and text input for pairing and setting mac/user_id/user-key via UI
button:
  - platform: template
    id: ble_settings
    name: BLE Settings _Save_
    icon: "mdi:content-save"
    on_press:
      - eqiva_key_ble.connect:
          mac_address: !lambda 'return id(mac_address).state;' 
          user_id: !lambda 'return id(user_id).state;'
          user_key: !lambda 'return id(user_key).state;'
  
  - platform: template
    id: ble_disconnect
    name: BLE Settings _Disconnect_
    icon: "mdi:clear"
    on_press:
      - eqiva_key_ble.disconnect:
  - platform: template
    id: ble_pair
    name: BLE Pair _Start_
    icon: "mdi:check-underline"
    on_press:
      - eqiva_key_ble.pair:
          card_key: !lambda 'return id(card_key).state;' 
          mac_address: !lambda 'return id(mac_address).state;'

  - platform: template
    id: lock_settings
    name: Lock Settings _Apply_
    icon: "mdi:check-underline"
    on_press:
      - eqiva_key_ble.settings:
          turn_left: !lambda 'return id(direction).state == "Left";' 
          key_horizontal: !lambda 'return id(position).state == "Horizontal";'
          lock_turns: !lambda 'return atoi(id(turns).state.c_str());'
  - platform: restart
    name: "Hintertür Controller Restart"

number:
  - platform: template
    mode: box
    name: BLE Settings User ID
    id: user_id
    max_value: 7
    min_value: 0
    step: 1
    optimistic: true
    restore_value: true

text:
  - platform: template
    mode: text
    name: BLE Settings Mac Address
    id: mac_address
    optimistic: true
    restore_value: true
  - platform: template
    mode: text
    name: BLE Settings User Key
    id: user_key
    optimistic: true
    restore_value: true
  - platform: template
    mode: text
    name: BLE Pair Card Key
    id: card_key
    optimistic: true

select:
  - platform: template
    name: Lock Settings Close Direction
    id: direction
    options:
     - "Left"
     - "Right"
    optimistic: true
  - platform: template
    name: Lock Settings Key Position
    id: position
    options:
     - "Vertical"
     - "Horizontal"
    optimistic: true
  - platform: template
    name: Lock Settings Turns
    id: turns
    options:
     - "1"
     - "2"
     - "3"
     - "4"
    optimistic: true




captive_portal:
    
external_components:
  source: github://digaus/esphome-components-eqiva
  # use refresh when you do not get latest version
  # refresh: 0s

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 200ms
    active: true

eqiva_ble:

eqiva_key_ble:
  id: key_ble
  # Below can left empty because we connect in wifi on_connect
  # mac_address: 00:12:
  # user_id: 0
  # user_key: x


text_sensor: 
  - platform: eqiva_key_ble
    mac_address: 
      name: "Mac Address"
    lock_status: 
      name: "Lock Status"
      id: lock_status
    low_battery:
      name: "Low Battery"
    lock_ble_state:
      name: "Lock BLE State"
    user_id:
      name: "User ID"
    user_key:
      name: "User Key"
    # on_raw_value:
            # then:   Do stuff on state change (!lambda "return x") 


# Call status every 4 minutes because lock seems to disconnect after 5 minutes of inactivity
# need to watch battery consumption, could also do some other time or present based approaches
time:
  - platform: sntp
    # ...
    on_time:
      # Every 4 minutes
      - seconds: 0
        minutes: /4
        then:
          - eqiva_key_ble.status:

# Make Fallensensor available            
binary_sensor:
  - platform: homeassistant
    name: "Hintertuer"
    entity_id: binary_sensor.eg_flur_reed_hintertuer_geschlossen
    id: Hintertuer_status

          
# Lock component for HA, can also create two locks and use connect service to connect/control two different locks
# One ESP per lock is still recommended
lock:
  - platform: template
    name: "Hintertür"
    lambda: |-
      if (id(Hintertuer_status).state) {
        return LOCK_STATE_UNLOCKED;
      } else  {
        return LOCK_STATE_LOCKED;
      }
    lock_action:
      - eqiva_key_ble.lock:
    unlock_action:
      - eqiva_key_ble.unlock:
    open_action:    
      - eqiva_key_ble.open:

[digaus]

I dont know what exactly he changed but I tried improving the speed and everytime I tried to send the first request faster it did not work correctly.

Used Claude to help me but without success.

[henfri]

Hi,

I have asked Gemini:

The timeout in Bluetooth libraries (often around 10 seconds) usually occurs because the system waits for a so-called "GATT Write Response" from the device after sending data. Since the Eqiva lock does not reply according to the standard (instead, it sends an asynchronous notification back later on), the ESP32 GATT system waits in vain until it hits the timeout.

I have updated the code in the ESPHome component accordingly. In the file [eqiva_key_ble.cpp](code-assist-path:c:\Users\hendr\Documents\eqiva\esphome-components-eqiva\components\eqiva_key_ble\eqiva_key_ble.cpp), the write command was changed from "with response" (ESP_GATT_WRITE_TYPE_RSP) to "without response" (ESP_GATT_WRITE_TYPE_NO_RSP):

// Before:
write->write_value((uint8_t *) (data.c_str()), 16, ESP_GATT_WRITE_TYPE_RSP);

// After:
write->write_value((uint8_t *) (data.c_str()), 16, ESP_GATT_WRITE_TYPE_NO_RSP);
As a result,the ESP32 now sends the pairing/connect commands(and all other fragments) to the lock without waiting for a formal Bluetooth protocol acknowledgment. The ESP32 routines can continue immediately, which should significantly improve connection and communication speeds and eliminate the hangs caused by timeouts.

See also:
https://esp32.com/viewtopic.php?t=2139

Did you try that?

Greetings,
Hendrik

[digaus]

Hi,

I have asked Gemini:

The timeout in Bluetooth libraries (often around 10 seconds) usually occurs because the system waits for a so-called "GATT Write Response" from the device after sending data. Since the Eqiva lock does not reply according to the standard (instead, it sends an asynchronous notification back later on), the ESP32 GATT system waits in vain until it hits the timeout.

I have updated the code in the ESPHome component accordingly. In the file [eqiva_key_ble.cpp](code-assist-path:c:\Users\hendr\Documents\eqiva\esphome-components-eqiva\components\eqiva_key_ble\eqiva_key_ble.cpp), the write command was changed from "with response" (ESP_GATT_WRITE_TYPE_RSP) to "without response" (ESP_GATT_WRITE_TYPE_NO_RSP):

// Before:
write->write_value((uint8_t *) (data.c_str()), 16, ESP_GATT_WRITE_TYPE_RSP);

// After:
write->write_value((uint8_t *) (data.c_str()), 16, ESP_GATT_WRITE_TYPE_NO_RSP);
As a result,the ESP32 now sends the pairing/connect commands(and all other fragments) to the lock without waiting for a formal Bluetooth protocol acknowledgment. The ESP32 routines can continue immediately, which should significantly improve connection and communication speeds and eliminate the hangs caused by timeouts.

See also: https://esp32.com/viewtopic.php?t=2139

Did you try that?

Greetings, Hendrik

The write itself is not the problem. Claude suggested the same but write is already fast (~100ms). The problem is the time it takes until I can send my first command (exchanging nonce). And I could not improve that.

[henfri]

Ok, for this, AI developed (done by Gemini, reviewed by Claude and Chatgpt):
ESP_GATTC_CONNECT_EVT fires (where the default MTU request is normally sent).

ESP_GATTC_OPEN_EVT fires (where ESPHome starts Service Discovery).

ESP_GATTC_CFG_MTU_EVT may fire later, but only stores the negotiated MTU value and does not participate in the connection state machine.

Since Service Discovery is triggered from ESP_GATTC_OPEN_EVT rather than ESP_GATTC_CFG_MTU_EVT, only CONNECT_EVT needs to be intercepted to suppress the MTU request.

By handling CONNECT_EVT and returning true, ESPHome skips the MTU negotiation while still allowing the normal OPEN_EVT → SEARCH_CMPL_EVT → ESTABLISHED flow to proceed. This mirrors the behavior that significantly improved connection times in the Python implementation and appears to avoid the 10-second delay observed with Eqiva locks.

The previously suggested manual call to esp_ble_gattc_search_service() was unnecessary and has therefore been removed.

In eqiva_key_ble.cpp

bool EqivaKeyBle::gattc_event_handler(esp_gattc_cb_event_t event, esp_gatt_if_t esp_gattc_if,
                                    esp_ble_gattc_cb_param_t *param) {
                                      
  this->mac_address_sensor_->publish_state(this->address_str());

  if (event == ESP_GATTC_CONNECT_EVT) {
      ESP_LOGI(TAG, "Intercepted ESP_GATTC_CONNECT_EVT: Bypassing MTU request.");
      this->conn_id_ = param->connect.conn_id;
      this->set_state(espbt::ClientState::CONNECTING);
      return true;
  }

Did you try that? I have no development environment.. Would take me a while to test that... Otherwise I would do.

Greetings,
Hendrik

[henfri]

I have implemented that on the ESP32 in standalone (no esphome) and it is fast:

--- Eqiva Lock Standalone ---
[Time] Systemzeit auf Kompilierungszeit gesetzt: 2026-06-04 23:21:35
Befehle: c=verbinden, d=trennen, l=sperren, u=entsperren, o=öffnen, s=status

[Eingabe] Befehl erhalten: t
[Test] Starte automatisierten Testlauf (Connect -> Befehl -> Disconnect)...
[Log] Verbindung zu 00:1a:22:18:a6:96 wird aufgebaut...
[Log] Status: Verbunden. (Dauer: 593 ms)
[Test] BLE-Verbindung physisch hergestellt nach 1566 ms (Handshake läuft...)
[Log] Sicherheits-Handshake: Nonce erhalten (User ID: 1). Fordere Status an... (Dauer ab Connect: 1611 ms)
[Log] Sende Befehl: STATUS ANFORDERN...
[Log] Befehl [STATUS ANFORDERN] -> Status erhalten: ENTRIEGELT (Zeit ab Befehlsstart: 60 ms)
>>> ZUSTAND: ENTRIEGELT (Batterie: OK)
[Test] Initialer Zustand: ENTRIEGELT. Sende Befehl: SPERREN...
[Log] Sende Befehl: SPERREN...
[Log] Befehl [SPERREN] -> Status erhalten: IN BEWEGUNG (Zeit ab Befehlsstart: 78 ms)
>>> ZUSTAND: IN BEWEGUNG (Batterie: OK)
[Test] Latenz bis Motorstart (Verbinden + Handshake + Befehl): 1762 ms
[Log] Schloss meldet Statusänderung (STATUS_CHANGED). Fordere aktuellen Status an...
[Log] Sende Befehl: STATUS ANFORDERN...
[Log] Befehl [STATUS ANFORDERN] -> Status erhalten: VERRIEGELT (Zeit ab Befehlsstart: 46 ms)
>>> ZUSTAND: VERRIEGELT (Batterie: OK)
[Test] Zielzustand VERRIEGELT erreicht! Gesamtzeit (inkl. Drehung): 5223 ms
[Log] Status: Verbindung getrennt. (Grund: 534)

Here is what Gemini suggests, in order to implement this in ESPHome:
esphome_optimization_notes.md

And here the important optimizations of my code and a benchmark quantifying the contribution of each of the points:
benchmark.txt

Happy to share my complete code.

Greetings,
Hendrik

[henfri]

Last post for today (Source: gemini):

Wie die ESPHome-Verbindung im Detail abläuft:

1. ESP_GATTC_CONNECT_EVT: Sobald die physikalische Bluetooth-Verbindung steht, sendet der Stack dieses Event. ESPHome reagiert darauf standardmäßig so:

   case ESP_GATTC_CONNECT_EVT: {
     ...
     this->conn_id_ = param->connect.conn_id;
     auto ret = esp_ble_gattc_send_mtu_req(this->gattc_if_, param->connect.conn_id);
     ...
   }

   Hier wird die MTU-Anfrage losgeschickt, die das Eqiva-Schloss blockiert.
2. ESP_GATTC_OPEN_EVT: Kurz darauf meldet der Stack, dass der GATT-Kanal geöffnet ist:

   case ESP_GATTC_OPEN_EVT: {
     ...
     this->set_state(espbt::ClientState::CONNECTED);
     ...
     this->log_event_("Searching for services");
     esp_ble_gattc_search_service(esp_gattc_if, param->open.conn_id, nullptr);
     break;
   }

   Wichtig: ESPHome wartet im ESP_GATTC_OPEN_EVT-Handler nicht darauf, dass die MTU-Verhandlung abgeschlossen ist. Es startet die Service-Discovery (esp_ble_gattc_search_service) sofort!
3. Warum es ohne Fix hängt: Da ESPHome im ersten Schritt die MTU-Anfrage gesendet hat und das Schloss nicht antwortet, wartet der BLE-Stack von ESP-IDF intern auf das Timeout (10 Sekunden). Während dieser Wartezeit ist die Warteschlange (GATT queue) blockiert. Die unmittelbar danach gestartete Service-Discovery wird deshalb erst nach dem 10-Sekunden-Timeout ausgeführt.

Warum der Intercept-Fix den Hang löst:

Wenn wir das ESP_GATTC_CONNECT_EVT in Deiner Custom Component abfangen und true zurückgeben, passiert Folgendes:

• Wir setzen die Verbindungs-ID (this->conn_id_) und den Zustand manuell.
• Durch das return true; verhindern wir, dass der Event-Handler der Basisklasse (BLEClientBase::gattc_event_handler) für dieses Event ausgeführt wird. Es wird kein MTU-Request gesendet.
• Sobald ESP_GATTC_OPEN_EVT eintrifft, leiten wir es normal an die Basisklasse weiter. Diese sieht den Zustand CONNECTING, setzt ihn auf CONNECTED und startet sofort und ohne jede Verzögerung die Service-Discovery, da der GATT-Kanal nicht durch eine ausstehende MTU-Verhandlung blockiert ist.
• Der Event ESP_GATTC_CFG_MTU_EVT (MTU-Konfiguration) wird zwar nie ausgelöst, aber dieser setzt in ESPHome ohnehin nur eine informative Variable (this->mtu_) und steuert keinerlei Logik.

---

Empfohlene Implementierung in Deiner Custom Component

Du kannst diesen Fix direkt in Deiner Custom Component in eqiva_key_ble.cpp einbauen, ohne den Core von ESPHome patchen zu müssen:

bool EqivaKeyBle::gattc_event_handler(esp_gattc_cb_event_t event, esp_gatt_if_t esp_gattc_if,
                                    esp_ble_gattc_cb_param_t *param) {
                                      
  this->mac_address_sensor_->publish_state(this->address_str());

  // 1. Intercept CONNECT_EVT um MTU-Request zu blockieren
  if (event == ESP_GATTC_CONNECT_EVT) {
    if (this->check_addr(param->connect.remote_bda)) {
      this->conn_id_ = param->connect.conn_id;
      this->set_state(espbt::ClientState::CONNECTING);
      ESP_LOGD(TAG, "Bypassing MTU request for Eqiva Lock on CONNECT event.");
      return true; // Verhindert, dass BLEClientBase den MTU-Request sendet
    }
  }

  // 2. Alle anderen Events normal an die Basisklasse weitergeben
  if (!BLEClientBase::gattc_event_handler(event, esp_gattc_if, param))
    return false;

  this->lock_ble_state_sensor_->publish_state(getClientState());

  switch (event) {
    // ... restlicher Switch-Block bleibt unverändert

[digaus]

[23:57:44.009][I][esp32_ble_client:126]: [0] [00:1A:22:18:45:9A] 0x00 Connecting
[23:57:44.025][D][ESP Eqiva:165]:  Address: 00:1A:22:18:45:9A, 00:1A:22:18:45:9A
[23:57:44.123][D][esp32_ble_tracker:169]: connecting: 1, discovered: 0, disconnecting: 0, active: 0
[23:57:44.124][S][text_sensor]: 'Lock BLE State' >> 'CONNECTING'
[23:57:47.283][D][esp32_ble_client:212]: [0] [00:1A:22:18:45:9A] ESP_GATTC_CONNECT_EVT
[23:57:47.283][D][eqiva_key_ble:233]: OTHER EVENT 40
[23:57:47.283][D][esp32_ble_client:212]: [0] [00:1A:22:18:45:9A] ESP_GATTC_OPEN_EVT
[23:57:47.283][I][esp32_ble_client:344]: [0] [00:1A:22:18:45:9A] Connection open
[23:57:47.289][D][esp32_ble_client:208]: [0] [00:1A:22:18:45:9A] Searching for services
[23:57:47.289][D][eqiva_key_ble:233]: OTHER EVENT 2
[23:57:47.289][D][esp32_ble_tracker:169]: connecting: 0, discovered: 0, disconnecting: 0, active: 1
[23:57:47.289][S][text_sensor]: 'Mac Address' >> '00:1A:22:18:45:9A'
[23:57:47.289][S][text_sensor]: 'Lock BLE State' >> 'CONNECTED'
[23:57:48.489][D][eqiva_key_ble:233]: OTHER EVENT 46
[23:57:48.710][D][eqiva_key_ble:064]: ESP_GATTC_REG_FOR_NOTIFY_EVT
[23:57:48.711][D][eqiva_key_ble:064]: ESP_GATTC_REG_FOR_NOTIFY_EVT
[23:57:48.711][D][eqiva_key_ble:064]: ESP_GATTC_REG_FOR_NOTIFY_EVT
[23:57:48.716][D][eqiva_key_ble:064]: ESP_GATTC_REG_FOR_NOTIFY_EVT
[23:57:48.716][D][eqiva_key_ble:064]: ESP_GATTC_REG_FOR_NOTIFY_EVT
[23:57:48.716][D][esp32_ble_client:212]: [0] [00:1A:22:18:45:9A] ESP_GATTC_SEARCH_CMPL_EVT
[23:57:48.716][I][esp32_ble_client:465]: [0] [00:1A:22:18:45:9A] Service discovery complete
[23:57:48.717][D][eqiva_key_ble:327]: Start send message
[23:57:48.717][D][eqiva_key_ble:352]: Start create fragments
[23:57:48.717][D][eqiva_key_ble:398]: Check send frag: not-empty, not-sending
[23:57:48.717][I][eqiva_key_ble:406]: Sending: 1073671616
[23:57:48.719][I][eqiva_key_ble:365]: Retaining message...
[23:57:48.719][I][eqiva_key_ble:382]: Reason: exchanging nonce
[23:57:48.719][I][eqiva_key_ble:385]: Reason: no remote session
[23:57:48.719][D][esp32_ble_client:411]: [0] [00:1A:22:18:45:9A] cfg_mtu status 0, mtu 23
[23:57:48.721][D][eqiva_key_ble:233]: OTHER EVENT 18
[23:57:48.721][D][eqiva_key_ble:233]: OTHER EVENT 38
[23:57:48.721][S][text_sensor]: 'Mac Address' >> '00:1A:22:18:45:9A'
[23:57:48.721][S][text_sensor]: 'Lock BLE State' >> 'ESTABLISHED'
[23:57:48.727][D][eqiva_key_ble:068]: ESP_GATTC_WRITE_CHAR_EVT
[23:57:48.727][I][eqiva_key_ble:070]: Send successfull: 190 | 190 | 0
[23:57:48.727][D][eqiva_key_ble:398]: Check send frag: empty, not-sending
[23:57:48.727][D][eqiva_key_ble:080]: ESP_GATTC_NOTIFY_EVT
[23:57:48.729][D][eqiva_key_ble:089]: LAST
[23:57:48.729][D][eqiva_key_ble:157]: Case 0x03
[23:57:48.729][D][eqiva_key_ble:165]: Nonce exchanged: 12F88A4805DE40B9
[23:57:48.729][D][eqiva_key_ble:166]: Remote user_id: 1
[23:57:48.730][D][eqiva_key_ble:327]: Start send message
[23:57:48.730][D][eqiva_key_ble:352]: Start create fragments
[23:57:48.730][D][eqiva_key_ble:398]: Check send frag: not-empty, not-sending
[23:57:48.730][I][eqiva_key_ble:406]: Sending: 1073672572
[23:57:48.734][D][eqiva_key_ble:398]: Check send frag: empty, sending
[23:57:48.780][S][text_sensor]: 'Mac Address' >> '00:1A:22:18:45:9A'
[23:57:48.781][S][text_sensor]: 'Lock BLE State' >> 'ESTABLISHED'
[23:57:48.781][S][text_sensor]: 'Current User Key' >> 'xxxxx'
[23:57:48.781][S][text_sensor]: 'Current User ID' >> '1'
[23:57:48.903][D][eqiva_key_ble:076]: ESP_GATTC_WRITE_DESCR_EVT
[23:57:48.903][D][eqiva_key_ble:068]: ESP_GATTC_WRITE_CHAR_EVT
[23:57:48.903][I][eqiva_key_ble:070]: Send successfull: 190 | 190 | 0
[23:57:48.903][D][eqiva_key_ble:398]: Check send frag: empty, not-sending
[23:57:48.907][D][eqiva_key_ble:080]: ESP_GATTC_NOTIFY_EVT
[23:57:48.907][D][eqiva_key_ble:089]: LAST
[23:57:48.907][D][eqiva_key_ble:110]: # Auth value: 
[23:57:48.907][D][eqiva_key_ble:111]: A649D68D
[23:57:48.911][D][eqiva_key_ble:114]: # Crypted data: 
[23:57:48.911][D][eqiva_key_ble:115]: ED3CC4E453D90195
[23:57:48.911][D][eqiva_key_ble:128]: # Decrypted: 
[23:57:48.911][D][eqiva_key_ble:129]: 71010B0010170000
[23:57:48.912][D][eqiva_key_ble:188]: Case 0x83
[23:57:48.912][D][eqiva_key_ble:218]: # Lock state: 3
[23:57:48.912][D][eqiva_key_ble:219]: # Battery low: false
[23:57:48.912][D][eqiva_key_ble:398]: Check send frag: empty, not-sending

-> <5 seconds on current esphome implementation. (Added connect call now but dont know if that improved anything)

The suggested fix was also provided by Claude but does not improve connection speed. You can just fork this repo and try the changes yourself. Feel free to post a PR if you can improve it.

[henfri]

Hi Dirk,

I did make a PR.
#51

This is not as fast as my standalone implementation, this is due to Wifi and BLE sharing the same Antenna. If I activate Wifi in the standalone implementation, I also lose about 800ms.
I have tried to disconnect wifi when receiving a command, but that brings no benefit (and quite a few disadvantages)

Greetings,
Hendrik

[digaus]

Hi Dirk,

I did make a PR. #51

This is not as fast as my standalone implementation, this is due to Wifi and BLE sharing the same Antenna. If I activate Wifi in the standalone implementation, I also lose about 800ms. I have tried to disconnect wifi when receiving a command, but that brings no benefit (and quite a few disadvantages)

Greetings, Hendrik

Thanks. Using caches for the read/write handles was also suggested but I deemed the minimal time benefit not worth the effort. With all changes combined it looks like it might save a second.

Looks like you hardcoded auto disconnect in your latest force push. Mistake?

Maybe add a flag "disconnectTimeout" which decides if you stay connected or not. If it is not set the default would be to refresh status every 4 minutes and stay connected.

[henfri]

Yes, that was by mistake ant I am already working on that.

[henfri]

also I have the latency test (.run_test) still in the code. Shall we keep that for future use?

[henfri]

See new PR
#52