Setzen weekProfile für mehrere Tage gleichzeitig fehlerhaft?

Begonnen von Adam, 17 März 2013, 20:02:46

Vorheriges Thema - Nächstes Thema

Adam

Hallo mit der neuen 10_MAX Version Revision 2910 kann ich per CUBE keine WeekProfile mit mehreren Tagen gleichzeitig senden.

Ich erhalte immer folgende Fehlermeldung:

2013.03.17 19:53:44 5: Cmd: >set MAX_TH_AZ weekProfile Sat 14.0,09:00,19.5,12:05,17.0,16:00,20.0,20:00,15.0,00:00 Sun 15.0,09:00,19.5,12:05,17.0,16:00,20.0,20:00,15.0,00:00<
2013.03.17 19:53:44 5: MAXLAN_SimpleWrite:  s:AADxAAAABBhiAD8=
2013.03.17 19:53:47 1: MAXLAN_ReadSingleResponse: timeout while reading from socket, disconnecting
2013.03.17 19:53:47 5: MAXLAN_Disconnect
2013.03.17 19:53:47 1: MAXLAN_ExpectAnswer: Error while waiting for answer S:
2013.03.17 19:53:47 5: MAX_LAN dispatch MAX,1,AckWakeUp,041862,31
2013.03.17 19:53:47 5: MAX_Parse MAX,1,AckWakeUp,041862,31
2013.03.17 19:53:47 5: Triggering MAX_TH_AZ (1 changes)
2013.03.17 19:53:47 5: Notify loop for MAX_TH_AZ 20.0 °C
2013.03.17 19:53:47 5: New Temperature part for 0: 386c4e9144c050f03c0045204520452045204520452045204520
2013.03.17 19:53:47 3: Opening MAX_LAN device 192.168.0.156:62910
2013.03.17 19:53:47 3: MAX_LAN device opened

Habt Ihr die gleichen Probleme?
Wenn ich die ältere Version (kann ich leider nicht mehr im File erkennen welche das ist)
funktioniert das noch, dann ist das keepAuto aber nicht dabei.

Adam

Adam

Das Setzen eines einzelnen Tages funktioniert und sieht im Log so aus:

2013.03.17 20:05:06 5: Cmd: >set MAX_TH_AZ weekProfile Sat 14.0,09:00,19.5,12:05,17.0,16:00,20.0,20:00,15.0,00:00<
2013.03.17 20:05:06 5: New Temperature part for 0: 386c4e9144c050f03c0045204520452045204520452045204520
2013.03.17 20:05:06 5: MAXLAN_SimpleWrite:  s:AAAQAAAABBhiAAA4bE6RRMBQ8DwARSBFIA==
2013.03.17 20:05:06 5: Msg S:20,0,31
2013.03.17 20:05:06 5: MAXLAN_Parse: dutycyle 32, freememoryslot 31
2013.03.17 20:05:06 5: MAX_LAN dispatch MAX,1,AckConfigWeekProfile,041862,0,0,386c4e9144c050f03c0045204520
2013.03.17 20:05:06 5: MAX_Parse MAX,1,AckConfigWeekProfile,041862,0,0,386c4e9144c050f03c0045204520
2013.03.17 20:05:06 5: Triggering MAX_TH_AZ (22 changes)
2013.03.17 20:05:06 5: Notify loop for MAX_TH_AZ weekprofile-0-Sat-time: 00:00-09:00  /  09:00-12:05  /  12:05-16:00  /  16:00-20:00  /  20:00-00:00
2013.03.17 20:05:06 5: New weekProfile: 386c4e9144c050f03c00452045203060346c38783c84409045203c6c4e9144c050f03c00452045203060346c38783c84409045203c6c4e9144c050f03c00452045204520452045204520452045203c6c4e9144c050f03c00452045203060346c38783c84409045203c6c4e9144c050f03c00452045203060346c38783c84409045203c6c4e9144c050f03c00452045203060346c38783c84409045203c6c4e9144c050f03c00452045203060346c38783c8440904520

Adam

Hat niemand die gleichen Probleme?
Könnt Ihr mit der letzten MAX Version Weekprofile für mehrere Tage gleichzeitig setzen?
Bei mir geht das immer noch nicht?

pet22

Leider funktioniert das Wochenprofil auch bei mir nicht perfekt:
* Debian Squeeze
* Cube über PowerLan verbunden (2 Stockwerke vom Server entfernt, könnte evtl. Meldungen wie 'MAXLAN_ReadSingleResponse: timeout while reading from socket, disconnecting' erklären)
* 2 * HT+, 1 * WT+ 'associate' mit 1 * HT
* FHEM auf aktuellem Stand

Momentaner Workaround: der erste Tag vom weekProfile verbleibt auf den alten Werten, daher wir er mit einem 2. 'set ...' nochmals gesendet.

Anbei ein Log vom vergangenen Wochenende. So ab Zeile 462 beginnt der interessante Teil.

Ohne Wirkung: maxValveSetting bei HT+

Vielen Dank!

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Ich frage mich, ob das an dem Wakeup liegt. Vielleicht kommt der erste Tag des Weekprofiles zu früh nach dem Wakup und wir müssten eine Sekunden oder so warten.

pet22

Ich habe mal heute einen Wireshark Trace der gleichen Schalt-Sequenze gemacht. So richtig sicher bin ich mir nicht, aber es scheint ein Bug/ Feature des Cube's zu sein.
Also besser abwarten, was eQ-3 noch so an Updates bringt.

Zwei Schönheitsfehler sind bei mir noch vorhanden:

1. Log (3)-Meldung: MAX: Invalid value 6.66666666666667 for READING valveOffset. Forcing to 0 -- irgendwo scheint noch ein 'int()' zu fehlen, aber ich komme nicht dahinter, wo im Perl Script
2. maxValveSetting zeigt bei meinen HT+ keine Wirkung

Vielen Dank und Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Probiert mal ob das Ändern von Zeile 439 in 10_MAX.pm von
  MAX_WakeUp($hash) if( @args > 2 );
in
  #MAX_WakeUp($hash) if( @args > 2 );
das Problem behebt.

pet22


Zeile 439 in 10_MAX.pm auskommentiert - Problem behoben. Es lassen sich nun beliebige Wochenprofile im Rahmen der
verfügbaren Credits setzen.


Zitat1. Log (3)-Meldung: MAX: Invalid value 6.66666666666667 for READING valveOffset. Forcing to 0 -- irgendwo scheint noch ein 'int()' zu fehlen, aber ich komme nicht dahinter, wo im Perl Script
2. maxValveSetting zeigt bei meinen HT+ keine Wirkung

betrachte ich im Moment als 'last priority'.

Danke und Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Adam

Ja auch bei mir funktioniert es, wenn das WAKEUP auskommentiert ist!

pet22


Kleiner Nachteil dieser Lösung:

wenn zuviele set-Commands zum gleichen Zeitpunkt abgesetzt werden, häufen sich nun die Meldungen

> MAXLAN_Parse: Command was discarded

Es war wesentlich toleranter mit WakeUp

Danke und Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs