structure mit get?

Begonnen von omnior, 16 Dezember 2020, 10:53:27

Vorheriges Thema - Nächstes Thema

omnior

Ich benutze das structure device zur Gruppierung von (ZWave) Heizkörperthermostaten (Eurotronics Spirit). Dort ist es so, dass die per set abgesetzen Befehle kein Telegram auslösen, sondern erst zusätzlich mit einem get die Werte überprüft werden können.
Da man die ganze structure mit einem set zwar setzen kann, ist es sehr umständlich dass man nicht auch per get eine komplette Abfrage auslösen kann.
Wäre das möglich den get Befehl zusätzlich in die structure mit aufzunehmen?

Beta-User

Zitat von: omnior am 16 Dezember 2020, 10:53:27
Ich benutze das structure device zur Gruppierung von (ZWave) Heizkörperthermostaten (Eurotronics Spirit). Dort ist es so, dass die per set abgesetzen Befehle kein Telegram auslösen, sondern erst zusätzlich mit einem get die Werte überprüft werden können.
Zum feature-Request kann ich nichts sagen, aber Rudi hatte jüngst was im ZWave-Modul (bzw. bei ZWDongle) geändert: https://forum.fhem.de/index.php/topic,112955.msg1100503.html#msg1100503.

Setze doch mal setReadingOnAck an deinem IO, dann sollten diese "get-Klimmzüge" Geschichte sein ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

omnior

Cool, gefunden und gleich mal ausprobiert. Damit kann man sicherlich einiges vereinfachen.
Jetzt wäre es noch super, wenn geänderte Stati oder Sollwerte gleich automatisch in einer ReadingsGroup angezeigt werden. Das funktioniert bei mir irgendwie noch nicht selbständig. Gabs da nicht auch irgendeine Einstellung?

Beta-User

readingsGroup ist nicht eben mein Spezialgebiet...

Schau' mal, ob in deiner FHEMWEB-Instanz longpoll auf 1 oder "ws" gesetzt ist (würde "ws" empfehlen), ansonsten gibt es evtl. noch was in der commandref zu readingsGroup zu entdecken?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

omnior

Danke dir, die webinstanz steht eigentlich auf ws, daran liegt es schon mal nicht. Ich geh nochmal weiter auf die Suche, aber vielleicht hat ja sonst noch jemand eine Idee an was es liegen könnte...

Beta-User

Hmm, "eigentlich" ist es ureigenste Idee hinter readingsGroup, jeweils den aktuellsten Readingwert anzuzeigen; irgendwas ist da also schräg.

Würde den Thread mal in den passenden Forenbereich verschieben (oder was neues aufmachen), aber vorher zum einen Absichern, dass da wirklich was aktuelles ist, was anzuzeigen wäre, und zum anderen mal checken, ob nicht der Code der readingsGroup irgendwie verbogen ist. Dazu wäre für kundige Augen aber erst mal ein list von der rG hilfreich ;) .

Grundsätzlich _vermute_ ich aber, dass wir erst noch etwas Aufwand in die Verarbeitung der ein- und ausgehenden Daten an den eigentlichen Devices schauen sollten, speziell bei dem ZWave-Spirit. Bin seit Rudis Änderung aber auch noch nicht dazu gekommen, mich da nochmal intensiver einzudenken und ggf. noch etwas mit den userReadings zu spielen (siehe die Ansätze in dem bereits verlinkten Thread).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Du hast jetzt in "Automatisierung" einen Thread aufgemacht?

"help readingsGroup" liefert bei mir:
ZitatModule: 33_readingsGroup.pm Maintainer: justme1968 Forum: Frontends/readingsGroup readingsHistory
Da in deinem neuen Thread aber steht, dass einzelne Werte automatisch aktualisiert werden, glaube ich nicht, dass es wirklich ein readingsGroup-Thema ist, sondern eher eines, das mit ZWave zusammenhängt.

Du solltest m.E. das ganze irgendwie nochmal neu aufziehen, und dann auch mal schauen, dass ggf. Infos, die direkt kommen auch auswertest und du nicht via get gehen musst. Das betrifft v.a. "desTempSaving" &Co.. Die dahinter stehenden Werte kann man m.E. automatisch in ein userReading packen, wenn man die richtigen trigger setzt, siehe auch meine Beiträge in dem "Spirit Einrichten"-Thread und das betreffende attrTemplate.

Da findet sich folgender Vorschlag:
attr DEVICE userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/; $1?$1:undef}, valve:reportedState.+(dim.[0-9.]+|off) {my $val = ReadingsVal($name,"state",0); return 0 if $val eq "off"; ReadingsNum($name,"state",0)}
Eigentlich glaube ich, dass der auch noch mit dem aktualisierten ZWave-Modul passen sollte...

Der Vorteil ist m.E. der: So passen dann setz-Anweisung und Rückmeldung zusammen, und man muss keine solchen Klimmzüge machen, um das über die readingsGroup gradezuziehen...

(Ach so: soll das ganze jetzt hier auf der Wunschliste bleiben, oder verschiebst du das unter passendem Titel nach ZWave?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files