rPI+ Max + Protokollfehler

Begonnen von John, 04 Februar 2013, 23:25:18

Vorheriges Thema - Nächstes Thema

John

Immer wenn die FHEM.cfg neu eingelesen wird erhalte ich nachfolgende Einträge in der Log-Datei.
Ich verwenden eine Raspberry Pi + COC + CUL. Die Max Komponenten sind auf dem CUL aufgeschalten.
Manchmal wird dabei sogar ein neues Device erzeugt, das nicht existiert.

Danach läuft allerdings alles ohne erkennbaren Fehler.

Gibt es hierzu eine Erklärung ?


2013.02.04 06:49:02 1: Including fhem.cfg
2013.02.04 06:49:02 3: telnetPort: port 7072 opened
2013.02.04 06:49:02 3: WEB: port 8083 opened
2013.02.04 06:49:02 3: WEBphone: port 8084 opened
2013.02.04 06:49:02 3: WEBtablet: port 8085 opened
2013.02.04 06:49:02 3: Opening COC device /dev/ttyAMA0
2013.02.04 06:49:02 3: Setting COC baudrate to 38400
2013.02.04 06:49:02 3: COC device opened
2013.02.04 06:49:02 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2013.02.04 06:49:02 3: Opening CUL device /dev/ttyACM0
2013.02.04 06:49:02 3: Setting CUL baudrate to 38400
2013.02.04 06:49:02 3: CUL device opened
2013.02.04 06:49:02 3: CUL: Possible commands: BCFiAZEGMRTVWXefmltux
2013.02.04 06:49:02 2: Setting CUL fhtid from Z0000Z1D841F0630019D4012345600101786000460063CCE0000000019052000A231Z1D001018851F0630019D4012345600101785810202063CCE123456000119000000Z1D841F0630019D4012345600101786000460063CCE0000000019052000A231Z1D001018851F0630019D4012345600101785810202063C to 0000
2013.02.04 06:49:02 3: SW: Ax (CUL)
2013.02.04 06:49:02 3: SW: X21
Zr (CUL)
2013.02.04 06:49:02 2: Switched CUL rfmode to MAX
2013.02.04 06:49:03 3: SW: Za123456 (CUL)
2013.02.04 06:49:03 3: CUL_MAX_BroadcastTime: payload 0d04063183
2013.02.04 06:49:03 1: Including ./log/fhem.save
2013.02.04 06:49:04 3: CUL: CE12345600010119
2013.02.04 06:49:04 3: CUL: unknown message CE12345600010119
2013.02.04 06:49:04 3: CUL: Z1D2F841F0630019D4012345600101786000460063CCE0000000019052000 -121
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 1F
2013.02.04 06:49:04 3: CUL: Z03560010 -62
2013.02.04 06:49:04 3: CUL: unknown message Z03560010
2013.02.04 06:49:04 3: CUL: Z1D0630019D4012345600101785810202063CCE12345600011900202F841F -71
2013.02.04 06:49:04 3: CUL: Z019D -42
2013.02.04 06:49:04 3: CUL: unknown message Z019D
2013.02.04 06:49:04 3: CUL: Z1D5600101786000460063CCE0000000019052000A2318356001018851F06 -50
2013.02.04 06:49:04 3: CUL: Z1D4012345600101785810202063CCE1234560000011900202F841F063001 -123.5
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 34
2013.02.04 06:49:04 3: CUL: Z12345600101786000460063CCE000000001905 -58
2013.02.04 06:49:04 2: Device want's to be re-paired to 000460, not to us
2013.02.04 06:49:04 3: CUL: Z1D318356001018851F0630019D4012345600101785810202063CCE123456 -74
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 56
2013.02.04 06:49:04 3: CUL: Z1900202F841F0630019D4012345600101786000460063CCE0000 -74
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 2F
2013.02.04 06:49:04 3: CUL: Z19052000A2318356001018851F0630019D401234560010178581 -73
2013.02.04 06:49:04 2: Device want's to be re-paired to 560010, not to us
2013.02.04 06:49:04 3: CUL: Z063CCE12345656 -74
2013.02.04 06:49:04 3: CUL: unknown message Z063CCE12345656
2013.02.04 06:49:04 3: CUL: Z1900202F841F0630019D4012345600101786000460063CCE0000 -74
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 2F
2013.02.04 06:49:04 3: CUL: Z19052000A2318356001018851F0630019D401234560010178581 -73
2013.02.04 06:49:04 2: Device want's to be re-paired to 560010, not to us
2013.02.04 06:49:04 3: CUL: Z063CCE12345600 -73.5
2013.02.04 06:49:04 3: CUL: unknown message Z063CCE12345600
2013.02.04 06:49:04 3: CUL: Z00 -58
2013.02.04 06:49:04 3: CUL: unknown message Z00
2013.02.04 06:49:04 3: CUL: Z041F063001 -123.5
2013.02.04 06:49:04 3: CUL: unknown message Z041F063001
2013.02.04 06:49:04 3: CUL: Z12345600101786000460063CCE000000001905 -58


2013.02.04 06:49:04 2: Device want's to be re-paired to 000460, not to us
2013.02.04 06:49:04 3: CUL: Z1D318356001018851F0630019D4012345600101785810202063CCE123434 -31
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 56
2013.02.04 06:49:04 3: CUL: Z0119 -74
2013.02.04 06:49:04 3: CUL: unknown message Z0119
2013.02.04 06:49:04 3: CUL: Z1D841F0630019D4012345600101786000460063CCE0000000019052000A2 -49.5
2013.02.04 06:49:04 2: CUL_MAX_Parse: Got unhandled message type 06

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

C. Zimmermann

Was passiert wenn du per putty den Pi rebootest?

Habe fast das Gefühl, dass du das gleiche Problem wie ich hast: Link

John

Es passiert nach einem Reboot dasselbe wie zuvor beschrieben.

Ich habe versucht über minicom manuell die Befehle an den CUL abzusetzen, die normalerweise FHEM absetzt.

Zur Darstellung
#    ein von mir hier eingefügerter Kommentar
->   Ausgabe vom CUL



# minicom aufrufen
minicom -D /dev/ttyACM0 -b 38400

#Version abfragen (Step 1)
V
-> V 1.52 CUL868

# Befehle abfragen (Step 2)
?
-> B C F i A Z E G M R T V W X e f m l t u x

# enable Data reporting : ab hier kommen massenweise Telegramme rein (Step 3)
X21

# Set the "own" housecode to HHHH (Step 4)
T010000

# disable asksin mode (Step 5)
Ax

# enable Data reporting (Step 6)
X21

# vermutlich Freigabe zum Empfang von MAX-Nachrichten (leider nicht in http://culfw.de/commandref.htmt dokumentiert) (Step 7)
# hier hört der Spuk auf, nun kommen nur noch Telegramme die eindeutig MAX-Komponenten zugeordnet werden können
Zr




Wir erhalten somit während der Initialisierungsphase massenhaft Telegramme  von Step 3 bis Step 6,
die nichts mit MAX zu tun haben.

Gibt es wohl eine geschicktere Initialisierungssequenz ?
Ich bin leider keine Experte im Umgang mit der Firmware von CUL.


CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Die erste komische Zeile ist ja schon
Setting CUL fhtid from Z0000Z1D841F0630019D4012345600101786000460063CCE0000000019052000A231Z1D001018851F0630019D4012345600101785810202063CCE123456000119000000Z1D841F0630019D4012345600101786000460063CCE0000000019052000A231Z1D001018851F0630019D4012345600101785810202063C
anscheinend sendet der CUL eine
Z....
Zeile obwohl der MAX Modus noch gar nicht aktiviert ist.
Solche "Z...." Zeilen werden jedoch nur in aus rf_moritz_task() und Unterroutinen
gesendet und nur wenn moritz_on = 1 ist.

In clib/rf_moritz.c wird
uint8_t moritz_on = 0;
als globale Variable initialisiert.
Und moritz_on wird nur auf 1 gesetzt, falls
man "Zr" an den CUL sendet.

Ich wundere mich also, wieso trotzdem rf_moritz_task
Z... sendet, obwohl doch moritz_on bis zu "Zr" auf 0 gesetzt sein müsste.

John

Ich habs gefunden und hoffe auch gelöst:

moritz_on wird durch den bisherigen Ablauf nie mehr zurückgesetzt.
Das wäre aber nach dem neuen Einlesen der FHEM.cfg nötig, um den betrachteten Fehler zu beseitigen.
Es reicht ein  "Fx" zum CUL zu senden (undefinierter Befehl) , damit moritz_on wieder auf 0 gesetzt wird
und somit den Moritz-Modus verlässt.
Dies muss bei der Initialisierung vom CUL geschehen, also so früh wie möglich.
Aber nur dann, wenn der CUL auch die Z-Befehle versteht.
Kann man vielleicht auch noch schöner kodieren, bin ein Perl-Anfänger.

Ich habe in 00_CUL.pm folgende Zeile hinzugefügt.

sub
CUL_DoInit($)
{
...
  Log 3, "$name: Possible commands: " . $hash->{CMDS};
  if ( index( $cmds,"Z")>= 0) {  CUL_SimpleWrite($hash,"Zx") }  # john, disable moritz mode
...


Die Log-Datei sieht nun gut aus, es erscheint kein Fehler mehr.


2013.02.05 23:55:31 1: Including fhem.cfg
2013.02.05 23:55:32 3: telnetPort: port 7072 opened
2013.02.05 23:55:32 3: WEB: port 8083 opened
2013.02.05 23:55:32 3: WEBphone: port 8084 opened
2013.02.05 23:55:32 3: WEBtablet: port 8085 opened
2013.02.05 23:55:33 3: Opening COC device /dev/ttyAMA0
2013.02.05 23:55:33 3: Setting COC baudrate to 38400
2013.02.05 23:55:33 3: COC device opened
2013.02.05 23:55:33 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2013.02.05 23:55:33 3: Opening CUL device /dev/ttyACM0
2013.02.05 23:55:33 3: Setting CUL baudrate to 38400
2013.02.05 23:55:33 3: CUL device opened
2013.02.05 23:55:33 3: CUL: Possible commands: BCFiAZEGMRTVWXefmltux
2013.02.05 23:55:33 3: SW: Ax (CUL)
2013.02.05 23:55:33 3: SW: X21
Zr (CUL)
2013.02.05 23:55:33 2: Switched CUL rfmode to MAX
2013.02.05 23:55:34 3: SW: Za123456 (CUL)
2013.02.05 23:55:35 3: CUL_MAX_BroadcastTime: payload 0d051737a3
2013.02.05 23:55:35 1: Including ./log/fhem.save
2013.02.05 23:55:35 1: usb create starting
2013.02.05 23:55:36 1: usb create end
2013.02.05 23:55:36 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2631 2013-02-02 13:57:30Z rudolfkoenig $, pid 4676)

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Sehr gute Beobachtung!

Allerdings würde ich den Fix an einer anderen Stelle machen, und zwar
in der culfw in der Behandlung von "X21". Dieser Befehl führt nämlich dazu,
dass eine neue Konfiguration auf den CC1101 geladen wird,
welche die Konfiguration für MAX überschreibt. Also muss
an der Stelle auch moritz_on auf Null gesetzt werden.

Ich hab das bei mir lokal gebaut. Kannst du die Firmware aus dem Anhang testen?

C. Zimmermann

Hallo Matthias,

meinem oben beschriebenen Problem hilft es. Nach dem Flashen deiner COC.hex hab ich nach dem Einlesen der FHEM.cfg keine Probleme mehr. Vielen Dank!

Matthias Gehre


John

Hallo Matthias,

auch CUL funktioniert nun nach dem Flashen mit CUL_V3.hex bestens.

Vielen Dank für die schnelle Reaktion.
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP