Folgende merkwürdige Log-Einträge mit aktueller CUL_V3.hex
Zitat2013.02.10 08:15:51 3: SW: Zs1152001112345605dc36002a243d09051803 (CUL)
2013.02.10 08:15:51 3: CUL: ? (0Zs1152001112345605dc36002a243d09051803 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.10 08:15:51 3: CUL: unknown message ? (0Zs1152001112345605dc36002a243d09051803 is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
2013.02.10 08:15:54 2: CUL_MAX_Resend: Missing ack from 05dc36 for 1152001112345605dc36002a243d09051803
2013.02.10 08:15:54 1: CUL_MAX_Resend: Giving up on that packet
Die 0 vor dem Z ist wohl das Problem bei "CUL: unknown message ?"
Gibt es eine Erklärung ?
Die Folgefehler sind klar, da ja tatsächlich nichts gesendet wurde.
was für eine Cul Firmware verwendest du und welches MAX SVN?
(Cul firmware ist gerade am mittwoch verändert worden ohne den Tag zu ändern, kannst ja pro forma einfach nen update machen)
ich verwende die Version die aktuell über das FHEM Update-Management vorliegt,
also aus dem Verzeichnis /opt/fhem/FHEM.
Kannst du per FHEM ein Update auf die neuste Firmware machen?
Ist der Fehler reproduzierbar? Immer? Spontan?
Ich bin gerade dabei mein System auf 6 Heizkörpertheromstate, teilweise mit Fensterkontakt auszubauen.
Gleichzeitig aktualisiere ich FHEM, sowie den CUL mit der aktuellsten Software.
So ist es nicht einfach die eigentliche Ursache bei Fehlern zu erkennen.
ZitatKannst du per FHEM ein Update auf die neuste Firmware machen?
Das habe ich gemacht und damit sind ja auch die beschriebenen Probleme aufgetaucht
ZitatIst der Fehler reproduzierbar? Immer? Spontan?
Nach den vielen neuen Problemen habe ich diese Link (http://forum.fhem.de/index.php?topic=10844.msg62382#msg62382)
CUL Version wieder verwendet, damit mein System wieder arbeitsfähig wird.
Den anfangs beschriebenen Fehler habe ich mit der "alten" Version noch nie gesehen.
Wenn mehr Zeit ist, werde ich es nochmals versuchen.
Weiterhin habe ich das Problem, dass teilweise kein ACK nach Setzen der desiredTemperature erhalten wird.
2013.02.10 10:01:01 3: SW: Zs0b53004012345605dc360064 (CUL)
2013.02.10 10:01:04 2: CUL_MAX_Resend: Missing ack from 05dc36 for 0b53004012345605dc360064
2013.02.10 10:01:04 1: CUL_MAX_Resend: Giving up on that packet
Zu schnelles Absetzen von Telegrammen scheint ein Problem zu sein.
Nach dem ersten Sendeversuch wird 3 Sekunden auf einen ACK gewartet. Nach dem Resend wird nicht mal eine Sekunde.
Ist das so gewollt ?
Resends sind deaktiviert, kann also sein, dass der Code da komisch aussieht.
Das Missing Ack bekomme ich manchmal, wenn ich schnell hintereinander (z.B. in einem Skript/der fhem.cfg)
zwei Thermostate anspreche. Ist das bei dir der Fall?
ZitatDas Missing Ack bekomme ich manchmal, wenn ich schnell hintereinander (z.B. in einem Skript/der fhem.cfg)
zwei Thermostate anspreche. Ist das bei dir der Fall?
Genau dies ist der Fall. Ich habe 2 Heizkörperthermostate in einem Raum, die über Heating_Control
praktisch gleichzeitig angesteuert werden.
In der aktuellsten Firmware warte ich etwas zwischen dem Senden von zwei Paketen.
Ich bekomme dann zwar immernoch für das erste Pakete "Missing Ack", aber anders als vorher
zeigen beide Pakete ihre Wirkung. Das "Missing Ack" kommt wohl daher, dass
wir gerade das zweite Paket senden, während wir das erste Ack empfangen sollten.
Damit bin ich immer noch nicht zufrieden. Ich werde wohl demnächste in FHEM
ein Scheduling einbauen, dass immer nur ein Paket sendet, und vor dem nächsten Paket auf
ein Ack wartet.
Da bin ich gespannt.
Ähnliches gibt es ja wohl schon für FS20 ala CUL_AddFS20Queue in 00_CUL.pm
Die MAX-Komponenten übernehme meist auch den Befehl, auch wenn der CUL keinen ACK erhält.