Sonoff TRVZB does not report every state.

[MeisterQ]

Im missing datapoints like Valve opening degree (numeric)

Is there anything missing or is my pairing just broken? I paired it twice to get more informations.

Current running zigbee is on version 1.10.3 and im using the cod.m czc poe coordinator.

If i try to send {"valve_closing_degree": "100" }, ill get the following errors.

If i try to get informations about the idle steps or so on, ill get this message

[asgothian]

Please add the device to the exclude list (tab "exclude" or "ausschliessen" in German)

A.

[MeisterQ]

Please add the device to the exclude list (tab "exclude" or "ausschliessen" in German)

A.

Was bewirkt das? Wir hier noch aktiv dran gearbeitet, dass alle exposes kommen?

[asgothian]

beim ausschliessen wird das gesamte device zu 100% aus den Exposes aufgebaut, auch wenn es explizit im zigbee Adapter in den devices definiert ist. Ich gehe aktuell davon aus das das der Fall ist.

A.

[MeisterQ]

beim ausschliessen wird das gesamte device zu 100% aus den Exposes aufgebaut, auch wenn es explizit im zigbee Adapter in den devices definiert ist. Ich gehe aktuell davon aus das das der Fall ist.

A.

Ich hab es ausgeschlossen:

Aber was bringt es mir nun genau? Adapter habe ich neu gestartet. Merke aber keine große Veränderung. Ideen?

[asgothian]

wenn das Gerät auf der Liste ist, versuch mal die 1.10.9 von Github.

Was es dir bringt ist das die Datenpunkte zu 100% durch die Exposes getrieben werden. Dennoch gibt es das Problem das die exposes sich über die Zeit ändern, und die 1.10.3 nutzt eine ältere Version der dahinter stehenden Bibliothek. In der Doku ist leider nicht zu erkennen welche Exposes in welcher Version unterstützt werden.

A.

[MeisterQ]

wenn das Gerät auf der Liste ist, versuch mal die 1.10.9 von Github.

Was es dir bringt ist das die Datenpunkte zu 100% durch die Exposes getrieben werden. Dennoch gibt es das Problem das die exposes sich über die Zeit ändern, und die 1.10.3 nutzt eine ältere Version der dahinter stehenden Bibliothek. In der Doku ist leider nicht zu erkennen welche Exposes in welcher Version unterstützt werden.

A.

Also sollten die exposes direkt kommen, ohne vom zigbee Adapter bearbeitet zu sein? Was eigentlich bedeuten sollte, dass die exposes, die in der Doku stehen, auch angezeigt werden und nicht NULL sind?

Es scheinen sich jetzt einige geupdated zu haben. Alle sind noch nicht da. Vielleicht muss ich neu Pairen oder mal die Ventile fahren lassen.

Das scheint aber auch nur bei einem TRV geklappt zu haben. Ein weiteres zeigt keinen Unterschied und egal was ich mache, die opening degrees verändern sich nicht.

[asgothian]

Willkommen bei TuYa. Offensichtlich sind die beiden Thermostate nicht identisch. Die Null Werte sind noch null weil der Thermostat sie noch nicht gemeldet hat. Kann bis zu 24 stunden dauern.

Ansonsten macht es Sinn bei dem wo es nicht geht den Thermostat neu anzulernen (nachdem du den sauber gelöscht hast)

A.

[MeisterQ]

Willkommen bei TuYa. Offensichtlich sind die beiden Thermostate nicht identisch. Die Null Werte sind noch null weil der Thermostat sie noch nicht gemeldet hat. Kann bis zu 24 stunden dauern.

Ansonsten macht es Sinn bei dem wo es nicht geht den Thermostat neu anzulernen (nachdem du den sauber gelöscht hast)

A.

Wieso bei Tuya? Sind ja sonoff Geräte. Wie meinst du unterschiedlich?

Der Adapter zeigt mir auch nur den einen Typ an.
Ich werde beide mal richtig löschen (ohne verloren) und dann neu anlernen.

Entwickelst du eigentlich aktiv am Adapter? Liegt das alles nun am TRV, am Adapter oder oder zigbee?

[asgothian]

Fangen wir mit den Antworten hinten an. Ja, ich entwickle am Adapter. Allerdings mache ich das nebenher - es kann also durchaus dauern bis ich etwas fertig habe. Aktuell geht es um Probleme beim Einbinden der neueren Versionen vom zigbee-herdsman und zigbee-herdsman-converters, zweier Bibliotheken die sowohl im Zigbee-Adapter als auch bei zigbee2mqtt.io genutzt werden. Leider gibt es da immer mal wieder "breaking changes" die ich erst erfahre wenn das Kind im Brunnen ist - so auch jetzt. Du kannst ja mal einen Blick in den Issue #2211 werfen.

Nun zur Frage warum ich TuYa erwähne. Dazu musst du wissen was TuYa wirklich ist. Viele glauben das TuYa ein Hersteller von zigbee-kompatiblen Geräten ist. Das ist aber nicht zu 100% korrekt. TuYa stellt neben eigenen Geräten anderen Herstellern einen Baukasten zur Verfügung. In diesem Baukasten finden sich Zigbee-Steuerplatinen, komplette Zigbee Geräte, Zigbee to Wifi oder Zigbee to LAN Konverter, sogar vollständige Zigbee-Hubs aber auch eine Implementation zur Anbindung. Wieviel davon ein Hersteller nutzen will bleibt dem Hersteller selber überlassen.

Auch SonOff nutzt diese Infrastruktur. Bei "neueren" Geräten fällt dieses nicht so auf, aber ich habe hier 2 SonOff Bewegungsmelder, die als Hersteller eWeLink melden - nicht SonOff.

Wie komme ich (ohne die Geräte zu kennen) darauf das die Thermostate auch TuYa sind ? Das liegt zum einen daran das sie einzelnen TuYa TS0601 sehr ähnlich sehen, (du kannst ja mal bei zigbee2mqtt.io auf der Seite der unterstützten Geräte mit diesem Filter schauen was da so hoch kommt:

noch mehr aber an Deiner Aussage:

Das scheint aber auch nur bei einem TRV geklappt zu haben. Ein weiteres zeigt keinen Unterschied und egal was ich mache, die opening degrees verändern sich nicht.

Ich habe das so gelesen das einer der beiden Thermostate die erweiterten Datenpunkte zeigt und auch füllt, der andere aber nur einen Teil der Datenpunkte zeigt und auch nur einen Teil der Datenpunkte füllt. Das was du jetzt schreibst hört sich so an als ob zwar die Datenpunkte alle da sind, sie aber nicht alle gefüllt werden. Das wiederum kann verschiedene Gründe haben:

• die Kommunikation klappt nur in eine Richtung - dann kannst du den Thermostat zwar steuern, bekommst aber keine Rückmeldung. Abhilfe schafft hier nur eine "Verbesserung" des Netzwerk. Das kann schon mal durch die Kombination von geschickt gesetzten Routern mit geringerer Sendeleistung am Koordinator geschehen. Ein Versuch dauert hier aber mindestens 48 h - Zeit die das Zigbee Netz braucht sich umzuorganisieren.
• der Thermostat hat zwar das Pairing erfolgreich geschafft, nicht aber die Konfiguration. Diese kann nachgeholt werden:
  . Dazu das Gerät aber auf jeden Fall "aufwecken", bzw. wach halten
• das Gerät verweigert es die Daten zu melden.

in einem ersten Schritt würde ich die letzten 8 Stellen der DeviceID in den State zigbee.0.info.debugmessages eintragen. Dann bekommst du für jede Kommunikation zu und von dem eingetragenen Gerät 4 Warn-Meldungen im Log. Siehe auch hier An der Stelle kannst du dann sehen ob das Gerät überhaupt etwas meldet oder nicht.

1 Punkt noch zur "availability". Diese lässt sich bei batterie-betriebenen Geräten nur bedingt feststellen. Generell gilt: Wird für ein Gerät eine Nachricht empfangen geht die availability auf "wahr". Zusätzlich gibt es im Adapter 2 unterschiedliche 'Gerätetypen', jede mit der eigenen Methode:

• Router Devices - diese müssen immer Strom haben, und sollten auf einen "ping" mit einer Antwort reagieren. Dieser Ping wird in regelmässigen Abständen gesandt. Kommt keine Antwort so wird die availability auf false gesetzt. Sobald
• end-Devices - diese sind üblicherweise batteriebetrieben, und reagieren daher nicht auf "ping" requests. Bei diesen Geräten läuft ein Timer - wenn sie innerhalb von 25 h keine Nachricht senden dann wird die availability auf "falsch" gesetzt.

Beim Start des Adapters wird zunächst bei allen Geräten die Availability auf wahr und die Link-Quality auf 10 gesetzt.

A.

[MeisterQ]

Nun zur Frage warum ich TuYa erwähne. Dazu musst du wissen was TuYa wirklich ist. Viele glauben das TuYa ein Hersteller von zigbee-kompatiblen Geräten ist. Das ist aber nicht zu 100% korrekt. TuYa stellt neben eigenen Geräten anderen Herstellern einen Baukasten zur Verfügung. In diesem Baukasten finden sich Zigbee-Steuerplatinen, komplette Zigbee Geräte, Zigbee to Wifi oder Zigbee to LAN Konverter, sogar vollständige Zigbee-Hubs aber auch eine Implementation zur Anbindung. Wieviel davon ein Hersteller nutzen will bleibt dem Hersteller selber überlassen.

Das wusste ich noch nicht. Sehr interessant jedenfalls.

Auch SonOff nutzt diese Infrastruktur. Bei "neueren" Geräten fällt dieses nicht so auf, aber ich habe hier 2 SonOff Bewegungsmelder, die als Hersteller eWeLink melden - nicht SonOff.

Wie komme ich (ohne die Geräte zu kennen) darauf das die Thermostate auch TuYa sind ? Das liegt zum einen daran das sie einzelnen TuYa TS0601 sehr ähnlich sehen, (du kannst ja mal bei zigbee2mqtt.io auf der Seite der unterstützten Geräte mit diesem Filter schauen was da so hoch kommt:

Hab schon gesehen, dass die Aqara E1 aussehen wie viele andere. Das ist mind-blown.

noch mehr aber an Deiner Aussage:

Das scheint aber auch nur bei einem TRV geklappt zu haben. Ein weiteres zeigt keinen Unterschied und egal was ich mache, die opening degrees verändern sich nicht.

Ich habe das so gelesen das einer der beiden Thermostate die erweiterten Datenpunkte zeigt und auch füllt, der andere aber nur einen Teil der Datenpunkte zeigt und auch nur einen Teil der Datenpunkte füllt. Das was du jetzt schreibst hört sich so an als ob zwar die Datenpunkte alle da sind, sie aber nicht alle gefüllt werden. Das wiederum kann verschiedene Gründe haben:

Genau. Datenpunkte werden erstellt, aber nicht gefüllt. Bei dem, der die schlechtere Linkquality hat, wurden nun welche gefüllt (Auch nicht alle)

Bei dem mit der besseren Linkquality wurden die aber nicht gefüllt.

• die Kommunikation klappt nur in eine Richtung - dann kannst du den Thermostat zwar steuern, bekommst aber keine Rückmeldung. Abhilfe schafft hier nur eine "Verbesserung" des Netzwerk. Das kann schon mal durch die Kombination von geschickt gesetzten Routern mit geringerer Sendeleistung am Koordinator geschehen. Ein Versuch dauert hier aber mindestens 48 h - Zeit die das Zigbee Netz braucht sich umzuorganisieren.

Sieht Aussage da drüber. Ich werde noch mal einen Router in die Nähe setzen.

• der Thermostat hat zwar das Pairing erfolgreich geschafft, nicht aber die Konfiguration. Diese kann nachgeholt werden:
  . Dazu das Gerät aber auf jeden Fall "aufwecken", bzw. wach halten

Das Probiere ich auch aus.

• das Gerät verweigert es die Daten zu melden.

in einem ersten Schritt würde ich die letzten 8 Stellen der DeviceID in den State zigbee.0.info.debugmessages eintragen. Dann bekommst du für jede Kommunikation zu und von dem eingetragenen Gerät 4 Warn-Meldungen im Log. Siehe auch hier An der Stelle kannst du dann sehen ob das Gerät überhaupt etwas meldet oder nicht.

Hier habe ich mal was angetriggert. Ist das "ok" oder ist da was ausergewöhnlich?

1 Punkt noch zur "availability". Diese lässt sich bei batterie-betriebenen Geräten nur bedingt feststellen. Generell gilt: Wird für ein Gerät eine Nachricht empfangen geht die availability auf "wahr". Zusätzlich gibt es im Adapter 2 unterschiedliche 'Gerätetypen', jede mit der eigenen Methode:

• Router Devices - diese müssen immer Strom haben, und sollten auf einen "ping" mit einer Antwort reagieren. Dieser Ping wird in regelmässigen Abständen gesandt. Kommt keine Antwort so wird die availability auf false gesetzt. Sobald
• end-Devices - diese sind üblicherweise batteriebetrieben, und reagieren daher nicht auf "ping" requests. Bei diesen Geräten läuft ein Timer - wenn sie innerhalb von 25 h keine Nachricht senden dann wird die availability auf "falsch" gesetzt.

Beim Start des Adapters wird zunächst bei allen Geräten die Availability auf wahr und die Link-Quality auf 10 gesetzt.

A.

Jetzt bleibt mir nur die Frage: Muss das TRV irgendwie zusätzlich "eingepflegt" werden (An welcher Stelle auch immer), oder wird es durch ein "standard" verarbeitet, der alle TRV quasi unterstützt und das Problem liegt am Netzwerk / Koordinator / Falscher Betriebszustand (schlafend) beim füllen der DP etc?

Danke für die Ausführliche Antwort. Zu warten ist kein Problem. :)

[asgothian]

Jetzt bleibt mir nur die Frage: Muss das TRV irgendwie zusätzlich "eingepflegt" werden (An welcher Stelle auch immer), oder wird es durch ein "standard" verarbeitet, der alle TRV quasi unterstützt und das Problem liegt am Netzwerk / Koordinator / Falscher Betriebszustand (schlafend) beim füllen der DP etc?

Nein - der Zigbee Adapter baut die gesamte Struktur aus dem aus was von den zigbee-herdsman-converters als exposes geliefert wird.

Eine Bitte noch - Logs immer als Text, dann kann ich die auch mobil lesen. Das Bild konnte ich nicht entziffern

Hier habe ich mal was angetriggert. Ist das "ok" oder ist da was ausergewöhnlich?

es ist schon auffällig das die Änderung des Modus nicht bestätigt wird. Das hätte ich eigentlich erwartet. Ansonsten wird die LQI regelmässig gemeldet - das ist ok.

A.

[MeisterQ]

@asgothian Ich habe vom TRV ein Update gemacht. Das schien erfolgreich gewesen zu sein.

Habe alles sauber gelöscht, neu angelernt sowohl rekonfiguriert während es aktiv ist.

Leider hat das alles nichts gebracht. Zumindest für die Opening und Closing degree.

Wenn ich die Schreiben will, bekomme ich

zigbee.0 | 2024-10-08 11:48:25.511 | warn | Send command to 0x0cae5ffffeb4560f failed with: Code 134 (Unsupported Attribute)

Als Antwort im Log

[asgothian]

Das bedeutet das die Abbildung im den zigbee-herdsman-converters nicht zu der Funktionalität der Geräte passt. Auch eine Eigenheit der China-Geräte - da wird gerne mal Unterstützung für bestimmte Datenpunkte entfernt oder ist abhängig vom Modus des Gerätes.

An der Stelle ist dann wahrscheinlich Schluss. Du kannst versuchen durch Umstellung des Betriebsmodus einen Modus zu finden wo das Setzen dieser Attribute möglich ist - ob das erfolgreich ist ist aber zumindest fraglich.

A.

[MeisterQ]

Das bedeutet das die Abbildung im den zigbee-herdsman-converters nicht zu der Funktionalität der Geräte passt. Auch eine Eigenheit der China-Geräte - da wird gerne mal Unterstützung für bestimmte Datenpunkte entfernt oder ist abhängig vom Modus des Gerätes.

An der Stelle ist dann wahrscheinlich Schluss. Du kannst versuchen durch Umstellung des Betriebsmodus einen Modus zu finden wo das Setzen dieser Attribute möglich ist - ob das erfolgreich ist ist aber zumindest fraglich.

A.

Dann würde ich sagen, ich muss das jetzt so hinnehmen. Vielen Dank für die Mühe. Der kann zu denke ich.

Nach dem Resetten und neu pairen habe ich folgendes beobachtet plötzlich.

Oben im Post ging es nicht. Hier schon

Sorry für den Screenshot

[asgothian]

diese Meldungen waren dein Versuch die Werte zu ändern. Die Werte wurden nicht vom Adapter geschrieben.

A