Danfoss/devolo Thermostat MT2650 u. Danfoss RS Room Sensor

[Ralf]

Hallo,
ich bin relativ neu bei FHEM, aber voll und ganz bei der Sache und habe bisher meine ganzen Probleme mit Hilfe des Forums und des Wikis selbst lösen können, aber jetzt komme ich nicht mehr weiter und hoffe mit Eurer Unterstützung eine Lösung zu finden.

Ausgangssituation:
Ich betreibe ein Danfoss devolo Thermostat MT2650, das annähernd Baugleich zum LC-13 von Danfoss ist. Das Teil läuft ohne Probleme.
Zusätzlich kommt noch der Danfoss RS zu Einsatz, eine Art Wandthermometer, das auch ohne Probleme läuft und mit dem die Temperatur eingestellt wird, die dann per notify an das Thermostat übertragen und dort per "setpointHeating" gesetzt wird.

Läuft eigentlich alles bestens und jetzt kommt das eigentliche Problem:
Das Thermostat am Heizkörper ist teilweise verbaut, was sich auch bautechnisch nicht anders regeln lässt. Das führt am Thermostat zu einem massiven Hitzestau, wodurch die Temperatur total verfälscht wird und da das MT2650 ja direkt am Thermostat misst, regelt dieses sofort zurück.

Ich suche jetzt nach einer Möglichkeit die Temperaturmessung am Thermostat zu deaktivieren oder zu manipulieren und die Steuerung nur über den Room Sensor laufen zu lassen.

Sollte mir da jemand helfen können, wäre ich sehr dankbar. 

Internals:
   DEF        c1662ed1 27
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     6015
   NAME       Thermostat_Kueche
   NR         85
   STATE      IST: 32.73 C | SOLL: 22.00 C heating
   TYPE       ZWave
   ZWAVE1_MSGCNT 6015
   ZWAVE1_RAWMSG 0004001b028407
   ZWAVE1_TIME 2016-10-07 17:04:01
   ZWaveSubDevice no
   homeId     c1662ed1
   isWakeUp   1
   lastMsgSent 1475852643.87747
   nodeIdHex  1b
   Readings:
     2016-10-07 12:17:12   SEND_DATA       failed:00
     2016-10-06 18:47:40   UNPARSED        BATTERY 03800145
     2016-10-07 17:04:00   battery         69 %
     2016-10-05 16:32:23   ccsChanged      00
     2016-10-07 17:04:01   ccsOverride     no, unused
     2016-10-05 16:37:16   ccs_fri         N/A
     2016-10-05 16:37:15   ccs_mon         N/A
     2016-10-05 16:37:16   ccs_sat         N/A
     2016-10-05 16:37:17   ccs_sun         N/A
     2016-10-05 16:37:16   ccs_thu         N/A
     2016-10-05 16:37:16   ccs_tue         N/A
     2016-10-05 16:37:16   ccs_wed         N/A
     2016-10-04 12:21:30   model           Danfoss devolo Thermostat MT2650
     2016-10-04 12:21:30   modelConfig     danfoss/z.xml
     2016-10-04 12:21:30   modelId         0002-0005-0175
     2016-10-07 17:04:01   setpointTemp    22.00 C heating
     2016-10-07 09:27:00   state           setpointHeating 26
     2016-10-07 17:04:01   temperature     32.73 C
     2016-08-14 11:20:05   thermostatSetpointSupported heating
     2016-10-07 17:04:03   timeToAck       0.054
     2016-10-07 17:04:03   transmit        OK
     2016-10-07 17:04:01   wakeup          notification
     2016-08-16 20:41:58   wakeupIntervalCapabilitiesReport min 60 max 1800 default 300 step 60
     2016-08-23 23:11:10   wakeupReport    interval 300 target 1
   SendStack:
     set:131b054301010116258f
     set:131b0543010101162590
     set:131b0543010101162591
     set:131b0543010101162592
Attributes:
   IODev      ZWAVE1
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION SENSOR_MULTILEVEL THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   group      Küche
   room       Küche,ZWave
   stateFormat IST: temperature | SOLL: setpointTemp
   vclasses   BATTERY:1 CLIMATE_CONTROL_SCHEDULE:1 CLOCK:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 PROTECTION:2 SENSOR_MULTILEVEL:6 THERMOSTAT_SETPOINT:2 VERSION:1 WAKE_UP:2

[A.Harrenberg]

Hi Ralf,

ich denke das dürfte nicht so einfach gehen... Ich kenne die Befehle der Klasse jetzt aber auch nicht mehr so genau, obwohl ich da einige von implementiert habe...

Soweit ich mich erinnere kann man da keinen Offset aufprägen. Die Temperatur am Thermostat kannst Du aber auch auslesen, oder?

Die einzige Idee die ich jetzt hätte wäre anhand der Termpeaturdifferenz Solltemperatur-Raumtemperatur den Setpoint des Thermostaten (in Abhängigkeit seiner eigener Temperatur zu ändern).

Also Zimmer 2°C zu kalt -> Solltemperatur 2°C höher setzen als der Termostat meldet und so weiter. Das dürfte allerdings die Batterie von dem Ding in einer ziemlichen kurzen Zeit leernuckeln, da Du für eine halbwegs vernünftige Regelung da wahrscheinlich mind. alle 15 Minuten den Setpoint neu setzen musst.

Wirklich schön wird das sicherlich nicht gehen.

Gruß,
Andreas.

[Ralf]

Hi Andreas,

die Batterien sind nicht das Problem, da ich das Thermostat schon so modifiziert habe, dass ich ganz schnell und einfach ein neues "Batterie-Pack" anstecken kann.
Das Problem ist der "Wärmestau", der extrem ist.

Wenn Du Dir meine geposteten Werte anschaust, siehst Du "setpointTemp  =  22.00 C heating", das ist die gesetzte "Soll-Temperatur" von Room-Sensor.
Die "temperature =  32.73 C" ist die gemessene Temperatur am Thermostat, das Thermometer im Rooms-Sensor , also die gemesse Raumtemperatur zeigte zur gleichen Zeit 19,1  C an.

Das bedeutet:
Der Room-Sensor war auf 22.00 C Soll eingestellt, übermittelt die Daten an das Thermostat am Heizkörper das innerhalb 2 Min. auf über 32 C steigt und deshalb sofort wieder abregelt. Wegen der kurzen Zeit schafft es der Heizkörper aber nicht den Raum zu erwären.

Aufgrund der extremen Erwärmung dauert es auch ziemlich lange bis das Heizkörperthermostat wieder unter 22.00 C fällt, so dass der Heinzkörper dann schon wieder total kalt ist, bist das Thermostat endlich wieder auf macht und das Spiel wieder von vorne beginnt.

Derzeit erreiche ich bei eingestellter maximaler Solltemperatur von 28.00 C gerade einmal 20.00 C Raumtemperatur.
 

[A.Harrenberg]

Hi Ralf,

Das Problem ist der "Wärmestau", der extrem ist.

Wenn Du Dir meine geposteten Werte anschaust, siehst Du "setpointTemp  =  22.00 C heating", das ist die gesetzte "Soll-Temperatur" von Room-Sensor.
Die "temperature =  32.73 C" ist die gemessene Temperatur am Thermostat, das Thermometer im Rooms-Sensor , also die gemesse Raumtemperatur zeigte zur gleichen Zeit 19,1  C an.

das ist in der Tat extrem...

Derzeit erreiche ich bei eingestellter maximaler Solltemperatur von 28.00 C gerade einmal 20.00 C Raumtemperatur.

Und das kleine Detail hier verhindert auch das Du die dynamisch den Setpoint verschiebst wie von mir vorgeschlagen, da es eine Maximaltemperature von 28°C gibt und Du in Deinem Beispiel fast 36°C als Setpoint setzen müsstest um ein ähnliches Heizverhalten zu erhalten.

So leid es mir tut, aber mir sind da keine weiteren Befehle oder Möglichkeiten in der Thermostatklasse bekannt da eine andere Temperatur als Regelgröße "einzuspeisen". Da wird dann nur noch eine Hardwaremodifikation helfen, entweder Lüftung verbessern oder das Ding zerlegen und den Temperaturfühler suchen und "in den Raum" verlängern.

Ob sich das allerdings lohnt weiß ich nicht.

Ich persönlich nutze Thermostate von HomeMatic zusammen mit Wandthermostaten. Hier findet (mMn) die Regelung auf den Sensorwert des Wandthermostat statt, so wie es für Dich ideal wäre. Vielleicht kommt ja für Dich auch ein neues System in Frage.

Gruß,
Andreas.

[Ralf]

Hi,

ok, danke für alle bisherigen Infos... aber so schnell gebe ich noch nicht auf , denn der "RS Room Sensor" ist ja eigentlich genau für meine Problematik gemacht, was der Info-Text von Danfoss zum Room Sensor zeigt:

Auszug:
Wenn das Thermostat Einflüssen durch nahegelegene Wärme- oder Kältequellen (z. B. einen Kamin, direkte Sonneneinstrahlung oder Durchzug)
ausgesetzt ist, kann das System durch einen Raumfühler des Typs Danfoss Link™ RS erweitert werden. Der RS-Fühler sollte in einem Abstand
zwischen einem und fünf Metern vom Thermostaten entfernt positioniert werden. Auf Grundlage der von dem Fühler gemessenen Temperatur wird
dann die Raumtemperatur geregelt.

Darum hab ich das Teil ja gekauft... vielleicht sollte ich mal Danfoss nerven, aber mann/frau kennt das ja, was da meist als Info kommt 

Ich bleib dran und halte Euch auf dem Laufenden...

[A.Harrenberg]

Hi,

kannst Du mal die Anleitungen zu den Teilen irgendwie posten? Ich finde im Netz da nur so "bla bla" Teile ohne richtige Details...

Ich schau mir nachher noch mal die Befehlsklasse an ob die soetwas überhaupt unterstützt, erinnern kann ich mich an so eine Möglichkeit da allerdings nicht.

Wenn das was von Danfoss Link (tm) dran steht würde mich auch nicht wundern wenn die etwas implementiert hätten was NICHT Standard und wozu uns dann natürlich die Befehle fehlen...

Gruß,
Andreas.

[A.Harrenberg]

Hi Ralf,

ich habe jetzt doch noch mal direkt in die Spezifikation reingeschaut. Mir fällt da nichts auf wie man sowas über die Befehlsklasse (THERMOSTAT_SETPOINT) machen könnte.

Ich könnte mir nur vorstellen, das wenn das Thermostat einen Temperaturreport bekommt das es diesen dann als Ist-Temperatur verwendet. Solche Notifications kann FHEM aber nicht erzeugen/versenden.

Um das mal grundlegend zu testen wäre es vielleicht möglich so vorzugehen:

In dem Raumfühler eine Assoziation (von der Gruppe die auch die Ist-Temperatur enthält) an das Thermostat eintragen, falls das konfigurierbar ist würde ich die Zeit zwischen den Reports auf das Minimum setzen. Das Ding sendet dann aber an ein "schlafendes Wake-Up" Device... D.h. Du müsstest über die entsprechenden Tastendrücke versuchen das Ding "wach zu halten", d.h. immer wieder manuell ein Wake-Up auslösen.

Falls das Wirkung zeigt wäre es möglich das man einen speziellen Befehl in FHEM erzeugt, der einen Temperatur-Report (mit der Temperatur des Raumfühlers) erzeugt und den an das Thermostat abschickt. Diesen Befehl müssten man dann in ein NOTIFY auf das Wake-Up von dem Thermostaten legen, damit immer wenn er aufwacht er was geschickt bekommt.

Ich halte es aber für recht unwahrscheinlich das das Thermostat auf eine gesendete Temperatur reagiert...

Aber vielleicht sagen ja Deine Anleitungen oder der Danfoss Support da noch mehr zu dem Thema.

Gruß,
Andreas.

[rudolfkoenig]

Wenn die Werbung einigermassen stimmt, dann gehe ich davon aus, dass bei der Anleitung des Raumfühlers beschrieben ist, wie man ihn mit der Heizungsregelung paart, sowas muss ohne FHEM oder andere HA-Software funktionieren, hoechstens fuer die Einrichtung muss ein HA-Software her.

Auf einem anderen Blatt steht, dass man das von FHEM auch gerne ohne einen Raumfühler steuern moechte.
Das ist aber Schritt zwei.

[Ralf]

Hi,

ok, hier mal kurz was ich bisher rausgefunden habe und was ich derzeit versuche.
1. Man muss grundsätzlich unterscheiden zwischen danfoss und danfoss/devolo.
2. Danfoss übernimmt keinerlei support für die devolo-Geräte obwohl dort auch danfoss drauf steht, da devolo laut danfoss die firmware modifiziert hat.
3. Nur bei meiner devolo-Anleitung befinden sich nähere Infos zu Z-Wave, hier der Link https://www.myplanets.de/infos/Full_Manual_Home_Control_Raumthermostat_0916_de_online.pdf
4. Eine direkte Kommunikation zwischen Raumfühler und Heizkörperthermostat gibt es, wie zu erwarten war, nicht. Läuft alles über die Zentrale (Controller). Es wird auch nirgends beschrieben wie man den Raumfühler mit dem Heizkörperthermostat paart.
5. Zwischenzeitlich hab ich rausgefunden, dass das Heizkörperthermostat über zwei Fühler verfügt. Einer sitzt in der Nähe des Heizkörperventils und misst die Wassertemp des Heizkörpers und ein Fühler sitzt hinter dem Display und soll die Umgebungstemperatur messen.
6. Habe  versucht durch Isolierung des Thermostats das schnelle Aufheizen zu verzögern. Ob das u.U. nicht sogar kontraproduktiv war, soll sich heute in Laufe des Tages zeige.
7. Habe den Support von devolo angeschrieben und das Problem geschildert, mal sehen was die schreiben.
8. Versuche derzeit eine "devolo Home Zentrale" zu Testzwecken aufzutreiben um zu sehen, ob es damit weitere Möglichkeiten gibt.

Ich halte Euch auf dem Laufenden..

Grüße

Ralf

[Nordmann]

Hallo zusammen,

ich habe einen FIBARO System FGMS001 Motion Sensor als Temperaturfühler im Einsatz und möchte
meinen Danfoss Thermostat nach folgender Logik steuern (zumindest in der ersten Ausbaustufe):
# Heizungssteuerung Teil 1 Küche (16.10.2016) -
# Temperatur Absenkung "OG_KUE_Thermostat" auf 17° wenn Sensor "OG_KUE_Sensor" über 21°
# Temperatur Anhebung "OG_KUE_Thermostat" auf 25° wenn Sensor "OG_KUE_Sensor" unter 21°

Aber ich glaube ich habe da in meiner Programmierung einen großen "BOCK" drin:

Code Auswählen Erweitern

define OG_KUE_Thermostat_Steuerung notify OG_KUE_Thermostat
{ if (ReadingsVal ("OG_KUE_Sensor","temperature",99) > 21.0)
    { fhem("set OG_KUE_Thermostat_Steuerung setpointHeating 17") }
else
    { fhem("set OG_KUE_Thermostat_Steuerung setpointHeating 25") }
}

Ich bekomme im Logfile folgende Fehlermeldung:

Code Auswählen Erweitern

2016.10.16 14:09:11.524 1: configfile: Usage: define <name> notify <regexp> <command>
Unknown command {, try help.
Please define OG_KUE_Thermostat_Steuerung first
Unknown command else, try help.
Please define OG_KUE_Thermostat_Steuerung first
Unknown command }, try help.

Ist das überhaupt sie richtige Vorgehensweise um die Aufgabe zu erfüllen?

[Nordmann]

Also ich habe den ganzen Tag an meiner "Steuerung" rumprobiert und habe mich in ein gedankliches "Loch" manövriert

Einer meiner Varianten ist:

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature] gt "21.0") (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature] le "21.0") (set OG_KUE_Thermostat setpointHeating 25)

Aber da passiert auch nichts.

Noch mal zur Erinnerung, ich will folgendes erreichen, um damit meinen Danfoss Heizkörper Thermostat zu Steuern:

# Heizungssteuerung Küche
# Temperatur Absenkung "OG_KUE_Thermostat" auf 17° wenn Sensor "OG_KUE_Sensor" über 21°
# Temperatur Anhebung "OG_KUE_Thermostat" auf 25° wenn Sensor "OG_KUE_Sensor" unter oder gleich  21°

Wäre jemand von Euch so freundlich und würde mich wieder auf den rechten Pfad bringen

[Nordmann]

Nachtrag, um kurz vor "dreh durch":

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature] gt "21.0 C") (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature] le "21.0 C") (set OG_KUE_Thermostat setpointHeating 25)

bringt auch nichts

Bei

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature] > 21.0) (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature] <= 21.0) (set OG_KUE_Thermostat setpointHeating 25)
bringt mir das Logfile Fehler wie diesen:

Code Auswählen Erweitern

PERL WARNING: Argument "22.8 C" isn't numeric in numeric gt (>) at (eval 916) line 1.

[Nordmann]

Guten Morgen zusammen!

Nach meiner "Programmierung" mit

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature] gt "21.0 C") (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature] le "21.0 C") (set OG_KUE_Thermostat setpointHeating 25)

ist irgendwann in der Nacht laut Eventmonitor folgendes passiert:

Code Auswählen Erweitern

2016-10-17 01:55:43.872 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 01:55:44.127 DOIF H_Steuerung_KUE cmd_nr: 2
2016-10-17 01:55:44.127 DOIF H_Steuerung_KUE cmd: 2
2016-10-17 01:55:44.127 DOIF H_Steuerung_KUE cmd_event: OG_KUE_Sensor
2016-10-17 01:55:44.127 DOIF H_Steuerung_KUE error: set OG_KUE_Thermostat setpointHeating 25: Scheduled for sending after WAKEUP
2016-10-17 01:55:44.127 DOIF H_Steuerung_KUE cmd_2
2016-10-17 01:55:44.131 ZWave OG_KUE_Sensor temperature: 0.00228 C
2016-10-17 01:57:18.278 ZWave OG_KUE_Thermostat battery: 63 %
2016-10-17 01:57:18.336 ZWave OG_KUE_Thermostat setpointTemp: 21.00 C heating
2016-10-17 01:57:18.393 ZWave OG_KUE_Thermostat ccsOverride: no, unused
2016-10-17 01:57:18.450 ZWave OG_KUE_Thermostat wakeup: notification
2016-10-17 02:00:42.084 DOIF H_Steuerung_KUE cmd_nr: 1
2016-10-17 02:00:42.084 DOIF H_Steuerung_KUE cmd: 1
2016-10-17 02:00:42.084 DOIF H_Steuerung_KUE cmd_event: OG_KUE_Sensor
2016-10-17 02:00:42.084 DOIF H_Steuerung_KUE error: set OG_KUE_Thermostat setpointHeating 17: Scheduled for sending after WAKEUP
2016-10-17 02:00:42.084 DOIF H_Steuerung_KUE cmd_1
2016-10-17 02:00:42.089 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:00:42.689 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:00:43.240 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:02:14.339 ZWave OG_KUE_Thermostat battery: 63 %
2016-10-17 02:02:14.400 ZWave OG_KUE_Thermostat setpointTemp: 25.00 C heating
2016-10-17 02:02:14.454 ZWave OG_KUE_Thermostat ccsOverride: no, unused
2016-10-17 02:02:14.511 ZWave OG_KUE_Thermostat wakeup: notification
2016-10-17 02:02:49.189 at Atdanfoss Next: 02:32:49
2016-10-17 02:02:49.202 at AtOG_KUE_Sensor Next: 02:32:49
2016-10-17 02:05:40.523 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:05:40.870 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:05:41.631 ZWave OG_KUE_Sensor temperature: 22.8 C
2016-10-17 02:07:10.409 ZWave OG_KUE_Thermostat battery: 63 %
2016-10-17 02:07:10.476 ZWave OG_KUE_Thermostat setpointTemp: 17.00 C heating

Also alles irgendwie falsch zwischendurch!
Und vor allen Dingen hat die "Programmierung" erst nach 2 Stunden "gegriffen", das ist doch viel zu spät!!!!!!
Was kann ich denn hier machen, damit die Sache läuft!!

[A.Harrenberg]

Hi,

du kannst nicht Zahlen und Texte durcheinanderwürfeln...

Aus der (deutschen) CommandRef zu DOIF:

Vergleichende Abfragen werden, wie in Perl gewohnt, mit Operatoren ==, !=, <, <=, >, >= bei Zahlen und mit eq, ne, lt, le, gt, ge, =~, !~ bei Zeichenketten angegeben.

D.h. du brauchst hier ">=" und "<" da Du Zahlen vergleichen willst. Da das Reading aber Zahl + Einheit enthält muss Du die Zahl "rausfiltern"...

Ebenfalls aus der CommandRef zu DOIF:

Filtern nach Ausdrücken mit Ausgabeformatierung   back

Syntax: [<Device>:<Reading>|<Internal>:d|"<Regex>":<Output>]

d - Der Buchstabe "d" ist ein Synonym für das Filtern nach Dezimalzahlen, es entspricht intern dem regulären Ausdruck "(-?\d+(\.\d+)?)"

Weiter macht es wenig (bis gar keinen Sinn) auf eine > 21 abzufragen und dann eine ELSEIF Abfrage auf < 21 zu machen. Hierbei lässt Du nämlich den Fall das es genau 21 Grad sind komplett weg! Also eine einfache DOIF ... > 21 DOELSE ... ist hier deutlich besser.

Schau Dir doch mal die vielen Beispiele in der deutschen CommandRef zu DOIF an.

Gruß,
Andreas.

[Nordmann]

Zu meiner "Ehrenrettung".
Das

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature] gt "21.0 C") (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature] le "21.0 C") (set OG_KUE_Thermostat setpointHeating 25) falsch ist, weil ich ja Zahlen auslesen will und keine Strings, leuchtet ein
Aber auch wenn das falsch war, die 21 C sind in der Abfrage dabei: le (lower equal), oder liege ich da wieder falsch 

Da ich ja noch am lernen bin und die Syntax peu à peu lerne, habe ich jetzt erst einmal versucht mein define "geradezubiegen.
Wenn das funktioniert teste ich die "DOIF ... > 21 DOELSE" Variante.

Ich habe mich an die Angaben in der Commandref gehalten.

Code Auswählen Erweitern

Es soll aus einem Reading, das z. B. ein Prozentzeichen beinhaltet, nur der Zahlenwert für den Vergleich genutzt werden:

define di_heating DOIF ([adjusting:actuator:d] < 10) (set heating off) DOELSE (set heating on)

Hier mein define:

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature:d] >= 21.0) (set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature:d] < 21.0) (set OG_KUE_Thermostat setpointHeating 25)

Jetzt bekomme ich im Eventmonitor folgende Fehlermeldeung:

Code Auswählen Erweitern

2016-10-17 19:26:31.507 DOIF H_Steuerung_KUE error: set OG_KUE_Thermostat setpointHeating 17: Scheduled for sending after WAKEUP

Wenn ich das jetzt richtig sehe, muss ein WAKEUP des OG_KUE_Thermostat stattfinden BEVOR das "set OG_KUE_Thermostat setpointHeating xx" abgesetzt wird.

Jetzt hatte ich folgende Idee:

Code Auswählen Erweitern

define H_Steuerung_KUE DOIF ([OG_KUE_Sensor:temperature:d] >= 21.0) (get OG_KUE_Thermostat battery && set OG_KUE_Thermostat setpointHeating 17) DOELSEIF ([OG_KUE_Sensor:temperature:d] < 21.0) (get OG_KUE_Thermostat battery && set OG_KUE_Thermostat setpointHeating 25)
Aber das bringt mich auch nicht weiter. Irgendwie ist da total der Wurm drin.

Nachtrag:
Also wenn ich das jetzt richtig sehe liegt es z.T. immer noch daran, dass ich die Temperatur immer noch nicht richtig auslese, oder?
Ich hab das immer noch nicht kapiert wie das mit dem "Trennen" der Zahl vom C (für Celsius) funktioniert.
Kann mir bitte da mal jemand auf die Sprünge helfen was das mit "(-?\d+(\.\d+)?)" auf sich hat.
Was muss ich machen, um bei 21.0 C in meinem o.g. Beispiel nur die 21.0 auszulesen. Und was mache ich wenn die Temperatur einstellig wird, also z.B. 7.0 C

[A.Harrenberg]

Hi,

also ich bin leider auch kein Fachmann für DOIF oder notify... (und mir ist nicht klar warum Du dein Thermostat nicht selber auf die Wunschtemperatur regeln lässt...)

Aber soweit ich weiß triggert DOIF nur einmal, falls eine Bedingung erfüllt, danach erst dann wieder wenn die andere erfüllt ist. Falls jetzt hier mal durch das testen ein Event ausgelöst wurde kommt erst mal keins bis sich der Status ändert. Das ist eigentlich ganz gut, ansonsten würdest Du bei jeder Änderung bzw. Update der Sensortemperatur erneut einen Befehl an das Thermostat schicken.

Problem ist hier aber auch das das Thermostat ja ein Batteriegerät mit WakeUp ist. Ich würde das so machen das ich ein Notify auf die WakeUp-Notification des Thermostat mache, dann in dem Notify schaue ob die Temperatur größer oder kleiner 21 ist und dann entsprechend den Befehl an das Thermostat absetzen. Das würde verhindern das sich da Befehle auf dem WakeUp-Stack stapeln die hin-und-herschalten wollen, falls sich zwischen den WakeUpIntervallen die Temperatur um die Schwelle bewegt.

Wie genau so ein Notify aussehen müsste kann ich Dir aber auch nicht so fehlerfrei dahersagen, dafür müsste ich auch nachschauen und probieren...

Code Auswählen Erweitern

define WU-Kueche notify OG_KUE_Thermostat:wakeup:.* set OG_KUE_Thermostat setpointHeating 17
So wäre das mit einem festen Befehl, anstelle des Befehls muss da jetzt eine IF Abfrage rein...

Code Auswählen Erweitern

define WU-Kueche notify OG_KUE_Thermostat:wakeup:.* {
if (ReadingsNum ("OG_KUE_Sensor","temperature",99) >= 21.0) {
    fhem("set OG_KUE_Thermostat_Steuerung setpointHeating 17")
} else {
   fhem("set OG_KUE_Thermostat_Steuerung setpointHeating 25")
}
}

Das ist jetzt aber nur aus dem Bauch und nicht getestet. Damit sollte jedesmal wenn das Thermostat aufwacht und auch bereit ist einen neuen Befehl entgegenzunehmen der Setpoint entsprechend der Abfrage gesetzt werden.

Gruß,
Andreas.

[tomspatz]

Meine Meinung:
Die LC-13 haben ja intern schon einen Regel Algorithmus. Ich habe selbst diese im Einsatz.
Da eine Heizung je nachdem wo im Raum die "Wunschtemperatur" abgefragt wird eh recht träge ist, würde ich diese DOIF Spielerei nicht einsetzten.
Es lässt sich ja relativ einfach in kurzer Zeit feststellen, wann es MIR mit der Raumtemperatur "passt".
Und damit meine ich NICHT 20.00 am Thermostat eingestellt sondern so lange diese Einstellung in kleinen Schritten verändern bis es MIR wohlig ist.
Dabei spielt es dann keine Geige ob die Einstellung 15.00 C oder 24.00 C ist, MIR muss es schön sein.
Diesen selbst ermittelten Wert dann als setpointHeating absetzen und fertig. Den Rest der Regelung übernimmt das Thermostat selbst.

LG
Tom

[Nordmann]

Hallo Tom,

erst einmal danke für Eure Tipps.
Mein Thermostat in der Küche ist ziemlich doof verbaut -> unten kopfüber an der Heizung und mit Display nach unten, sodass mann weder das Display ablesen, noch die Tasten richtig bedienen kann.
Aber aus baulichen Gründen ging es nicht anders; kann man auch nicht ändern.
Außerdem möchte ich auch die Steuerung einbauen, dass der Thermostat runterregelt, wenn die Terrassentür offen ist, bzw. das Fenster.
In einer weiteren Ausbaustufe kommt dann noch ein Heizplan dazu, mit Ferienplaner etc.
Aber davon bin ich im Augenblick noch Meilenweit entfernt. 

Wenn ich jetzt die erste "Einstiegs Variante" von Andreas setzte

Code Auswählen Erweitern

define H_Steuerung_KU notify OG_KUE_Thermostat:wakeup:.* set OG_KUE_Thermostat setpointHeating 17
passiert noch nichts. Ich nehme mal an, dass das so ist weil beim wakeup immer nur notification steht, also hier auch keine Änderung zu verzeichnen ist.
Ich habe mal das Listing beigefügt.

Code Auswählen Erweitern

Internals:
   DEF        f1df7bc3 27
   IODev      ZWAVE1
   NAME       OG_KUE_Thermostat
   NR         193
   STATE      active
   TYPE       ZWave
   ZWaveSubDevice no
   homeId     f1df7bc3
   isWakeUp   1
   nodeIdHex  1b
   Readings:
     2016-10-09 18:34:06   CMD             ZW_APPLICATION_UPDATE
     2016-10-16 22:05:25   UNPARSED        CLOCK 0381033f
     2016-10-18 18:30:40   battery         63 %
     2016-10-18 18:30:40   ccsOverride     no, unused
     2016-10-09 14:01:44   clock           none 00:02
     2016-10-09 14:00:13   model           Danfoss Z Thermostat 014G0013
     2016-10-09 14:00:13   modelConfig     danfoss/z.xml
     2016-10-09 14:00:13   modelId         0002-0005-0004
     2016-10-16 13:50:41   neighborList    ZWAVE1 OG_WZ_Rauchmelder Steckdose EG_Sirene EG_Flur_h_Repeater
     2016-10-18 18:30:40   setpointTemp    25.00 C heating
     2016-10-16 15:12:14   state           active
     2016-10-18 18:30:42   timeToAck       0.059
     2016-10-18 18:30:42   transmit        OK
     2016-10-18 18:30:40   wakeup          notification
     2016-10-09 14:05:37   wakeupReport    interval 1800 target 1
   SendStack:
     get:131b0280022551
Attributes:
   IODev      ZWAVE1
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   icon       temp_control
   room       OG_Kueche,ZWave
   vclasses   BATTERY:1 CLIMATE_CONTROL_SCHEDULE:1 CLOCK:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 PROTECTION:2 THERMOSTAT_SETPOINT:2 VERSION:1 WAKE_UP:2
   verbose    5

Die zweite Variante

Code Auswählen Erweitern

define H_Steuerung_KUE notify OG_KUE_Thermostat:wakeup:.* {
if (ReadingsNum ("OG_KUE_Sensor","temperature",99) >= 21.0) {
    fhem("set OG_KUE_Thermostat setpointHeating 17")
} else {
   fhem("set OG_KUE_Thermostat setpointHeating 25")
}
}


wirft mir folgende Fehlermeldung aus:

Code Auswählen Erweitern

Unknown command if, try help.
Unknown command fhem("set, try help.
Unknown command }, try help.
Unknown command fhem("set, try help.
Unknown command }, try help.
Unknown command }, try help.

Mir gehts ein wenig wie Goethe Faust

"Da stehe ich nun ich armer Tor und bin so klug als wie zuvor"

[tomspatz]

Hi Nordmann
ME ist das "if" im notify ganz fehl am Platz.
Lese dir bitte die WiKi zum LC-13 durch. Dein wakeupInterwal 1800 ist viel zu lang. Das Thermostat reagiert dann ja nur alle 30 Minuten auf das was du ihm schickst.
Glaube das du dich in diese Richtung schon ganz schön reingefressen hast.

Ein dummy zum Werte setzten, ein notify darauf, fertig.

LG und viel Spass

Tom

[Nordmann]

Hallo Tom,

meist Du den WIKI Eintraghttp://www.fhemwiki.de/wiki/Z-Wave
mit dem Eintrag:

Code Auswählen Erweitern

Danfoss
DAN_LC-13 Heizungsthermostat LC-13 (014G0013)
Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem at abgefragt werden (Beitrag):

define Atdanfoss at +*00:30 get <name> battery

Wenn ja, das define habe ich auch schon gesetzt.

Meinst Du mit dummy:

Code Auswählen Erweitern

define H_Steuerung_KUE_17 dummy
set OG_KUE_Thermostat setpointHeating 17

define H_Steuerung_KUE_25 dummy
set OG_KUE_Thermostat setpointHeating 25


Aber mit "notify drauf" komme ich noch nicht ganz klar, sprich blicke ich nicht 

[A.Harrenberg]

Hi Nordmann,

sorry, die Definition für das notify muss in eine lange Zeile wenn Du das über das Eingabefeld machst,

Code Auswählen Erweitern

define H_Steuerung_KUE notify OG_KUE_Thermostat:wakeup:.* { if (ReadingsNum ("OG_KUE_Sensor","temperature",99) >= 21.0) { fhem("set OG_KUE_Thermostat setpointHeating 17") } else { fhem("set OG_KUE_Thermostat setpointHeating 25") }}
ich hatte das nur zur besseren Lesbarkeit umgebrochen.

@Tom: Wieso meinst Du wäre das "if" da Fehl am Platz?

Meiner Meinung nach ist das die effektivste Variante um diese besondere Aufgabenstellung zu bewerkstelligen. Dadurch wird nur genau während des Notify einmal ein Befehl ausgelöst. Lösungen die während der Schlafphase Befehle erzeugen legen die auf den WakeUp-Stack, was evtl. zu unnötig vielen Übertragungen führt.

Insgesamt ist das natürlich alles nicht wirklich schön, wenn das aber mit der Einbauposition zusammenhängt... Ok...
Aber das Problem mit der Regelbarkeit wegen der "Totzeit" des Geräts bleibt bestehen. Und das wakeupinterval steht in direkten Zusammenhang mit dem Batterieverbrauch...

Gruß,
Andreas.

[tomspatz]

Moin Andreas

@Tom: Wieso meinst Du wäre das "if" da Fehl am Platz?

http://fhem.de/commandref_DE.html#notify
In der Commandref steht es so nicht drin, probiert habe ich es so nicht.

Deine Idee den Befehl abzusenden, hört sich logisch an. Aber inwiefern ist das relevant gegenüber die auf den Sendstack sofort zu legen. Dieser wird ja auch beim WakeUp abgearbeitet.
Das wakeupInterwal habe ich auf 300 gesetzt. Damit ist das System nicht ganz so träge.
Die mitgelieferten Batterien bei den LC-13 hielten bei meinen 5 Räumen gut 8 Monate. Nachdem Batterie "low" gemeldet wurde noch 15 Tage bis Exitus.
Damit kann ich leben.

Bevor ich nur alle 30 Minuten eine Änderung um 8 Grad einstellen kann, überlasse ich die Regelung den Thermostaten selbst, das können die ja.

@Nordmann
Den dummy meine ich so:

Code Auswählen Erweitern

define HeizungReglerBuero dummy
attr HeizungReglerBuero setList state:4.00,4.50,5.00,5.50,6.00,6.50,7.00,7.50,8.00,8.50,9.00,9.50,10.00,10.50,11.00,11.50,12.00,12.50,13.00,13.50,14.00,14.50,15.00,15.50,16.00,16.50,17.00,17.50,18.00,18.50,19.00,19.50,20.00,20.50,21.00,21.50,22.00,22.50,23.00,23.50,24.00,24.50,25.00,25.50,26.00,26.50,27.00,27.50,28
attr HeizungReglerBuero stateFormat {sprintf(" %.1f °C",(ReadingsNum("HeizungReglerBuero","state",0)))}
attr HeizungReglerBuero webCmd state

Diesen horchst du mit einem notify ab:

Code Auswählen Erweitern

define HeizungReglerNotifyBuero notify HeizungReglerBuero:* {
my $reglerwert =
ReadingsVal("HeizungReglerBuero","state","on");;\
fhem ("set ThermostatBuero thermostatSetpointSet $reglerwert");
}

Auf dein Begehren gehe ich leider gar nicht ein da es ME wenig Sinn macht. SORRY

LG
Tom

[A.Harrenberg]

Moin Tom,

Moin Andreashttp://fhem.de/commandref_DE.html#notify
In der Commandref steht es so nicht drin, probiert habe ich es so nicht.

danke, die CommandRef kenne ich, aber kennst Du das Notify Wiki? 
Im Befehlsteil des Notify (bei FHEM allgemein) kann man über die geschweiften Klammer PERL Syntax verwenden, genauso wie Du das in Deinem Beispiel auch machst. Und "if" ist ganz normale Perl Syntax...
In dem Wiki ist das z.B. bei dem Beispiel zu Einfache_UND_Funktion so gemacht.

Deine Idee den Befehl abzusenden, hört sich logisch an. Aber inwiefern ist das relevant gegenüber die auf den Sendstack sofort zu legen. Dieser wird ja auch beim WakeUp abgearbeitet.

Du gehst davon aus das während der "Schlafphase" nur EIN Befehl erzeugt wird der dann auf dem Stack liegt. Ich gehe davon aus das bei der Methode die Nordmann hier nutzen möchte es durchaus möglich ist das bei einer Temperatur die um die Grenze schwankt auch MEHRERE Befehle nacheinander auf dem Stack landen. Das erhöht die Funklast und den Batterieverbrauch, wenn man das vermeiden kann, sollte man das immer tun...

Dein Vorschlag realisiert ja sehr schön eine Art "Fernbedienung" für die Solltemperatur, aber wenn durch den Einbauort und die Lage des Thermostaten dieser eben NICHT in der Lage ist die Temperatur selbst vernünftig zu regeln dann läuft das auch ins Leere. Im Ursprungsthema dieses Threads geht es z.B. genau darum das am Thermostaten eine Hitzestau entsteht und der dann > 30°C anzeigt obwohl der Raum noch kalt ist...

Falls der Themostat von Nordmann aber doch noch halbwegs regeln kann ist die Vorgabe einer Solltemperatur und Regeln über den Thermostaten auf jeden Fall um Klassen besser als so ein Zweipunktregler mit einer Totzeit von 5 Minuten ,-) Dann kann Nordmann Dein Beispiel gut nutzen.

Gruß,
Andreas

[tomspatz]

Hallo Andreas

danke, die CommandRef kenne ich, aber kennst Du das Notify Wiki? 
Im Befehlsteil des Notify (bei FHEM allgemein) kann man über die geschweiften Klammer PERL Syntax verwenden, genauso wie Du das in Deinem Beispiel auch machst. Und "if" ist ganz normale Perl Syntax...
In dem Wiki ist das z.B. bei dem Beispiel zu Einfache_UND_Funktion so gemacht.

COOL, kannte ich nicht.

Meine "Fernbedienung" funktioniert allerdings sehr gut so, und die eigentliche Regelung machen die Thermostate tatsächlich.
Das notify triggert ja NUR eine Änderung des dummys, somit wird ja nur einmal traffic erzeugt. Es sei denn du stellst da permanent dran rum. Aber warum?
Die Totzeit ist allerdings bei Nordmann zwangsweise 30 Minuten, dann kommt das notify und setzt das Thermostat auf 25 Grad. Dummerweise Hitzestau innerhalb kurzer Zeit macht das Thermostat dicht und der Raum bleibt kühl.
30 Minuten später setzt das notify wieder 25 Grad ab. UND... juckt doch niemanden. Das Thermostat bedankt sich und schläft wieder ein. Spätestens dann schmeißt Seine Frau Ihn samt der sche... Steuerung raus. 
Ich möchte die LC-13 nicht hochloben aber so funktioniert das halt zuverlässig ohne das man direkt ans Ventil zum regeln kommt.

LG
Tom

[Ralf]

Hi,

zwischenzeitlich ist mein begonnenes Thema von "Nordmann" etwas "zweckentfremdet" worden, was ich persönlich nicht so toll finde, da sein Problem nicht direkt etwas mit meiner Problemstellung zu tun hat. Man möge es mir also verzeihen, wenn ich wieder zu meinem Problem zurückkehre.

Kurze Zusammenfassung der Ausgangssituation:
Verbautes devolo Thermostat MT2650, das wegen extremen  Wärmestaus (31 °C) total abregelt, obwohl der der Raum erst 19 °C hat.
Installiertes Raumthermostat das die richtige Raumtemperatur anzeigt und die gewünschte Soll-Temperatur auch an das Heizkörperthermostat richtig überträgt, das aber wie bereits gesagt, ja selbst die IST-Temperatur misst und wegen Wärmestau viel zu früh abstellt. Ein extremes "hochdrehen" der Solltemperatur  geht auch nicht, da die MT2650 "nur" bis 28 °C gehen und das aber nicht reicht.

Lösungsansatz:
Es müsste eine Möglichkeit gefunden werden, dass nur die tatsächliche Raumtemperatur vom Raumthermostat genutzt wird, und das Heizkörperthermostat so lange heizt, bis diese erreicht worden ist.

Ich habe dazu Devolo, die ja dafür das Raumthermostat mit dem entsprechenden Heizkörperthermostat extra zu diesem genannten Zweck bewerben, angeschrieben und als Antwort erhalten:

"Die von Ihnen gewünschte Funktion wird von der Devolo Home Control Zentrale umgesetzt. Bitte fassen Sie die das Heizkörperthermostat und das Raumthermostat in eine Gruppe zusammen, welche dann von dem Raumthermostaten her über die Regel gesteuert werden. Damit sollte auch die Heizung hinter dem Schrank nicht frühzeitig zurück regeln."

Um zu testen ob das jetzt tatsächlich mit der "Devolo Home Control Zentrale" funktioniert, habe ich mir zu Testzwecken eine solche beschafft, und siehe da, das funktioniert tatsächlich.

Tja, aber eigentlich ist das jetzt nicht das gewünschte Ziel, da ich jetzt mit FHEM und Devolo Home Control zwei SmartHome-Zentralen am Laufen habe.

Was ich nicht verstehe ist, die Devolo Home Control Zentrale und die beiden Thermostate sind voll Z-Wave kompatibel und Devolo wirbt ja extra damit, dass sie Z-Wave als Standard nutzen und ich konnte ja auch beide Thermostate ohne Probleme in FHEM inkludieren.  Es müsste dann doch eigentlich auch möglich sein, die Regelung irgendwie im FHEM nach zu bilden?

Hat dazu irgendjemand eine Idee?

[A.Harrenberg]

Hi,

also wenn die ganze Kommunikation nur über ZWave läuft musste man mal "sniffen" was an das Thermostat gesendet wird. Das ist mittlerweile ja mit einem USB-CUL möglich, aber nicht ganz trivial.

Ich gehe mal davon aus das man in der Devolo Home Zentrale nicht an irgendwelche aussagekräftigen Logfiles kommt, oder?
Gibt es in der Anleitung der Zentrale vielleicht irgendwelche Hinweise darauf wie die das machen?

Mir fehlt da ehrlich gesagt jegliche Idee wie das mit (den mir bekannten) ZWave-Klassen gemacht werden sollte. Das Problem das das Thermostat ja ein WakeUp-Gerät ist und damit nicht beliebig angesprochen werden kann bleibt ja weiterhin...

Außer sniffen fällt mir dazu nix ein.

Gruß,
Andreas.

[rudolfkoenig]

Außer sniffen fällt mir dazu nix ein.

Mir auch nicht, es sei denn die Herren von Devolo verraten, welche ZWave Befehle an dem Thermostat zu schicken sind.
Uns sollte auch sniffen auf USB-Level reichen. Ist etwas fummelig, erfordert aber keine Programmierkenntnisse.

[A.Harrenberg]

Hi Rudi,

Mir auch nicht, es sei denn die Herren von Devolo verraten, welche ZWave Befehle an dem Thermostat zu schicken sind.
Uns sollte auch sniffen auf USB-Level reichen. Ist etwas fummelig, erfordert aber keine Programmierkenntnisse.

Soweit ich das verstehe ist die Zentrale aber eigenständig mit eigenem internen ZWave Modul und nur per Netzwerk angebunden. Daher wird hier sniffen auf USB-Level wohl nicht funktionieren oder verstehe ich hier was falsch?

Ich habe ehrlich gesagt meine Zweifel ob das wirklich über ZWave realisiert wird oder nicht vielleicht über ein 433MHz Signal... Zumindest aus der Thermostatklasse gibt es nichts mit dem man so etwas realisieren könnte. Und das Ding wacht ja auch nur alle x-Minuten auf...

@Ralf: Funktioniert die Regelung auch noch wenn Du das WakeUp-Interval auf sehr große Werte stellst? (Kannst Du das auslesen und in der Zentrale ändern?)

Gruß,
Andreas.

[Ralf]

Hi Andreas,

Devolo schreibt ganz klar, dass die Kommunikation über ZWave läuft und ich habe ja beide Thermostate vorher am FHEM über ZWave am laufen gehabt.

Habe ausserdem ja auch noch zwei Fenster/Tür Kontakte von Devolo über ZWave am FHEM laufen und es gibt auch eine Kompatibilitätsliste  http://www.smarthomecommunity.eu/wiki/index.php?title=Devolo_Home_Control_-_Kompatibilit%C3%A4tsliste von Devolo wo die Geräte aufgeführt sind, die mit der "Devolo Zentrale" laufen und da sind die gängigsten ZWave-Geräte aufgeführt.

An der Devolo Zentrale kann man bez. Kommunikation, WakeUp oder dergl. überhaupt nichts einstellen. Es gibt keinen direkten Zugriff auf die Zentrale.
Die Verbindung läuft ausschließlich über Web, mydevolo.com oder die App die auf Handy oder Tablet installiert werden kann.
Man kann sich das im Internet  unter https://hcdemo.devolo.net/?lang=de im "Demo-Haus" ansehen.

Tja, dachte auch daran die Kommunikation von der Zentrale "mit zu schneiden", aber mit was?

Werde mich da weiter schlau machen und halte Euch auf dem Laufenden..

Gruß

Ralf

[rudolfkoenig]

Soweit ich das verstehe ist die Zentrale aber eigenständig mit eigenem internen ZWave Modul und nur per Netzwerk angebunden.

Sorry, war mir nicht bewusst, dass "devolo Home Control" ein Geraet ist, ich dachte, es ist nur Software. Das Geraet kann man auch bestimmt irgendwie hacken und dann das Gesendete protokollieren, der Aufwand ist aber deutlich hoeher und falls man keine Anleitung hat, erfordert Spezialwissen.
Der Aufwand fuer sniffen mit dem CUL ist sicher niedriger, weiss aber nicht, ob dieser Feature in FHEM zu haben Dir Wert ist, dafuer ein CUL zu besorgen.
Wenn es hilft: du wuerdest damit zu unserer Bildung was beitragen

[A.Harrenberg]

Hi Ralf,

hast Du vielleicht noch ein "list" von dem Wandthermostat? Mich würde interessieren welche Klassen dort gemeldet werden...

Gruß,
Andreas.

[Ralf]

Hi,

@rudi
Da ich meinen "Bildungsauftrag" sehr ernst nehme    , mache ich mich gleich am Montag auf die Suche, denn ich bin mir fast sicher, dass ich noch irgendwo ein CUL rum liegen habe und dann können wir ja mal schauen, ob wir da was hinkriegen, wäre klasse.

@Andreas,
sorry, hab leider kein list des Wandthermostat gespeichert und das das Teil jetzt an der "Devolo Zentrale" hängt, bei der ich es erst wieder abmelden müsste und Faktorysettings setzenmüsste um es am FHEM wieder zu inkludieren, kann ich leider auf die Schnelle diese Infos nicht besorgen. Werde versuchen ob ich die Infos zu dem Teil anderweitig auftreiben kann.

Habe zwischenzeitlich versucht nähre Infos aus dem Devolo-Support zu erhalten, wie denn diese "Synchronisation" der beiden Thermometer abläuft.

Das Ergebnis ware leider ziemlich mager und lautet in groben Auszügen:
Beide Thermostate sind in einer sog. "Gruppierung" zusammen zu fassen, ein Gruppenname zu vergeben und dann die Funktion "Syncron" zu aktivieren. Anschließend wird für die Gruppe ein Schieberegler zur Verfügung gestellt, über den die gewünschte Temperatur eingestellt wird. Die Synchronisation der beiden Thermostate muss "eingelernt" werden, so dass es 4 - 7 Tage dauern kann, bis das Heizkörperthermostat sich korrekt mit dem Wandthermostat synchronisiert.

Tja und genau so war es dann auch. Die ersten Tage hat es nicht besonder gut geklappt, wurde dann aber immer besser und jetzt passt es wirklich sehr genau.

Ok, ich hoffe, dass wir das mit dem Sniffer vielleicht hinkriegen und dann mehr erfahren ?!

Gruß

Ralf

[A.Harrenberg]

Hi Ralf,

das Ding ist ja wirklich SEHR rätselhaft. Habe kurz überlegt ob das Ding vielleicht einfach eine Art Offset auf sein internes Sensorsignal gesendet bekommt. Ist in der Anleitung zu dem Thermostaten auch eine List/Beschreibung der Config-Register enthalten? Falls ja, kannst Du das mal posten?

Falls Du Deinen CUL nicht findest könnte ich Dir evtl. meinen leihen, da müsste dann nur wieder die richtige Firmware drauf, ich hatte da mal zu Testzwecken einiges geändert ,-)

Gruß,
Andreas.

[Ralf]

Hi Andreas,

danke für das Angebot, aber ich hab mein CUL gefunden, ist von busware, CUL V3.2, ich hoffe das passt.

und auch mit mit den Config-Register kann ich dienen.
Hier die Links zu den Handbüchern, in denen am Ende die Register beschrieben werden.
Leider geben die meiner Meinung nach nix neues her.

Raumthermostat: https://www.myplanets.de/infos/Full_Manual_Home_Control_Raumthermostat_0916_de_online.pdf
Heinzkörperthermostat: https://www.myplanets.de/infos/Full_Manual_Home_Control_Heizkoerperthermostat_0916_de_online.pdf

Ok, wie geht es jetzt mit dem CUL weiter?

Gruß

Ralf

[rudolfkoenig]

Ok, wie geht es jetzt mit dem CUL weiter?

- wenn dfu-programmer mit root-s-bit installiert ist: FHEM mit default fhem.cfg starten (sollte das angeschlossene CUL erkennen und definieren), und CUL mit "CULflash CUL_1 CUL_V3_ZWAVE" flashen.
- sonst irgendwie selbst flashen mit dieser Datei.

Danach am besten ein separates FHEM in einem Terminal starten, mit folgenden fhem.cfg

Code Auswählen Erweitern

attr global logfile -
attr global modpath .
attr global mseclog 1
define zwc ZWCUL <USB-DEVICE-NAME> 00000000 01
attr zwc dataRate 100k
attr zwc verbose 5
Kann sein, dass die Kommunikation mit dem Thermostat auf 40k, und nicht 100k laeuft.

[A.Harrenberg]

Hi Ralf,

und auch mit mit den Config-Register kann ich dienen.
Hier die Links zu den Handbüchern, in denen am Ende die Register beschrieben werden.
Leider geben die meiner Meinung nach nix neues her.

da muss ich Dir leider Recht geben, da steht nichts erhellendes drin...

Gruß,
Andreas.

[Ralf]

Hi,

ok, das mit den flashen des CUL krieg ich hin, da ich aber ein Z-Wave Modul (RaZberry) das im Raspberry verbaut ist, benutze, müsste ich das ja wohl erst mal de-installieren und ausbauen, befürchte, dass das ansonsten mit dem CUL irgendwie in die Quere kommt?!

Vielleicht wäre es überhaupt sinnvoll ein eigenes "Testsystem" auf zu setzen. Mal sehen ob ich das dieses Wochenend schaffe.
Letzte Frage: Mit meinen verbauten Z-Wave Modul (RaZberry) funktioniert das Sniffen wohl nicht oder?

Gruß

Ralf

[rudolfkoenig]

müsste ich das ja wohl erst mal de-installieren und ausbauen, befürchte, dass das ansonsten mit dem CUL irgendwie in die Quere kommt?!

Nein, mit der gezeigten Konfig hoert das CUL nur zu.

Vielleicht wäre es überhaupt sinnvoll ein eigenes "Testsystem" auf zu setzen.

Muss auch nicht sein, mit dem gezeigten Konfig kann FHEM parallel zu einem laufenden FHEM gestartet werden.

Mit meinen verbauten Z-Wave Modul (RaZberry) funktioniert das Sniffen wohl nicht oder?

Vorsichtig ausgedrueckt: mir ist kein Weg bekannt.

[Ralf]

Hi,

ok, danke für die Info, dann gehe ich das am Wochenende an, vorher werde ich es zeitlich vermutlich nicht schaffen.
Melde mich wieder sobald ich das CUL am Laufen habe.

[Ralf]

Hi,

@rudi
ok, das flashen hat hingehauen, aber ansonsten hab ich jetzt keinerlei Ahnung was jetzt laufen sollte.

es wird ein CUL_0 angezeigt mit folgenden Internals:
Internals:
   CFGFN
   CMDS       BCFiAZGMKUYRTVWXefmLltuxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         4
   FHTID      1034
   NAME       CUL_0
   NR         12
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s][A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
   Readings:
     2016-10-28 21:12:51   cmds             B C F i A Z G M K U Y R T V W X e f m L l t u x z
     2016-10-28 21:12:51   state           Initialized

Und ein zwc mit folgenden Daten:

Internals:
   Clients    :ZWave:STACKABLE_CC:
   DEF        CUL_0 00000000 01
   DeviceName CUL_0
   NAME       zwc
   NR         2
   PARTIAL
   STATE      disconnected
   TYPE       ZWCUL
   baudRate   100k
   homeId     00000000
   homeIdSet  00000000
   initString zm1
   monitor    1
   nodeIdHex  01
   Matchlist:
     1:ZWave    .*
     2:STACKABLE_CC ^\*
   Readings:
     2016-10-28 21:12:50   homeId          HomeId:00000000 CtrlNodeIdHex:01
     2016-10-28 21:12:50   state           disconnected
Attributes:
   dataRate   100k
   verbose    5

zwc ist "disconnect"

Vielleicht fehlt bei mir auch noch was in der fhem.cfg
Wäre nicht traurig, wenn Du mir eine vollständige fhem.cfg zur Verfügung stellen könntest.

Ok, ich wie gehts jetzt weiter, bzw. was stimmt da noch nicht??

Grüße

Ralf

[krikan]

Es kann nur ein FHEM-Device auf den CUL zugreifen.
Also CUL_0 löschen.
Im DEF von zwc die richtige Schnittstelle mit passender Baudrate auswaehlen  (/dev/ttyACM0@38400)
Attribut datarate auf 40k.
Save Config und ggfs shutdown restart.

Geloggte/Mitgeschnittene ZWave-Funknachrichten zwischen Thermostat und Zentrale stehen nachher im LogFile.

[rudolfkoenig]

es wird ein CUL_0 angezeigt mit folgenden Internals:

Ich gehe davon aus, dass du nicht das von mir muehsam erstellte, und im Antwort #34 gepostete fhem.cfg verwendet hast
Wenn nicht, bitte probier das so aus, sonst gelten meine Aussagen wie "stoert niemanden, kann parallel zum laufenden FHEM eingesetzt werden" nicht.

P.S.: mein fhem.cfg gilt nicht _zusaetzlich_ zu was Existierendes, sondern Solo. Also das war die komplette fhem.cfg.

[Ralf]

@rudi,

ah... ok... hab ich eigentlich erwähnt, dass ich mit fhem noch ganz an Anfang stehe  ?

Ok..hab Deine fhem.cfg schon benutzt, aber leider überlesen, dass Du geschrieben hast:

Danach am besten ein separates FHEM in einem Terminal starten, mit folgenden fhem.cfg

Tja und jetzt muss ich leider zugeben, dass ich überhaupt nicht weiss, wie man "ein separates FHEM in einem Terminal startet"

@all
Ich habe jetzt mein "produktiv FHEM" gestoppt und würde lieber den Sniffer in meinem "Testsystem" laufen lassen und dazu hätte ich halt gerne eine fhem.cfg gehab mit der ich mich auch wieder in fhem einloggen kann  und das ein log in eine LOG-Datei schreibt ?


etwas verzweifelte Grüße...

Ralf

[krikan]

@all
Ich habe jetzt mein "produktiv FHEM" gestoppt und würde lieber den Sniffer in meinem "Testsystem" laufen lassen und dazu hätte ich halt gerne eine fhem.cfg gehab mit der ich mich auch wieder in fhem einloggen kann  und das ein log in eine LOG-Datei schreibt ?

Das war das, was ich Dir in meinem letzten Post vermitteln wollte. 

Du musst nichts machen, außer den CUL im laufenden FHEM passend zu definieren bzw. umzudefinieren:

Code Auswählen Erweitern

define zwc ZWCUL <USB-DEVICE-NAME> 00000000 01
attr zwc dataRate 40k
attr zwc verbose 5

<USB-DEVICE-NAME> ersetzt Du durch die Schnittstelle des CUL (bspw: /dev/ttyACM0@38400). Das sollte es sein.

Zusätzlich

Code Auswählen Erweitern

attr global mseclog 1
setzen.

Oder Du nimmst aus dem svn die "leere" fhem.cfg https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/fhem.cfg und ergänzt das obige darin vor dem FHEM-Start(Finde ich persönlich umständlicher).

[Ralf]

Hi,

danke, jetzt hab sogar ich es kappiert 

Hier jetzt mal eine Logdatei, keine Ahnung ob man damit was anfangen kann.
Hab zu Beginn der Datei mehrmals die Temperatur geändert, daraufhin wurden auch einige Zeilen geschrieben.

Gruß

Ralf

[A.Harrenberg]

Hallo Ralf,

hmm, ich habe mir das Log mal kurz angeschaut und hätte mal ein paar Fragen...

- was ist Deine ZWave Home-ID? f4181b47? c1662ed1?

-wie sind die ID's Deiner Geräte?
  - 03: Thermostat?
  - 11: Wandtermometer?

Ich finde bei den Nachrichten mit ID f4181b47 nichts ungewöhnliches, da werden Deine Setpoints geschrieben (20.00 oder 18.00) und entsprechende Reports verschickt.

Interessanterweise gibt es aber anscheinend ein zweites Netz mit der ID c1662ed1, dort wird von einem Gerät 11 ebenfalls was verschickt...
Entweder hast Du noch ein weiteres ZWave-Netz oder Du empfängst da was vom Nachbarn...

So richtig schlau werde ich daraus nicht, ich sehe nur per "Climate Control Schedule" ein permanenter Override an das Thermostat gesendet wird und das auch vom Ventil bestätigt wird.

Es KÖNNTE sein das hier einfach ein "Offset" zwischen den beiden (Ist-)Temperaturen (Ventil und Wandthermometer) ausgewertet wird und das dieser Override dann mit diesem Offset beschrieben wird. Hier könnte es sein das mit diesem Offset die Grenze von 28°C überschritten werden kann, wodurch Du dann wieder heizen kannst, auch wenn das Ding sich bereits über 28°C aufgeheizt hast und von "alleine" nicht mehr öffnen würde.

Das ist aber nur eine Vermutung, und mir fällt auf die Schnelle nichts ein wie Du das mal bestätigen könntest.

Vielleicht haben Rudi und Christian ja auch noch eine Idee...

Gruß,
Andreas.

[Ralf]

@Andreas,

natürlich gibt es zwei zWave Netze, das Netz das auf meinen Raspberry lauft und an dem der Sniffer installiert ist = c1662ed1
Und das Netz  der Devolo Home Control Zentrale, um die es ja eigentlich geht = f4181b47

An der Devolo Home Control Zentrale hängen die beiden Thermostate, wobei nicht sagen kann, welche ID was ist, denn es wie gesagt keinelei Möglichkeit gibt, an der Devolo Zentale irgend etwas auszulesen.

Hab jetzt nochmals ein LOG eingefügt, bei dem bis heute morgen mit gesnifft worden ist.

Interessant dürften das Log am Ende sein, denn da habe ich bewusst Einstellungen vorgenommen:

10:31 Uhr , da habe ich das Heizkörperthermostat auf 13.0 °C eingestellt
10:41 Uhr, Raumthermostat wurde auf 20 °C eingestellt.

Auffällig ist, egal an welchem Thermostat ich etwas einstelle, die Temperatur wird auf das andere Thermostat weitergereicht.
Laut Devolo ist das so, da die Thermostate auf "synchron" eingestellt und in einer sog. "Gruppe" zusammengefasst sind.

Andreas, ich teile Deine Vermutung mit dem Offset und dem Overwrite. Ich vermute inzwischen, dass da so etwas ähnliches läuft.

Hab mir heute einmal Gedanken für eine Offset für meine Steuerung gemacht und glaube, dass ich auch mit der Grenze von 28°C auf eine max. Raumtemperatur von 22°C hinkomme könnte. Dauert vermutlich etwas länger, aber das tut es jetzt bei Devolo auch.

Bisher war es so, dass ich am RT zB. 21° eingestellt habe, die das RT an das HT weitergereicht hat, das dann zu heizen begann, aber wegen dem Wäremestau in ganz kurzer Zeit ca. 31° erreichte und das Ventil komplett geschlossen hat.
Dann dauerte es natürlich ewig bis wieder eine Temperatur von unter 21° erreicht wurde, inzwischen war der Heizkörper kalt und alles begann von vorne.

Ich würde die Steuerung jetzt so ändern, dass das HT auf 28° geregelt wird, solange das RT nicht die gewünschte Temperatur erreicht hat. Natürlich kommt es hier ebenfalls zum Hitzestau, aber es dauert bei weiten nicht so lange, bis der Heizkörper wieder zu heizen beginnt.
Mann könnte da u.U. noch eine "Feinjustierung" integrieren, die die HT Temperatur anpasst, wenn die gewünschte Soll-Temperatur de RT  langsam erreicht wird.

Aber von der Idee her, glaubst Du dass das so klappen könnte?

Gruß

Ralf

[gamauf]

Hallo!

Steht nicht im Handbuch (https://www.myplanets.de/infos/Full_Manual_Home_Control_Raumthermostat_0916_de_online.pdf),
dass das "Max set-point and override limit" vom default 28°C auf max. 40°C geändert werden kann???

LG
Rainer

[Ralf]

@Rainer

richtig, das steht beim Raumthermostat, aber beim Heizkörperthermostat steht "Regelbereich 4 bis 28°C" und das Teil nimmt keine SetPoints > 28 !
Ehrlich gesagt kapiere ich zwar nicht warum das RT dann bis 40°C geht, wenn man das HT nicht über 28 einstellen kann, aber wie gesagt, bisher hat das HT größere SetPoint ignoriert und die Befehlsklasse "Max set-point and override limit" gibt es anscheinend nur beim RT.

Gruß

Ralf

[A.Harrenberg]

Hi,

der "Trick" dabei ist das Du z.B. 25°C in Deiner Schedule einstellst dann aber über die Override Funktion aus "Climate Control Schedule" einen Offset auf diesen eingestellten Wert aufprägen kannst.

Und die SUMME aus setpoint plus dem Offset kann jetzt wohl bis 40°C betragen.

Richtig regeln kann das Ding damit allerdings auch noch nicht, da Du ja keinen festen Offset hast, sondern was "chaotisches", d.h. beim Heizen mehr Offset, beim Auskühlen immer weniger.

Gruß,
Andreas.

[Ralf]

Hi Andreas,

ok, danke für den Tip mit dem "Climate Control Schedule", ich hoffe dass ich dieses Wochenende dazu kommen mir das nochmals genau anzusehen.
Werde dann mal versuchen etwas zu basteln.

Gruß

Ralf

[Ralf]

Hi,

ok hat alles etwas gedauert, aber jetzt hab ich meine beiden Thermostate wieder von der Devolo-Home-Control Zentrale getrennt und am FHEM laufen.
Dabei hat sich ein Problem ergeben, das u.U. auch für andere User, die das Devolo-Termostat einsetzen, interessant sein könnte.

Wie gesagt, das Devolo Heizkörperthermostat und das Devolo Raumthermostat wurden testweise für einige Tage an der "Devolo-Home-Control Zentrale" betrieben.
Jetzt ging es daran, diese beiden Geräte wieder im FHEM zu betreiben.

Dazu habe ich das Devolo Raumthermostat einfach auf "Werkseinstellung" zurück gesetzt, was problemlos gelang. Es konnte dann ohne Probleme wieder im FHEM inkludiert werden.
Das gleiche versuchte ich dann mit dem Heizkörperthermostat, Werkseinstellungen wurden ohne Probleme genommen und auch quittiert, aber FHEM hat dann das Thermostat nicht inkludieren können. Ich habe den Vorgang dann mindestens 20 mal probiert. Kein Erfolg.

Erst als ich das HT nochmals in Devolo angemeldet habe, dort dann eine ordnungsgemäße Abmeldung durchführte und dann nochmals ein Rücksetzen auf Werkseinstellung vornahm, konnte es im FHEM inkludiert werden. Eigentlich ging ich davon aus, dass das Rücksetzen auf Werkseinstellungen ausreichen müsste, also wieder etwas dazu gelernt. 

Ok, jetzt noch eine Sache, die mir beim Devolo Raumthermostat aufgefallen ist und u.U. Probleme andere User mit dem Thermostat lösen könnte.

Bei Tests mit dem Raumthermostat ist aufgefallen, das das Thermostat zwar mit z.B. "setpointHeating 20" theoretisch auf 20 °C eingestellt werden kann, der Befehl wird ordnungsgemäß abgesetzt, steht auch im Log, wird aber nicht am Thermostat verarbeitet, was auch in den Readings ersichtlich ist.
Das wakeup läuft einwandfrei durch, das ist auch am Zeitstempel der notifikation ersichtlich, das Thermostat meldet auch z.B. den Battery Status, ignoriert aber den "setpoint"

Tests haben dann ergeben, dass, sobald eine Taste am Termostat gedrückt wird, der Setpoint-Wert aber eingelesen wird.

Hab jetzt aber herausgefunden, dass wenn nach einem "set setpointHeating xxx" ein "get setpoint 1" durchgeführt wird,  der Wert sofort richtig eingelesen und auch unter "setpointTemp" richtig angezeigt wird.

Tja, als nächstes mach ich mich jetzt an ccsOverride, mal sehen ob ich da weiter komme ...

[tomspatz]

Hab jetzt aber herausgefunden, dass wenn nach einem "set setpointHeating xxx" ein "get setpoint 1" durchgeführt wird,  der Wert sofort richtig eingelesen und auch unter "setpointTemp" richtig angezeigt wird.

Hat das ggf. etwas mit MULTI_CMD zu tun?

[rudolfkoenig]

Hat das ggf. etwas mit MULTI_CMD zu tun?

Hoechstens inidirekt, durch Bug im Firmware.
MULTI_CMD ermoeglicht mehrere Befehle als ein Funk-Telegramm zu senden, was z.Bsp. Batterie sparen kann.

[Ralf]

ALSO, würde jetzt gerne ein ccsOverride an mein Heizkörperthermostat senden, so dass er jetzt  permanent zur seiner derzeitigen SollTemp von 22 °C  +5°C addiert.

Bin eigentlich davon ausgegangen, dass dafür das ccsOverride das richtige Mittel dazu ist?!

Oder lieg ich da falsch?
Hab leider keinerlei Ahnung wie ich das aufbauen soll und finde dazu leider auch nix hier im Forum oder sonst wo ?!

Bin für jeden Tip dankbar... DANK!

Ah.... wenn das mit dem ccsOverride sowieso der falsche Weg wäre, bin ich für den Anfang schon dankbar wenn mir jemand kurz mitteilt, wie ich auf einen per "ReadingsVal" gelesenen Wert z.B. + 5°C drauf rechnen kann.

DANKE !!!

Gruß

Ralf

[Ralf]

Hi,

ich habe meine Problem eigentlich größtenteils gelöst, bis auf "ccsOverride" !

Konnte problemlos ein "CLIMATE_CONTROL_SCHEDULE" für die Wochentage setzen, die aber ohne Funktion bleiben, also keinerlei Auswirkung haben.
in den Readings wird auch angezeigt: ccsOverride no, unused

Ich gehe davon aus, dass das daran liegt, dass noch ccsOverridge (permanent oder temporär)gesetzt werden müsste.

Leider gibt es aber im FHEM derzeit kein SET für ccsOverridge, nur das get.

Als Anhang hab ich den entsprechenden Auszug aus der Z-Wave Spezifikation für SCHEDULE_OVERRIDE_SET beigefügt.

Wird die Funktion u.U. in nächster Zeit implementiert?

Gruß

Ralf

[A.Harrenberg]

Hi,

ich denke Climate_Control_Schedule funktioniert anders als Du glaubst...

Konnte problemlos ein "CLIMATE_CONTROL_SCHEDULE" für die Wochentage setzen, die aber ohne Funktion bleiben, also keinerlei Auswirkung haben.
in den Readings wird auch angezeigt: ccsOverride no, unused

hier stimmt mMn schon was nicht wenn die Schedule keine Auswirkung hat. Mein Verständnis der Funktion ist so:

Man setzt die Schedule und die regelt entsprechend dem programmierten Zeitverlauf die eingestellten Temperaturen. Dann kann man über den Override diesen Temperaturverlauf mit einem Offset belegen und das ganze permanent oder temporär machen.

Wenn bei Dir die Schedule keine Wirkung zeigt stimmt da noch was grundlegendes nicht.

Ich gehe davon aus, dass das daran liegt, dass noch ccsOverridge (permanent oder temporär)gesetzt werden müsste.

Ich gehe davon aus das es NICHT an dem override liegt sondern das da vorher bei der Schedule schon was nicht stimmt.

Wird die Funktion u.U. in nächster Zeit implementiert?

Das Set für Override kann ich mal implementieren, und es in den nächsten Tagen mal an Rudi geben.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

anbei ein kleiner Patch der "setOverride" für ccs implementiert. Konnte es natürlich nicht an einem echten Thermostat ausprobieren, die erzeugten Pakete sehen aber gut aus.

Gruß,
Andreas.

@Ralf: Wenn Rudi das eingecheckt hat dauert es noch einen Tag bis das dann per Update verfügbar ist.

[rudolfkoenig]

Habs eingecheckt.

[Ralf]

Hallo Andreas, hallo Rudi

danke für den Patch, werde das testen sobald das Update verfügbar ist.

CLIMATE_CONTROL_SCHEDULE wurde bei mir so gesetzt:

set Thermostat_Kueche ccs tue 05:00 2.0 23:00 0.0

Für mich würde das bedeuten, dass ab 5:00 Uhr  + 2 °C zum derzeitigen Soll-Wert gerechnet werden und ab 23:00 Uhr der Sollwert, der am Thermostat eingestellt gilt,  bis es um 5:0 Uhr wieder von Vorne beginnt, da ich die Werte für jeden Tag eingetragen habe.

Diese werden auch in den Readings z.B. für Montag mit:
ccs_mon     05:00 2.0 23:00 0.0

angezeigt.

Stimmt das so nicht?

Gruß

Ralf

[A.Harrenberg]

Hallo Ralf,

set Thermostat_Kueche ccs tue 05:00 2.0 23:00 0.0

Für mich würde das bedeuten, dass ab 5:00 Uhr  + 2 °C zum derzeitigen Soll-Wert gerechnet werden und ab 23:00 Uhr der Sollwert, der am Thermostat eingestellt gilt,  bis es um 5:0 Uhr wieder von Vorne beginnt, da ich die Werte für jeden Tag eingetragen habe.

Diese werden auch in den Readings z.B. für Montag mit:
ccs_mon     05:00 2.0 23:00 0.0

angezeigt.

Stimmt das so nicht?

das ist schwer zu sagen... Ich selbst habe kein ZWave-Thermostat und ich glaube Rudi hat auch keines. Das bedeutet das die Befehle so implementiert sind wie sie beschrieben sind, bzw. zum damaligen Zeitpunkt bekannt waren. Und selbst mit der "offiziellen" Dokumentation von Sigma bleibt da immer noch genügend Spielraum für Vermutungen was mit den einzelnen Parametern wirklich gemeint ist und was damit letztendlich passiert. Dann kommt noch hinzu das die Geräte selbst sich nicht immer an die Spezifikation halten und Befehle auch durchaus schon mal unterschiedlich verarbeiten.

Also was soll ich jetzt sagen... Der Befehl sieht in Ordnung aus, das Reading auch. Reagiert das Thermostat denn wirklich nicht auf die Schedule?

Da fällt mir gerade noch was ein, wie sieht es eigentlich mit der Zeit aus? Welche Klassen unterstützt das Thermostat? Da muss sicherlich erst mal die Zeit eingestellt werden bevor das Ding mit den Schedules was anfangen kann... Hat das Ding eine Uhrzeit im Display?

Gruß,
Andreas.

[Ralf]

Hallo Andreas,

Da fällt mir gerade noch was ein, wie sieht es eigentlich mit der Zeit aus?

Ahhh shit, DIE UHRZEIT, dafür gibt es ja "set/get clock" und die hat tatsächlich nicht gestimmt, weder Tag noch Uhrzeit und ist dazu noch auf Sonntag gestanden und das war der einzige Tag den ich bisher noch nicht eingestellt habe.

Ok, jetzt werde ich die Sache die nächsten Tage mal beobachten und auch Override testen....

Nochmals DANKE und sorry 

Gruß

Ralf

[A.Harrenberg]

Hi Ralf,

gibt es was neues zu berichten? Hat das Einstellen der Uhrzeit was gebracht? Funktioniert der "set ccsOverride"?

Gruß,
Andreas.

[Ralf]

Hi Andreas,

tja, ccsOverride funktioniert, DANKE nochmals an Dich und Rudi, ABER bringt für mein ursprüngliches Problem (Wärmestau) leider auch nix, denn so wie es aussieht ist bei 28°C einfach Schluss und das Heizkörperthermostat macht zu.

Hab jetzt um die Sache einigermaßen in den Griff zu kriegen einen thermogesteuerten Lüfter am Thermostat verbaut, der etwas Besserung bringt, aber leider, obwohl es ein "silent-Lüfter" ist, doch nicht ganz geräuschlos läuft. Erreiche damit bei einigermaßen erträglicher Geräuschkulisse max. ca. 21 °C, was derzeit reicht wenn es kein strenger Winter wird  .

Bei Gelegenheit werde ich einmal ein Danfoss/devolo Thermostat auseinander nehmen und schauen, ob es eine Möglichkeit gibt, den Temperaturfühler des Thermostats zu manipulieren.

Die andere Alternative wäre, bei den Thermostaten auf HM umzusteigen. Da aber ansonsten bei mir alle anderen Geräte mit ZWave laufen und das sind immerhin ca. 20 Stück die ohne Probleme verteilt über 3 Etagen + Keller und Garten  ihren Dienst verrichten, würde ich ungern nur wegen dem einen Heizkörper, extra noch HM dazu zu nehmen.

Außerdem befürchte ich, dass das nicht so einfach wird mit HM?!
Ich hätte zwar noch ein CUL, aber mein Raspi, auf dem FHM läuft, befindet sich ein Stockwerk höher, abgeschirmt durch eine massive Betondecke als der betroffene Heizkörper, so dass ich befürchte, dass das über den direkten Weg nicht funktionieren wird. Bei Zwave ist das aufgrund des "Mesh-Netzwerk" kein Problem.

Ok, also nochmals an alle Beteiligen vielen Dank für die Unterstützung. Ich werde Euch weiterhin auf dem Laufenden halten.

Gruß

Ralf

[A.Harrenberg]

Hi Ralf,

also irgendwie muss es doch gehen, hat ja mit der anderen Zentrale auch funktioniert.

Was passiert denn wenn Du in der Schedule 28°C einstellst und dann per Override +12°C einstellst. Da sollte dann doch quasi 40°C bei rauskommen...

Gruß,
Andreas.

[Ralf]

@Andreas,

ah.... was verstehst Du jetzt unter

"Du in der Schedule 28°C einstellst"

?

Es gibt die Möglichkeit über "setpointTemp" das Thermostat auf 28°C einzustellen. Geht, führt dann zu ca. 31°C gemessene Temp am Thermostat und ca. 20C Raumtemperatur.

Oder ich mache es z.B. mit "ccs sat 5:00 4.00 23:00 0.0"   ausgehen von einer eingestellten Temp von 24 °C  was wieder 28°C gegeben würde.
Dann  setze ich noch ein "ccsOverride permanet 12.0" das er auch nimmt, wobei die 12°c nirgends angezeigt werden, aber es ändert sich dadurch nichts. Das Thermostat pendelt dann mit kurzen Heizphasen zwischen ca. 31C und 27,8 C was in der Summe dann ca. 20°C Raumtemperatur ergibt.

Wobei.... wenn ich mir das genauer anschauen, bin ich mir jetzt nicht mehr sicher ob das mit dem "Override" wirklich funktioniert?!

Wie lautet denn der genaue Syntax für "ccsOverride" ?

Ich kann folgendes beim entsprechenden Thermostat über set ohne Fehler oder dergl. eingeben:
ccsOverride permanet 12.0
ccsOverride permanet +12.0
ccsOverride permanet 12.0 C
ccsOverride permanet +12.0 C

Im Protokoll des Thermostat finde ich dann aber keinerlei Einträge, ein get ccsOverride liefert dann ein: ccsOverridge: permanent, unused

Ich bin jetzt der Meinung, dass das ccs bei Thermostat nicht richtig läuft.

Wenn ich mich im Forum so umschauen, hat es ja auch bisher anscheinend noch niemand geschafft bei einem ZWave-Thermostat CCS richtig ans Laufen zu bringen. Eigenartig ist nur, dass CCS beim "Devolo Home Controlcenter" funktioniert hat, dafür gab es da kein ccsOverride !

Gruß

Ralf

[A.Harrenberg]

Hi Ralf,

Es gibt die Möglichkeit über "setpointTemp" das Thermostat auf 28°C einzustellen. Geht, führt dann zu ca. 31°C gemessene Temp am Thermostat und ca. 20C Raumtemperatur.

ich meinte eher setpointTemp, die Schedule sollte laut der Beschreibung ja von dem ccsOverride überschrieben werden.

Oder ich mache es z.B. mit "ccs sat 5:00 4.00 23:00 0.0"   ausgehen von einer eingestellten Temp von 24 °C  was wieder 28°C gegeben würde.

Was passiert denn wenn Du setpointTemp auf 28°C stellst und in der Schedule 12°C angibst?

Dann  setze ich noch ein "ccsOverride permanet 12.0" das er auch nimmt, wobei die 12°c nirgends angezeigt werden, aber es ändert sich dadurch nichts. Das Thermostat pendelt dann mit kurzen Heizphasen zwischen ca. 31C und 27,8 C was in der Summe dann ca. 20°C Raumtemperatur ergibt.

Wobei.... wenn ich mir das genauer anschauen, bin ich mir jetzt nicht mehr sicher ob das mit dem "Override" wirklich funktioniert?!

Wie lautet denn der genaue Syntax für "ccsOverride" ?

Ich kann folgendes beim entsprechenden Thermostat über set ohne Fehler oder dergl. eingeben:
ccsOverride permanet 12.0
ccsOverride permanet +12.0
ccsOverride permanet 12.0 C
ccsOverride permanet +12.0 C

Im Protokoll des Thermostat finde ich dann aber keinerlei Einträge, ein get ccsOverride liefert dann ein: ccsOverridge: permanent, unused

Also "permanent 12.0" sollte richtig sein. Das positive Vorzeichen ist optional, nachfolgender Text wird wohl ignoriert...

Wenn das get ccsOverride das aber nicht zurückmeldet, dann stimmt da was nicht... Kannst Du evtl. mal ein Log mit "verbose 5" machen wenn Du das set ccsOverride und anschließend ein get ccsOverride machst?

Ich bin jetzt der Meinung, dass das ccs bei Thermostat nicht richtig läuft.

Wenn ich mich im Forum so umschauen, hat es ja auch bisher anscheinend noch niemand geschafft bei einem ZWave-Thermostat CCS richtig ans Laufen zu bringen. Eigenartig ist nur, dass CCS beim "Devolo Home Controlcenter" funktioniert hat, dafür gab es da kein ccsOverride !

Na ja, es hat sicherlich schon seinen Grund warum die Klasse deprecated ist...
Hattest Du nicht mal beim Devolo "mitgesnifft"? Ich schau bei Gelegenheit den Thread noch mal durch was da so an Befehlen zu sehen war.

Gruß,
Andreas.

[Ralf]

Hi Andreas...

Kannst Du evtl. mal ein Log mit "verbose 5" machen wenn Du das set ccsOverride und anschließend ein get ccsOverride machst?

Hier als Anlage das gewüschte Log mit verbos 5.
Hab ein "set ccsOverride permanent 12.0" und gleich danach ein "get  ccsOverride" abgesetzt.

Interessant sind natürlich nur die Einträge mir das "Thermostat_Kueche"

Aber wie gesagt, mit keinerlei erkennbarer Reaktionen beim Thermostat selbst.

Gruß

Ralf

[A.Harrenberg]

Hi,

also ich sehe das setzen von "permanent 12.0" und die Antwort lautet auch "permanent 12.0"...
Wenn da nichts am Thermostat passiert bin ich jetzt erst mal überfragt. ,-(

Die Rückmeldung "unused" von Fhem ist allerdings ein kleiner BUG... Danach schaue ich bei Gelegenheit mal, das ist noch relativ alter Code.

Gruß,
Andreas.