Zigbee2mqtt: Docker-Testimage basierend auf Gladys v4

@cicoub13 Ich dachte mir, dass es nervig wird, die z2m-Geräte zu warten.

Könnten wir das Feature-Mapping nicht automatisch verwalten?

Diese Informationen sind schließlich auf dem Broker verfügbar.

Nein. Ich hatte das bereits auf zwei Arten durchdacht:

  • über die Nachricht, die alle Geräte enthält Redirecting... => das Feld exposes von definition könnte für eine automatische Zuordnung nützlich sein, aber ich habe es mit vielen verschiedenen Geräten getestet und habe dieses Feld nie :frowning: (Beispiel hier: Zigbee devices - Pastebin.com)
  • über die erste Nachricht des Geräts Redirecting... => das Problem ist, dass sie nicht genug Informationen enthält. Zum Beispiel werden ein Schalter und eine Glühbirne dieselbe Nachricht {"state": "ON"} senden

Falls du eine Idee hast, bin ich offen dafür :wink:

Ah, ich habe es gefunden :roll_eyes:

Wenn man include_device_information: true in der Container-Konfiguration von zigbee2mqtt hinzufügt, kann man die Liste der von jedem Gerät bereitgestellten Funktionen abrufen und eine automatische Zuordnung vornehmen.

Ich weiß nicht, ob es besser ist, die Konfiguration der getesteten Geräte zu kontrollieren ODER eine automatische Zuordnung vorzunehmen, die viele Fälle verwalten muss.

{
  "date_code" : "20191205",
  "definition" : {
    "description" : "Aqara Temperatur-, Feuchtigkeits- und Drucksensor",
    "exposes" : [ {
      "access" : 1,
      "description" : "Verbleibende Batterie in %",
      "name" : "battery",
      "property" : "battery",
      "type" : "numeric",
      "unit" : "%",
      "value_max" : 100,
      "value_min" : 0
    }, {
      "access" : 1,
      "description" : "Gemessener Temperaturwert",
      "name" : "temperature",
      "property" : "temperature",
      "type" : "numeric",
      "unit" : "°C"
    }, {
      "access" : 1,
      "description" : "Gemessete relative Luftfeuchtigkeit",
      "name" : "humidity",
      "property" : "humidity",
      "type" : "numeric",
      "unit" : "%"
    }, {
      "access" : 1,
      "description" : "Der gemessene atmosphärische Druck",
      "name" : "pressure",
      "property" : "pressure",
      "type" : "numeric",
      "unit" : "hPa"
    }, {
      "access" : 1,
      "description" : "Spannung der Batterie in Millivolt",
      "name" : "voltage",
      "property" : "voltage",
      "type" : "numeric",
      "unit" : "mV"
    }, {
      "access" : 1,
      "description" : "Linkqualität (Signalstärke)",
      "name" : "linkquality",
      "property" : "linkquality",
      "type" : "numeric",
      "unit" : "lqi",
      "value_max" : 255,
      "value_min" : 0
    } ],
    "model" : "WSDCGQ11LM",
    "supports_ota" : false,
    "vendor" : "Xiaomi"
  }

Es gibt viel Arbeit, um ein Smart Mapping zu erstellen, aber sobald es erledigt ist, haben wir auch zukunftssichere Kompatibilität.

Die Sensoren selbst sind einfach zu erstellen, aber die Schalter sind eine andere Geschichte.

HA macht es so, aber sie haben einen Vorteil: Alles ist im MQTT-HA-Format.

Diese Option ist Teil meiner Konfiguration (mit dem Zeitstempel), also habe ich es nicht bemerkt. Ich dachte, es wäre standardmäßig freigegeben.

Die automatische Erkennung der exponierten Features wäre wirklich ideal, um sicherzustellen, dass alle Geräte standardmäßig unterstützt werden.

Aber man kann das Beste aus beiden Welten bewahren:

  1. Wenn eine Vorlagendatei existiert, wird diese verwendet
  2. Andernfalls werden die Features automatisch erkannt (und in der UI angezeigt?)

So werden alle neuen Geräte unterstützt, aber man kann besondere Fälle verwalten, indem man eine bestimmte Konfiguration erzwingt.

Zur Info, Gladys v4.2.2 wird gerade mit den Fixes von @VonOx und @cicoub13 gebaut!

Build läuft hier:

https://github.com/GladysAssistant/Gladys/actions/runs/726223336

Gladys v4.2.2 ist jetzt live mit den Änderungen :slight_smile: Lasst mich wissen, ob es okay ist, bevor ich darüber kommuniziere.

Kann jemand schnell den z2m überprüfen, ich kann nicht auf den Discover in 4.2.2 zugreifen
FF:

edge:

Ich habe denselben Fehler.

@pierre-gilles War das nicht der React-Select, der gemerged wurde?

preact-i18n wurde von 2.0.X auf 2.3.X aktualisiert und in einer Version haben sie den Kontext geändert Release 2.1.1-preactx · synacor/preact-i18n · GitHub

Ich kann heute Abend einen Blick darauf werfen, um es zu beheben

Hätten wir das mit Cypress gesehen @AlexTrovato?

Schade für die neuen Geräte :sweat_smile:

Ist das in diesem Build, in dem meine Glühbirne wieder zu einer Glühbirne werden soll? (Und nicht zu einem Schalter)

Ich habe mein Gerät gelöscht, neu hinzugefügt, aber nichts Neues.

Muss ich den gesamten Vorgang erneut durchführen? Das heißt, mit Ausschalten/Einschalten der Glühbirne fünfmal?

Du bist nicht auf 4.2.2, weil der Tab „Entdecken“ nicht mehr zugänglich ist (es ist kaputt)

Nein, du musst das Pairing nicht wiederholen.

Willst du den Trottel?

Das betrifft auch:

  • die Geräteauswahl in der Dashboard-Box
  • den Kalender
  • die Szenenbearbeitung
  • die Bluetooth-, MQTT- und Zigbee2MQTT-Dienste
  • die Suche in Integrationen

@pierre-gilles Ich denke, das Beste wäre, diese 2 PRs zurückzusetzen und etwas mehr Zeit zu nehmen, um zu analysieren (unser Gebrauch von this.context.intl ist meiner Meinung nach ein Hack :stuck_out_tongue: )
https://github.com/GladysAssistant/Gladys/pull/1128
https://github.com/GladysAssistant/Gladys/pull/1126

Oh Mann, der hat alles kaputt gemacht, Rob :sweat_smile:

Da merkt man, dass es keine Tests auf der Front gibt.

:fire: „Das ist in Ordnung“ :fire:

Das hätten wir mit Cypress gesehen

Ja, klar, sobald die Tests gemacht sind.
Aber dieses Problem habe ich bei der Migration zu Preact (um den Cypress-Coverage zu testen).

Das kommt nur von diesem PR
https://github.com/GladysAssistant/Gladys/pull/1128/files

Der zweite ist nicht betroffen.

Ach Mist! Ich dachte, ich hätte alles getestet :sweat_smile: Ich muss ein SELECT vergessen haben

Mein Fehler!