Hmm, es scheint, als hätte ich unter diesem Tag nichts Neues zum Pullen. Ich versuche es später nochmal (wahrscheinlich morgen, heute Abend bin ich nicht verfügbar).
Okay, ich habe zu früh gesprochen, es scheint, als ob noch etwa 45 Minuten vergehen, bis das Bild fertig ist 
Neuer Test mit dem neuen Bild, aber es scheint, dass der „Speichern“-Button sich nicht ändert, selbst nach dem erneuten Hinzufügen des Geräts 
Das Gerät verschwindet beim Hinzufügen… und erscheint dann beim Neuladen der Seite wieder.
Gute Neuigkeiten!
Ganz im Gegensatz zu dem, was ich dachte, hatte ich einen der Schalter dabei, dessen Hinzufügung ich vor einiger Zeit angefragt hatte (Zigbee2mqtt: Add device ZM-L03E-Z · Issue #1244 · GladysAssistant/Gladys · GitHub) und er funktioniert auch 
Das macht mich traurig. Kann ich hoffen, dass du es falsch getestet hast??
Das Gerät verschwindet? Wird der Button nicht zu „Bereits in Gladys“ geändert? Und beim Neuladen steht immer noch „Speichern“? Nicht „Aktualisieren“?
Alles klar, ich habe das Problem reproduziert, und tatsächlich, ein dummer Fehler bei der ID-Erkennung…
Neues Image mit dem Fix wird gerade gebaut, es dauert etwa 1,5 Stunden, bis es verfügbar ist.
Okay, jetzt habe ich „Bereits erstellt“ auf den Geräten, die in Gladys registriert sind.
Wenn ich ein Gerät (über Gladys, dann Z2M) lösche, kann ich es direkt in Gladys wieder integrieren, ohne Probleme; der „Speichern“-Button erscheint wieder anstelle des „Bereits erstellt“-Buttons.
Ich denke, wir sind jetzt eher gut dran 
P.S.: Solange ich schon dabei bin, habe ich einige Tests durchgeführt und eine Inkonsistenz bei den Szenen beim Löschen und erneuten Hinzufügen eines Geräts festgestellt. In den Blöcken vom Typ „Licht ein-/ausschalten“ wird das Gerät beim Löschen aus Gladys entfernt. Sobald es entfernt ist, muss es manuell in die Szene zurückgesetzt werden. Allerdings verhält sich das bei Blöcken vom Typ „Gerät steuern“ etwas anders. Das Bearbeiten einer Szene nach dem Löschen des Geräts behält den Steuerblock des betreffenden Geräts (aber nicht ausgefüllt) bei. Wenn das Gerät jedoch vor dem erneuten Speichern der Szene (also zwischen dem Löschen und dem erneuten Hinzufügen) wieder hinzugefügt wird, behält die Szene die Eigenschaften des Geräts vor dem Löschen bei.
Okay, das ist ein bisschen viel.
Aber für einen Szenenfehler denke ich, dass man darüber nicht in einem zigbee2mqtt-Thread sprechen sollte, sonst verlieren wir die Leute.
Danke, dass du @Shiftmaj getestet hast, es ist cool, Feedback zu bekommen, das hilft uns, ruhiger zu mergen (ich habe diese Hardware nicht)
Ich habe gerade den PR von @AlexTrovato gemerged!
@AlexTrovato Bestätigst du, dass das, was wir auf master haben, jetzt „production ready“ ist? Gibt es noch bekannte Bugs?
Zu diesem Teil bin ich mir nicht bewusst, dass es weitere Fehler im Zusammenhang mit den Änderungen gibt. Ich bin eher entspannt.
(Ich habe das Gefühl, dass jemand etwa zehn GitHub-Tickets zu diesem Thema schließen möchte )
Ansonsten könnte ich mich verfügbar machen.
Top! Aha, das ist nicht für mich, das ist für die Leute, die diese Kompatibilitäten verlangen
Das wird wirklich cool, sobald wir diese automatische Erkennung in der Produktion haben.
Also, ich teste gerade meine neuen Spielzeuge. Bisher keine großen Probleme, großartige Arbeit an diesem Service 
Ich habe nur eine Frage zu dieser Art von Gerät Philips 929002398602 control via MQTT | Zigbee2MQTT, es ist eine Art Fernbedienung/Schalter. Wenn ich es richtig verstehe, ist die richtige Methode, um eine Lampe von diesem Gerätetyp ein- und auszuschalten, über Szenen zu gehen. Aber es scheint, dass das nicht möglich ist. In den Auslösern habe ich Gerätezustandsänderung eingestellt, meine Fernbedienung ausgewählt und dann gleich und dort setze ich den Wert on_press (die zigbee2mqtt-Dokumentation gibt die Liste der möglichen Werte an). Leider gibt es beim Speichern einen Fehler mit "[0].value" must be a number als Nachricht im Entwickler-Netzwerk-Tab. Ist das einfach noch nicht implementiert oder ist meine Lösung nicht die richtige?
Entschuldigung, aber tatsächlich werden diese Geräte (Fernbedienung / Würfel …) nicht vollständig unterstützt.
Die Werte sind nicht-numerische Aktionen und wir haben, soweit ich weiß, noch nicht untersucht, wie man diese Art von Werten im Gladys-Kern am besten verwaltet.
Und bei zigbee2mqtt sind die Werte in Form von Zeichenketten fast für jedes Gerät einzigartig.
Man muss von Fall zu Fall vorgehen und eine spezifische Komponente in der UI erstellen, um die Werte zu verwalten
Mehrere Möglichkeiten:
- Entweder man macht eine Abbildung mit numerischen Werten (was es ermöglicht, den Verlauf zu haben). Zum Beispiel « Klick » = 1, « Doppelklick » = 2, usw… und dann muss man in der UI eine spezifische Komponente anzeigen, die einen übersetzten Wert anzeigt.
- Oder man macht keine Abbildung und verwendet die « string »-Zustände von Gladys 4 (ja, die gibt es ), allerdings verliert man dann den Verlauf der Werte. Und genauso muss man eine spezifische Komponente in der UI erstellen, um die Werte zu übersetzen
Zur Info, die neue Version von Gladys integriert Zigbee2mqtt mit automatischer Erkennung 
Danke an @AlexTrovato!
Es scheint, dass die von zigbee2mqtt verwendete Bibliothek eine Liste von Status für jede Aktion bereitstellt zigbee-herdsman-converters/devices/philips.js at 05f0795cbf3742a17d59152bbe2186ec6bc8a48e · Koenkk/zigbee-herdsman-converters · GitHub
Wahrscheinlich ist diese zweite Lösung einfacher, oder? Mir scheint, dass der einzige Ort, an dem wir diese Status benötigen, in den Szenen ist, also die Beibehaltung der Strings könnte eine gute Lösung sein, und da wir die Liste automatisch erhalten können (also ein Dropdown-Menü für die Auslösebedingungen der Szenen).
Zur Info sieht man, dass die Status von Gladys gut erkannt werden, hier ist, wie es auf dem Dashboard aussieht.
Um auf die Geschichte der Geräte mit dem Wert « string » zurückzukommen,
- Es muss möglich sein, dies in die Szenen zu integrieren, da ein Doppelklick eine Szene auslösen könnte (ich denke, das wäre toll)
- tatsächlich existieren die « string »-Zustände, aber die Verwaltung dieser ist im Moment noch sehr begrenzt (je nach Kameras), daher im aktuellen Zustand nicht nutzbar
Jetzt wird es « kompliziert » (aber nicht unmöglich) sein, eine vollständige und kohärente Zuordnung zwischen allen möglichen Zuständen der Geräte und Integrationen und Gladys zu schaffen.
Für mich wäre die einfachste Lösung, eine Zuordnung zu numerischen Werten zu erstellen, aber auf der UI-Ebene könnte die Anzeige aufgrund der Anzahl der Zustände und ihrer Varianten komplex werden.
@Tolkyen
Ich ping dich hier bezüglich des Zigbee2Mqtt-Mehrfachsteckers.
Falls du motiviert bist, eine Testphase durchzuführen, habe ich ein neues Docker-Image erstellt, das dein Gerät verwalten sollte: atrovato/gladys:zigbee2mqtt
Falls du nicht „geübt“ bist, Test-Images zu installieren, rate ich dir nicht, es zu versuchen.
PS: Für alle enthält dieses Image ein Update zur Steuerung der Geräte und eine Korrektur zum Statuswechsel der Aktoren
@AlexTrovato Was denkst du, wird es möglich sein, die Funktion umzusetzen, über die wir uns mal unterhalten haben, bei der die Steckdosenleisten in mehrere Geräte aufgeteilt werden (nativ)?
Die Idee ist, dass der Nutzer die verschiedenen Steckdosen in verschiedenen Räumen verteilen kann, jede Steckdose einzeln in Szenen steuern kann und dass diese Steckdosen mit Sprachassistenten funktionieren
Ja, 100 %, das ist nicht codiert. Aber was ich sagen wollte, ist, dass es nicht unmöglich ist und dass wir das Funktionsprinzip mit den Kameras bereits im Datenmodell/DB hatten.
Allerdings muss man die Szenen anpassen / und den Kern ein wenig, um diese Zustände ordnungsgemäß zu verbreiten.
Das ist ein bisschen das Problem der doppelten Zuordnung, das kann schnell ein Chaos werden ^^