[PATCH] CC 0x4e SCHEDULE_ENTRY_LOCK, CC 0x43 THERMOSTAT_SETPOINT

[A.Harrenberg]

Hi Rudi,

anbei ein etwas größerer Patch mit einer neuen CC 0x4e SCHEDULE_ENTRY_LOCK und der Erweiterung für die 0x43 THERMOSTAT_SETPOINT (siehe hier).
Bei 0x43 fehlt noch ein GET/REPORT für einen neuen V3-Befehl, das kann ich aber nicht offline implementieren, dazu brauche ich noch mal jemand der ein Thermostat mit einer V3 hat und das dann testet. Ansonsten habe ich mich um "Rückwärtskompatibliität" bemüht. Die beiden "alten" SET Befehle habe ich drin gelassen, der bisherige GET Befehle akzeptiert jetzt den benötigten Type als Parameter, kann aber auch noch ohne aufgerufen und hat dann type 1=heating als Voreinstellung. Event / Reading für das Get ist auch "gleich" geblieben, allerdings sind jetzt mehr types bekannt und werden gemeldet.

Des weiteren sind da noch zwei Kleinigkeiten mit drin vesteckt:
a.) Eine Erweiterung bei get model damit auch das Danalock mit seiner zu langen Antwort erkannt werden kann
b.) Eine kleine Änderung für CCS die es ermöglicht die Schedule für einen Tag zu löschen indem man keine weiteren Argumente übergibt. Siehe diesen Thread.

Doku ist bis auf b.) angepasst.

Gruß,
Andreas.

P.S.: Wegen der ccs gab es noch die Idee eine Abfrage für alle Tage zu machen. Ist es da sinnvoller in einer Schleife ZWave_Get aufzurufen oder einfacher direkt die Befehle per ZWave_addToSendStack abzuschicken. Ich würde dafür den Weg über ZWave_addToSendStack nehmen bin aber nicht sicher ob ich dabei was übersehe...

[rudolfkoenig]

Habs eingecheckt, das Modul ist 15% gewachsen.

Wegen der ccs gab es noch die Idee eine Abfrage für alle Tage zu machen

Eigentlich muessten wir diese Befehle als set absetzen. Wenn ich mal seelisch soweit bin, werde ich get umbauen, dann wird get nicht mehr blockieren. Solange waere mir ZWave_addToSendStack lieber.

[A.Harrenberg]

Hi Rudi,

Habs eingecheckt, das Modul ist 15% gewachsen.

danke, und ich bekenne mich schuldig... Ich schreibe keinen soo kompakten Code, ich will das auch am nächsten Tag noch verstehen ,-)
Die letzten Funktionen die ich gemacht habe sind aber auch einfach umfangreich.

Ich habe gerade mal nachgeschaut, FHEM5.6 (9.11.2014) -> 10_ZWave.pm 53.1 kB, aktueller Stand 168.5 kB. Aber gegen EnOcean (667 kB) oder CUL_HM (493 kB) kommen wir (noch) nicht an...

Eigentlich muessten wir diese Befehle als set absetzen. Wenn ich mal seelisch soweit bin, werde ich get umbauen, dann wird get nicht mehr blockieren. Solange waere mir ZWave_addToSendStack lieber.

Ich finde das diese "Multicommands", ebenso wie das ConfigRequestAll und AssociationRequestAll keine Antwort brauchen. Diese Befehle dienen doch "nur" dazu die Readings zu füllen, von daher finde ich das auch die richtige Lösung das per SendStack zu machen.

Dann werde ich mal schauen ob ich die Größe des Moduls noch etwas weiter nach oben treiben kann ,-)

Gruß,
Andreas.