Alternativ kannst du noch ins Logbuch der ESPHome Node schauen. Die Standard-Konfiguration enthält diesen Abschnitt:

esp32_ble_tracker:
  on_ble_advertise:
    then:
      - lambda: |-
          if (x.get_name().rfind("JK-", 0) == 0) {
            ESP_LOGI("ble_adv", "New JK-BMS found");
            ESP_LOGI("ble_adv", "  Name: %s", x.get_name().c_str());
            ESP_LOGI("ble_adv", "  MAC address: %s", x.address_str().c_str());
            ESP_LOGD("ble_adv", "  Advertised service UUIDs:");
            for (auto uuid : x.get_service_uuids()) {
              ESP_LOGD("ble_adv", "    - %s", uuid.to_string().c_str());
            }
          }

Dieser sorgt dafür, dass immer wenn der ESP eine BLE-Ankündigung empfängt und sie mit dem Gerätenamen "JK-" beginnt ein paar Meldungen ins Log schreibt. Die Zeile "MAC address: ..." enthaelt die MAC-Adresse des BMS. Alternativ kannst du dir eine beliebige Android App schnappen, welche in der Lage ist BLE-Geräte in der Luft aufzulisten. Sehr beliebt ist die App "nRF Connect for Mobile". Viel Erfolg!

So sollte der Stecker aussehen: https://raw.githubusercontent.com/syssi/esphome-jk-bms/main/images/circuit.jpg

@dremeier Der ESP32 hat eine GPIO-Matrix und kann deshalb per Software einen der drei Hardware-UARTs auf nahezu beliebige Pins routen. Beim ESP8266 war das anders (festverdrahtet). Ich bin gespannt, ob dein Konverter funktioniert. Ich habe leider schon von vielen rauchenden Komponenten gehoert, sobald der ESP vom DC/DC-Wandler direkt von der Batterie gespeist wurde. Ich hoffe, dass die galvanische Trennung (auf allen Ebenen?) insb. auf der Masse-Leitung zwischen Batterie- und "ESP" bzw. DC/DC-Wandler. Ich habe hier leider zu wenig Ahnung von Schaltkreisen um hier guten Input zu geben.

@dremeier Die GPIOs können für beliebige Zwecke zum Einsatz kommen. Durch die Konfiguration in der YAML wird definiert, ob sie zum Lauschen oder zum Sprechen zum Einsatz kommen sollen. Antwortet dein BMS nicht auf Anhieb, weil etwas "falsch" angeschlossen ist, dann verdrehst du entweder die Kabel oder vertauschst die GPIOs.

Sowas habe ich noch nie gemacht. Ich befürchte, dass es die YAML sehr unleserlich macht. Du wirst pro Sensor/Entität sog. Overrides der entsprechenden Eigenschaften ergänzen müssen. Hier die Dokumentation: https://esphome.io/components/mqtt.html#mqtt-component-base-configuration

Hier eine Vermutung, wie es dann pro Sensor aussehen würde (ungetestet!):

sensor:
  - platform: jk_bms_ble
    jk_bms_ble_id: bms0
    min_cell_voltage:
      name: "${name} min cell voltage"
      state_topic: bms1_min_cell_voltage

So sieht das Schnippsel aus, wenn man am ersten Sensor (min_cell_voltage) lauscht und pro Update einmal die LED blinken lässt:

output:
  - platform: gpio
    pin: GPIO27
    id: bluetoothled

sensor:
  - platform: jk_bms_ble
    jk_bms_ble_id: bms0
    min_cell_voltage:
      name: "${name} min cell voltage"
      on_value:
        then:
          - output.turn_on: bluetoothled
          - delay: 500ms
          - output.turn_off: bluetoothled
    max_cell_voltage:
      name: "${name} max cell voltage"
    min_voltage_cell:
      name: "${name} min voltage cell"
    max_voltage_cell:
      name: "${name} max voltage cell"
    # ...und die restlichen Sensoren...

Ggf. sollten wir die Bluetooth LED lieber an den Update-Event eines Sensors (z.B. total_voltage) hängen. Ich habe die Sorge, dass warum auch immer die BLE-Verbindung nicht zusammenbricht und trotzdem keine Daten vom BMS kommen. Über ein Blink per Sensor-Update hättest du einen besseren Herzschlag. Alternativ lötest du eine dritte LED an Board.

Diesen Abschnitt:

ble_client:
  - mac_address: ${mac_address}
    id: client0

bitte ersetzen durch diesen Abschnitt:

ble_client:
  - mac_address: ${mac_address}
    id: client0
    on_connect:
      then:
        - output.turn_on: bluetoothled
    on_disconnect:
      then:
        - output.turn_off: bluetoothled

output:
  - platform: gpio
    pin: GPIO27
    id: bluetoothled

Bitte den (bisher nicht erwähnten) Widerstand vergessen: https://techexplorations.com/guides/esp32/begin/digitalout/

Gut erkannt. Bitte umschiffen. Wenn du GPIO0 versehentlich (permant) auf Masse ziehst, dann bootet der ESP in Zukunft nur noch in den "Schreibe jetzt bitte neue Software drauf"-Modus anstatt die Anwendung zu starten.

@marco-3 Für WiFi/MQTT kannst du diesen Schnippsel nutzen:

status_led:
  pin:
    number: GPIO2
    inverted: true

Hier findest du eine Beschreibung, was er tut: https://esphome.io/components/status_led.html

Für Bluetooth solltest du dir einen Lötkolben schnappen und eine weitere LED an einen freien GPIO löten. Vorzugsweise eine Blaue. Daraufhin werde ich dir zeigen, wie man sich an den on_connect und on_disconnect-Callback des ble_client haengt, so dass man die LED an bzw. ausschaltet, sobald die Verbindung zum BMS steht/abbricht. (https://esphome.io/components/ble_client.html#on-connect)

In der YAML ist keine Anweisung enthalten, dass die LED gesteuert werden soll. Die Erklärung wird vielmehr sein: Eines der Boards besitzt eine TX-LED, welche leuchtet sobald Daten auf der seriellen Schnittstelle (GPIO1?) rausgeschrieben werden. Wenn du das Board über das Kabel flashst sollte sie flackern. Da der logger von ESPHome periodisch die Nachrichten auf die serielle Schnittstelle schreibt, leuchtet die LED im gleichen Takt.

Wir können die YAML-Konfiguration beliebig erweitern und mit einer Anweisung versehen, was mit der LED (an GPIO2 des D1 Mini ESP32) passieren soll.