[How To] ESPhome mit BitShake SmartMeterReader Air

Hallo zusammen,

ich teile Mal hier die Konfig dafür, ich war mich nicht sicher ob es klappt und es hilft vielleicht manchen im Entscheidungsprozess. Und auf Feedback freue ich mich natürlich, ich bin noch nicht so Erfahren.

Das SmartMeterReader Air von BitShake erlaubt SmartMeters, die SML über einer IR Schnittstelle reden auszulesen. Das „Air“ Modell hat alles drin, IR-Lesekopf, ESP32 und WLAN, was für mich beeindruckend ist. WLAN Empfang ist sogar gut fand ich.

Vom Werk aus wird es mit Tasmota vorinstalliert geliefert, was super ist für Leute die kein Home Assistant haben: man bekommt eine nette Benutzeroberfläche, mit stündliche/tägliche/monatliche Charts (muss man aber konfigurieren).

Ich nutze aber ESPhome mit Home Assistant schon, deswegen war ich wenig scharf darauf die Tasmota Integration und Add-On in meinem HA hinzuzufügen. Genau aus den selben Grund habe ich MQTT auch weggelassen, die API reicht mir vollkommen, noch ein Add-On weniger.

SmartMeterReader Air von Bitshake nutz ein esp32-c3-mini-1, was ganz klar mit ESPhome kompatibel ist. Meine einzige Sorge war, ob die SML Library von ESPhome was taugt, aber auch das hat geklappt.

Mein Zähler ist ein DZG WS7412 mit einem Firmware Bug (workaround dazu im yaml code unten), der ab und zu negative Werte zurückgibt.

ESPhome yaml:

# BitShake SmartMeterReader Air – custom board with ESP32-C3-MINI-1
# GPIO5 is connected to IR sensor
# SML ESPhome doc:
# https://github.com/esphome/esphome-docs/blob/current/components/sml.rst
# Not using MQTT, just ESPhome native API
# https://esphome.io/components/api.html#advantages-over-mqtt

esphome:
  name: smartmeterreader
  friendly_name: SmartMeterReader

esp32:
  board: esp32-c3-devkitm-1
  framework: 
    # esp-idf framework recommended for ESP32-C3:
    # https://esphome.io/components/esp32.html#esp-idf-framework
    type: esp-idf

logger:

api:
  encryption:
    key: !secret home_assistant_encryption_key

ota:
  password: !secret ota_password

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${friendly_name} Hotspot"
    password: !secret fallback_ssid_password

captive_portal:

# web GUI for troubleshooting
web_server:

uart:
  id: uart_bus
  rx_pin: GPIO5
  baud_rate: 9600
  data_bits: 8
  parity: NONE
  stop_bits: 1

sml:
  id: mysml
  uart_id: uart_bus

sensor:
  - platform: sml
    name: "Total energy"
    icon: mdi:meter-electric
    sml_id: mysml
#    server_id: "0a012345670000abcdef" # optional, since there is a single SML input. Enable DEBUG log to find it.
    obis_code: "1-0:1.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 4
    device_class: energy
    state_class: total_increasing
    filters:
      - multiply: 0.0001 # One unit from DZG WS7412 represents 0.1 W

  - platform: sml
    name: "Current power"
    icon: mdi:lightning-bolt-circle
    sml_id: mysml
#    server_id: "0a012345670000abcdef" # optional, since there is a single SML input. Enable DEBUG log to find it.
    obis_code: "1-0:36.7.0"
    unit_of_measurement: W
    accuracy_decimals: 0
    device_class: power
    state_class: measurement
    filters:
      - multiply: 0.01
      # the below line is only required on WS7412 meters returning negative values from time to time.
      # https://github.com/volkszaehler/libsml/pull/136
      - lambda: |-
          return abs(x);
    # options to reduce the rate of updates (multiple times per second on a WS7412 e.g.) while retaining some reactivity using 'delta'
     # - or:
     #   - throttle_average: 5s
     #   - delta: 5%
    # another option:
     # - or:
     #   - median:
     #     window_size: 5
     #     send_every: 5
     #     send_first_at: 3
     #   - delta: 5%

          
  # there are two more OBIS codes, visible when enabling DEBUG logs: 1-0:96.50.1 and 1-0:96.1.0
  # both are static, one is the meter ID, the other is probably the model.

  # Wi-Fi
  # https://github.com/MallocArray/airgradient_esphome/blob/main/packages/sensor_wifi.yaml
  - platform: wifi_signal
    name: "WiFi Signal"
    id: wifi_dbm
    update_interval: 60s

  - platform: internal_temperature
    name: "ESP Temperature"
    id: sys_esp_temperature

  - platform: uptime
    name: "Uptime"
    id: device_uptime

  # diagnostics
  # https://github.com/MallocArray/airgradient_esphome/blob/main/packages/diagnostic.yaml
  - platform: template
    id: esp_memory_percent
    icon: mdi:memory
    name: ESP Percentage Free Memory
    lambda: return heap_caps_get_free_size(MALLOC_CAP_INTERNAL)*100 / 532480;
    unit_of_measurement: "%"
    state_class: measurement
    entity_category: "diagnostic"
  
  - platform: template
    id: esp_memory
    icon: mdi:memory
    name: ESP Free Memory
    lambda: return heap_caps_get_free_size(MALLOC_CAP_INTERNAL) / 1024;
    unit_of_measurement: "kB"
    state_class: measurement
    entity_category: "diagnostic"
2 „Gefällt mir“

Keine gute Idee, eine funktionierende Lösung zu ersetzen… der Tasmota Reader lässt sich sehr einfach in HA integrieren, warum eine andere Lösung suchen?

Hi, warum ist es eine schlechte Idee aus deiner Sicht?

Meine Gründe sind alle im Beitrag, einfach lesen…

Never change a running system…

Mit Benutzung von esphome Version 2024.2.2 verfängt sich das Gerät in einer Bootschleife.
Mit welcher esphome Version mag es wohl funktioniert haben?

Hast du es Uber USB geflasht oder OTA?

Ich musste es zwei Mal versuchen am Rechner, ich habe es OTA nicht versucht.

So weit ich weiß kann man von Tasmota 12 nicht OTA auf ESPhome migrieren, falls du von tasmota 12 kommst.

Ich habe das Gerät direkt über USB angeschlossen. Nach einer kurzen Recherche fand ich einen passenden Artikel, der auf die Bootschleife mit dem ESP32-C3 und esphome eingeht. Die Angabe von passenden platformio_options wie im Artikel erwähnt half.

Du hast also diese 4 Zeilen hinzugefügt? Wirklich merkwürdig, dass ich es nicht notwendig hatte. Danke für den Feedback auf jeden Fall.

  platformio_options:
    board_build.f_flash: 40000000L
    board_build.flash_mode: dio
    board_build.flash_size: 4MB

Ja diese vier Zeilen waren nötig. Ich nutze wie erwähnt esphome 2024.2.2. Vielleicht mag es daran liegen.
Das drahtlose Aktualisieren über des von mir eingesetzten Sensor bitShake SmartMeterReader - Air funktioniert prima. So war es dann bequem möglich, die weiteren, vom hier genutzten Zähler Norax3d+ bereitgestellten Datensätze in HomeAssistant bereitzustellen.

cool, danke!
ist also bestätigt, das es mit den ESP32-Cn und ESP-IDF läuft.

Was eine schmalbandige Weltsicht. Niemand will zwei Tech-Stacks (ESPHome und MQTT) am Laufen haben, wenn es auch mit einem geht. Den meisten dürfte ESPHome in Verbindung mit Home Assistant besser gefallen.

Ich danke jedenfalls @syg für die Experimentierfreudigkeit. Bin gerade am Bauen einer Firmware, werde berichten, wie es sich bei mir verhält.

Nachtrag:
Also bei mir ging es mit o.g. Minimalkonfiguration (d.h. ohne jegliche platformio_options).

Die genauen OBIS Kennungen muss man dann mittels debug Output bzw. Datenblatt des Herstellers herausfinden und zuordnen, da ist bekanntlich jeder Zähler anders …

:crayon:by HarryP: Zusammenführung Doppelpost (bitte “bearbeiten” Funktion nutzen)

Hallo @syg,

kannst du auch schreiben wo diese .yaml Datei in HA hin muss?.

Entschuldige bitte ich bin ganz neu in HA und habe wirklich meine Probleme damit.

Unter den ESPHome Abschnitt, wenn du die esphome Integration installiert hast. Neues Gerät kreieren, yaml einfügen und flashen.

Ich bin selber ESPHome-Fan und mache was geht über ESPHome (aus Freude am Basteln), allerdings ist MQTT sehr effizient und läuft bei mir unter Homeassistant wirklich super. Auf meinem Raspberry PI 4 laufen momentan sicher und stabil ca. 6 ESPHome und 15 MQTT Verbindungen.
Anstelle mehrere Tage mit einer ESPHome Integration zu kämpfen, würde ich allen Anfängern auf jeden Fall raten einfach MQTT zu verwenden, wenn es bereits fertig über Tasmota angeboten wird und nach 30 Minuten fertig zu sein (außer man macht den Fehler wie ich und drückt bei Tasmota zu schnell auf Firmware Update und bekommt eine Version ohne SML…). Ich sehen den Vorteil von ESPHome in diesem Fall nicht.
Die Belastung des Systems wird eher davon abhängen, wie oft man bestimmte Werte aktualisiert und was man alles speichert (und wie aufgeräumt das System ist) und nicht an einer zusätzlichen MQTT-Integration hängen.

1 „Gefällt mir“