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