[PATCH] CC 0x46 CLIMATE_CONTROLE_SCHEDULE

A.Harrenberg · 08 Februar 2016, 11:03:55

Hi Rudi,

hier mal mein Vorschlag für das ccsAllGet.

Das ganze ist unspektakulär als kleine Schleife um ZWave_addToSendStack gebaut, allerdings habe ich das dennoch als GET implementiert! Ich finde das diese Sachen einfach unter GET gehören, das ConfigRequestAll und AccociationRequestAll unter SET zu "finden" sind finde ich persönlich sehr verwirrend.

Um nun das Problem mit ReadAnswerFn zu umgehen habe ich, in Anlehnung einer damaligen Idee von Dir zur Unterdrückung der ganzen Security Get-Befehle, ein %zwave_quietGetCmds eingeführt das in ZWave_CMD dann den Aufruf der ReadAnswerFn verhindern kann.

Das geht natürlich nur so einfach, wenn die Abfragen auch so einfach erzeugt werden können. Komplexere Sachen wie: Abfragen wie wiele user_ID es gibt und dazu dann in einer Schleife entsprechend Informationen abzufragen bleibt auch mit den Hooks noch schwierig.

Frage: Würde dieses Konstrukt die Probleme mit GET umgehen oder übersehe ich da wieder was?

Du siehst, ich hänge am GET...

Gruß,
Andreas.

rudolfkoenig · 08 Februar 2016, 13:37:13

ZitatUm nun das Problem mit ReadAnswerFn zu umgehen habe ich, in Anlehnung einer damaligen Idee von Dir zur Unterdrückung der ganzen Security Get-Befehle, ein %zwave_quietGetCmds eingeführt das in ZWave_CMD dann den Aufruf der ReadAnswerFn verhindern kann.

Das mit dem quiet hast du falsch verstanden. Das alte zwave_quietCmds hat logging statt Level 2 auf 4 geschoben, und keine Readings aktualisiert. Sozusagen alles auf leise.

Deine Version wandelt get in set um: der Benutzer setzt zwar get ab, das Modul wartet aber nicht mehr auf das Ergebnis, das Verhalten ist damit identisch mit einem set. Mit leise hat das nichts zu tun, und ich verstehe den Sinn auch nicht. Ich schlage vor "get ccsAll" in "set ccsRequestAll" umzubenennen, analog zu configRequestAll und associationRequestAll.

A.Harrenberg · 08 Februar 2016, 13:58:38

Hallo Rudi,

Zitat von: rudolfkoenig am 08 Februar 2016, 13:37:13
Das mit dem quiet hast du falsch verstanden. Das alte zwave_quietCmds hat logging statt Level 2 auf 4 geschoben, und keine Readings aktualisiert. Sozusagen alles auf leise.

Deine Version wandelt get in set um: der Benutzer setzt zwar get ab, das Modul wartet aber nicht mehr auf das Ergebnis, das Verhalten ist damit identisch mit einem set.

soweit habe ich das schon verstanden, ich hätte mich beim Namane aber nicht so sehr an das "quiet" anlehnen sollen. Das ist ein "get_do_not_wait_for_answer" und ist auch genauso gedacht.

Zitat von: rudolfkoenig am 08 Februar 2016, 13:37:13
Mit leise hat das nichts zu tun, und ich verstehe den Sinn auch nicht. Ich schlage vor "get ccsAll" in "set ccsRequestAll" umzubenennen, analog zu configRequestAll und associationRequestAll.

Der Sinn? Es war genauso gedacht, ein Befehl als GET abzusetzen aber NICHT auf die Antwort zu warten. Ich finde es SEHR unlogisch diese Befehle unter SET anzusiedeln und wäre eher dafür die configRequestAll und associationRequestAll unter GET einzusortieren...
Aus Benutzersicht ist das nicht nachvollziehbar... Ich frage ein Item ab -> GET, ich will alle abfragen -> SET...

Wie gesagt, das ist meine Meinung dazu, daher war es auch als Vorschlag deklariert.
Wenn Du weiterhin der Meinung bist das soll unter SET, dann verschiebe ich das ich natürlich und passe die Doku an.

Gruß,
Andreas.

rudolfkoenig · 08 Februar 2016, 19:41:29

Zitatwäre eher dafür die configRequestAll und associationRequestAll unter GET einzusortieren...

Nach etwas Nachdenken akzeptiert:
- "set configRequestAll" -> "get configAll"
- "set associationRequestAll" -> "get associationAll"
- falls get nicht direkt aus dem Frontend (telnet/FHEMWEB) aufgerufen wird (!defined($hash->{CL}), dann wartet nicht / verhaelt sich wie ein set, d.h. blockiert auch nicht.
- damit entfaellt auch die Notwendigkeit von zwave_quietCmds und Konstrukten wie "set configX request"
- hab dein Patch uebernommen, und ZWave_ccsAllGet auf get umgebaut. Kannst du es bitte testen?

A.Harrenberg · 08 Februar 2016, 20:01:14

Hi Rudi,

Zitat von: rudolfkoenig am 08 Februar 2016, 19:41:29
Nach etwas Nachdenken akzeptiert:
- "set configRequestAll" -> "get configAll"
- "set associationRequestAll" -> "get associationAll"
- falls get nicht direkt aus dem Frontend (telnet/FHEMWEB) aufgerufen wird (!defined($hash->{CL}), dann wartet nicht / verhaelt sich wie ein set, d.h. blockiert auch nicht.
- damit entfaellt auch die Notwendigkeit von zwave_quietCmds und Konstrukten wie "set configX request"
- hab dein Patch uebernommen, und ZWave_ccsAllGet auf get umgebaut. Kannst du es bitte testen?

Danke! Ich schau mir nachher mal an, testen kann ich aber auch nicht in "echt", ich kann da auch nur die Befehle generieren lassen und schauen was rausgeht, ich habe ja auch kein ZWave-Thermostat.

Gruß,
Andreas.

krikan · 08 Februar 2016, 20:02:02

Zwischenfrage: Spricht etwas dagegen zur Vereinheitlichung auch "versionClassRequest" von set auf get umzustellen?

A.Harrenberg · 08 Februar 2016, 20:18:44

Hi Rudi,

so, hab' mal die neue Version vom SVN geholt, funktioniert einwandfrei. Bei get ccsAll werden brav alle Befehle erzeugt (und an das Danalock) verschickt ,-)
Die Befehle sehen auch in Ordnung aus.

Jetzt schau ich mir mal an was Du da gemacht hast.

Gruß,
Andreas.

rudolfkoenig · 08 Februar 2016, 21:21:19

Ich habe Muell gebaut.

Das Problem ist, dass man an die Geraete nicht was Neues senden darf, wenn die Antwort noch nicht angekommen ist. Wenn get nicht auf die Antwort wartet, und das naechste Befehl aus der Queue vorher rausschickt, dann kommen manche Antworten nie mehr an.
Ich habe das "noblocking" get wieder ausgebaut, das ist mAn der kleinere Uebel, und denke inzwischen nach, wie man das get Problem richtig loest. Ich tendiere zu einer Modifikation der SendStack, damit er weiss, was ein "get" Befehl ist. versionClassRequest Umbau kommt danach.

A.Harrenberg · 08 Februar 2016, 22:23:57

Hi Rudi,

hmm, jetzt wo Du es sagst...

Im Security stack speichere ich mir den ganzen Befehl mit ab, und nicht nur den bereits codierten Befehl. Damit entscheide ich dann ob ich nach einer Nachricht das secEnd aufrufe oder auf eine Antwort warte. Damit "blockiere" ich den Sendstack so lange bis die Antwort da ist oder ein Fehler auftritt. Dabei blieb dann meist das secStart noch aktiv, dafür habe ich ja diesen Timer eingebaut der das dann wenigstens wieder beendet...

Die Steuerung des Sendstacks ist mMn der richtige Weg, allerdings kann da ja so einiges an Sonderfällen auftreten die es dann zu berücksichtigen gibt.

Gruß,
Andreas.

rudolfkoenig · 09 Februar 2016, 21:51:24

Habe ZWave_processSendStack umgebaut: set laeuft wie bisher, get wartet auf eine Nachricht, bevor der naechste Eintrag vom Stack gesendet wird. ZWave_addToSendStack hat ein Parameter mehr (set/get), ZWave_secAddToSendStack ruft sie imer mit set auf (bisheriges Verhalten), evtl. willst Du es noch erweitern. Timeout habe ich von 10s auf 3s verringert.

Habe "set versionClassRequest" auf "get versionClassAll" umgestellt, sie verwendet auch parseHook, und ist kuerzer.
Habe alle 3 getAll Befehle mit einem zwave.me Dongle und mit dem CUL getestet, funktioniert so, wie ich es erwarte.
Habe das nonblocking get fuer "nicht-frontend-gets" aktiviert, das wird auch von den 3 getAll's verwendet.