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

@dieter_p Hallo Dieter! Ich kann deine Annahmen nur bestätigen: Die Implementierung kann unabhängig oder auch ganze ohne eine Heimautomation genutzt werden. Man hat die Möglichkeit alle Messwerte über einen MQTT-Broker abzusetzen oder Schalter/Einstellungen über MQTT zu verändern. Die geposteten Logbuch-Zeilen scheinen ioBroker spezifisch zu sein und ich weiss nicht, was sie bedeuten.

@dieter_p said in JK-BMS über RS485 mit ESPHome auslesen:

Was mich noch wundert: Kann mich nicht erinnern irgendwo mein Settings-Kennwort eingetragen zu haben, trotzdem hat man Vollzugriff aufs BMS?

Das Passwort in der Android App ist leider Augenwischerei. Wenn du es setzt, dann wird es zwar auf dem BMS gespeichert. Um es zu validieren, wird es in Plaintext per Bluetooth abgerufen und in der App gegen deine Eingabe verglichen. Stimmt das Passwort, dann bekommst du Zugritt zur jeweiligen View/Funktion (in der App). Per Blueooth akzeptiert das BMS immer jegliche Befehle und unterzieht sie keiner Passwortüberprüfung.

@dieter_p Hallo Dieter! Ich kann deine Annahmen nur bestätigen: Die Implementierung kann unabhängig oder auch ganze ohne eine Heimautomation genutzt werden. Man hat die Möglichkeit alle Messwerte über einen MQTT-Broker abzusetzen oder Schalter/Einstellungen über MQTT zu verändern. Die geposteten Logbuch-Zeilen scheinen ioBroker spezifisch zu sein und ich weiss nicht, was sie bedeuten.

@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.