boostduration & boostValvePosition greifen nicht

[wkarl]

Hallo,

bisher habe vorwiegend Homematic betrieben, aber meine Ladies "wir wollen was zum drehen, ääähh". Also testweise einen MAX HT+ gekauft.

Anlernen hat nach einiger Zeit des wikis und manuals auch geklappt. Aber zu folgendem Problem finde ich nichts.

Setzen von desiredTemperature klappt wunderbar. Aber das Setzten von boostDuration und boostValvePosition überhaupt nicht.

Hat jemand einen Tipp dazu.

Danke schon mal und ciao
walter

[Matthias Gehre]

Ist das ein normales Heizkörperthermostat oder ein "Heizkörperthermostat plus"?

[wkarl]

Hallo Matthias,

Es ist ein plus.

Ciao Walter

[Matthias Gehre]

Hast du einen MAX-Cube? Kannst du das Setzen boostDuration und boostValvePosition mit der offiziellen MAX Software
per Wireshark o.ä. mitschneiden?

[wkarl]

Die MAX HTs steuere ich über einen CUNO 868 an. Das Investment in einen Cube würde ich Mir gerne sparen.

Alternativen wie ich Dir die gewünschten Informationen liefern kann?

[Matthias Gehre]

Das Problem ist folgendes:
Für die normalen Heizkörperthermostate habe die benötigen Steuerbefehle herausgefunden, da ich deren Kommunikation mit der MAX! Software
mitschneiden konnte.
Ich besitze leider kein Heizkörperthermostat plus, kann daher nichts machen. Nur jemand anders mit Heizköperthermostat plus und MAX! Cube
kann da helfen.

Es wundert mich allerdings, dass das Protokoll bei den "plus" Thermostaten geändert wurde. Funktioniert denn das Setzen von desiredTemperature und ecoTemperature? Vielleicht ist da auch noch ein Bug im Code, ich teste das heute abend mal.

[Matthias Gehre]

Hab's noch mal getestet: Mit dem Heizkörperthermostat (ohne "plus") geht das Setzen von boostDuration.

[wkarl]

Hallo Matthias,

folgendes getestet und funktioniert:

desiredTemperature (Reading verändert)
decalcification (Reading unverändert)
auto/manu (Reading unverändert)
weekProfile
valveOffset (Reading unverändert, regelt nach)

und dies scheint nicht zu funktionieren

maxValveSetting (Reading unverändert)
boostDuration (Reading unverändert, bleibt bei 300s)
boostValveposition (Reading unverändert)
ecoTemperature (Reading unverändert)
groupid (Reading unverändert)
comfortTemperature (Reading unverändert)
maxValveSetting (Reading unverändert)
valveOffset (Reading unverändert, regelt auch nicht nach)

Zusätzlich taucht im Terminal in dem ich fhem starte hin und wieder folgendes auf.

Argument "No answer" isn't numeric in numeric lt (<) at /opt/fhem/FHEM/14_CUL_MAX.pm line 417.

Nachtrag: ist mir eben erst aufgefallen. Die Readings-Zeiten sind nicht synchron.
(siehe Anhang / see attachement)

Lass mich wissen was ich noch zum debuggen beitragen kann.
ciao walter

[John]

Hallo wkarl

 ich setzte auch mehrere Heatingtermostat+ ein und kann die von dir aufgeführten Probleme
 nicht bestätigen.
 
 Die hier beschriebenen Befehle werden korrekt zum Thermostat gesendet
 und auch die Rückmeldung ist erfolgreich.
             
Mann kann den Ablauf im Event Monitor gut verfolgen:

BoostDuration
 
<<1 Befehl wird an FHEM abgesetzt>>
2013-06-08 11:12:03 MAX HT.WOZI boostDuration 5

<<2 befehl wird von CUL versendet>>
2013-06-08 11:12:04 MAX HT.WOZI mode: auto
2013-06-08 11:12:04 MAX HT.WOZI battery: ok
2013-06-08 11:12:04 MAX HT.WOZI desiredTemperature: 17.0
2013-06-08 11:12:04 MAX HT.WOZI valveposition: 0
2013-06-08 11:12:04 MAX HT.WOZI 17.0 °C

<<3 Rückmeldung vom Ventil, ca. 1 Sek. später>>
2013-06-08 11:12:05 MAX HT.WOZI boostDuration: 5
2013-06-08 11:12:05 MAX HT.WOZI 17.0 °C


boostValveposition  
 
<<1 Befehl wird an FHEM abgesetzt>>
2013-06-08 11:19:03 MAX HT.WOZI boostValveposition 100

<<2 Befehl wird von CUL versendet>>
2013-06-08 11:20:07 MAX HT.WOZI mode: manual
2013-06-08 11:20:07 MAX HT.WOZI battery: ok
2013-06-08 11:20:07 MAX HT.WOZI desiredTemperature: 16.0
2013-06-08 11:20:07 MAX HT.WOZI valveposition: 0
2013-06-08 11:20:07 MAX HT.WOZI 16.0 °C

<<3 Bestätigung vom Ventil>>
2013-06-08 11:20:08 MAX HT.WOZI boostValveposition: 100
2013-06-08 11:20:08 MAX HT.WOZI 16.0 °C


Desired Temperature

desi auf ON gesetzt, damit wir MaxValveSetting testen können
2013-06-08 11:37:10 MAX HT.WOZI desiredTemperature on

<<2 Befehl wird von CUL versendet>>
2013-06-08 11:37:11 MAX HT.WOZI mode: manual
2013-06-08 11:37:11 MAX HT.WOZI battery: ok
2013-06-08 11:37:11 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:37:11 MAX HT.WOZI valveposition: 0
2013-06-08 11:37:11 MAX HT.WOZI 30.5 °C

es dauert 1.5 Min bis das Ventil den Befehl hörbar ausführt
danach
2013-06-08 11:39:35 MAX HT.WOZI battery: ok
2013-06-08 11:39:35 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:39:35 MAX HT.WOZI valveposition: 100
2013-06-08 11:39:35 MAX HT.WOZI temperature: 26.2
2013-06-08 11:39:35 MAX HT.WOZI 30.5 °C


MaxValveSetting
maxvalve setting auf 80

<<1 Befehl wird an FHEM abgesetzt>>
2013-06-08 11:41:09 MAX HT.WOZI maxValveSetting 80

<<2 Befehl wird von CUL versendet>>
2013-06-08 11:41:10 MAX HT.WOZI mode: manual
2013-06-08 11:41:10 MAX HT.WOZI battery: ok
2013-06-08 11:41:10 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:41:10 MAX HT.WOZI valveposition: 100
2013-06-08 11:41:10 MAX HT.WOZI 30.5 °C

<<3 Bestätigung vom Ventil>>
2013-06-08 11:41:11 MAX HT.WOZI maxValveSetting: 80
2013-06-08 11:41:11 MAX HT.WOZI 30.5 °C

Nach ca. 3 Minuten erfolgt hörbar die  Ausführung, ohne weitere Rückmeldung
im Event-Monitor.
Man muss etwas Geduld haben, die Reaktion am Ventil ist verzögert.

Die Readings werden offensichtlich mit dem Versenden eines Telegramms und dem Empfang gesetzt.


John

[wkarl]

Hallo John,

Danke für die Informationen. Das meine Situation hier, weiter zu untersuchen.

Nach einem set boostDuration sieht das bei mir so aus:

2013-06-08_17:59:05 Buero_HK boostDuration 15
2013-06-08_17:59:06 Buero_HK mode: manual
2013-06-08_17:59:06 Buero_HK battery: ok
2013-06-08_17:59:06 Buero_HK desiredTemperature: 8.5
2013-06-08_17:59:06 Buero_HK valveposition: 0
2013-06-08_17:59:06 Buero_HK 8.5 °C
2013-06-08_18:00:18 Buero_HK mode: manual
2013-06-08_18:00:18 Buero_HK battery: ok
2013-06-08_18:00:18 Buero_HK desiredTemperature: 8.5
2013-06-08_18:00:18 Buero_HK valveposition: 0
2013-06-08_18:00:18 Buero_HK temperature: 23.1
2013-06-08_18:00:18 Buero_HK 8.5 °C

Und zeitgleich läuft dies über den CUNO:

2013.06.08 17:59:06.830 1: CUNO_868: Z0E4E0202077F11F15A5F0001190011 -62.5
2013.06.08 18:00:18.160 1: CUNO_868: Z0F3B0460077F110000000019001100E7 -70.5

So wie es aussieht findet die Bestätigung seitens des HTs nicht statt.

Hierzu habe ich eine grundlegende Frage - mit welcher firmware muss ich den CUNO flashen. Ich habe CUNO2.hex in der Version 1.55 genommen.

Danke schon mal und ciao
walter

[Matthias Gehre]

Setze mal
  attr global verbose 5
im der fhem.cfg.

  Argument "No answer" isn't numeric in numeric lt (<) at /opt/fhem/FHEM/14_CUL_MAX.pm line 417.
scheint ein Problem der Kommunikation zwischen FHEM und CUNO zu sein.

[wkarl]

Hallo Matthias,

anbei die entsprechenden log Daten.

ciao walter

[wkarl]

Habe die log Dateien mit MultiTail entsprechend gefiltert. Der erste Teil ist ein boostDuration, der zweite ein desiredTemperature.

-------------------------------2013/06/09 07:14:51------------------------------
2013.06.09 07:14:59.073 5: CUL_MAX_BroadcastTime: payload 0d09074ebb
2013.06.09 07:15:02.295 5: CUL_MAX_Send: enqueuing 0e960012F15A5F077f1100900cff0
0
2013.06.09 07:15:02.296 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:02.310 5: CUNO_868 sending Zs0e960012F15A5F077f1100900cff00
2013.06.09 07:15:02.312 1: SW: Zs0e960012F15A5F077f1100900cff00
2013.06.09 07:15:02.798 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:03.301 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:03.513 5: CUL/RAW: /Z0E960202077F11F15A5F00011900201F
2013.06.09 07:15:03.513 1: CUNO_868: Z0E960202077F11F15A5F0001190020 -58.5
2013.06.09 07:15:03.514 5: CUNO_868 dispatch Z0E960202077F11F15A5F0001190020
2013.06.09 07:15:03.533 5: CUL_MAX_Parse: len 14, msgcnt 96, msgflag 02, msgType
Raw Ack, src 077f11, dst f15a5f, groupid 0, payload 01190020
2013.06.09 07:15:03.535 5: CUNO_MAX dispatch MAX,0,Ack,077f11,01190020
2013.06.09 07:15:03.542 5: MAX_Parse MAX,0,Ack,077f11,01190020
2013.06.09 07:15:03.543 5: MAX_Parse MAX,0,ThermostatState,077f11,190020
2013.06.09 07:15:04.096 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:04.597 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:05.100 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:05.603 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:05.603 2: CUL_MAX_SendQueueHandler: Missing ack from 077f11 for
 0e960012F15A5F077f1100900cff00
2013.06.09 07:15:05.604 5: Triggering CUNO_MAX (1 changes)
2013.06.09 07:15:05.610 5: Notify loop for CUNO_MAX packetsLost: 4437
-------------------------------2013/06/09 07:15:25------------------------------
2013.06.09 07:15:41.251 5: CUL_MAX_Send: enqueuing 0b970040F15A5F077f110066
2013.06.09 07:15:41.252 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:41.266 5: CUNO_868 sending Zs0b970040F15A5F077f110066
2013.06.09 07:15:41.268 1: SW: Zs0b970040F15A5F077f110066
2013.06.09 07:15:41.754 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:42.258 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:42.533 5: CUL/RAW: /Z0E970202077F11F15A5F00011900261C
2013.06.09 07:15:42.535 1: CUNO_868: Z0E970202077F11F15A5F0001190026 -60
2013.06.09 07:15:42.537 5: CUNO_868 dispatch Z0E970202077F11F15A5F0001190026
2013.06.09 07:15:42.540 5: CUL_MAX_Parse: len 14, msgcnt 97, msgflag 02, msgType
Raw Ack, src 077f11, dst f15a5f, groupid 0, payload 01190026
2013.06.09 07:15:42.542 5: CUNO_MAX dispatch MAX,0,Ack,077f11,01190026
2013.06.09 07:15:42.544 5: MAX_Parse MAX,0,Ack,077f11,01190026
2013.06.09 07:15:42.546 5: MAX_Parse MAX,0,ThermostatState,077f11,190026
2013.06.09 07:15:43.098 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:43.599 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:44.102 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:44.605 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 07:15:44.607 2: CUL_MAX_SendQueueHandler: Missing ack from 077f11 for
 0b970040F15A5F077f110066
2013.06.09 07:15:44.609 5: Triggering CUNO_MAX (1 changes)
2013.06.09 07:15:44.613 5: Notify loop for CUNO_MAX packetsLost: 4438

[wkarl]

Hallo Matthias,

mittlerweilen habe ich alle HTs rückgesetzt und neu angelernt. Nun kann ich nachvollziehbar boostDuration setzen. Jedoch werden die Readings nicht aktualisiert.
Im log fehlen immer noch die Antworten des HTs, so wie sie bei John zu sehen sind.

ciao
walter

[Matthias Gehre]

1. Teil: Hier wird das boostDuration Paket an das HT gesendet
2013.06.09 06:25:02.229 5: Cmd: >set Buero_HK boostDuration 15<
2013.06.09 06:25:02.232 5: CUL_MAX_Send: enqueuing 0e8c0012F15A5F077f1100700cff0
0
2013.06.09 06:25:02.232 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 06:25:02.234 1: SW: X
2013.06.09 06:25:02.245 5: CUL/RAW (ReadAnswer): 21  833

2013.06.09 06:25:02.246 5: needPreamble: 1, necessaryCredit: 112, credit10ms: 83
3
2013.06.09 06:25:02.247 5: CUNO_868 sending Zs0e8c0012F15A5F077f1100700cff00
2013.06.09 06:25:02.249 1: SW: Zs0e8c0012F15A5F077f1100700cff00

2. Teil: Hier kommt das Ack vom HT. Allerdings merkt FHEM nicht, dass wir auf dieses Ack warten
2013.06.09 06:25:03.416 5: CUL/RAW: /Z0E8C0202077F11F15A5F00011900221E
2013.06.09 06:25:03.416 1: CUNO_868: Z0E8C0202077F11F15A5F0001190022 -59
2013.06.09 06:25:03.416 5: CUNO_868 dispatch Z0E8C0202077F11F15A5F0001190022
2013.06.09 06:25:03.417 5: CUL_MAX_Parse: len 14, msgcnt 8C, msgflag 02, msgType
Raw Ack, src 077f11, dst f15a5f, groupid 0, payload 01190022
2013.06.09 06:25:03.417 5: CUNO_MAX dispatch MAX,0,Ack,077f11,01190022
2013.06.09 06:25:03.417 5: MAX_Parse MAX,0,Ack,077f11,01190022
2013.06.09 06:25:03.419 5: MAX_Parse MAX,0,ThermostatState,077f11,190022
2013.06.09 06:25:03.420 5: battery 0, rferror 0, panel 0, langateway 1, dstsetti
ng 1, mode 1, valveposition 0 %, desiredTemperature 17, until , curTemp

3. Teil: Nach dem Timeout meldet FHEM "Missing ack", obwohl das Ack ja eben kam
2013.06.09 06:25:04.038 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 06:25:04.540 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 06:25:05.043 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.06.09 06:25:05.384 2: CUL_MAX_SendQueueHandler: Missing ack from 077f11 for
 0e8c0012F15A5F077f1100700cff00

Der Fehler scheint um Zeile 254 in 14_CUL_MAX.pm aufzutreten.
  Dispatch($shash, "MAX,$isToMe,Ack,$src,$payload", {RAWMSG => $rmsg});
wird wohl noch aufgerufen (und produziert den Log-Eintrag "2013.06.09 06:25:03.417 5: MAX_Parse MAX,0,Ack,077f11,01190022")
Die Zeilen danach, insbesondere das if, welches zu
  Log $ll5, "Got matching ack";
führen sollte, wird nicht aufgerufen.
Vielleicht kannst du da ein paar Log's in den Code schreiben, alles ausgeben lassen
und mal schauen, was das sein kann,