FHEM Forum

FHEM - Hausautomations-Systeme => MAX => Thema gestartet von: wkarl am 01 Juni 2013, 13:10:53

Titel: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 01 Juni 2013, 13:10:53
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 03 Juni 2013, 10:47:40
Ist das ein normales Heizkörperthermostat oder ein "Heizkörperthermostat plus"?
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 04 Juni 2013, 18:38:15
Hallo Matthias,

Es ist ein plus.

Ciao Walter
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 05 Juni 2013, 07:57:30
Hast du einen MAX-Cube? Kannst du das Setzen boostDuration und boostValvePosition mit der offiziellen MAX Software
per Wireshark o.ä. mitschneiden?
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 05 Juni 2013, 16:02:42
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?
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 05 Juni 2013, 16:26:34
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.
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 05 Juni 2013, 20:43:53
Hab's noch mal getestet: Mit dem Heizkörperthermostat (ohne "plus") geht das Setzen von boostDuration.
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 08 Juni 2013, 08:38:26
Hallo Matthias,

folgendes getestet und funktioniert:
und dies scheint nicht zu funktionieren

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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: John am 08 Juni 2013, 12:40:29
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





Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 08 Juni 2013, 18:12:48
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 09 Juni 2013, 00:08:12
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.
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 09 Juni 2013, 06:39:58
Hallo Matthias,

anbei die entsprechenden log Daten.

ciao walter
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 09 Juni 2013, 07:20:06
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 09 Juni 2013, 09:27:10
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 10 Juni 2013, 10:18:58
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,
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 11 Juni 2013, 11:13:50
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 14 Juni 2013, 09:47:45
Probier mal mit der Datei im Anhang ein Log zu machen.
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 23 Juni 2013, 09:24:16
Hallo Matthias,

sorry, bin erst heute dazu gekommen die debugging Informationen zu erzeugen.

ciao walter
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 25 Juni 2013, 08:09:22
Hab einen Fix eingecheckt. Das Problem war, dass ein einer Stelle die Adresse nicht in Kleinbuchstaben konvertiert wurde und somit
ein Vergleich fehlschlug.
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: wkarl am 25 Juni 2013, 19:22:05
Hallo Matthias,

super - nach dem update werden die Daten richtig angezeigt.

Danke und ciao
walter
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: mgernoth am 26 Juni 2013, 21:28:31
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
Titel: Aw: boostduration & boostValvePosition greifen nicht
Beitrag von: Matthias Gehre am 28 Juni 2013, 19:51:29
Danke, hab einen Fix committed.