MaxCube: Zwischenstecker entfernen, danach "unsichtbarer" rferror?

Schnup · 04 November 2013, 16:11:10

Beim Max-Zwischenstecker am MaxCube habe ich festgestellt, dass offensichtlich keine Meldung verfügbar ist, wenn der ZW-Stecker aus der Steckdose entfernt wird. Eine Reaktion erfolgt erst nachdem ein Schaltbefehl an den ZW-Stecker gesendet wird:

- Die eQ3-Software meldet in so einem Fall einen Verbindungsfehler. Nach erneutem Einstecken wird der Zustand "Aus"
erkannt und der ZW lässt sich wieder bedienen, allerdings ist danach der AutoModus in der eQ3-Software gestört!

- Bei FHEM erfolgt keine Meldung, auch bei den Internals steht "rferror 0". Nach dem Einstecken lässt sich der ZW-Stecker aber
überhaupt nicht mehr schalten, auch nicht nach Shutdown und Neustart.

Workaround:
1. Wird der ZW-Stecker unter FHEM nicht mehr erkannt, kann man über die eQ3-Software einen Schaltbefehl absetzen,
danach wird das Gerät unter FHEM wieder erkannt.
2. Ist der AutoModus (Wochenprofil) gestört, lässt er sich manuell über den FHEM-Befehl
"set <Name> desiredTemperature auto >on/off<" wieder zurücksetzen.
Das Attribut "keepAuto 1" wird wohl im Moment noch nicht berücksichtigt!

Um das Verhalten besser zu erkennen habe ich die relevanten Werte aus L-Response (Device List) aufgelistet:
Normalbetrieb : Byte(5): 12h= 00010010b -> Answer_OK , NoError | Byte(6): 18h= 00011000b -> Mode Auto
ZW-Stecker entfernt : dito | dito
Befehl an Stecker : Byte(5): 1Eh= 00011110b -> NO_Answer , ERROR | dito
ZW wieder eingesteckt : Byte(5): 1Ah= 00011010b -> Answer_OK , error | Byte(6): 19h= 00011001b -> Mode Manual

Obwohl der "rfError" in der Deviceliste eingetragen ist, bleibt der Eintrag bei den Internals "0".
Da die Software über "answer" erkennt, ob der ZW-Stecker wieder angeschlossen ist, sollte dann nicht auch der "rfError" geprüft und ggf. wieder zurückgesetzt werden? Der Mode-Wert könnte dann auch, abhängig von "keepAuto", auf Mode Auto gesetzt werden.

Beim Versuch zu erkennen, ob der ZW-Stecker vorhanden ist, habe ich zuerst ein "WakeUp" gesendet.
Danach kommt auch sofort die Meldung "MAXLAN_Write: MAXLAN_ExpectAnswer: Error while waiting for answer S:",
aber auch hier wird der "rfError" nicht verändert bzw. angezeigt.
Ich bin mir auch nicht sicher, ob es sinnvoll den "rfError" zu verändern, eine globale Variable wäre da wohl besser. In der eQ3-Software wird dafür wohl ein "dirtyState" für jeden Raum(groupID) geführt.

Leider reichen meine Perl-Kenntnisse nicht aus, um herauszufinden wo die rfError Behandlung stolpert.

Jürgen

Tom_S · 04 November 2013, 18:38:30

hallo,

Obwohl der "rfError" in der Deviceliste eingetragen ist, bleibt der Eintrag bei den Internals "0".

meiner Meinung nach zeigt Internals das falsche Bit an (Bit 6 von Byte 6).
es müsste Bit 3 von Byte 5 sein.
Ist bei den Thermostaten auch so - klar, wird ja als gleiches Gerät erkannt.

mfg Tom_S

Matthias Gehre · 08 November 2013, 12:08:14

Zitat von: Schnup am 04 November 2013, 16:11:10
Um das Verhalten besser zu erkennen habe ich die relevanten Werte aus L-Response (Device List) aufgelistet:
Normalbetrieb : Byte(5): 12h= 00010010b -> Answer_OK , NoError | Byte(6): 18h= 00011000b -> Mode Auto
ZW-Stecker entfernt : dito | dito
Befehl an Stecker : Byte(5): 1Eh= 00011110b -> NO_Answer , ERROR | dito
ZW wieder eingesteckt : Byte(5): 1Ah= 00011010b -> Answer_OK , error | Byte(6): 19h= 00011001b -> Mode Manual

Obwohl der "rfError" in der Deviceliste eingetragen ist, bleibt der Eintrag bei den Internals "0".
Da die Software über "answer" erkennt, ob der ZW-Stecker wieder angeschlossen ist, sollte dann nicht auch der "rfError" geprüft und ggf. wieder zurückgesetzt werden? Der Mode-Wert könnte dann auch, abhängig von "keepAuto", auf Mode Auto gesetzt werden.

Beim Versuch zu erkennen, ob der ZW-Stecker vorhanden ist, habe ich zuerst ein "WakeUp" gesendet.
Danach kommt auch sofort die Meldung "MAXLAN_Write: MAXLAN_ExpectAnswer: Error while waiting for answer S:",
aber auch hier wird der "rfError" nicht verändert bzw. angezeigt.
Ich bin mir auch nicht sicher, ob es sinnvoll den "rfError" zu verändern, eine globale Variable wäre da wohl besser. In der eQ3-Software wird dafür wohl ein "dirtyState" für jeden Raum(groupID) geführt.

Leider reichen meine Perl-Kenntnisse nicht aus, um herauszufinden wo die rfError Behandlung stolpert.

Jürgen

Danke für die ausführliche Erklärung. Es wird mir noch nicht ganz klar, was genau passiert. Könntest du einen Auszug aus dem Log posten (mit verbose 5) für:
1. Senden eines Schaltbefehls, während der Stecker ganz normal in der Steckdose steckt
2. Senden eines Schaltbefehls, nachdem der Stecker aus der Steckdose gezogen wurde
3. Senden eines Schaltbefehls, nachdem der Stecker wieder in die Steckdose gesteckt wurde

So wie ich dich verstanden haben, bewirkt 3. kein Schalten, obwohl das wieder funktionieren sollte.

Außerdem: Hast du die Möglichkeit, per Wireshark die Kommunikation der MAX! Software mit dem Cube mitzuschneiden? So können wir sehen, was die MAX! Software macht.

Schnup · 08 November 2013, 13:41:47

Gibt es eine Anleitung einen WireShark einzurichten?

Matthias Gehre · 08 November 2013, 14:29:55

Zitat von: Schnup am 08 November 2013, 13:41:47
Gibt es eine Anleitung einen WireShark einzurichten?

Die Software dazu gibts hier: http://www.wireshark.org/
Anleitungen im Netz. Falls du es nicht hinkriegst, ist nicht schlimm. Ist auch etwas komplizierter.

Schnup · 08 November 2013, 19:24:26

Hallo Matthias,

es hat etwas länger gedauert, weil ich erst die Erfahrung machen musste, dass ein Zw-Stecker auch nach dem Entfernen aus der Steckdose noch für ca. 30 Sekunden durch das interne Netzteil versorgt wird!

ZitatSo wie ich dich verstanden haben, bewirkt 3. kein Schalten, obwohl das wieder funktionieren sollte.

Ja, und auch nicht nach einem Neustart!

Anbei zwei Log-Dateien, wobei der Name des Zw-Steckers "ZW1_074da1" (addr 074da1) ist.
Zur besseren Übersicht habe ich die Aktionen in der Datei durch "***" gekennzeichnet:

*** 1. 15:57:12 Normaler Schaltbefehl mit eingestecktem Zwischenstecker
*** 2.2 15:58:20 Schaltbefehl bei entferntem Zwischenstecker
*** 2.3 15:58:21 Noch keinen Verbindungsfehler erkannt: rferror 0, answer 0,
*** 2.4 15:59:02 Verbindungsfehler erkannt: rferror 1, answer 1,
*** 3.2 16:03:20 Schaltbefehl bei erneut eingestecktem Zwischenstecker
*** 3.3 16:03:21 ab hier nur noch "rferror 1", aber das Gerät ist ansprechbar: "answer 0"

Hinweis:
Wie bereits gesagt, bei den Internals bleibt der "rfError 0", nur der Mode wird auf "Manual" gesetzt.

Zur Information habe ich die gleichen Versuche auch einmal mit "wakeUp" gemacht und eine zweite Log-Datei beigefügt.
Allerdings musste ich erkennen, das die Meldung "Error while waiting for answer S:" auch bereits gesendet wird, wenn der Zw-Stecker ganz normal funktioniert!

Jürgen

Matthias Gehre · 13 November 2013, 16:22:35

Tritt das gleiche Problem auf, wenn du den MAXLAN ohne "ondemand" betreibst? (D.h. fhem.cfg ändern, neustarten, testen?)

Schnup · 13 November 2013, 17:20:46

Ja, der Fehler verhält sich genau so. Auch hier ist der ZW-Stecker nicht mehr ansprechbar.

Schnup · 22 November 2013, 14:31:57

Habe das Verhalten, wenn der Zwischenstecker entfernt wird, mit den neuen MAXLAN-Readings aufgelistet.
Die jeweiligen Veränderungen sind in der Tabelle hervorgehoben:

AKTION | ZEIT | MODE |SOLL |MAXLAN_|MAXLAN_ |MAXLAN_ |
| | |WERT |error |errInCom|isAnswer|
Status nach Neustart | 19:13:13 | auto | on | 0 | | 0 |
Zwischenstecker entfernt | 19:15:16 | auto | on | 0 | | 0 |
Befehl OFF, ohne Stecker | 19:17:22 | auto | on | >1< |>WakeUp<| >1< |
Stecker wieder eingesteckt| 19:20:00 |>manual< |>off<| 1 | WakeUp | >0< |
Befehl ON , mit Stecker | 19:20:25 | manual | off | 1 | WakeUp | 0 |

Erkenntnis
1. Es wird nicht erkannt, wenn der Stecker entfernt wird.
2. Ein Fehler wird erst erkannt, wenn ein nicht vorhandener Zw-Stecker angesprochen wird.
Im Moment bleibt der Fehler unter FHEM dauerhaft bestehen!

3. Das Wiedereinstecken wird sehr wohl erkannt und "MAXLAN_isAnswer" wird mit "0" zurückgegeben.
Befindet sich der Stecker im Fehlermodus "MAXLAN_error = 1", dann könnte der Fehler jetzt zurückgesetzt werden:
if MAXLAN_error = 1 AND MAXLAN_isAnswer = 0 then MAXLAN_error = 0

4. Beim Wiedereinstecken werden auch die readings "Mode = manual" und "desiredTemperature = off" gesetzt.
Wenn dieser Status bereits vor dem Entfernen des Steckers gesetzt war, ist hier allerdings auch keine
Veränderung erkennbar.

Schnup

Matthias Gehre · 14 Dezember 2013, 22:50:27

Okey, jetzt wissen wir schon mal, dass FHEM bei MAXLAN_error = 1 irgendetwas tun muss, damit danach die Kommunikation mit dem Cube wieder funktioniert. Das ist der erste Teil.

Jetzt müssen wir noch herausfinden, was FHEM dann tun (= an den Cube senden) muss. Dafür musst du mit Wireshark mitschneiden, was die offizielle Max-Software nach so einem Fehler an den Cube sendet.

Tom_S · 30 Dezember 2013, 15:12:43

Ich habe leider keinen Zwischenstecker, aber einen Thermostat bei dem jetzt mal "MAXLAN error 1" aufgetreten ist.

MAXLAN_error      1         2013-12-30 14:54:37
MAXLAN_errorInCommand   TimeInformation      2013-12-27 14:54:37
MAXLAN_initialized   1           2013-12-30 14:54:37
MAXLAN_isAnswer      0         2013-12-30 14:54:37
MAXLAN_valid      1         2013-12-30 14:54:37

Ich habe mit der MAX! Software die Temperature auf 20°C gesetzt.
Die WireShark Datei habe ich angehängt

MAXLAN_error      0         2013-12-30 15:03:54
MAXLAN_errorInCommand            2013-12-30 15:03:54
MAXLAN_initialized   1           2013-12-30 15:03:54
MAXLAN_isAnswer      0         2013-12-30 15:03:54
MAXLAN_valid      1         2013-12-30 15:03:54

danach ist der Fehler weg und der Thermostat läst sich mit FHEM wieder steuern.

Die IP von meinem Cube ist die 192.168.115.90

ich hoffe es kann jemand etwas damit anfangen.

mfg
Tom_S

Matthias Gehre · 30 Dezember 2013, 15:58:47

Hallo,

das hilft!
Der Befehl zum Zurücksetzten des Fehlers ist "r:01,base64(addr)"

Probiere mal, ob nach der Veränderung

Code Auswählen

diff --git a/FHEM/00_MAXLAN.pm b/FHEM/00_MAXLAN.pm
index 3ed3aa0..63c2d96 100755
--- a/FHEM/00_MAXLAN.pm
+++ b/FHEM/00_MAXLAN.pm
@@ -667,6 +667,9 @@ MAXLAN_Parse($$)
         readingsBulkUpdate($dhash, "MAXLAN_valid", $valid);
         readingsBulkUpdate($dhash, "MAXLAN_isAnswer", $answer);
         readingsEndUpdate($dhash, 1);
+        if($error) {
+          MAXLAN_Write($hash,"r:01,".encode_base64(pack("H*",$addr),""), "S:");
+        }
       }
 
       $bindata=substr($bindata,$len+1); #+1 because the len field is not counted

FHEM den Fehler automatisch resettet.

Tom_S · 30 Dezember 2013, 17:53:25

hallo Matthias,

hat ein bischen gedauert bis ich den Fehler reproduzieren konnte.
Es funktioniert. Der Fehler wird gelöscht. Das kannst du so einbauen.

mfg Tom_S