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
Ist das ein normales Heizkörperthermostat oder ein "Heizkörperthermostat plus"?
Hallo Matthias,
Es ist ein plus.
Ciao Walter
Hast du einen MAX-Cube? Kannst du das Setzen boostDuration und boostValvePosition mit der offiziellen MAX Software
per Wireshark o.ä. mitschneiden?
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?
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.
Hab's noch mal getestet: Mit dem Heizkörperthermostat (ohne "plus") geht das Setzen von boostDuration.
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.
ZitatArgument "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
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
Hallo John,
Danke für die Informationen. Das meine Situation hier, weiter zu untersuchen.
Nach einem
set boostDuration sieht das bei mir so aus:
Zitat2013-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:
Zitat2013.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
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.
Hallo Matthias,
anbei die entsprechenden log Daten.
ciao walter
Habe die log Dateien mit MultiTail entsprechend gefiltert. Der erste Teil ist ein boostDuration, der zweite ein desiredTemperature.
Zitat-------------------------------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
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
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,
Hallo Matthias,
Dein Vertrauen in meine Perl Kenntnis ehrt mich, aber das was ich in fhem an Perl code umsetzen klaue ich mir aus anderen Beispielen zusammen und ein bisschen Hilfe von Google ist auch dabei.
Wenn ich mir das Modul ansehe muss ich leider eingestehen, dass ich keinen Durchblick habe. Ich helfe gerne beim debuggen, aber das geforderte coding überfordert mich.
Lass mich wissen wie ich trotzdem helfen kann.
ciao walter
Probier mal mit der Datei im Anhang ein Log zu machen.
Hallo Matthias,
sorry, bin erst heute dazu gekommen die debugging Informationen zu erzeugen.
ciao walter
Hab einen Fix eingecheckt. Das Problem war, dass ein einer Stelle die Adresse nicht in Kleinbuchstaben konvertiert wurde und somit
ein Vergleich fehlschlug.
Hallo Matthias,
super - nach dem update werden die Daten richtig angezeigt.
Danke und ciao
walter
Hallo Matthias,
Zitat von: Matthias Gehre schrieb am Di, 25 Juni 2013 08:09Hab einen Fix eingecheckt. Das Problem war, dass ein einer Stelle die Adresse nicht in Kleinbuchstaben konvertiert wurde und somit ein Vergleich fehlschlug.
kann es sein, dass das lc() in Zeile 175 (fake{SC,WT}-Behandlung) dort nicht gebraucht wird?
fhem> set CUL_MAX fakeSC Thermostat_AZ 1
No MAX device with address thermostat_az
Wenn ich das lc() wieder rausmache, dann geht es.
Gruß
Michael
Danke, hab einen Fix committed.