Danfoss LC-13: ccs Eintrag löschen?

[lada04]

habe versucht, den Ventilen climate-control-Befehle einzuimpfen.
Nachdem meine eigene Befehlskette gescheitert ist (ich vermute, es lag nur an den  positiven Vorzeichen bei den Temperaturdifferenzen), habe ich einfach das Beispiel
http://forum.fhem.de/index.php/topic,32145.msg268359.html#msg268359
probiert, uns es hat funktioniert!
Nun habe ich aber einen Eintrag in der Tabelle, den ich garnicht haben wollte:

Code Auswählen Erweitern

2016-02-05 19:26:58   ccs_sun         06:00 10.0 08:00 -2.0 13:00 4.0 17:00 -3.0 19:00 3.0 22:00 -12.0
Wie kann ich diesen wieder löschen?
Ein set ohne Parameter wird abgelehnt. Könnte einen Platzhalter um 0:00 eine Differenz von 0 eintragen, aber muss doch exakter gehen?

Weiterhin ist mir aufgefallen, dass man den Gang die internen Uhr nur schwer bewerten kann. Nach einem

Code Auswählen Erweitern

get clock
steht der abgerufene Wert in den Readings, ohne dass man weiß, wann der Befehl nun wirklich zum Sensor gelangt ist.

Und zum Schluß noch eine Frage: Ist das ein Problem?

Code Auswählen Erweitern

     2016-02-04 23:39:20   state           TRANSMIT_NO_ACK
Diesen Status habe ich inzwischen bei drei von vier Ventilen, auch bei denen, die in 'Sichtweite' sind...

[A.Harrenberg]

Hi lada04,

Nun habe ich aber einen Eintrag in der Tabelle, den ich garnicht haben wollte:

Code Auswählen Erweitern

2016-02-05 19:26:58   ccs_sun         06:00 10.0 08:00 -2.0 13:00 4.0 17:00 -3.0 19:00 3.0 22:00 -12.0
Wie kann ich diesen wieder löschen?
Ein set ohne Parameter wird abgelehnt. Könnte einen Platzhalter um 0:00 eine Differenz von 0 eintragen, aber muss doch exakter gehen?

theoretisch sollte es gehen wenn Du den SET Befehl mit "sun" ohne weitere Parameter absetzt. Welche (Fehler-)Meldung bekommst Du denn wenn Du das versuchst?

Weiterhin ist mir aufgefallen, dass man den Gang die internen Uhr nur schwer bewerten kann. Nach einem

Code Auswählen Erweitern

get clock
steht der abgerufene Wert in den Readings, ohne dass man weiß, wann der Befehl nun wirklich zum Sensor gelangt ist.

Am Reading steht aber doch dran wann der Wert angekommen ist. Auch wenn das ein WakeUp-Gerät ist, sollte der Zeitstempel der bei den Readings ja auch immer gesetzt wird doch ausreichen um das zu beurteilen. Der Befehl "wartet" ja im Sendstack bis das Gerät sich wieder meldet, wird dann weggeschickt und nahezu sofort vom Gerät beantwortet. Oder verstehe ich Deine Frage hier falsch?

Und zum Schluß noch eine Frage: Ist das ein Problem?

Code Auswählen Erweitern

     2016-02-04 23:39:20   state           TRANSMIT_NO_ACK
Diesen Status habe ich inzwischen bei drei von vier Ventilen, auch bei denen, die in 'Sichtweite' sind...

Kann sein, muss aber nicht...
Die Fehlermeldung kommt mittlerweile leider gehäuft vor, bei mir passiert das weil mein WakeUp-Gerät schneller einschläft als FHEM glaubt und dann schickt FHEM ein "geh schlafen" an das Gerät was nicht mehr beantwortet wird. Ob dies bei Dir der Fall ist kann man nur mit Log (verbose level auf 5, attribut mseclog auf 1) sagen. Man kann die Zeit bis FHEM glaubt das Gerät ist eingeschlafen mit dem Attribut WNMI_delay setzen um das für diesen Fall zu verbessern.

Also am besten mal ein Logfile posten, dann kann man da mal drauf schauen.

Gruß,
Andreas.

[lada04]

Danke für die schnelle Antwort!

theoretisch sollte es gehen wenn Du den SET Befehl mit "sun" ohne weitere Parameter absetzt. Welche (Fehler-)Meldung bekommst Du denn wenn Du das versuchst?

dann bekomm ich diesen Fehler:

Code Auswählen Erweitern

fhem> set Kueche_Danfoss_Wand ccs sun
wrong arg, need: <weekday> HH:MM relTemp HH:MM relTemp ...

Am Reading steht aber doch dran wann der Wert angekommen ist. Auch wenn das ein WakeUp-Gerät ist, sollte der Zeitstempel der bei den Readings ja auch immer gesetzt wird doch ausreichen um das zu beurteilen. Der Befehl "wartet" ja im Sendstack bis das Gerät sich wieder meldet, wird dann weggeschickt und nahezu sofort vom Gerät beantwortet. Oder verstehe ich Deine Frage hier falsch?

Nein, ich glaube, nicht.
Vielleicht liegt es daran, dass ich nicht glauben wollte, dass die Uhr bereits eine Stunde falsch geht?

Code Auswählen Erweitern

     2016-02-05 19:02:28   clock           fri 20:01
Oder läuft die auf UTC 

Das mit dem Schlafen ist mir sowieso nicht ganz klar.
Die Empfehlung war ja, das wakeup-Intervall auf 300s zu stellen. Das habe ich auch gemacht. Allerdings stand der STATE Parameter noch lange
auf '86400 1', bis dann irgendwann NO_ACK auftauchte. Mir war anfangs überhaupt nicht klar, wann das Ventil überhaupt Befehle aus dem fhem-stack entgegennimmt, wenn das wakeup-intervall noch auf dem default steht - erst nach einem Tag?
Auf Temperaturänderungen hat es aber innerhalb weniger Minuten reagiert...

Gut, mache das log erstmal gesprächiger.

[A.Harrenberg]

Hi lada02,

dann bekomm ich diesen Fehler:

Code Auswählen Erweitern

fhem> set Kueche_Danfoss_Wand ccs sun
wrong arg, need: <weekday> HH:MM relTemp HH:MM relTemp ...

ok, ich schau noch mal in den Code, auf den ersten Blick sah es für mich so aus als ob das möglich sein sollte.

Nein, ich glaube, nicht.
Vielleicht liegt es daran, dass ich nicht glauben wollte, dass die Uhr bereits eine Stunde falsch geht?

Code Auswählen Erweitern

     2016-02-05 19:02:28   clock           fri 20:01
Oder läuft die auf UTC 

Beides kann stimmen... Diese internen Uhren sind meist nicht so besonders, und viele ZWave Geräte laufen intern auf UTC und man kann/muss da teilweise den Offset zu UTC angeben.
Diese Befehlsklasse hat jetzt da selbst keine solche Einstellung, Du könntest mal ein "list" von dem Device machen, dann wäre klar welche Klassen das Thermostat sonst noch so unterstützt.

Das mit dem Schlafen ist mir sowieso nicht ganz klar.
Die Empfehlung war ja, das wakeup-Intervall auf 300s zu stellen. Das habe ich auch gemacht. Allerdings stand der STATE Parameter noch lange
auf '86400 1', bis dann irgendwann NO_ACK auftauchte. Mir war anfangs überhaupt nicht klar, wann das Ventil überhaupt Befehle aus dem fhem-stack entgegennimmt, wenn das wakeup-intervall noch auf dem default steht - erst nach einem Tag?
Auf Temperaturänderungen hat es aber innerhalb weniger Minuten reagiert...

Also das ist mit den WakeUp-Zeiten ist ein zweischneidiges Schwert. Du kannst natürlich Änderungen nur nach dem WakeUp übertragen, und man möchte dafür natürlich möglichst kurze Intervalle, andererseits erhöht das den Stromverbrauch nicht unerheblich. Man sollte sich gut überlegen welche Intervalle man hier WIRKLICH benötigt. So eine Heizung ist recht träge, daher kann man hier sicherlich auch 15 minuten vertreten. Weiter muss man sich überlegen ob man bei JEDEM WakeUp auch Daten abfragen möchte. Wenn das Ding nur aufwacht und wieder einschlafen darf ohne was zu senden ist das sicherlich auch günstiger als wenn man da jedesmal alle Daten abfragt die möglich sind.

Wenn Du nach dem Ändern des WakeUp-Intervalls keinen manuellen WakeUp ausgelöst hast wird der Befehl natürlich erst beim nächsten regulären WakeUp gesendet.

Gruß,
Andreas.

[A.Harrenberg]

Hi lada04,

ok, ich schau noch mal in den Code, auf den ersten Blick sah es für mich so aus als ob das möglich sein sollte.

habe gerade noch mal nachgeschaut, der original Code verlangt an der Stelle mindestens drei Parameter.

Falls Du mit einem Editor umgehen kannst könntest Du mal versuchen das auf 1 zu setzen, der Rest des Codes "müsste" dann auch noch funktionieren. Ich hab' das mal gemacht und der Befehle der dann verschickt wird sieht i.O. aus. Da ich kein ZWave-Thermostat habe ist das natürlich nicht wirklich getestet...

Du müsstest in der Datei FHEM/10_ZWave.pm die Funktion ZWave_ccsSet finden und in der Zeile mit

Code Auswählen Erweitern


  return ($usage,"") if(@arg < 3 || int(@arg) > 19 || (int(@arg)-1)%2 != 0);
die Abfrage auf mindestens 3 argumente auf mindestens 1 argument ändern:

Code Auswählen Erweitern


  return ($usage,"") if(@arg < 1 || int(@arg) > 19 || (int(@arg)-1)%2 != 0);

Wenn man dann nur den Wochentag als Parameter übergibt werden alle 9 möglichen Schaltpunkte als unused markiert.

Wenn das bei Dir funktioniert, dann können wir das Rudi als offizielle Änderung vorschlagen.

Gruß,
Andreas.

[lada04]

Habe die Stelle gefunden und auch gelernt, dass man das Modul anschließend mit  reload 10_ZWave neu laden muss.
Es scheint zu klappen, ein get Kueche_Danfoss_Wand ccs sun ergibt nun

Code Auswählen Erweitern

     2016-02-06 10:35:48   ccs_sun         N/A
Der Eintrag ist also gelöscht, sehr schön.

Zur clock: Habe die Uhr neu gestellt, ein unmittelbares get zeigt Übereinstimmung:

Code Auswählen Erweitern

     2016-02-06 10:30:54   clock           sat 10:30
Werde das weiter beobachten, aber wenn die Uhr innerhalb weniger Tage um Stunden davonläuft, ist  CCS nur brauchbar, wenn  man die Uhr regelmässig stellt.

Mir ist nicht klar, was besser ist: Die Temperatureinstellungen mit CCS am Ventil zu programmieren oder einen schedule mit fhem zu erstellen (mit at wahrscheinlich?).

Zur Abfrage mit get ccs: Wäre es nicht elegant, wenn beim Fehlen des Parameters für den  Wochentages automatisch alle Wochentage abgefragt würden? Mein Eindruck ist aber, dass ZWave_ccsGet($) den Befehl nur für einen einzelnen konkreten Wochentag zurückgeben muss, oder könnte man die sprintf("02%02x", $i) verketten, z.B. mit einer Schleife über  1..$#zwave_wd?

Zum Aufwachen habe ich noch eine Frage.
Der Batteriestand soll alle 30 Minuten mit get battery abgefragt werden, damit sich die Batterien nicht schnell entleeren.
Es müsste doch dann ausreichen, das wakeup-Intervall ebenfalls auf 30 Minuten zu stellen, es sei denn es sollen noch andere Befehle in kürzeren Intervallen verarbeitet werden. Temperaturänderungen könnte man dann mit beliebigen Intervallen über CCS vornehmen, zusammen mit einer täglichen Uhrkorrektur. Das müsste doch weiter Energie sparen. Die Batterien haben nämlich im Laufe von 14 Tagen schon fast 20% verloren, das würde bedeuten, in 8 Wochen wären sie alle...

Ach, und dann nochetwas: Benutze inzwsichen telnet aus einer console. Leider gibt es keine command-history. Liegt das an meinen telnet-Einstellungen oder unterstützt der fhem-server das nicht?

Viele Grüße, Hartmut

[A.Harrenberg]

Hallo Hartmut,

Habe die Stelle gefunden und auch gelernt, dass man das Modul anschließend mit  reload 10_ZWave neu laden muss.
Es scheint zu klappen, ein get Kueche_Danfoss_Wand ccs sun ergibt nun

Code Auswählen Erweitern

     2016-02-06 10:35:48   ccs_sun         N/A
Der Eintrag ist also gelöscht, sehr schön.

oh, sorry, hatte vergessen den Neustart bzw. das Reload zu erwähnen...
Dann können wir das Rudi ja als Änderung vorschlagen, ist ja durchaus ein realer Einsatzfall...

Zur clock: Habe die Uhr neu gestellt, ein unmittelbares get zeigt Übereinstimmung:

Code Auswählen Erweitern

     2016-02-06 10:30:54   clock           sat 10:30
Werde das weiter beobachten, aber wenn die Uhr innerhalb weniger Tage um Stunden davonläuft, ist  CCS nur brauchbar, wenn  man die Uhr regelmässig stellt.

Hmm, mir fällt gerade auf das man da einfach per "at" ein mal am Tag ein set clock auslösen darf, da dies dann natürlich mit der gerade aktuellen Uhrzeit im WakeUp-Stack landet, aber später losgeschickt wird, wodurch dann die Uhrzeit natürlich nicht stimmt. D.h. Du müsstest da per Notify auf das WakeUp reagieren, aber nur einmal am Tag die Uhr stellen.

Mir ist nicht klar, was besser ist: Die Temperatureinstellungen mit CCS am Ventil zu programmieren oder einen schedule mit fhem zu erstellen (mit at wahrscheinlich?).

Das ist ein wenig Geschmackssache, ich versuche aber die Geräte so viel wie möglich "selber" machen zu lassen. D.h. meine (Homematic-) Thermostate haben ein Wochenprogramm eingestellt das sie auch ohne FHEM "abfahren", das hat schon mal Vorteile wenn FHEM mal nicht will...
Ich nutze FHEM dann nur um z.B. per Tastendruck alle Soll-Temperaturen auf "Normaltemperatur" zu setzen wenn man ausserhalb der normalen Heizzeiten anwesend ist, oder auch alles auf "Absenktemperatur" zu stellen wenn man mal früher zu Bett geht.

Zur Abfrage mit get ccs: Wäre es nicht elegant, wenn beim Fehlen des Parameters für den  Wochentages automatisch alle Wochentage abgefragt würden? Mein Eindruck ist aber, dass ZWave_ccsGet($) den Befehl nur für einen einzelnen konkreten Wochentag zurückgeben muss, oder könnte man die sprintf("02%02x", $i) verketten, z.B. mit einer Schleife über  1..$#zwave_wd?

Also der entsprechende Befehl an das Gerät liefert nur die Daten für EINEN Tag, den muss man also auch spezifieren. Die Idee ist natürlich naheliegend da eine "Schleife drum zu machen"...
Die Readings ja bereits für jeden Tag getrennt angelegt, das ist schon mal gut. Wie/ob man die Befehle dann in der Schleife aufruft muss man mal schauen. Ich bin mir nicht ganz sicher ob man an der Stelle dann direkt in den Stack schreiben sollte/darf...

Ich schau mir das noch mal an und mache Rudi mal einen Vorschlag.

Zum Aufwachen habe ich noch eine Frage.
Der Batteriestand soll alle 30 Minuten mit get battery abgefragt werden, damit sich die Batterien nicht schnell entleeren.

Äh, DAMIT sich die Batterien nicht so schnell entleeren sollte so wenig wie möglich abgefragt werden. Erwartest Du das die Batterie innerhalb von 30 Minuten aufgiebt? Ich würde da maximal 1x täglich abfragen. Du kannst aber auch mal in die Anleitung schauen, evtl. gibt es eine Schwelle unterhalb der das Thermostat dann selbstständig die Batteriemeldung verschickt. (Die Anleitungen von Danfoss sind aber im Allgemeinen eine Frechheit und enthalten nichts...)

Es müsste doch dann ausreichen, das wakeup-Intervall ebenfalls auf 30 Minuten zu stellen, es sei denn es sollen noch andere Befehle in kürzeren Intervallen verarbeitet werden. Temperaturänderungen könnte man dann mit beliebigen Intervallen über CCS vornehmen, zusammen mit einer täglichen Uhrkorrektur. Das müsste doch weiter Energie sparen. Die Batterien haben nämlich im Laufe von 14 Tagen schon fast 20% verloren, das würde bedeuten, in 8 Wochen wären sie alle...

Wie gesagt, so wenig "Traffic" wie möglich...

Ach, und dann nochetwas: Benutze inzwsichen telnet aus einer console. Leider gibt es keine command-history. Liegt das an meinen telnet-Einstellungen oder unterstützt der fhem-server das nicht?

Dafür habe ich auch keine Lösung. Es gab mal irgendwo eine Anleitung wie man das hinbekommen kann. Dazu war dann unter Linux ein zusätzliches Paket nötig das zumindest bei mir nie lief und im ChangeLog stand auch was davon das diese Funktion nicht mehr unterstützt wird. Daher habe ich das mit dem Telnet sein lassen...

Gruß,
Andreas.

[lada04]

Äh, DAMIT sich die Batterien nicht so schnell entleeren sollte so wenig wie möglich abgefragt werden. Erwartest Du das die Batterie innerhalb von 30 Minuten aufgiebt? Ich würde da maximal 1x täglich abfragen. Du kannst aber auch mal in die Anleitung schauen, evtl. gibt es eine Schwelle unterhalb der das Thermostat dann selbstständig die Batteriemeldung verschickt.

Naja, einleuchtend erschien mir das auch nicht, und ich will ja keine Entladekurve messen. Es steht halt in der wiki:
http://www.fhemwiki.de/wiki/Z-Wave#DAN_LC-13_Heizungsthermostat_LC-13_.28014G0013.29
Es dient wohl dazu, das Thermostat kommunikationsbereit zu halten und den Fehler E5 zu vermeiden, der dann zur wiederum zur kurzfristigen Entleerung der Batterien führt.

Werde das Intervall mal hochsetzen und beobachten, was dann passiert.

Das mit der Uhr ist mir nun auch klar, die übermittelte Uhrzeit stammt vom Zeitpunkt des Absenden des Befehls und nicht vom Zeitpunkt der Übertragung.

Danke noch für die übrigen Einschätzungen, werde mit CCS weiter experimentieren!

Viele Grüße,
Hartmut

[A.Harrenberg]

Hi Hartmut,

Naja, einleuchtend erschien mir das auch nicht, und ich will ja keine Entladekurve messen. Es steht halt in der wiki:
http://www.fhemwiki.de/wiki/Z-Wave#DAN_LC-13_Heizungsthermostat_LC-13_.28014G0013.29
Es dient wohl dazu, das Thermostat kommunikationsbereit zu halten und den Fehler E5 zu vermeiden, der dann zur wiederum zur kurzfristigen Entleerung der Batterien führt.

ah, ok, noch so eine Merkwürdigkeit. Ich würde mal damit anfangen das Ding "in Ruhe" zu lassen und schauen ob der E5 Fehler dann auch bei Dir eintritt. (vielleicht nicht gerade am Wohnzimmerthermostat ausprobieren sondern vielleicht eher Gästetoilette...).

Das mit der Uhr ist mir nun auch klar, die übermittelte Uhrzeit stammt vom Zeitpunkt des Absenden des Befehls und nicht vom Zeitpunkt der Übertragung.

Danke noch für die übrigen Einschätzungen, werde mit CCS weiter experimentieren!

Kein Problem, weitere Fragen etc. dann am besten im ZWave-Forum stellen.

Gruß,
Andreas.