Hi,
ich habe bei einem meiner MAX-Thermostate einen externen Temperatursensor (WS555) der alle 5-10min die Raumtemp meldet. Per Notify sende ich die Temp zum Max-Thermostat. Das funktioniert auch gut, das Thermostat akzeptiert diese und zeigt sie auch als eigene an.
Problem aber: seitdem meldet das Max-Thermostat ständig rf-error sobald es selbst etwas an meinen CUL meldet. Zb. am Stellrad die Soll-Temperatur ändern, Valveposition geändert etc. Dann blinkt mal lang - mal weniger lange- das kleine Antennensymbol auf dem Thermostat.
Ich schätze, das Thermostat wandert selbst ständig in ein LOVF rein, aber warum?? Das Max-eigene WandThermostat sendet doch auch ständig die Temperatur zum Heizkörperthermostat, und da wird wohl alles sauber funktionieren..
Ich sehe hier 2 Ansätze:
1. ich melde die Temperatur zu oft. Einen noch längeren Zeitraum schraubt aber die Trägheit des Systems nach oben, entweder wird es zu spät warm, oder zu spät die Heizung abgeregelt und ich habe Sauna.
2. an der Implementierung im Modul ist noch etwas nicht ganz korrekt
3. benötigt man bei diesem fake-Anwendungsfall kein ACK des CUL und kann dies im Thermostat abschalten? Gibts dafür einen Parameter das man bei einer NAchricht kein ACK haben möchte? Wie machts das Original Max-Wandthermostat?
Hier mal das Notify zum Temp an das Thermostat übermitteln:
WZ_Temperatur:temperature.* {
my $heizung = "WZ_Heizung";
my $wandthermostat = "WZ_Wandthermostat";
my $temperature = %EVTPART1;
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
if($desiredTemp) {
Log 3, "set $wandthermostat fake $heizung $desiredTemp $temperature";
fhem("set $wandthermostat fake $heizung $desiredTemp $temperature");
} else {
Log 3, "Konnte desired-temperature aus $heizung nicht auslesen!";
}
}
Also der Cube kann 33 Pakete pro Stunde senden bis zum LOVF, daher nehme ich an, dass es beiden Thermostaten auch so ist.
Allerdings zeigen die irgendwas an, wenn sie im LOVF sind. Dazu stand was im Handbuch der Thermostate.
zu deinen Varianten:
1. Probier doch mal aus, ob das den Fehler beseitigt
2. Möglich, aber dazu brauchen wir eben einen Anhaltspunkt. Also erst mal 1.) ausprobieren.
3. Wenn du ein Wandthermostat hast, dann kannst du mit dem CUL mitschneiden, was da zwischen Wandthermostat und Heizthermostat passiert.
M.E. machen wir das genauso wie die beiden, aber du kannst das noch mal verifizieren.
4. Die Argumente von "fake" werden noch nicht besonders gut validiert. Insbesondere darf das zweite Argument im Moment nicht über 25.5 sein.
So, mal einige Varianten durchprobiert.
Sobald ich das Thermostat mit dem Fake Wandthermostat paire, bekomme ich rf-errors (blinkendes Ant.symbol). Und auch immer dann wieder wenn ich am Thermostat die Temp ändere.
Ich denke das Thermostat fragt irgendetwas vom Wandthermostat aktiv ab und entweder bleibt die Antwort aus, oder ein Ack fehlt worauf das MAX-Modul noch nicht reagiert.
Nachtrag: gleich nach dem pairen, ca 30sek später habe ich den rf-error. Bis dahin habe ich noch kein Fake-Temp Signal gesendet.
Sobald ich zb. ein "set WZ_Wandthermostat fake WZ_Heizung 19.5 19.7" sende, ist der rf-error weg.
Stelle ich am HeizkThermostat nun manuell um, zb auf 20°C um, so beginnt es wieder zu blinken -> rf-error.
Ich denke das MAX-Modul muss ggf. als Type WallMountedThermostat antworten und nicht als Type Cube
Kommen den irgendwelche Pakete vom Heizkörper an die Adresse des "fake" Wandthermostats?
Ja:
2013.01.30 18:56:28 5: CUL/RAW: /Z0B3204400179EB4567890067F1
2013.01.30 18:56:28 5: CUL: Z0B3204400179EB4567890067 -81.5
2013.01.30 18:56:28 5: CUL dispatch Z0B3204400179EB4567890067
2013.01.30 18:56:28 5: CUL_MAX_Parse: len 11, msgcnt 32, msgflag 04, msgTypeRaw SetTemperature, src 0179eb, dst 456789, groupid 0, payload 67
2013.01.30 18:56:28 5: Unhandled message SetTemperature
2013.01.30 18:56:31 5: CUL/RAW: /Z0B3304400179EB4567890067EF
2013.01.30 18:56:31 5: CUL: Z0B3304400179EB4567890067 -82.5
2013.01.30 18:56:31 5: CUL dispatch Z0B3304400179EB4567890067
2013.01.30 18:56:31 5: CUL_MAX_Parse: len 11, msgcnt 33, msgflag 04, msgTypeRaw SetTemperature, src 0179eb, dst 456789, groupid 0, payload 67
2013.01.30 18:56:31 5: Unhandled message SetTemperature
Sobald ich ein Fake sende, hört das blinken auf
Ich nehme mal an, wir müsste darauf ein Ack Paket senden, damit das Thermostat zufrieden ist.
Ist aber eine etwas kompliziertere Sache, da das in culfw gemacht werden muss.
Zitat von: Matthias Gehre schrieb am Mi, 30 Januar 2013 19:49Ist aber eine etwas kompliziertere Sache, da das in culfw gemacht werden muss.
:( hmmmmmm, da kann ich leider nicht unterstützen..... ich hoffe mal das du es irgendwie hinbekommst....
Ich hab das testweise mal in die angehängte culfw eingebaut.
Nach dem Start vom FHEM
bitte per
set CUL0 raw Zw456789
aktivieren. (Falls 456789 die Adresse vom fake Wandthermostat ist, ansonsten
anpassen)
Dieser Befehl sollte die culfw anweisen, auf alle SetTemperature Pakete an Adresse
456789 mit einem Ack zu antworten. Zur Kontrolle tauchen die gesendeten Acks
auch in FHEM in CUL_MAX_Parse auf.
Bitte testen!
Hallo Matthias,
ich komm leider nicht vor dem WE dazu zu testen. Melde mich.
ich bin noch am testen....
Als Zwischeninfo, folgende LogInfos finde ich:Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 572.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
2013.02.13 09:32:35 2: Invalid WallThermostatState packet
Use of uninitialized value $desiredTemperature in bitwise and (&) at ./FHEM/10_MAX.pm line 599.
Mir hilft nur ein Log auf verbose 5.
Bekommst du immernoch rferror mit der Anleitung aus meiner letzten Antwort?
Hab jetzt mal verbose 5 gestartet und die Temp am Thermostat (id: 0179eb) manuell verstellt:
WZ_Wandthermostat ist das Fake-Wandthermostat mit der ID 456789. U.a fällt mir auch die desiredTemp von 0.0 auf.
Das vorheriuge Problem, des missingAck nach dem Verstellen der Temp am Thermostat ist mit deinem Patch nicht mehr aufgetreten. Kannst du also so einbauen..?? Ohne den "set CUL0 raw Zw456789" BEfehl?
2013.02.14 05:46:45 5: CUL/RAW: /Z0B1000024567890179EB000000
Z0B1004400179EB456789006004
2013.02.14 05:46:45 5: CUL: Z0B1000024567890179EB0000 -74
2013.02.14 05:46:45 5: CUL dispatch Z0B1000024567890179EB0000
2013.02.14 05:46:45 5: CUL_MAX_Parse: len 11, msgcnt 10, msgflag 00, msgTypeRaw Ack, src 456789, dst 0179eb, groupid 0, payload 00
2013.02.14 05:46:45 5: CULMAX0 dispatch MAX,0,Ack,456789,00
2013.02.14 05:46:45 5: MAX_Parse MAX,0,Ack,456789,00
2013.02.14 05:46:45 5: MAX_Parse MAX,0,WallThermostatState,456789,
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 572.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
Use of uninitialized value $args[0] in length at ./FHEM/10_MAX.pm line 575.
2013.02.14 05:46:45 2: Invalid WallThermostatState packet
Use of uninitialized value $desiredTemperature in bitwise and (&) at ./FHEM/10_MAX.pm line 599.
2013.02.14 05:46:45 5: desiredTemperature 0
2013.02.14 05:46:45 5: Triggering WZ_Wandthermostat (2 changes)
2013.02.14 05:46:45 5: Notify loop for WZ_Wandthermostat desiredTemperature: 0.0
2013.02.14 05:46:45 5: CUL: Z0B1004400179EB4567890060 -72
2013.02.14 05:46:45 5: CUL dispatch Z0B1004400179EB4567890060
2013.02.14 05:46:45 5: CUL_MAX_Parse: len 11, msgcnt 10, msgflag 04, msgTypeRaw SetTemperature, src 0179eb, dst 456789, groupid 0, payload 60
2013.02.14 05:46:45 5: Unhandled message SetTemperature
Ist morgen im Update dabei.
muss ich die cul-fw auch updaten?
Wenn ja, Ist da dann schon der Patch für das Ack eines externen Tempsensors dran?
Jupp, siehe ChangeLog Thread.