Zigbee2mqtt-Fehhlermeldung

Danke für deine Antwort, ich teste das Bild gerade.
Muss ich meine Geräte entfernen / hinzufügen oder wird das Mapping automatisch aktualisiert?

Bisher habe ich keine Rückschritte, aber einige Mappings funktionieren nicht, weil sie noch nicht in Gladys unterstützt werden (vernetzte Heizkörperthermostate):

Ich habe herausgefunden, dass die zweite Schaltfläche im Dashboard „Fenstererkennung“ entspricht, die erste weiß ich noch nicht :sweat_smile: Im Moment ist es in Gladys unmöglich zu wissen, was den verschiedenen Schaltflächen in Zigbee2Mqtt entspricht.

Ist das erste nicht der eco_mode?

Ja, genau. In Gladys fehlt also der Schalter, der boost_heating entspricht und in meinem Screenshot nicht sichtbar ist.
Derzeit zeigt die Oberfläche den Wert an, aber ich kann den Schalter nicht verwenden, da Gladys nicht die von Zigbee2Mqtt akzeptierten Werte zurückgibt:

@lmilcent normalerweise müssen Geräte nicht gelöscht/hinzugefügt werden, außer um neue Features zu integrieren, die möglicherweise entdeckt wurden (was nicht der Zweck des Bildes ist).

Ich muss verstehen, dass die Standardbenennung der Features überarbeitet werden muss?
(ich muss überprüfen, ob es sich um die Benennung der Features oder die Anzeige im Dashboard handelt)

Was den LOCK betrifft, ist dies im Ticket [Zigbee2Mqtt] Failed to convert value for device RadiateurSalon: Error: Zigbee2mqqt don't handle value "LOCK" for feature "mode". · Issue #1448 · GladysAssistant/Gladys · GitHub als behoben identifiziert.
Hast du das letzte Bild atrovato/gladys:zigbee2mqtt von gestern Abend?

Die Meldung « No converter available… » ist beim Gerät Moes BRT-100-TRV identifiziert?
Falls ja, überprüfe, ob das Bild in Ordnung ist. Theoretisch wird die Eigenschaft « state » bei diesem Gerät nicht verwendet, sondern « child_lock ».

Ich glaube nicht, dass das etwas miteinander zu tun hat, aber ich habe diese Meldung erhalten.

lol ok bon… wir machen weder LQI noch Coordinator…
danke :wink:

Hallo,
Ich habe gesehen, dass es in dem Testbild die Integration von Alarm und CO2 gibt. Ich habe bereits beide Geräte in einem Karton. Kann ich von dem offiziellen Bild zu dem DEV-Bild wechseln, ohne alles zu zerstören, oder gibt es ein Risiko?

Risiko null gibt es nicht, aber ich bin eher zuversichtlich.
Ein Backup der Datenbank davor wird empfohlen.

Ich habe gerade getestet, die Funktionen werden für den Alarm (Tuya TS0216 control via MQTT | Zigbee2MQTT), einen CO-Detektor (Heiman HS1CA-E control via MQTT | Zigbee2MQTT) und einen Rauchmelder (https://www.zigbee2mqtt.io/devices/HS1SA.html) erkannt.

Ich weiß jedoch nicht, ob der fehlende Wert für die Detektoren der Standard ist oder ob es einen 0 oder einen Standardwert von « Nein » geben sollte.

(PS Allerdings haben alle drei Geräte eine Sirene und ich habe mich von meinem Gehör für den Nachmittag verabschiedet :stuck_out_tongue: )

Für den Standardwert habe ich schon nachgedacht, das wird ein nächster Schritt. Lass uns erstmal die noch umfassendere Verwaltung der Geräte validieren.

Hast du mit den Alarmen seit Gladys gespielt? Die Ohrstöpsel waren nicht dabei?? :stuck_out_tongue:

Ja, ich habe mit dem Alarm gespielt, nur in einer Szene mit Aktivierung zu einer bestimmten Uhrzeit, das hat gut funktioniert, und der Ein-/Ausschaltknopf funktioniert auch gut!

Leider nein und ich hätte nicht mit so viel Lärm gerechnet, vor allem von den beiden CO- und Rauchmeldern :smiley:

Auf jeden Fall super Arbeit, das verspricht große Möglichkeiten für die Zukunft :wink:

Edit: Es wäre interessant, den Lautstärkepegel der Alarmsirene in Gladys ähnlich wie die Helligkeit einer Lampe steuern zu können

Ich muss ein Problem mit meinem Alarm TS0216 haben, denn ich kann ihn trotz mehrerer Versuche nicht zum Erkennen bringen.
Trotzdem habe ich in ein Gateway Tuya (Lidl) investiert, um es zu überprüfen: Es funktioniert gut über die dedizierte Schnittstelle. Ich verstehe nicht, was los ist?

Entschuldige @AlexTrovato, ich konnte früher nicht antworten. Soweit ich weiß, hatte ich tatsächlich die letzte Version des Docker-Images.

Hmm, ich weiß nicht, wie man das überprüft? Nur zur Info, ich habe das GitHub-Ticket eröffnet, das du erwähnt hast :wink:

Haha jetzt, wo du es sagst, stimmt es tatsächlich, die Pseudos passen :slight_smile:
Das letzte Testbild ist in Version 4.8.0 (Gladys → Admin → System).
Laut dem Ticket auf GitHub scheint es zu funktionieren, es sei denn, du hast einfach die Dateien kopiert, dann wird das Testbild nicht validiert.

Zur Information habe ich den PR von @AlexTrovato gemerged, der die benutzerdefinierten Mappings für die Zigbee2mqtt-Integration hinzufügt!

Ich habe gerade einen DEV-Build auf dem Docker-Tag gestartet, der in etwa einer Stunde fertig sein wird:

gladysassistant/gladys:dev

(Der Build: https://github.com/GladysAssistant/Gladys/actions/runs/2078334755)

Ich bin offen für Feedback zur Zigbee2mqtt-Integration, um sicherzustellen, dass sie das gewünschte Verhalten für Geräte liefert, die zuvor nicht unterstützt wurden, und dass sie den Rest von Zigbee2mqtt nicht beeinträchtigt, natürlich :smiley:

Vielen Dank an alle, die testen werden!

@pierre-gilles Auf welchem RPI-Betriebssystem kann man diesen Build testen?

Auf allen (das ist nicht OS-abhängig)

Danke @VonOx Bei mir funktioniert es korrekt mit meinen Geräten: Lampen, Steckdosen, Sirene, Temperatur, Luftfeuchtigkeit, getestet mit einem CC2652 BLE Simplelink 2.2G Zigbee2MQTT
Danke und Glückwunsch zu der guten Arbeit!
Nur zur Info, mein Sonoff-Dongle erkennt alle meine Geräte, er funktioniert korrekt beim Empfang, aber nicht beim Senden. Wurde dieses Problem bereits gemeldet?

Im Fernsehen?

Das heißt im Befehlsmodus für Schalter, Lampen oder eine Sirene