STACKABLE_CC und FS20 ST, Probleme

[cebulon]

Hallo,

ich heiße Gerd und bin ein Newbie bezüglich FHEM, betrieben auf einem RASPI-2 mit dem aktuellen Betriebssystem. Nachdem ich unter FHEM eine Reihe von DECT-Schaltsteckdosen über die Fritzbox zum Laufen bringen konnte, habe ich den Rechner mit dem SCC (stackable CC1101) von Busware ergänzt, um zusätzlich erworbene HomeMatic-Komponenten zu betreiben (Bewegungsmeter, Fensterkontakte, Drehgriff-Schalter, 3-Kanal-Kontaktabfrage, Schaltsteckdose, Funkgong, 4-Kanal-Fernbedienung). Die Installation des SCC habe ich nach der Anleitung von Busware vorgenommen. Alles läuft schon seit einer Weile programmgesteuert zu meiner Zufriedenheit, auch die FHEM-Alarmfunktion.

Einen weiteren SCC habe ich gleich mitbestellt, um eine Reihe alter FS-20 Komponenten wiederzuverwenden. Überrascht wurde ich zunächst dadurch, daß sich wohl über die autocreate-Funktion 2 Temperatur/Feuchtesensoren (die sich im Garten befinden und Teil eines Wettercomputers sind) mit schöner Kurvendarstellung im GUI auftauchten,. Dasselbe passierte, als ich die Tasten der alten Fernbedienung/Zentrale FS20 ZE betätigte. Die Kommunikation im SlowRF-Mode über den 2. SCC scheint also grundsätzlich zu funktionieren.

Das gilt über FHEM leider NICHT für die alten Schaltsteckdosen vom Typ FS20 ST.
Wohlgemerkt: Ich kann die Schaltsteckdosen mit der vorgenannten Fernbedienung direkt schalten. FHEM zeigt mir auch zweifelsfrei den eingestellten Hauscode und den Gerätecode an.

Jeder Versuch, die Schaltsteckdosen an FHEM anzubinden, ist jedoch gescheitert. Ich habe ein dummy-Device angelegt, ,,lamp" genannt. Gemäß der aktuellen Dokumentation habe ich die Schaltsteckdose zuerst in den Anlernmodus gebracht und dann ,,lamp" über das GUI ein- und ausgeschaltet. Ganz egal, ob ich die vorgenannten Adressen verwende oder ganz neue definiere – die Schaltsteckdose reagiert schlichtweg NICHT!

Alle Versuche, im Internet Hinweise zu diesem Problem zu finden, sind fehlgeschlagen.

Das Listing von ,,lamp" zeigt folgendes:

Code Auswählen Erweitern

Internals:
   BTN        00
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG 810b04xx0101a0019999000011
   CUL_0_RSSI -63
   CUL_0_TIME 2017-01-27 14:46:55
   DEF        32323232 00
   IODev      STACKABLE_CC_1
   LASTInputDev STACKABLE_CC_1
   MSGCNT     7
   NAME       lamp
   NR         117
   STACKABLE_CC_1_MSGCNT 6
   STACKABLE_CC_1_RAWMSG 810b04xx0101a0019999000014
   STACKABLE_CC_1_RSSI -91.5
   STACKABLE_CC_1_TIME 2017-01-27 19:16:15
   STATE      off
   TYPE       FS20
   XMIT       9999
   Code:
     1          9999 00
   Readings:
     2017-01-29 15:16:07   state           off
Attributes:
   IODev      STACKABLE_CC_1
   room       FS20
   verbose    0

Darin kann man also auch die Adresse wiederfinden. Warum die messages mal mit 11 und mal mit 14 enden, verstehe ich allerdings nicht.

Das Listing von  ,,STACKABLE_CC_1":

Code Auswählen Erweitern

Internals:
   CMDS       mBbCFiAZGMYRTVWXef*ltuxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        CUL_0
   IODev      CUL_0
   NAME       STACKABLE_CC_1
   NOTIFYDEV  CUL_0
   NR         61
   NTFY_ORDER 50-STACKABLE_CC_1
   PARTIAL
   RAWMSG     tA03C52852ED0
   RSSI       -98
   STACKABLE_CC_1_MSGCNT 5610
   STACKABLE_CC_1_TIME 2017-01-29 15:16:58
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.66 CSM868
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
   Readings:
     2017-01-26 17:33:49   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:12dB
     2017-01-27 14:17:57   cmds             m B b C F i A Z G M Y R T V W X e f * l t u x z
     2017-01-26 16:00:01   raw             V 1.66 CSM868
     2017-01-29 15:16:58   state           Initialized
     2017-01-04 17:29:11   version         V 1.66 CSM868
   Helper:
Attributes:
   rfmode     SlowRF
   room       STACKABLE_CC
   verbose    0

IM Logfile steht immer wieder folgendes:

Code Auswählen Erweitern

2017.01.26 19:33:59 3: FS20 set lamp on
2017.01.26 19:34:01 3: FS20 set lamp off
2017.01.26 19:34:03 4: CUL_Parse: STACKABLE_CC_1 tAEF554054EE0 -90
2017.01.26 19:34:03 5: STACKABLE_CC_1: dispatch TXAEF554054E

Die ausgeführten Kommandos in der 1. und 2. Zeile haben aber wohl nichts mit den Texten in Zeile 3 und 4 zu tun – denn das müssen die Signale des Temperatur/Feuchtesensors sein. Die wiederum erscheinen im GUI übbrigens in einer eigenen Gruppe, ,,CUL_TX" genannt.

Ich laboriere nun schon einige Wochen erfolglos an diesem Problem herum. Kann mir irgend jemand einen Hinweis darauf geben, wie ich die Sache weiter eingrenzen und eine Lösung finden kann?

mfg Gerd

[rudolfkoenig]

FS20 verwendet einen ungenau eingestellten Sender/Empfaenger, der auf einem relativ breiten Frequenzband sendet/empfaengt. Das vom SCC verwendete CC1101 ist dagegen deutlich genauer. Ich vermute, dass in diesem Fall freq/bWidth fuer das SCC angepasst werden muss.

[cebulon]

Hallo Rudolf,

danke für die schnelle Antwort und die Arbeit, die Du in FHEM gesteckt hast.

Ich vermute, dass in diesem Fall freq/bWidth fuer das SCC angepasst werden muss.

Das habe ich schon hinter mir. Ich habe alle  Parameter variiert, die die Funkstrecke betreffen und auch die FS20 ST bis auf 1 m an den SCC herangebracht – das Ding reagiert nicht. Die Antenne ist übrigens ¾ Lambda lang.

Inzwischen habe ich zu dem Thema nochmal hier im Forum gestöbert und einen Logeintrag von Dir gefunden, der im Zusammenhang mit einem ähnlichen Problem stand:

Code Auswählen Erweitern

2016.11.25 21:41:48.528 3: FS20 set Fenster1 on
2016.11.25 21:41:48.528 5: SCC sending *F74915411
2016.11.25 21:41:48.528 5: SW: *F74915411

,,Solch eine Sequenz habe ich in meinem Logfile definitiv NICHT gefunden." hatte ich eben bereits eingetippt, als mir spontan der Gedanke kam, danach doch mal in ALTEN Logs zu suchen, weil irgendwann in den ersten Tagen mit FHEM das Relais mal geklappert hat. Dann bin ich tatsächlich  fündig geworden, und zwar zu einem Zeitpunkt, als nur 1 SCC auf dem RASPI steckte und ,,CUL_0" hieß.

Das damalige Listing habe ich nicht mehr, so sieht das AKTUELLE ,,CUL_0" aus:

Code Auswählen Erweitern

Internals:
   CMDS       mBbCFiAZGMYRTVWXef*ltuxz
   CUL_0_MSGCNT 1062
   CUL_0_TIME 2017-01-29 17:22:03
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyAMA0@38400 1034
   DeviceName /dev/ttyAMA0@38400
   FD         15
   FHTID      1034
   NAME       CUL_0
   NR         60
   NR_CMD_LAST_H 10
   PARTIAL
   RAWMSG     A0DF086104F4AF7000000060100003A
   RSSI       -45
   STACKED    STACKABLE_CC_1
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CSM868
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2017-01-04 18:50:15   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-01-27 14:21:43   cmds            m B b C F i A Z G M Y R T V W X e f * l t u x z
     2016-12-07 10:32:46   raw             No answer
     2017-01-29 17:22:03   state           Initialized
     2016-12-10 14:41:06   version         V 1.66 CSM868
   XMIT_TIME:
     1485700824.40168
     1485700824.92387
     1485700827.54791
     1485700827.73975
     1485700831.85754
     1485700838.42724
     1485700882.92929
     1485700896.42798
     1485702844.51521
     1485702856.76408
   Helper:
     373975:
       QUEUE:
     375b51:
       QUEUE:
     41b123:
       QUEUE:
     4f4af7:
       QUEUE:
Attributes:
   rfmode     HomeMatic
   verbose    0

Damals muß das also im rfmode SlowRF gewesen sein, denn die HomeMatic-Komponenten hatte ich noch gar nicht. Liegt an dieser Stelle ,,der Hund begraben" und was muß ich ändern?

Ansonsten hatte ich auch eine VCCU eingerichtet – noch nicht so richtig verstehend, wozu die eigentlich gut ist. Ich hoffe, damit keinen Fehler gemacht zu haben, der mit dem aktuellen Problem zusammenhängt.

mfg Gerd

[rudolfkoenig]

Zu VCCU kann ich nichts sagen, mit Homematic in FHEM kenne ich nicht (mehr) aus.
- welches 00_CUL.pm Modul verwendest du: es gibt was spezielles fuer HM, keine Ahnung, ob der SCC richtig unterstuetzt.
- *Fxxx mit einem SCC ist schraeg, weil * vom SCC Modul hinzugefuegt wird, macht also nur mit 2 aufgesteckten Boards Sinn.

Kannst du bitte ein "attr global log 5" Mitschnitt eines FS20-Sendevorgangs hier anhaengen?

[cebulon]

Hallo Rudolf,

- welches 00_CUL.pm Modul verwendest du: es gibt was spezielles fuer HM, keine Ahnung, ob der SCC richtig unterstuetzt.

,,# $Id: 00_CUL.pm 12667 2016-11-27 09:12:29Z rudolfkoenig $" in /opt/fhem/FHEM

Darüber hinaus steht eine gleichnamige Datei

,,# $Id: 00_CUL.pm 12027 2016-08-21 12:05:23Z rudolfkoenig $" in /opt/fhem/restoreDir/2016-12-12/FHEM

- *Fxxx mit einem SCC ist schraeg, weil * vom SCC Modul hinzugefuegt wird, macht also nur mit 2 aufgesteckten Boards Sinn.

Ich verwende derzeit 2 aufgesteckte Boards (SCCs). Nachträgliche Ergänzung: Damals war nach meiner Erinnerung nur 1 Board aufgesteckt. Damit funktionierte die Schaltsteckdose, heute aber leider nicht mehr.

Kannst du bitte ein "attr global log 5" Mitschnitt eines FS20-Sendevorgangs hier anhaengen?

Daran scheitere ich. Dieses Kommando führt zu einer Fehlermeldung. Nach der Suche in der Dokumentation habe ich dann "attr global logfile 5" eingegeben und einen weiteren (erfolglosen) Anlernversuch durchgeführt, aber ich kann kein entsprechendes Log finden. Wie geht das genau?

mfg Gerd

[rudolfkoenig]

Sorry, es heisst "attr global verbose 5".

[cebulon]

Hallo Rudolf,

so, das ist der Mitschnitt eines erneuten Anlernversuches:

Code Auswählen Erweitern

2017.01.30 13:15:39 4: WEB_192.168.178.12_50567 POST /fhem?cmd.lamp=set%20lamp%20on&room=FS20&XHR=1&fw_id=207; BUFLEN:0
2017.01.30 13:15:39 5: Cmd: >set lamp on<
2017.01.30 13:15:39 3: FS20 set lamp on
2017.01.30 13:15:39 5: CUL_0 sending *F99992211
2017.01.30 13:15:39 5: SW: *F99992211
2017.01.30 13:15:39 5: Triggering lamp (1 changes)
2017.01.30 13:15:39 5: Starting notify loop for lamp, 1 event(s), first is on
2017.01.30 13:15:39 4: name: /fhem?cmd.lamp=set%20lamp%20on&room=FS20&XHR=1&fw_id=207 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.01.30 13:15:42 4: WEB_192.168.178.12_50567 POST /fhem?cmd.lamp=set%20lamp%20off&room=FS20&XHR=1&fw_id=207; BUFLEN:0
2017.01.30 13:15:42 5: Cmd: >set lamp off<
2017.01.30 13:15:42 3: FS20 set lamp off
2017.01.30 13:15:42 5: CUL_0 sending *F99992200
2017.01.30 13:15:42 5: SW: *F99992200
2017.01.30 13:15:42 5: Triggering lamp (1 changes)
2017.01.30 13:15:42 5: Starting notify loop for lamp, 1 event(s), first is off
2017.01.30 13:15:42 4: name: /fhem?cmd.lamp=set%20lamp%20off&room=FS20&XHR=1&fw_id=207 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.01.30 13:15:48 4: Connection closed for WEB_192.168.178.12_50566: EOF
2017.01.30 13:15:48 4: WEB_192.168.178.12_50567 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-01.log; BUFLEN:0

Mit meiner bescheidenen Erfahrung interpretiere ich das so, daß das Kommando tatsächlich gesendet wird, aber von "CUL_0" und nicht von "STACKABLE_CC_1". Das Erstgenannte hat aber den rfmode "HomeMatic".

Das kann doch nicht funktionieren?!

mfg Gerd

[rudolfkoenig]

Doch, genauso ist das gedacht. Da FHEM keinen direkten Zugriff zu "Etage 2" hat, bittet es "Etage 1" die Daten weiterzuschicken. Das passiert im Firmware der Etage 1, wenn die erste Buchstabe ein * ist. Siehe auch "get STACKABLE_CC_1 uptime". Einen Fehler kann ich nicht entdecken, evtl. ist im Firmware/Hardware was falsch

[cebulon]

Hallo Rudolf,

besten Dank für die Info. Ich werde mal versuchen, das ganze System wieder bei Null aufzusetzen und nur mit 1 SCC zu beginnen.

mfg Gerd