Wie findet man sich in diesem ganzen YAML-Djungle zurecht?

member1

New member
Hallo,

ich verwende seit ein paar Wochen HA auf einem kleinen Raspi-4. Der Einstieg und Grundeinrichtung war soweit einfach und nun möchte ich so einige Sensoren anschließen. Ich dachte mir ich fange mit was ganz einfachem an, einem Stromzähler. Habe noch so einen alten Ferraris Zähler mit Zählrad (75 U/kWh) und einer roten Markierung daran, welche ich nach einigen Fehlversuchen nun mittels einer IR-Reflexlichtschranke einigermaßen Jitterfrei erkennen kann. Vermutlich müsste ich noch einen Schmitt-Trigger dazwischen schalten um ein sauberes, prellfreies Rechtecksignal zu bekommen. Das ganze ist an einem ESP8266 D1 Mini per WLAN verbunden.

Aber - das ist nicht mein Problem, sondern diese schier unüberschaubare Anzahl von Einstellungen, Statements und Schreibweisen. Ich habe nun die Wahl zwischen "pulse_meter", "pulse_counter", "binary_sensor", ... und nichts habe ich vernünftig ans laufen bekommen :-(

Kann mir jemand helfen und mal Schritt für Schritt erklären wie man das sauber einrichtet, so dass die Werte auch stimmen, ich bekomme immer nur Quatsch raus. Auch weiss ich nicht wie man sich dann Statistiken für Tages- Monatsverbräuche etc. generieren kann. Habe schon jeden Abend stunden im Internet verbracht um nach Infos zu suchen, aber je mehr ich finde umso verwirrter werde ich. Für etwas Starthilfe wäre ich sehr dankbar :)
 

Nival

-
Moderator
Von HA habe ich selber auch wenig Ahnung, aber nen paar Sensoren schon hinbekommen - also zuerst mal, was von den Optionen entspräche denn überhaupt Deinem Ziel? Bezüglich pulse_meter und pulse_counter unterscheidet es sich ja schon in der Frage, ob Du die Daten "live" oder erst nach einem gewissen Zeitraum haben möchtest.

Was die Statistiken angeht, wäre da eventuell https://forum.heimnetz.de/threads/a...ern-und-mit-grafana-visualisieren-part-1.343/ etwas für Dich?
 

azrael783

Active member
Wie, bzw. welche Daten kommen denn bei dir in Home-Assistant an? Du schreibst was von einem ESP8266, was läuft denn da für eine Firmware drauf? Hast du die zufällig mit ESPHome konfiguriert? Wenn ja poste doch mal deine YAML Datei.
 

member1

New member
An meiner Yaml hättet ihr keinen Spaß... die ist kraut und rüben und ich fürchte es macht zu diesem Zeitpunkt keinen Sinn das zu betrachten.

Aber fangen wir vorn an, mit den fachlichen Anforderungen:
Ich möchte die Umdrehungen meines Analogen Stromzählers erfassen um hieraus den Stündlichen, Tages-, Monats- und Jahresverbrauch immer im Blick haben zu können. Das Zählerrad mach 75 U/kWh. Der Zählerstand soll auch direkt eingegeben werden können um den Anfangswert und ggf. Korrekturwerte einfach zu hinterlegen. Bei den Werten denke ich da immer in kWh. Ideal wäre es auch mein vertragliches Gesamtvolumen erfassen und mit darstellen zu können.

Nun zu meinen Möglichkeiten:
Ich habe sowohl Zigbee als auch Wifi Devices zur Verfügung. Zuletzt habe ich mit einem Wemos D1 Mini Board gearbeitet, dieses hat einen ESP8266 drauf.
HA ist auf einem Rapi4 installiert und eingerichtet, das ESPHome Addon installiert. Ein solches Device intial aufzunehmen ist kein Problem, auch OTA Updates funktionieren inzwischen zuverlässig.

Für die Erfassung habe ich eine IR-Reflexlichtschranke modifiziert und vor dem Zählerrad begestigt. Die Erkennung läuft seit einiger Zeit recht zuverlässig. Das ausgangssignal ist nur so bedingt rechteckig, was ich mit dem Dso gemessen habe, es benötigt also eine Entprellung.

Ich blicm noch überhaupt nicht was esphome und was ha für eine Funktion einmimmt und wie die schier endlosen Optionen zusammenspielen. Was liefert der ESP und wie verarbeitet Ha das.
 

RKsHass

New member
Um auf die Frage zu Antworten, Ordung im Yaml Dschungel
Ich bin auch recht frisch dabei und hatte/habe das problem auch , was wie wohin.
Als ersten Schritt habe ich aus der configuration.yaml einzelne Teil ausgelagert und Included
als z.B. Variablen in eine var.yaml geschrieben

var.yaml
Code:
#var:
#Heizung Temps
  temp_hz_off:
    friendly_name: 'temp_hz_Off'
    initial_value: 12
  bs_temp_hz_max:
    friendly_name: 'bs_temp_hz_max'
    initial_value: 24
  bs_temp_hz_min:
...

configuration.yaml

Code:
...
var: !include var.yaml
...

Das macht es (mir) schon mal einfacher.

Zu deinen Problem mit Esphome und HA Zusammenspiel,
Unter Settings/Devices... solltest du deine ESP Geräte unter ESPHome finden, hast du sicher schon.
Wenn du auf eine Device klickst bekommst du das Gerät und die dazugehörenden Entities angezeigt.

Wenn du ganz oben auf Devices oder Enities klickst bekommst du die geräte auch angezeigt.
1666684901141.png
mit den Entity IDs kannst du in Settings: automations, scripts etc. arbeiten
oder im Lovelace Frontend Schalter, Anzeigen etc. verknüpfen.

Ich hoffe ich konnte ein bischen helfen?
Ich versuche durch diese Art Dokumentation selber damit klar zu kommen. :)
 
Zuletzt bearbeitet:

u5zzug

Active member
Auf die Sensoren, die du im ESPHome Gerät definierst, kannst du in HA ohne weitere Klimmzüge zugreifen.
 

member1

New member
Um das für mich mal zu sortieren, bitte ergänzt, bestätigt oder korrigiert.

Home Assistant ist ja erstma eine Art Steuerzentrale an die man alle möglichen Sensoren und Aktoren ankoppelt. Das kann sicher in sehr unterschiedlicher Weise gesehen, womöglich sogar auch direkt angeschlossene Geräte über USB, LAN oder Erweiterungsboards.

Das meiste wird sicherlich irgendwie mittels einer Web-API angekoppelt.
Home Assistant stellt dann die Sensorwerte in unterschiedlichster Art auf seiner eigenen Web-GUI dar, kann das aber vermutlich auch auf andere Geräte "projezieren".

Und jetzt kommen die verschiedenen Erweiterungen ins Spiel, wo wohl auch ESPHome eine darstellt. Das ist ja ansich ein eigenständiges Projekt, wird über das Plugin auf dem HA Host installiert und ist dann über die HA GUI konfigurierbar.

Der ESPHome liefert wohl einen eigenen Backend-Service mit an dem sich die Nodes dann via API verbinden um darüber ihre Sensorwerte bzw. Aktionen abzurufen.
Dann gibt es da ja noch eine Messagequeue "MQTT", was ja ansich auch ein eigenständiger Dienst wäre, welcher wohl in HA integriert ist.

Die Magie liegt wohl jetzt überwiegend darin das zwischen den einzelnen Komponenten und Home Assistent Core eine Verbindung hergestellt wird, sodass man die Erweiterungen nutzen kann als wären sie Bestandteil von HA.

Ich würde jetzt gern ganz genau wissen welche Teile wozu gehören?

Ein Device kann ja zahlreiche Endpunkte (Entities) besitzen. Auch hier müsste es eine Namenskopplung von Entität und Gerät geben.

Was mich auch umtreibt ist die Frage der Namensgebung an div. Stellen. Ich würde da lieber gern eine technische Id/Namen wählen und dann den Anzeigenamen in den Gui Elementen frei wählen. Es scheint nämlich das eine Änderung eines Device- oder Entity-Name die Zuordnungen kappt die man auf die alten Namen gemacht hat.

Dann ist die Frage wie HA mit den z.b. gelieferten Sensorwerten umgeht. Es wird die wohl in einer Datenbank speichern.
 

u5zzug

Active member
MQTT ist kein Teil von HA, man muss dafür das Mosquitto Addon installieren. ESPHome braucht aber nicht unbedingt MQTT.

https://developers.home-assistant.io/blog/2022/07/10/entity_naming/

Der angegebene Name wird als Bezeichner kleingeschrieben, Leerzeichen mit _ ersetzt u.ä..
Einen frei wählbaren Namen kannst du als friendly_name: angeben.
Die Benennung der Entities in ESPHome liegt in deiner Hand.
Sinnvoll ist sicher was in der Art für das Gerät esp1: esp1_sensor1, esp1_sensor2.
Wenn du die entsprechenden Typen angibst, kann HA die Daten auch entsprechend behandeln.
YAML:
    unit_of_measurement: "m³"
    accuracy_decimals: 2
    icon: 'mdi:fire'
    device_class: gas
    state_class: total_increasing

HA speichert die meisten Daten nur eine bestimmte Zeit lang, Energie u.ä., was man im Energiedashboard ansehen kann, wird länger aufgehoben.
 

member1

New member
Um mal etwas YAML in den Raum zu werfen, hier meine Config für den Gaszähler:
YAML:
esphome:
  name: esphome-web-1cebf6

esp8266:
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:


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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-XXXXXX"
    password: "****************"

captive_portal:

globals:
  - id: total_pulses
    type: int
    restore_value: false
    initial_value: '9086948'  # hier kann der Gaszählerstand initialisiert werden

binary_sensor:
  - platform: gpio
    id: internal_pulse_counter
    pin:
      number: GPIO5 # "D1"
      mode: INPUT_PULLUP
    name: "Live-Impuls"
    filters:
      - delayed_on: 100ms
    on_press:
      then:
        - lambda: id(total_pulses) += 1;

sensor:
  - platform: template
    name: "Gasverbrauch"
    device_class: gas
    unit_of_measurement: "m³"
    state_class: "total_increasing"
    icon: "mdi:fire"
    accuracy_decimals: 2
    lambda: |-
      return id(total_pulses) * 0.01;

Was immer recht aufwändig ist, die IO-Pins zu identifizeren, ebenso das richtige Board. Die Erfassung selbst mache ich mit einem Reed-Kontakt (Meeder) nachdem ich über Tage verzweifelt versucht habe das mit einem Hall-Sensor oder einem optischen Sensor (IR-Reflex) stabil an laufen zu bekommen. Der gute alte Reed funktioniert hier noch am zuverlässigsten und ist auch am billigsten ;-)

Die config habe ich geklaut und versuche sie noch zu verstehen. Die Idee dahinter ist den "binary_sensor" zu verwenden um quasi die Ein/Aus-Schaltzeitpunkte zu erfassen. Bei jedem Übergang von 1->0 wird eine Zählervariable hochgezählt. Das entspricht dann immer einer vollen Umdrehung der letzten (3.) Nachkommastelle am Gaszähler und somit 0,01 m³ Gasverbrauch.

Die erste Zeilen zeigen wohl an das "esphome" als Integrationsplugin genutzt werden soll?
YAML:
esphome:
  name: esphome-web-1cebf6
Der Name ist das was angezeigt und intern verwendet wird. Den kann man nachträglich nicht mehr ändern ohne seine Dashboards zu killen. Daher "wähle weise!".

Dann folgt die Angabe des Board-typs an dem der Sensor angeschlossen ist. Ich verwende hier ein Shield von az-delivery was wohl ein clone der bekannten Wemos D1 mini Serie ist. Der Wifi-Chip auf dem Shield ist ein "Espressif 8266 12-F":
azdelivery_d1_mini_pcb_top.pngazdelivery_d1_mini_pcb_btm.png
YAML:
esp8266:
  board: d1_mini
Da ich vermute das diese Settings im Kontext mit ESPHome zu verstehen sind, habe ich hier bei den Devices geschaut:
https://esphome.io/devices/index.html was am besten passen könnte und bin auf den https://esphome.io/devices/esp8266.html gestoßen, was ja dem Chipsatz entspricht. Auf dieser Seite gibt es dann einen Link wo alle möglichen Boards aufgelistet sind: https://registry.platformio.org/platforms/platformio/espressif8266/boards
Den az-delivery sucht man da vergebens, aber den Wemos D1 mini ist enthalten: https://docs.platformio.org/en/latest/boards/espressif8266/d1_mini.html
Da drin wiederum ist der Hinweis auf den Board-Typ "d1_mini". Über diese Wahl wird wohl neben der richtigen Toolchain zum kompilieren der Firmware auch das Pinout bestimmt, welches für mein o.g. Board so aussieht:
azdelivery_d1_mini_pinout.png

Den Reed-Kontakt habe ich zwischen "GND" und "D1" verbunden. Meine Idee war das der active-low schalten soll, daher muss der Pin dann einen Pullup haben. Den hätte ich per 10k Widerstand gegen +3.3V (WICHTIG! Der ESP8266 hat eine IO-Spannung von 3.3V) hochziehen können, aber der Chip hat auch interne Pullups, da spart man ein Bauteil.
Beachten muss man hier das der Chipsatz (ESP8266 12-F) ja eigene Pins und Bezeichnungen hat. Die weichen von dem was auf dem Board aufgedruckt ist erheblich ab und ohne eine solche Legende hat man eigentlich keine Chance den richtigen Pin zu treffen. Auch sind nicht immer alle Pins rausgeführt bzw. gibt es eigene Komponenten auf dem Board die an Pins liegen. Das macht es unglaublich "würzig"...

Ich habe diesen Meder MK4-1A66B genommen:
meder_MK4-1A66B.png
Entscheidend ist hier das "B", es gibt nämlich die Empfindlichkeit an, also die magnetische Kraft welche benötigt wird um den Kontakt zu schließen. Diese wiederum ist natürlich von der Ausrichtung und Entfernung zum Magneten abhängig. Laut Datenblatt ist der Wert "10-15 AT", keine Ahnung was das in Tesla bedeutet.

Zur Erfassung hat man hier den "binary_sensor" genommen https://esphome.io/components/binary_sensor/index.html um Ein/Ausschaltimpulse zu zählen. Dann kommt wieder so ein wirres Stück YAML was eine "platform" einstellt (keine Ahnung was das wieder ist). Der "pin" wird definiert mit "GPIO5" was oben in der Legende "IO5" und letztlich dem Aufdruck "D1" auf dem Board entspricht. Mit "mode: INPUT_PULLUP" wird der interne Pullup-Widerstand aktiviert. Das ist wichtig bei Active-Low ohne externen Pullup. Über einen "delayed_on" filter wird der Kontakt entprellt, sodass leicht zittriges anziehen keine Mehrfachauslösung erzeugt. Ich habe 100ms Entprellzeit gewählt, das scheint mir ausreichend groß um prellen jeder art zu unterdrücken und klein genug um keinen Umdrehungsimpuls zu verpassen.
YAML:
binary_sensor:
  - platform: gpio
    id: internal_pulse_counter
    pin:
      number: GPIO5 # "D1"
      mode: INPUT_PULLUP
    name: "Live-Impuls"
    filters:
      - delayed_on: 100ms
    on_press:
      then:
        - lambda: id(total_pulses) += 1;
MIt "on_press" wird wohl eine Triggerfunktion ausgelöst, in diesem Fall eine sog. Lambda-Funktion. In anderen Programmiersprachen versteht man darunter eine Unterroutine ohne eigenen Funktionsnamen, quasi "Inline - on the fly code". Die Funktion "id()" kenne ich nicht, könnte aber sein das daruch ein Wert irgendwo hin geschrieben wird. Der Wert der aus der Gleichung heraus kommt ist der letzte Wert von "total_pulses" plus 1. total_pulses ist der Name der Variablen in der er gespeichert ist. Eventuell gibt es diese Variable nur im Arbeitsspeicher auf dem Board, aber evtl. auch in der Datenbank von HA?

Diese Variable wird hier definiert, als globale Variable vom Typ Integer:
YAML:
globals:
  - id: total_pulses
    type: int
    restore_value: false
    initial_value: '9086948'  # hier kann der Gaszählerstand initialisiert werden
Das "initial_value" sorgt dafür das die Variable nicht mit "0" anfängt (oder ggf. sogar UNDEF ist), sondern eben dem abgelesenen Gaszählerstand entspricht. Wichtig hierbei ist das die Nachkommastellen, bis auf die letzte Zählerstelle, als gesamte Ganzzahl eingegeben wird. Vermutlich kann man das auch anders machen und anstelle einem "int" einen "float" definieren, mit "90869.48" initialisieren und dann nicht "+= 1" zählen, sondern "+= 0.01" ?

Zuletzt folgt noch der "sensor" Block:
YAML:
sensor:
  - platform: template
    name: "Gasverbrauch"
    device_class: gas
    unit_of_measurement: "m³"
    state_class: "total_increasing"
    icon: "mdi:fire"
    accuracy_decimals: 2
    lambda: |-
      return id(total_pulses) * 0.01;
Den verstehe ich so das mit "sensor" eine Liste von Entities entstehen kann. Hierr entsteht nur einer mit dem Name "Gasverbrauch" (sicher wieder eine schlechte Wahl, besser wäre wohl ein technischer Name?). Dann kommen viele interessante Angaben die man zwar versteht, aber ich nicht weiss wie man darauf kommt das da hin schreiben zu können...
Das "icon: mdi:fire" sorgt für die kleine Flamme. Ich habe mal geschaut was es alles für icons gibt, das ist uferlos, tausende.

Am Ende erhält man bei "+ADD DEVICE" und Auswahl des Sensors "Gasverbrauch" im Dashboard einen Gaszähler, nicht schick aber er tut was er soll:
1666807290576.png
 
Zuletzt bearbeitet:

blurrrr

Well-known member
Auch wenn ich damit mal so rein garnichts an der Mütze habe, MQTT ist ein "Protokoll", bedeutet, dass damit definiert wird, wie die Parteien miteinander zu sprechen haben (gleiches gilt auch für IP, TCP, HTTP, usw.). Wenn Du irgendwas mit MQTT machen willst, wäre es durchaus empfehlenswert, sich zumindestens mal den entsprechenden Wikipedia-Artikel (https://de.wikipedia.org/wiki/MQTT) anzuschauen, da es ggf. auch dabei helfen kann, Problemen auf die Spur zu kommen. Wenn Du weisst, wie die Kommunikation auszusehen hat, lassen sich Probleme (bzgl. der Kommunikation) auch leichter identifizieren.

MQTT hat somit auch weder was mit HomeAssistant, noch was mit irgendwelchen Geräten zu tun, sondern ist etwas für sich. Natürlich ergibt sich damit dann - je nach Einsatz - auch immer irgendwo der Gebrauch von MQTT, z.B. dann, wenn man mit entsprechenden Geräten kommunizieren will.

Im Bereich "Web" hast Du z.B. eine Kombination aus diversen Verkettungen, als sehr laienhafte (und fachlich sicherlich nicht 100%ig korrekte) Darstellung z.B.:

Benutzer <-> Computer <-> Webbrowser <-> HTTP-Protokoll <-> Website

Bei HA/MQTT-Gerät könnte es z.B. so aussehen:

Benutzer <-> HA <-> Mosquitto-Integration <->MQTT-fähiger Stick <-> MQTT-Protokoll <-> Smarthome-Gerät

Ist natürlich jetzt alles nur extrem veranschaulicht und entbehrt sicherlich auch jeglicher Fachlichkeit, aber es geht ja nur um das Verständnis 😅 Die Mosquitto-Integration sorgt dann wohl dafür, dass HA überhaupt was mit MQTT anfangen kann, da HA von sich aus eben kein MQTT spricht. Somit ist die Integration dann vermutlich sowas wie ein Übersetzer.

Die Magie liegt wohl jetzt überwiegend darin das zwischen den einzelnen Komponenten und Home Assistent Core eine Verbindung hergestellt wird, sodass man die Erweiterungen nutzen kann als wären sie Bestandteil von HA.
HA macht von von sich aus erstmal nicht wirklich etwas, ausser die Weboberfläche und die dahinterstehende Logik (z.B. für Automatisierungen) bereitzustellen. HA von sich aus kann eigentlich erstmal sogut wie "nix" mit anderen Dingen anfangen, weil es garnicht weiss, wie es mit den anderen "sprechen" soll. Dafür gibt es dann die Integrationen, die eine entsprechende Kommunikation (über APIs, Protokolle, etc.) ermöglichen und somit wieder als Übersetzer agieren.

Es ist schon ungefähr so wie Du sagst: Du hast Produkt XY, damit kann HA erstmal nix anfangen. Es braucht eine passende Integration, welche dann als Schnittstelle/Übersetzer zwischen HA und Produkt XY agiert. Nicht immer sind entsprechende Integrationen vorhanden, die machen das HA-Leben ja durchaus recht einfach, es gibt aber auch oft die Möglichkeit, statt "Integration <-> Hersteller-Basis" einfach selbst einzugreifen. Zwar fehlt dann das "angenehme" dabei, aber wenn die Endgeräte (welche dann via Hersteller-Basis angesprochen werden), auch eins der "üblichen" Protokolle sprechen, kann man da ggf. auch noch selbst fummeln (was aber ziemlich zeitaufwändig sein dürfte, grade wenn man noch recht frisch im Thema ist).

So, jetzt hab ich aber auch genug die Klappe aufgerissen, faktisch hab ich davon nämlich auch keine Ahnung, deswegen bin ich jetzt auch wieder ganz still 😇😅

EDIT: Vermutlich genau aufgrund dieser Trennung gibt es hier auch einmal "Smarthome (Hersteller)" und einmal "Smarthome (Management-Systeme)", die Hersteller-Dinge stehen für sich allein, die Management-Systeme können halt diverse Hersteller-Systeme einbinden (da ist HomeAssistant ja nicht allein, hier sind z.B. noch NodeRed und ioBroker aufgeführt und es gibt auch noch andere, wie z.B. FHEM, etc.) 🙃
 
Um mal etwas YAML in den Raum zu werfen, hier meine Config für den Gaszähler:
YAML:
esphome:
  name: esphome-web-1cebf6

esp8266:
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:


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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-XXXXXX"
    password: "****************"

captive_portal:

globals:
  - id: total_pulses
    type: int
    restore_value: false
    initial_value: '9086948'  # hier kann der Gaszählerstand initialisiert werden

binary_sensor:
  - platform: gpio
    id: internal_pulse_counter
    pin:
      number: GPIO5 # "D1"
      mode: INPUT_PULLUP
    name: "Live-Impuls"
    filters:
      - delayed_on: 100ms
    on_press:
      then:
        - lambda: id(total_pulses) += 1;

sensor:
  - platform: template
    name: "Gasverbrauch"
    device_class: gas
    unit_of_measurement: "m³"
    state_class: "total_increasing"
    icon: "mdi:fire"
    accuracy_decimals: 2
    lambda: |-
      return id(total_pulses) * 0.01;

Was immer recht aufwändig ist, die IO-Pins zu identifizeren, ebenso das richtige Board. Die Erfassung selbst mache ich mit einem Reed-Kontakt (Meeder) nachdem ich über Tage verzweifelt versucht habe das mit einem Hall-Sensor oder einem optischen Sensor (IR-Reflex) stabil an laufen zu bekommen. Der gute alte Reed funktioniert hier noch am zuverlässigsten und ist auch am billigsten ;-)

Die config habe ich geklaut und versuche sie noch zu verstehen. Die Idee dahinter ist den "binary_sensor" zu verwenden um quasi die Ein/Aus-Schaltzeitpunkte zu erfassen. Bei jedem Übergang von 1->0 wird eine Zählervariable hochgezählt. Das entspricht dann immer einer vollen Umdrehung der letzten (3.) Nachkommastelle am Gaszähler und somit 0,01 m³ Gasverbrauch.

Die erste Zeilen zeigen wohl an das "esphome" als Integrationsplugin genutzt werden soll?
YAML:
esphome:
  name: esphome-web-1cebf6
Der Name ist das was angezeigt und intern verwendet wird. Den kann man nachträglich nicht mehr ändern ohne seine Dashboards zu killen. Daher "wähle weise!".

Dann folgt die Angabe des Board-typs an dem der Sensor angeschlossen ist. Ich verwende hier ein Shield von az-delivery was wohl ein clone der bekannten Wemos D1 mini Serie ist. Der Wifi-Chip auf dem Shield ist ein "Espressif 8266 12-F":
Anhang anzeigen 1868Anhang anzeigen 1870
YAML:
esp8266:
  board: d1_mini
Da ich vermute das diese Settings im Kontext mit ESPHome zu verstehen sind, habe ich hier bei den Devices geschaut:
https://esphome.io/devices/index.html was am besten passen könnte und bin auf den https://esphome.io/devices/esp8266.html gestoßen, was ja dem Chipsatz entspricht. Auf dieser Seite gibt es dann einen Link wo alle möglichen Boards aufgelistet sind: https://registry.platformio.org/platforms/platformio/espressif8266/boards
Den az-delivery sucht man da vergebens, aber den Wemos D1 mini ist enthalten: https://docs.platformio.org/en/latest/boards/espressif8266/d1_mini.html
Da drin wiederum ist der Hinweis auf den Board-Typ "d1_mini". Über diese Wahl wird wohl neben der richtigen Toolchain zum kompilieren der Firmware auch das Pinout bestimmt, welches für mein o.g. Board so aussieht:
Anhang anzeigen 1869

Den Reed-Kontakt habe ich zwischen "GND" und "D1" verbunden. Meine Idee war das der active-low schalten soll, daher muss der Pin dann einen Pullup haben. Den hätte ich per 10k Widerstand gegen +3.3V (WICHTIG! Der ESP8266 hat eine IO-Spannung von 3.3V) hochziehen können, aber der Chip hat auch interne Pullups, da spart man ein Bauteil.
Beachten muss man hier das der Chipsatz (ESP8266 12-F) ja eigene Pins und Bezeichnungen hat. Die weichen von dem was auf dem Board aufgedruckt ist erheblich ab und ohne eine solche Legende hat man eigentlich keine Chance den richtigen Pin zu treffen. Auch sind nicht immer alle Pins rausgeführt bzw. gibt es eigene Komponenten auf dem Board die an Pins liegen. Das macht es unglaublich "würzig"...

Ich habe diesen Meder MK4-1A66B genommen:
Anhang anzeigen 1871
Entscheidend ist hier das "B", es gibt nämlich die Empfindlichkeit an, also die magnetische Kraft welche benötigt wird um den Kontakt zu schließen. Diese wiederum ist natürlich von der Ausrichtung und Entfernung zum Magneten abhängig. Laut Datenblatt ist der Wert "10-15 AT", keine Ahnung was das in Tesla bedeutet.

Zur Erfassung hat man hier den "binary_sensor" genommen https://esphome.io/components/binary_sensor/index.html um Ein/Ausschaltimpulse zu zählen. Dann kommt wieder so ein wirres Stück YAML was eine "platform" einstellt (keine Ahnung was das wieder ist). Der "pin" wird definiert mit "GPIO5" was oben in der Legende "IO5" und letztlich dem Aufdruck "D1" auf dem Board entspricht. Mit "mode: INPUT_PULLUP" wird der interne Pullup-Widerstand aktiviert. Das ist wichtig bei Active-Low ohne externen Pullup. Über einen "delayed_on" filter wird der Kontakt entprellt, sodass leicht zittriges anziehen keine Mehrfachauslösung erzeugt. Ich habe 100ms Entprellzeit gewählt, das scheint mir ausreichend groß um prellen jeder art zu unterdrücken und klein genug um keinen Umdrehungsimpuls zu verpassen.
YAML:
binary_sensor:
  - platform: gpio
    id: internal_pulse_counter
    pin:
      number: GPIO5 # "D1"
      mode: INPUT_PULLUP
    name: "Live-Impuls"
    filters:
      - delayed_on: 100ms
    on_press:
      then:
        - lambda: id(total_pulses) += 1;
MIt "on_press" wird wohl eine Triggerfunktion ausgelöst, in diesem Fall eine sog. Lambda-Funktion. In anderen Programmiersprachen versteht man darunter eine Unterroutine ohne eigenen Funktionsnamen, quasi "Inline - on the fly code". Die Funktion "id()" kenne ich nicht, könnte aber sein das daruch ein Wert irgendwo hin geschrieben wird. Der Wert der aus der Gleichung heraus kommt ist der letzte Wert von "total_pulses" plus 1. total_pulses ist der Name der Variablen in der er gespeichert ist. Eventuell gibt es diese Variable nur im Arbeitsspeicher auf dem Board, aber evtl. auch in der Datenbank von HA?

Diese Variable wird hier definiert, als globale Variable vom Typ Integer:
YAML:
globals:
  - id: total_pulses
    type: int
    restore_value: false
    initial_value: '9086948'  # hier kann der Gaszählerstand initialisiert werden
Das "initial_value" sorgt dafür das die Variable nicht mit "0" anfängt (oder ggf. sogar UNDEF ist), sondern eben dem abgelesenen Gaszählerstand entspricht. Wichtig hierbei ist das die Nachkommastellen, bis auf die letzte Zählerstelle, als gesamte Ganzzahl eingegeben wird. Vermutlich kann man das auch anders machen und anstelle einem "int" einen "float" definieren, mit "90869.48" initialisieren und dann nicht "+= 1" zählen, sondern "+= 0.01" ?

Zuletzt folgt noch der "sensor" Block:
YAML:
sensor:
  - platform: template
    name: "Gasverbrauch"
    device_class: gas
    unit_of_measurement: "m³"
    state_class: "total_increasing"
    icon: "mdi:fire"
    accuracy_decimals: 2
    lambda: |-
      return id(total_pulses) * 0.01;
Den verstehe ich so das mit "sensor" eine Liste von Entities entstehen kann. Hierr entsteht nur einer mit dem Name "Gasverbrauch" (sicher wieder eine schlechte Wahl, besser wäre wohl ein technischer Name?). Dann kommen viele interessante Angaben die man zwar versteht, aber ich nicht weiss wie man darauf kommt das da hin schreiben zu können...
Das "icon: mdi:fire" sorgt für die kleine Flamme. Ich habe mal geschaut was es alles für icons gibt, das ist uferlos, tausende.

Am Ende erhält man bei "+ADD DEVICE" und Auswahl des Sensors "Gasverbrauch" im Dashboard einen Gaszähler, nicht schick aber er tut was er soll:
Anhang anzeigen 1875
Hallo,

würde auch gerne meinen Gaszähler smart machen und haben mir den gleichen D1 Mini ESP8266MOD 12-F von AZ Delivery geholt.

Da es im Netz unterschiedliche Anleitungen zum erstmaligen einrichten des D1 Mini gibt hier meine Frage:

Kann ich den ohne weiteres über ESP Home einbinden? Oder gibt es da noch was zu beachten.
Zum erstmaligen Inbetrieb nehmen kann ich den per USB direkt an den Raspberry wo Home Assistent drauf ist anschließen oder?
Und nach der Einrichtung ist er dann per Wlan erreichbar.
Oder habe ich da was falsch verstanden?

Vielen Dank im voraus für eure Geduld.
 

member1

New member
Grundsätzlich stimmt das alles so.
Im Detail habe ich es jedoch nicht am Raspy gemacht, sondern an meinem PC angesteckt. Dort musst Du dann ggf. einen USB-Treiber für den CH430 installieren, damit Windows das als Serielle Schnittstelle bereitstellt. Dann kann man über eine ESPHome Seite den D1 menügeführt mit dem WLAN koppeln und eine Basisfirmware flashen. Anschließend kann der Rest OTA (Over-The-Air) gemacht werden.
 

alexamend

Active member
Der D1 mini von AZ ist bei Auslieferung ohne Software diese muss über Windows/Linux/MacOS drauf gebügelt werden, Für den Chrom Browser gibt es einen online flasher dieser erkennt auch das angeschlosse Gerät und stellt dementsprechend die korrekte Version zur Verfügung. Ansonsten tasmotizer oder esp32_flasher wenn Windows verwendet wird es geht auch manuell mit phyton, dann aber komplett händisch.
Ich persönlich flashe immer tasmota da man hier beim Umschaltung auf mqtt das Gerät nicht doppelt in HA hat (esphome wird dann unterbunden) dies geht in der console auf dem tasmota gefläshten Gerät mit
SetOption19 1 für mgtt
SetOption19 0 für ESP_Home

Bei den AZ Produkten wird der ch340 Treiber für Windows benötigt.

Tasmota online Install
Tasmotizer
esp flasher
ch340 Treiber Windows 10/11

alle haben ihre Vor-und-Nachteile
Für Anfänger würde ich den online Install empfehlen, da dieser out of the Box funktioniert, wenn man aber Programme übertragen möchte die offiziell nicht in den Spricher passen dann geht das nur mit dem esp flasher, z.b google chart für IR Stromzähler ist nur manuell möglich.
 
Der D1 mini von AZ ist bei Auslieferung ohne Software diese muss über Windows/Linux/MacOS drauf gebügelt werden, Für den Chrom Browser gibt es einen online flasher dieser erkennt auch das angeschlosse Gerät und stellt dementsprechend die korrekte Version zur Verfügung. Ansonsten tasmotizer oder esp32_flasher wenn Windows verwendet wird es geht auch manuell mit phyton, dann aber komplett händisch.
Ich persönlich flashe immer tasmota da man hier beim Umschaltung auf mqtt das Gerät nicht doppelt in HA hat (esphome wird dann unterbunden) dies geht in der console auf dem tasmota gefläshten Gerät mit
SetOption19 1 für mgtt
SetOption19 0 für ESP_Home

Bei den AZ Produkten wird der ch340 Treiber für Windows benötigt.

Tasmota online Install
Tasmotizer
esp flasher
ch340 Treiber Windows 10/11

alle haben ihre Vor-und-Nachteile
Für Anfänger würde ich den online Install empfehlen, da dieser out of the Box funktioniert, wenn man aber Programme übertragen möchte die offiziell nicht in den Spricher passen dann geht das nur mit dem esp flasher, z.b google chart für IR Stromzähler ist nur manuell möglich.
habe es geschafft ihn zu flashen und habe jetzt zugriff über Wlan.
In der Konsole habe ich die Set Option19 eingegeben.
Jetzt meine Frage:
Kann mir jemand sagen was in den Geräteeinstellungen noch einzustellen ist?
Bin mir unsicher weil da Sonoff Basic steht und z.b. GPIO5 nicht angezeigt wird.
Müsste da nicht was eingestellt werden?
Oder habe ich beim Flashen was falsch gemacht?Screenshot 2022-11-29 183628.jpgScreenshot 2022-11-29 184313.jpg
 

alexamend

Active member
Du Wählst am besten Generic 0

Screenshot_20221129_211223_Samsung Internet.jpg
Zudem darfst du nur
SetOption19 0
Oder
SetOption19 1
Eingeben beides geht nicht und ohne den zusatz für mqtt oder für ESP_Home
 
Zuletzt bearbeitet:
Ach ja und noch ne Frage:

bei den Shellys wird empfohlen eine feste IP zu vergeben. Ist das hier auch ratsam ?
und wo kann ich das einstellen? Im D1 mini oder über die Fritzbox?
Bei den Shellys geht das direkt in den Einstellungen. In den Wlan Einstellungen des D1 mini ist da nix drin.
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
1.334
Beiträge
17.778
Mitglieder
843
Neuestes Mitglied
smartloftnrw
Oben