[ESPHome] Beta release

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

@dutchman Ja, ich bezog das auch auf die gezeigte 3.8. Die kann ich aufrufen. Aber ESPHOme hält sich an die 2.7

und genau da geht es schief er braucht naemlich 3.7
In der package mache ich keine links fuer python 2.x

  "python": {
    "execPath": [
      "python3.8",
      "python3.7",
      "python3",
      "python"
    ],

[klassisch]

@dutchman ok, und wie bekomme ich das hin, so daß 2.7 und 3.3 nutzbar sein können?

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

@dutchman ok, und wie bekomme ich das hin, so daß 2.7 und 3.3 nutzbar sein können?

gute frage wie lauten deine Pfade fuer python ?

@dutchman sagte in [ESPHome] Beta release:

  "python"                                                                                                                                                                            

eventuell kommt er durch diesen Eintrag die 2.7

[klassisch]

@dutchman
directories sehr strange: c:\Users\JS\AppData\Local\Programs\Python\Python38-32\

und c:\Python27\

Und wenn ich in der Konsole "path" eingeben, dann ist dort
C:\Python27;C:\Python27\Scripts;C:\Windows\system32;

enthalten.
Also man Path austauschen?

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

Und wenn ich in der Konsole "path" eingeben, dann ist dort

also nimmt er standard die 2.7, schau dir das hier mal an um das auf die 3.7 um zu leiten

https://stackoverflow.com/questions/5087831/how-should-i-set-default-python-version-in-windows

[klassisch]

@dutchman herzlichen Dank für Deine Geduld und Deine Tipps.

Habe jetzt alles neu auf Basis python 3.8 aufgebaut, upgedatet - auch platformio. Habe gelernt, daß mein ESP Flashtool nicht mehr funktioniert, die neue espHome-Plattform das jetzt aber auch kann.
Und daß man seine degub-Änderungen auch wieder rückgängig machen sollte

Jetzt ist das Gerätchen wieder online und liefert neben den MQTT-Daten auch noch die API-Daten direkt in Deinen Adapter.

Flashen ota scheint auch zu funktionieren - zumindest von esphome aus.

Hinterlegen der credentials, incl. api credentials in einem zentralen file für alle Sensoren auch.

Klasse!

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

Flashen ota scheint auch zu funktionieren - zumindest von esphome aus.

sind die Geräte per mdns erreichbar, also im selben Subnetz ?

@klassisch sagte in [ESPHome] Beta release:

Hinterlegen der credentials, incl. api credentials in einem zentralen file für alle Sensoren auch.

wie meinst ?

[klassisch]

@dutchman sagte in [ESPHome] Beta release:

sind die Geräte per mdns erreichbar, also im selben Subnetz ?

die sind alle im selben Netz. Bin Netzwerklaie und verwende eine Fritte. Und halte es einfach - so lange es geht.

@klassisch sagte in [ESPHome] Beta release:

Hinterlegen der credentials, incl. api credentials in einem zentralen file für alle Sensoren auch.

wie meinst ?

So ein file, in dem ich die ganzen IP Adressen, Passwörter, SSID und das was alle meine Sensoren gemeinsam haben, zusammenfasse und welches dann im yaml mit

<<: !include includes.yaml

referenziert wird.

[klassisch]

vielleicht noch eine Frage: Wie viel Ressourcen braucht ein solches Dashboard? Habe noch einen NUT-Server auf einem OPI plus 2e und armbian laufen. Allerdings nur 1GB RAM,. Passt das da noch drauf? Das Teil idled sonst nur rum.

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

vielleicht noch eine Frage: Wie viel Ressourcen braucht ein solches Dashboard? Habe noch einen NUT-Server auf einem OPI plus 2e und armbian laufen. Allerdings nur 1GB RAM,. Passt das da noch drauf? Das Teil idled sonst nur rum.

Nicht so viel sollte passen

[klassisch]

Vielen Dank! Auf dem SBC sind die falschen python Versionen drauf. 2.7 als default und dann noch eine 3.5. Das lasse ich mal lieber, am Ende runiere ich noch den NUT Server... Bin Linux Laie und schaffe es nicht einmal ein Linux Mint ordentlich mit Remote Desktop zu connecten.... Und auch der OPi hatte nach der letzten Neuinstallation von armbian nur noch 1GB statt 2GB RAM.

[klassisch]

Wie erfolgt die Benennung der einzelnen Datenpunkte?

Die Frage stellt sich im Zusammenhang mit mehreren gleichartigen Sensoren und Skript.
Die Id eines States scheint beim ESPHome mit einer random number verbunden zu sein, was die Behandlung gleichartiger Sensoren erschwert, weil man dann immer alle Datenpunkte einzeln eingeben muß.
Nehmen wir als Beispiel einen aufsummierenden pulsecounter, wie er als S0 oder Wasseruhrzähler eingesetzt wird.

Mich interessiert der state "S0-heating total" und "S0-heating-delta" sowie uptime sensor
Die ID der einzelnen states scheint aber nicht aus der ID des Sensors ableitbar zu sein, wie das z.B. bei ESPEasy, zigbee, HM etc ist. Beispiel EPSEasy

Beim pulse counter kann ich die Ids aus der ID des Sensors ableiten. Ein anderer pulse counter vergibt die Namen nach dem gleichen Schema

Das ist natürlich in Skripten viel praktischer.

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

Wie erfolgt die Benennung der einzelnen Datenpunkte?

Die Struktur ist :

Adapter.Instance.Geraet.SensorType.Entitaet.>wert<
Der name kommt aus der yaml und wird vom code so übernommen, kannst mir deine mal zeigen was da definiert ist ?

Um es ein wenig übersichtlicher zu machen kommt im niesten update die option den ordner "SensorType" weck zu lassen, löst aber nicht das problem deiner frage.

@klassisch sagte in [ESPHome] Beta release:

Die ID der einzelnen states scheint aber nicht aus der ID des Sensors ableitbar zu sein

Korrekt, daran kann ich leider nichts ändern jeder sensor Eintrag in der yaml erstellt deine Entität (das ist diese id).
Ich brauche das auch in den states um es unterscheiden zu können, sonst haben wir das Risiko das anderen Sensoren mit gleichen Namen die selben Datenpunkte bekommen daher ist innerhalb einer device diese id vorhanden.

@klassisch sagte in [ESPHome] Beta release:

Beim pulse counter kann ich die Ids aus der ID des Sensors ableiten. Ein anderer pulse counter vergibt die Namen nach dem gleichen Schema

ist halt wie ESPHome es bereitstellt

Schau so sieht aus was ich reinbekomme (zufällig n pulse counter auch hier fuer die Wasseruhr :))

Eerst die device (alzo info zum ESP)

{
  "usesPassword": true,
  "name": "testnodemcu",
  "macAddress": "2C:F4:32:79:FA:8E",
  "esphomeVersion": "1.19.4",
  "compilationTime": "Jul 5 2021, 15:32:14",
  "model": "PLATFORMIO_NODEMCUV2",
  "hasDeepSleep": false
}

Dan bekomme ich die so genannten Entitäten :

{
  "objectId": "waterverbruik_in_liters",
  "key": 725167390,
  "name": "Waterverbruik_in_liters",
  "uniqueId": "testnodemcusensorwaterverbruik_in_liters",
  "icon": "mdi:water",
  "unitOfMeasurement": "l/h",
  "accuracyDecimals": 1,
  "forceUpdate": false
}

Der KEY hier ist wichtig und siehst du auch zurueck in deinen baum Strukturen, jede eint die ich reinbekomme wird so verarbeitet.

Danach kommen nur noch die werte rein :

{
  "key": 725167390,
  "state": 0,
  "missingState": false
}

Ergo, ich muss jede Entität separieren sonst koennen Sensoren sich überlappen, der name des ordner kommt aus dem Namen hier welche in der yaml hinterlegt ist

sensor:
  - platform: pulse_meter
    pin: D6
    name: "Waterverbruik_in_liters"
    id: water_usage
    icon: "mdi:water"
    unit_of_measurement: 'l/h'
    accuracy_decimals: 1
    timeout: 60sec
    total:
      id: sensor_pulse_meter_total
      name: "Water Total verbruik"
      icon: "mdi:cube-outline"
      unit_of_measurement: "m³"
      accuracy_decimals: 3
      filters:
        - multiply: 0.001

[klassisch]

Vielen Dank für Deine ausführliche und klare Antwort.
Habe schon vermutet, daß das im ESP-Home Konzept liegt und nicht zu ändern ist.
Könnte zu einer effizienteren und besser planbaren Datenübertragung führen. Die Kollegen werden schon ihre Gründe dafür haben.
Was mir aber unklar ist, wie der ESP wissen kann, ob die Zufallszahl nicht bereits anderweitig vergeben wurde. Aber das ist ja eine ganz andere Frage, die die Kollegen vom ESPHome oder Home Assitant sicherlich bereits gelöst haben.

Meine Definition sieht so aus:

  - platform: pulse_counter
    name: "S0-heating-delta"
    pin: 
      number: GPIO13
      mode: INPUT_PULLUP
      inverted: false
    count_mode:
      rising_edge: increment
      falling_edge: disable 
    update_interval: 60s

    total:
      name: S0-heating-total

Wirklich wichtig für mich ist das "total". Den Rest mache ich im ioBroker.

Da man ja nicht sooo viele Geräte braucht, wird man die Eingabe der einzelnen Adressen auch überleben

Ansonsten ist der pulsecounter recht flott. 2kHz kann er beim 8266 noch verarbeiten, wobei die Gating-Time etwas "rauscht".
Kann man schön beobachten, wenn man z.B. rising inkrementiert und falling dekrementiert und an den FUnktionsgenerator anschließt.

[Dutchman]

@klassisch sagte in [ESPHome] Beta release:

Was mir aber unklar ist, wie der ESP wissen kann, ob die Zufallszahl nicht bereits anderweitig vergeben wurde. Aber das ist ja eine ganz andere Frage, die die Kollegen vom ESPHome oder Home Assitant sicherlich bereits gelöst haben.

brauch er ja nicht, er muss es nur fuer sich selber wissen und das kan die firmware halt

[Slowman]

@dutchman

Habe jetzt so ne komische Fehlermeldung im ESPHome. Es funktioniert alles, so weit ich das erkennen kann.

esphome.0 (1276) [dashboardProcess ERROR] WARNING Calling ESPHome with the configuration before the command is deprecated and will be removed in the future. WARNING Please instead use:WARNING esphome dashboard /opt/iobroker/iobroker-data/esphome.0

[klassisch]

@slowman wahrscheinloch hast Du

esphome meins.yaml run

eingegeben. Mittlerweile will er aber

esphome run meins.yaml

[Dutchman]

@slowman sagte in [ESPHome] Beta release:

@dutchman

Habe jetzt so ne komische Fehlermeldung im ESPHome. Es funktioniert alles, so weit ich das erkennen kann.

esphome.0 (1276) [dashboardProcess ERROR] WARNING Calling ESPHome with the configuration before the command is deprecated and will be removed in the future. WARNING Please instead use:WARNING esphome dashboard /opt/iobroker/iobroker-data/esphome.0

Welche Adapter Version ?

[Slowman]

@dutchman

[klassisch]

Was macht eigentlich die Neuerung in V 0.2.4

option if config of ESPHome device should be shown as states