Fensterkontakte - Keine stündliche Statusmeldung

Begonnen von Talkabout, 26 November 2015, 08:56:52

Vorheriges Thema - Nächstes Thema

Talkabout

Hallo Matthias,

vielleicht könntest Du einen Blick in diesen Thread werfen:

http://forum.fhem.de/index.php/topic,44680.0.html

Vielleicht kannst Du aufklären, warum MAX Fensterkontakte mal einen stündlichen Status senden und mal nicht.

Danke!

Gruss

Talkabout

#1
Hallo,

nachdem das Thema heute mal wieder aktuell war, habe ich bei mir mal das Log durchforstet mit der Hoffnung einen Hinweis darauf zu finden, warum FHEM keine stündliche Meldung meiner Fensterkontakte bekommt. Und siehe da, es gibt tatsächlich was.

Hin und wieder habe ich Meldungen der Art
2015-11-26_22:35:28 SCC868SlowRf UNKNOWNCODE 0B8806300AA5261234560010FD
2015.11.26 22:35:28 2: SCC868SlowRf: unknown message 0B8806300AA5261234560010FD

Ich habe mir die Nachricht angeschaut und versucht anhand der Adressen meiner Fensterkontakte rauszufinden, ob diese auf einen passt. Ich glaube auch den richtigen gefunden zu haben:
define SZFensterkontakt01 MAX ShutterContact 0aa526
Die Adresse des FKs kommt so auch in der Nachricht vor (0AA526), daher gehe ich davon aus, dass bei mir das MAX-Modul mit dieser Nachricht nichts anfangen kann. Ich hoffe hier, dass der Mathias mitliest und vielleicht einen entscheidenden Hinweis liefern kann. Unter Umständen hat das wieder mit der Tatsache zu tun, dass ich als CUL einen SCC verwende, der ja schon damals beim Anlernen Probleme bereitet hat. Bis auf die stündliche Meldung funktionieren die FKs übrigens problemlos.

Danke!

Gruss

Edit: ich habe viele weitere Nachrichten gefunden, die ebenfalls auf andere meiner FKs passen. Damit ist das wohl der Grund, warum bei mir die stündliche Meldung nicht ankommt, obwohl sie offensichtlich gesendet wird.

Talkabout

#2
Hallo,

weitere Details zu dem Problem:

Ich habe mal in der Datei 14_CUL_MAX.pm in Zeile 279 die Ausgabe etwas erweitert und mir die Message ausgeben lassen, die dort geparst wird:
2015.11.26 23:57:31 3: CUL_MAX_Parse: msg Z0BB800021234560555760000, len 11, msgcnt B8, msgflag 00, msgTypeRaw Ack, src 123456, dst 055576, groupid 0, payload 00
2015-11-26_23:57:31 SCC868SlowRf UNKNOWNCODE 0BB8063005557612345600102C
2015.11.26 23:57:31 2: SCC868SlowRf: unknown message 0BB8063005557612345600102C

Wie man sieht ist dies eine andere Message als das, was danach als "unknown message" deklariert wird. Scheinbar schickt der Fensterkontakt ein Ack, welches aber vom Modul nicht beantwortet wird, da dieses ja auf kein Ack wartet. Was ich an dieser Stelle noch nicht verstehe ist, warum der CULMAX eine andere Nachricht erhält als die, die FHEM gerade aufzulösen versucht...

Gruss

Edit: falscher Ansatz, die von mir ausgegebene Nachricht ist ein Ack, welches an den Fensterkontakt geschickt wird.

Talkabout

Hallo,

nochmal ein letzter Status für heute:

Es scheint so zu sein, als würden meine Fensterkontakte die stündliche Meldung ohne ein vorangestelltes "Z" an FHEM senden. In FHEM (00_CUL.pm) werden MAX Nachrichten über ein "Z" am Anfang der Nachricht interpretiert. Dieses "Z" kommt auch brav bei allen Nachrichten, die beim Statuswechsel vom Fensterkontakt gesendet werden. Bei der stündlichen Meldung allerdings fehlt dieses "Z". Dies ist der Grund warum FHEM die Nachricht nicht zuordnen kann und als "Unknown message" deklariert. Ich habe mal in der 00_CUL.pm in Zeile 917 mal ein Log eingebaut, welches mir bei einer nicht-erkannten Nachricht eine Meldung im Log ausgibt, mit folgendem Ergebnis:
2015.11.27 00:44:42 3: fn: 0, len: 26, msg: 0B8605300554C512345600101D
2015-11-27_00:44:42 SCC868SlowRf UNKNOWNCODE 0B8605300554C512345600101D
2015.11.27 00:44:42 2: SCC868SlowRf: unknown message 0B8605300554C512345600101D

Man sieht hier sehr schön, dass die Eigenschaft "fn"="0" ist, wo eigentlich "Z" stehen müsste. Ich habe keine Ahnung warum das "Z" nicht mitkommt und wüsste auch nicht, wo ich noch ansetzen könnte. Wäre dankbar für einen Tip.

Danke!

Gruss

gero

Mit welcher Firmware betreibst du den SCC? Ist das die Original CUL-Firmware? Wenn ja, welche Version?

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

chris1284

ZitatSCC868SlowRf

dein scc läuft aber nicht wie der name sagt im slowrf oder?
dein scc sollte im rfmode MAX sein wenn du MAX nutzt

Talkabout

Zitat von: gero am 27 November 2015, 06:09:26
Mit welcher Firmware betreibst du den SCC? Ist das die Original CUL-Firmware? Wenn ja, welche Version?

Gruß,
Gero
Bei mir läuft die original CUL Firmware in der Version 1.63 (V 1.63 CSM868)

Gruss

Talkabout

Zitat von: chris1284 am 27 November 2015, 06:29:33
dein scc läuft aber nicht wie der name sagt im slowrf oder?
dein scc sollte im rfmode MAX sein wenn du MAX nutzt
Ich habe 4 SCCs übereinander gestapelt und der SCCSlowRf ist der unterste, daher wird die Fehlermeldung ausgegeben wenn auch dieses Modul die Annahme der Nachricht verweigert, deswegen steht er da. Wenn mein MAX CUL mit SlowRf laufen würde, würde genau gar nichts gehen :)

Gruss

Talkabout

Hallo,

habe heute noch die culfw-Firmware meines SCCs aktualisiert, der sich damit auf der Version 1.65 befindet. Trotzdem bleiben die Fehlermeldungen bestehen und die stündliche Meldung der FKs in FHEM bleibt aus.

Gruss

gero

Ich kenne mich mit den SCCs leider überhaupt nicht aus. Aber ich denke, dass dort das Problem zu suchen ist.
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Talkabout

Zitat von: gero am 27 November 2015, 18:31:04
Ich kenne mich mit den SCCs leider überhaupt nicht aus. Aber ich denke, dass dort das Problem zu suchen ist.
Ja, die Vermutung habe ich auch, allerdings komme ich da mit meinen Analysen gerade nicht weiter. Ich hoffe der Matthias schaut hier mal vorbei.

Gruss

JoWiemann

Hallo,

das Problem besteht auch mit einem CUL mit CULFW V 1.57b CUL868 bei einem MAX Fensterkontakt. Sieht als eher nach einem Firmwareprobleme der MAX, oder nach einer nicht 100% Umsetzung des Protokolls aus.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Talkabout

Zitat von: JoWiemann am 27 November 2015, 18:37:54
Hallo,

das Problem besteht auch mit einem CUL mit CULFW V 1.57b CUL868 bei einem MAX Fensterkontakt. Sieht als eher nach einem Firmwareprobleme der MAX, oder nach einer nicht 100% Umsetzung des Protokolls aus.

Grüße Jörg
Danke für die Info. Wie sieht es mit der Firmware 1.65 aus, zeigt der CUL da das selbe Verhalten?

Talkabout

Hier noch die Ausgabe mit Verbose-Level 5:

Funktionierender Block:

2015.11.27 18:34:15 5: CUL/RAW: /***Z0F00
2015.11.27 18:34:15 5: CUL/RAW: ***Z0F00/04600B2A
2015.11.27 18:34:15 5: CUL/RAW: ***Z0F0004600B2A/FE000000
2015.11.27 18:34:15 5: CUL/RAW: ***Z0F0004600B2AFE000000/00390422
2015.11.27 18:34:15 5: CUL/RAW: ***Z0F0004600B2AFE00000000390422/00AB3E
2015.11.27 18:34:15 5: SCCIT dispatch ***Z0F0004600B2AFE0000000039042200AB3E
2015.11.27 18:34:15 5: SCC868SlowRf dispatch **Z0F0004600B2AFE0000000039042200AB3E
2015.11.27 18:34:15 5: SCCHomeMatic dispatch *Z0F0004600B2AFE0000000039042200AB3E
2015.11.27 18:34:15 4: CUL_Parse: SCCMAX Z0F0004600B2AFE0000000039042200AB3E -43
2015.11.27 18:34:15 5: SCCMAX dispatch Z0F0004600B2AFE0000000039042200AB
2015.11.27 18:34:15 5: CUL_MAX_Parse: len 15, msgcnt 00, msgflag 04, msgTypeRaw ThermostatState, src 0b2afe, dst 000000, groupid 0, payload 39042200AB
2015.11.27 18:34:15 5: CUL_MAX_Parse: rssi: -43
2015.11.27 18:34:15 5: CULMAX0 dispatch MAX,0,ThermostatState,0b2afe,39042200AB
2015.11.27 18:34:15 5: battery 0, rferror 0, panel 1, langateway 1, dstsetting 1, mode 1, valveposition 4 %, desiredTemperature 17, until , curTemp 17.1


2 niicht-funktionierende Blöcke:

2015.11.27 18:31:22 5: CUL/RAW: /***Z0B46
2015.11.27 18:31:22 5: CUL/RAW: ***Z0B46/00021234
2015.11.27 18:31:22 5: CUL/RAW: ***Z0B4600021234/560A800F
2015.11.27 18:31:22 5: CUL/RAW: ***Z0B4600021234560A800F/000000
2015.11.27 18:31:22 5: SCCIT dispatch ***Z0B4600021234560A800F000000
2015.11.27 18:31:22 5: SCC868SlowRf dispatch **Z0B4600021234560A800F000000
2015.11.27 18:31:22 5: SCCHomeMatic dispatch *Z0B4600021234560A800F000000
2015.11.27 18:31:22 4: CUL_Parse: SCCMAX Z0B4600021234560A800F000000 -74
2015.11.27 18:31:22 5: SCCMAX dispatch Z0B4600021234560A800F0000
2015.11.27 18:31:22 5: CUL_MAX_Parse: len 11, msgcnt 46, msgflag 00, msgTypeRaw Ack, src 123456, dst 0a800f, groupid 0, payload 00
2015.11.27 18:31:22 5: CUL/RAW: /*0B4606300A800F123456001025
2015.11.27 18:31:22 5: SCCIT dispatch *0B4606300A800F123456001025
2015.11.27 18:31:22 4: CUL_Parse: SCC868SlowRf 0B4606300A800F123456001025
2015.11.27 18:31:22 5: Triggering SCC868SlowRf (1 changes)
2015.11.27 18:31:22 5: Notify loop for SCC868SlowRf UNKNOWNCODE 0B4606300A800F123456001025
2015.11.27 18:31:22 5: Notify from Device: SCC868SlowRf recieved
2015-11-27_18:31:22 SCC868SlowRf UNKNOWNCODE 0B4606300A800F123456001025
2015.11.27 18:31:22 2: SCC868SlowRf: unknown message 0B4606300A800F123456001025


2015.11.27 18:35:29 5: CUL/RAW: /***Z0B8A
2015.11.27 18:35:29 5: CUL/RAW: ***Z0B8A/00021234
2015.11.27 18:35:29 5: CUL/RAW: ***Z0B8A00021234/560AA526
2015.11.27 18:35:29 5: CUL/RAW: ***Z0B8A00021234560AA526/000000
2015.11.27 18:35:29 5: SCCIT dispatch ***Z0B8A00021234560AA526000000
2015.11.27 18:35:29 5: SCC868SlowRf dispatch **Z0B8A00021234560AA526000000
2015.11.27 18:35:29 5: SCCHomeMatic dispatch *Z0B8A00021234560AA526000000
2015.11.27 18:35:29 4: CUL_Parse: SCCMAX Z0B8A00021234560AA526000000 -74
2015.11.27 18:35:29 5: SCCMAX dispatch Z0B8A00021234560AA5260000
2015.11.27 18:35:29 5: CUL_MAX_Parse: len 11, msgcnt 8A, msgflag 00, msgTypeRaw Ack, src 123456, dst 0aa526, groupid 0, payload 00
2015.11.27 18:35:29 5: CUL/RAW: /*0B8A06300AA526123456001001
2015.11.27 18:35:29 5: SCCIT dispatch *0B8A06300AA526123456001001
2015.11.27 18:35:29 4: CUL_Parse: SCC868SlowRf 0B8A06300AA526123456001001
2015.11.27 18:35:29 5: Triggering SCC868SlowRf (1 changes)
2015.11.27 18:35:29 5: Notify loop for SCC868SlowRf UNKNOWNCODE 0B8A06300AA526123456001001
2015.11.27 18:35:29 5: Notify from Device: SCC868SlowRf recieved
2015-11-27_18:35:29 SCC868SlowRf UNKNOWNCODE 0B8A06300AA526123456001001
2015.11.27 18:35:29 2: SCC868SlowRf: unknown message 0B8A06300AA526123456001001

Timmi

Bei mir mit einem original CUL und Firmaware 1.61,  http://culfw.de/culfw.html bleiben die Statusmeldungen ebenfalls aus !

Gruß
Tim

Talkabout

Zitat von: Timmi am 27 November 2015, 19:25:22
Bei mir mit einem original CUL und Firmaware 1.61,  http://culfw.de/culfw.html bleiben die Statusmeldungen ebenfalls aus !

Gruß
Tim
Kannst Du bitte mal in Deinem Log nachschauen ob Du, so wie ich, "UNKNOWN MESSAGES" bekommst. Wenn ja, dann prüf bitte mal nach, ob die Adresse Deiner Fensterkontakte in diesen Nachrichten erscheinen. Sie müssten an der 9. Stelle der Nachricht beginnen.

Gruss

Wzut

Org CUL868 mit V1.60 , alle FKs (V1.0 und V1.3) ok
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Talkabout

Zitat von: Wzut am 27 November 2015, 20:34:47
Org CUL868 mit V1.60 , alle FKs (V1.0 und V1.3) ok
Danke für die Rückmeldung. Habe meinen SCC auf Version 1.60 geflashed, leider immer noch das selbe Verhalten.

Gruss

Edit: meine FKs haben die Firmware 1.4. Kann jemand bestätigen, dass die stündlichen Meldungen auch mit dieser Firmware bei FHEM ankommen?

gero

Ich habe zumindest einen FK mit Firmware 1.4, der bei mir funktioniert. Allerdings verwende ich die Firmware 1.65.
Die Nachricht, die bei dir ohne führendes Z kommt und in einer UNKNOWN MESSAGE landet, ist tatsächlich eine Status-Nachricht vom FK. Ich habe nochmal in die Firmware gesehen und meiner Meinung nach wird das Z in jedem Fall gesendet.
Wo und warum es verloren geht, ist mir noch nicht klar.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Talkabout

Zitat von: gero am 27 November 2015, 22:34:43
Ich habe zumindest einen FK mit Firmware 1.4, der bei mir funktioniert. Allerdings verwende ich die Firmware 1.65.
Die Nachricht, die bei dir ohne führendes Z kommt und in einer UNKNOWN MESSAGE landet, ist tatsächlich eine Status-Nachricht vom FK. Ich habe nochmal in die Firmware gesehen und meiner Meinung nach wird das Z in jedem Fall gesendet.
Wo und warum es verloren geht, ist mir noch nicht klar.

Gruß,
Gero
Wieso bist Du der Meinung, dass das Z mit gesendet wird? Im FHEM Log, das ich oben gepostet habe, sieht man ja die RAW Messages. Bei den funktionierenden Nachrichten ist das Z zu sehen, bei der nicht-funktionierenden ist es nicht da. Kennst Du dich mit dem Firmware-Code aus?

Gruss

gero

Ich kenne zumindest den MAX-Teil der Firmware ziemlich gut. Und aus dem kommt keine Nachricht ohne führendes Z raus.
Wieviele SCCs hast du gestapelt?
Hast du schonmal versucht nur den MAX SCC anzuschließen?
Wird der SCC, den du für MAX verwendest, zwischendurch auch für andere Systeme verwendet/umgeschaltet?
Bist du dir sicher, dass die Schnittstelle ttyAMA0 nicht noch anderweitig im System verwendet wird?

Entschuldige die dummen Fragen, aber um das Problem zu lösen, brauchen wir neue Ideen.
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Talkabout

Zitat von: gero am 27 November 2015, 23:05:20
Ich kenne zumindest den MAX-Teil der Firmware ziemlich gut. Und aus dem kommt keine Nachricht ohne führendes Z raus.
Wieviele SCCs hast du gestapelt?
Hast du schonmal versucht nur den MAX SCC anzuschließen?
Wird der SCC, den du für MAX verwendest, zwischendurch auch für andere Systeme verwendet/umgeschaltet?
Bist du dir sicher, dass die Schnittstelle ttyAMA0 nicht noch anderweitig im System verwendet wird?

Entschuldige die dummen Fragen, aber um das Problem zu lösen, brauchen wir neue Ideen.
Ich finde es ja schon super, dass sich jemand, der die Firmware einigermaßen kennt, meines Problems annimmt :)

Ich versuche die Fragen zu beantworten:

ich habe 4 SCCs gestapelt, in dieser Reihenfolge:

SCCIT (Intertechno)
SCC868SlowRf (868)
SCCHomeMatic (Homematic)
SCCMAX (Max)

Ich habe mal alle anderen 868 Empfänger entfernt und nur den SCCIT und den MAX aktiviert => keine Besserung

Der SCC für Max wird für nichts anderes verwendet.

Die Schnittstelle ttyAMA0 wird soweit mir bekannt für nichts anderes mehr verwendet. Es ist ja auch so, dass alles andere funktioniert, nur die Status-Meldung des FKs nicht. Es wäre sehr komisch, wenn es ein grundsätzliches Problem gäbe, dieses sich aber nur in dieser einen Message wieder spiegeln würde.

Wie funktioniert denn die Firmware grundsätzlich? Ist es so, dass dieses "Z" von der Firmware vorangestellt wird oder kommt die Nachricht so schon vom FK?

Gruss

Talkabout

NEUE ERKENNTNIS:

Ich habe jetzt mal die Reihenfolge meiner SCCs geändert:

SCCMAX
SCCIT
SCC868SlowRf
SCCHomeMatic

Jetzt werden die Nachrichten korrekt interpretiert. Lediglich der SCCIT läuft nicht, ich kann damit nichts schalten. Aber das Problem scheint die Reihenfolge zu sein. Vielleicht kannst Du damit was anfangen um mal schauen, ob die Firmware da voraussetzt, dass der MAX CUL immer an erster Stelle steht.

Gruss

gero

Das Z wird von der Firmware erzeugt. Bei Empfang einer Nachricht wird zuerst geprüft, ob ein ACK gesendet werden muss. Ist dies der Fall, wird es gesendet und die gesendete ACK Nachricht ebenfalls über die serielle Schnittstelle an fhem geschickt. Danach wird die ursprünglich empfangene Nachricht ebenfalls an fhem geschickt. Und an dieser Stelle sehe ich keine Möglichkeit, dass das Z nicht geschickt wird.

Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

gero

Vielleicht findet sich noch jemand, der mit den SCCs Erfahrung hat. Ich verwende nur den Original-CUL.
Falls nicht, kann ich mir das voraussichtlich erst übernächste Woche genauer ansehen.
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Talkabout

Zitat von: gero am 27 November 2015, 23:43:13
Vielleicht findet sich noch jemand, der mit den SCCs Erfahrung hat. Ich verwende nur den Original-CUL.
Falls nicht, kann ich mir das voraussichtlich erst übernächste Woche genauer ansehen.
Ok, trotzdem danke für die Mühe!

Gruss

Talkabout

#26
Zitat von: gero am 27 November 2015, 23:43:13
Vielleicht findet sich noch jemand, der mit den SCCs Erfahrung hat. Ich verwende nur den Original-CUL.
Falls nicht, kann ich mir das voraussichtlich erst übernächste Woche genauer ansehen.
Noch ein bisschen weiter getestet. Es ist so, dass sobald ich einen SCC mit rfmode MAX definiere, der Intertechno SCC nicht mehr sendet. Weiterhin ist es so, dass wenn ich den MAX SCC nicht an erster Stelle definiere, er die Nachrichten der Fensterkontakte nicht korrekt interpretieren kann. Es scheint also 2 Probleme zu geben:

1. der rfmode MAX funktioniert nur dann 100%ig korrekt an SCCs, wenn er sich an erster Stelle (ganz unten) im Stack befindet
2. der rfmode MAX scheint das Senden von Intertechno Nachrichten zu stören, sobald er sich im Stack vor dem Intertechno SCC befindet

Es wäre toll wenn sich das jemand anschauen könnte, der sich mit dem Bereich für MAX der CUL-Firmware auskennt.

Danke!

Gruss

Edit: beim 2. Punkt ist das nicht MAX spezifisch. Der Intertechno SCC muss ganz unten liegen, sonst funktioniert das Senden nicht.

Timmi

Ich bekomme keine "UNKNOWN MESSAGES", und nur bei einem Alarm steht bei mir in Log :

MAX_1094ae battery: ok
MAX_1094ae onoff: 1
MAX_1094ae opened
MAX_1094ae RSSI: -52

Gruß
Tim

gero

Hast schon mal versucht den FK auf Werkseinstellung zurück zusetzen und neu zu pairen? Das hat bei mir geholfen, als ein FK ein ähnliches Verhalten zeigte.
Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Timmi

Ja, habe ich schon mehrmals zurückgesetzt und wieder gapairt .

Gruß
Tim

Matthias Gehre

Ich erinnere mich nicht mehr genau, aber das könnte die Ack Nachricht sein, die der CULMAX als Antwort für den Fensterkontakt erzeugt. Könnte sein, dass diese Antwort auch an FHEM geliefert
wird. Müsste man nochmal im culfw code nachschauen.

Talkabout

Zitat von: Matthias Gehre am 09 Dezember 2015, 00:27:40
Ich erinnere mich nicht mehr genau, aber das könnte die Ack Nachricht sein, die der CULMAX als Antwort für den Fensterkontakt erzeugt. Könnte sein, dass diese Antwort auch an FHEM geliefert
wird. Müsste man nochmal im culfw code nachschauen.
Hallo Matthias,

ich habe Deine Antwort erst jetzt gelesen, aber da ich mich des Problems wieder annehmen will, wäre Deine Hilfe sehr erwünscht :)

Die grundsätzliche Problematik ist Dir denke ich klar: Mein SCC im rfmode MAX empfängt die stündlichen Meldungen der Fensterkontakte nicht, wenn er sich nicht ganz unten im Stack der SCCs befindet. Die Fehlermeldung im Log sieht so aus:

SCCMAX UNKNOWNCODE 0BA206300554C5123456001018
2015.12.18 19:17:21 2: SCCMAX: unknown message 0BA206300554C5123456001018


wie man sieht ist die Nachricht an sich korrekt, es handelt sich hierbei um eine Meldung vom FK zum CUL mit ID "123456". Allerdings fehlt am Anfang das "Z", was auch der Grund ist, warum die Nachricht vom MAX-Modul nicht interpretiert werden kann. Da ich glaube, dass das Problem bereits in der Firmware liegt, und ich mich mit dieser genau gar nicht auskenne, hoffe ich auf einen Tip von Dir, wo dieser Prefix verloren gehen kann.

Danke!

Gruss

Talkabout

Ich habe not etwas weiter analyisert...

Wenn ich in fhem.pl in der Funktion "Dispatch" mal alle Nachrichten logge, bekomme ich folgende Ausgabe:

2015.12.18 19:31:25 3: received raw message: STACKABLE_CC : *Z0B5000021234560A800F000000
2015.12.18 19:31:25 3: received raw message: CUL_MAX : Z0B5000021234560A800F0000
2015.12.18 19:31:25 3: received raw message: STACKABLE_CC : *0B5006300A800F1234560010F7
2015-12-18_19:31:25 SCCMAX UNKNOWNCODE 0B5006300A800F1234560010F7
2015.12.18 19:31:25 2: SCCMAX: unknown message 0B5006300A800F1234560010F7


Die erste Nachricht (wird vermutlich ein Ack sein) kommt korrekt an. Dann kommt sofort eine 2. Nachricht rein, die aber bereits ohne das vorangestellte "Z" daher kommt. Es scheint also wirklich so zu sein, als würde das "Z" in der Firmware "verloren" gehen. Vielleicht hilft das beim Analysieren.

Gruss

Talkabout

Hallo,

das Problem bei mir besteht weiterhin. Ich denke, dass dieses auch bei anderen Leuten auftreten wird, wenn Stackable Transceivers verwendet werden. Da im rfmode Homematic,SlowRf(868) alles korrekt funktioniert, scheint es irgendwie mit MAX und SlowRf(433) zusammen zu hängen. Vielleicht schafft es ein Maintainer der culfw sich das mal anzuschauen.

Danke!

Gruss