Eurotronic Spirit: Aussetzer bei Werten bzw. mehrere Werte reporten

[laufhem]

Hallo ich habe mehrere Eurotronic Spirit ZWave Thermostate im Einsatz und bei manchen auch Probleme, dass Temperaturwerte bzw. Ventilöffnungen nicht richtig übertragen werden (https://forum.fhem.de/index.php?topic=77598).
1)
Ich habe gelesen, dass dies an der Assoziation liegen kann? Was muss ich da genau prüfen?

2)
Unabhängig davon habe ich aber auch beobachtet, dass manche Thermostate zwar die Temperatur regelmäßig gemäß Änderungsgrenzwert berichten, aber der zuständige "reportedState" (get * swmStatus) veraltet ist.
Kann ich einstellen, dass jedes Gerät mit jeder Temperaturänderung zusätzlich auch z.B. noch den reportedState, den setPoint und den thermostatMode sendet?

3)
Wenn ich im FHEM mehrere Thermostate abfragen möchte, berichten manche nicht:

Code Auswählen Erweitern

get Thermostat.* smStatus --> manche berichten nicht.
Wenn ich diese einzelnen Geräte dann explizit abfrage, kommt der Wert allerdings

Code Auswählen Erweitern

get Thermostat_Badezimmer smStatus --> Badezimmer liefert Wert.
Ist das "prinzipbedingt" Funküberlast im ZWAVE Netz? Wie kann man das optimieren (wenn ich alle Thermostate abfragen möchte)?
Generell liefern manche Geräte auch erstmal als Antwort ein "Timeout", aber kurz darauf ist der Wert im FHEM aktualisiert zu lesen. Ist das normal?

[rudolfkoenig]

1) mit "get assotiation <NR>", ob da der ZWave-Dongle eingetragen ist. <NR> ist meist 1, mehr Details dazu sollte im Beipackzettel stehen.

2) reportedState wird parallel zu state gesetzt, da state ueberschrieben werden kann (durch set Befehle, frueher auch durch transmit Fehler).
state wird ueber die Klassen SWITCH_BINARY, SWITCH_MULTILEVEL und SENSOR_BINARY gemeldet.

3) Der ZWave Dongle kann es nicht ab, wenn man ihn stoert, wenn er (z.Bsp. mit einem get) nicht fertig ist.
Die Warteschlangen fuer diese Aufgabe wurden in FHEM in den ZWave Instanzen angelegt, richtig waere diese in der ZWDongle Instanz zu pflegen.
Das Protokoll zum Dongle mussten wir selbst rausfinden, da dazu (meines Wissens) keine Doku existiert, deswegen diese (an dieser Stelle falsche) Loesung.
Die Warteschlangen umzustellen wuerde etliche Tage Arbeit bedeuten, und ich habe das bisher nicht investiert.
Kurz: bitte  "get .* cmd" meiden. Selbst beim set ist es ratsam, die Aufgabe ueber structure zu loesen, und da async_delay zu setzen.

[laufhem]

Zu 1)
Das würde nur erklären, wenn nie automatisch Werte gesendet werden, oder? Bei mir steht überall der Richtige ZW-Dongle. Die Aussetzer sind auch nur sporadisch

Zu 2) Ich weiß nicht, ob wir uns richtig verstehen. Ich möchte dem ZWave Gerät sagen, dass er mehrere Werte gleichzeitig sendet (z.B. Temperatur und Ventilposition in einem) Ist das überhaupt möglich?

Zu 3)
Kann ich irgendwie prüfen, ob der ZWDongle gerade ausgelastet ist und einen Befehl so lange zurück halten?
Ich habe es gerade mittels For-Schleife über alle Thermostate in Perl so umgebaut, dass alle 1.5s der nächste "get/set Thermostat XY" Befehl abgesetzt wird. Dennoch werden zwischendurch einige Befehle offensichtlich nicht ausgeführt.

[rudolfkoenig]

1) klingt nach Uebertragungsfehler
2) meines Wissens nein, jedenfalls nicht mit den "standard" ZWave Klassen.
3) da waeren wir beim fehlenden Doku Selbstgebaute forschleife klingt nach Blockieren, deswegen habe ich structure mit async_delay erwaehnt.

[laufhem]

Zu 3)
Wie ich das lese, unterstützt ein struct keine get Methoden. Daher mein Selbstbau.
Nichtdestotrotz habe ich nun ein Struct mit allen Thermostaten und async_delay=2s gebaut. Im ZWDongle ist setReadingOnAck attr gesetzt.

Code Auswählen Erweitern

set HKThermostate_Struct configValveOpeningPercentageReport 2

liefert bei manchen Geräten weiterhin einen veralteten Wert im Reading. Dort muss ich weiterhin händisch per get das Reading abfragen, damit es korrekt angezeigt wird. Wie kann ich das umgehen?

Außerdem gibt es weiterhin wenige Geräte, die den Wert offenbar nicht übernommen haben. Kann ich fehlgeschlagene Übermittelungen automatisch neu starten?


Nachtrag: ein

Code Auswählen Erweitern

set HKThermostate_Struct configValveOpeningPercentageReport 2 aus der Weboberfläche "zusammengeklickt" schickt offenbar den Wert 7 raus (obwohl ich 2 drin stehen habe).
Erst wenn ich den Befehl in der Webcmd-Leiste oben händisch eingebe, funktioniert die 2. ?!
Noch seltsamer

[rudolfkoenig]

Stichworte, die mir einfallen:
- timeToAck Reading anschauen. Wenn das groesser als 0.1 ist, dann ist die Uebertragung problematisch.
- wenn moeglich, ZWave-Router einbauen, das sind Geraete, die staendig mit Strom versorgt werden. Danach ein neighborUpdate durchfuehren. Siehe auch https://wiki.fhem.de/wiki/Z-Wave#Hinzuf%C3%BCgen_eines_neuen_Z-Wave_Ger%C3%A4ts_/_Inklusion
- womoeglich hilft das Visualisieren der Netzwerkverbindungen (in ZWDongle), dazu muss vorher fuer jedes Geraet ein "get neighborList" durchgefuehrt werden. Die Anzeige ist nicht ganz verlaesslich, weil auch dynamische Wege moeglich sind.
- falls das Senden schiefgegangen ist, dann wird ein transmit Event erzeugt (samt Reading), vmtl. mit NO_ACK als Wert, obwohl theoretisch auch andere Werte moeglich sind.

[Wardancer]

Hallo zusammen,

Stichworte, die mir einfallen:
- timeToAck Reading anschauen. Wenn das groesser als 0.1 ist, dann ist die Uebertragung problematisch.

Bitte nicht vergessen, das das Flirs-Devices sind, die brauchen manchmal ein bisschen, bis die Lust haben sich zu melden...
Ich hab bei mir auch immer mal wieder das Problem, das der ein oder andere Befehl nicht geAckt wird, meistens liegt das dann aber im Zwave-Timeout um die Thermostate haben es trotzdem mitbekommen. Ich hab aber auch diverse allways on devices die das Routing übernehmen.
Ich würde mich auch mal um die Optimierung deiner Kommunikation kümmern. Immer nachsenden macht ja auch die ZWave-Übertragung dicht.

[Shadow3561]

- timeToAck Reading anschauen. Wenn das groesser als 0.1 ist, dann ist die Uebertragung problematisch.

Moin,
es ist mir ein Rätsel wie diese Werte zu erreichen sind.
Bei mir hängt der Raps mit dem Zwafe_Stick etwa 15cm neben den Ventilen. Bei mir sind die Werte zwischen 1,2 und 1,8.

Mit freundlichen Grüßen

[laufhem]

Danke für die Hinweise. Leider sind die Thermostate sehr unzuverlässig. Manchmal erreiche ich Werte <1s, dann antworten sie teilweise wieder für mehrere Stunden gar nicht mehr.
Die Thermostate sind die einzigen ZWave-Geräte, die diese Probleme verursachen. Ich habe mehrere Z-Wave Aktoren mit Dauerstromversorgung als Repeater erfolgreich im Einsatz.