Neues Modul - Heating_Control, WeekdayTimer

[Dietmar63]

%TIME wird von delayedExecutionCond nicht unterstützt.
Was soll deiner Meinung nach darin jeweils von HC zur Verfügung gestellt werden?

War wohl noch nie so. In  der Doku ist %TIME allerdings erwähnt.

[Dietmar63]

habe es mal ergänzt - %TIME oder $TIME liefert die definierte Wunschzeit - wahrscheinlich im Format: 23:45:00 - probier es mal aus.

[m8ichael]

Hallo Dietmar,

ja, ich bin bisher davon ausgegangen, dass da die Schaltzeit abgelegt wird.

Kann ich die Ergänzung schon mal irgendwie testen?

Viele Grüße

Michael

[Dietmar63]

nach einem update steht die Änderung zur Verfügung

[m8ichael]

OK, jetzt mal getestet.  Nun enthält die Variable eine Ziffer (aktuelle "2"). Bedeutet dies, dass die zweite Zeitscheibe aktiv ist? Und was muss ich in meinem Fall abfragen, um eine Verzögerung vor Eintritt in die dritte Zeitscheibe zu erreichen?

Beispiel:

Code Auswählen Erweitern


... Mo-So|10:00|20 Mo-So|18:00|22 Mo-So|20:00|17 ...


Wenn ich nun erreichen wollte, dass die Einstellung ab 20:00 Uhr verzögert wird, würde die Variable $time dann um 20:00 Uhr den Wert "3" erhalten und ich müsste dies in meine Abfrage einbauen?

Viele Grüße

Michael

[m8ichael]

Hallo,

ich habe nun mal ein wenig getestet. Es scheint, als würde unter $Time wirklich die "Nummer" des Timers abgelegt. Besteht hier Hoffnung, dass man auch die Uhrzeit ausgeben kann? Denn die Timernummer ist wenig praktikabel, wenn man bestimmte Abhängigkeiten hat und man im Zweifel noch einen Timer einfügen muss.

Und dann habe ich noch eine Frage: Wie lange wird der Schaltvorgang maximal verzögert, wenn die Bedingung im Attribut "delayedExecutionCond" wahr ist? Ich hatte jetzt die Situation, dass nach einer Verzögerung von >2,5 Stunden kein Schaltvorgang mehr ausgeführt wird.

Viele Grüße

Michael

[Dietmar63]

ich habe nun mal ein wenig getestet. Es scheint, als würde unter $Time wirklich die "Nummer" des Timers abgelegt. Besteht hier Hoffnung, dass man auch die Uhrzeit ausgeben kann? Denn die Timernummer ist wenig praktikabel, wenn man bestimmte Abhängigkeiten hat und man im Zweifel noch einen Timer einfügen muss.

hast recht - ändere ich

Und dann habe ich noch eine Frage: Wie lange wird der Schaltvorgang maximal verzögert, wenn die Bedingung im Attribut "delayedExecutionCond" wahr ist? Ich hatte jetzt die Situation, dass nach einer Verzögerung von >2,5 Stunden kein Schaltvorgang mehr ausgeführt wird.

An sich sollte das fast bis in alle Ewigkeit so weitergehen. Allerdings könnte man der Meinung sein, dass ein nachfolgender Timer den alten überschreiben sollte. Nur leider haben verschiedene Versuche das zu implementieren nicht gefruchtet, bzw. sind schief gegangen.
Es kann kompliziert werden, zu definieren was aufeinanderfolgende timer sind.

Ein Grenze ist auf jeden Fall Mitternacht. Dann werden die timer des neuen Tages gesetzt und laufende gelöscht.

Wieso bei dir nach 2,5 Stunden Schluss war, vermag ich nicht zu sagen.
Vielleicht kannst du ja eine Lücke in WeekdayTimer_FensterOffen() finden.

[m8ichael]

Hi,

habe jetzt mal ausgiebig getestet... Funktioniert mittlerweile prima und auch die Zeiten werden sauber übergeben. Einzig beim Tagwechsel kommt es dann zu Problemen, wenn die Verzögerung gerade aktiv ist. Fällt dann die Verzögerung (am Folgetag) weg, so wird dies auch entsprechend protokolliert, der state des moduls verbleibt aber trotzdem beim alten Wert und ändert sich nicht.

Viele Grüße

Michael

Gesendet von meinem SM-G900F mit Tapatalk

[cornelius fillmore]

Moin zusammen,

kann es sein, das an dem Modul etwas verändert wurde.

Seit dem letzten update kommen keine Befehle mehr an meinen FHTs an.

Manuele Kommunikation mit den FHT funktioniert aber.

Mich wundert auch folgende Zeile im log

Code Auswählen Erweitern

2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:measured-temp (not A-Za-z/\d_\.-), notify the FHT module maintainer.
2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:start-xmit (not A-Za-z/\d_\.-), notify the FHT module maintainer.
2016.01.23 10:48:41 3: WARNING: unsupported character in reading FHZ:warnings (not A-Za-z/\d_\.-), notify the FHT module maintainer.

Sind jetzt "_" nicht mehr erlaubt?

[m8ichael]

Sind jetzt "_" nicht mehr erlaubt?

Hmm, die Unterstriche werden in der Fehlermeldung allerdings nicht bemängelt...

[cornelius fillmore]

Thema gelöst:

update force gemacht und alles läuft wieder

[tomspatz]

Hallo Dietmar

auch ich nutze dein Modul (FETTES THX für deine Arbeit), allerdings mit z-wave Komponenten.
Kriegst du denn auch ein z-wave Fenstersensor dran?

Grüße Tom

[m8ichael]

Hallo Dietmar

auch ich nutze dein Modul (FETTES THX für deine Arbeit), allerdings mit z-wave Komponenten.
Kriegst du denn auch ein z-wave Fenstersensor dran?

Grüße Tom

Hi,

bei der Nutzung des Moduls sollte es ziemlich egal sein, welches System genutzt wird. Im Zweifel muss eine kleine Funktion erstellt werden, die den isDelayed-Wert triggert (siehe Doku).

Gruß

Michael

[tomspatz]

hmmmm

im Log finde ich aber:

2016.01.27 06:30:00 3: [HeizungssteuerungBad] TYPE 'ZWave' of FensterBad not yet supported, FensterBad ignored - inform maintainer

[Dietmar63]

Erstellt bitte ein list des Zwave Fensterkontakten, dann kann prüfen, wie ich HC erweitere. Schaffe es aber frühestens am Sonntag - Urlaub