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:
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":
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:
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
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.
Hallo Rudolf,
danke für die schnelle Antwort und die Arbeit, die Du in FHEM gesteckt hast.
ZitatIch 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:
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:
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
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?
Hallo Rudolf,
Zitat- 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
Zitat- *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.
ZitatKannst 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
Sorry, es heisst "attr global verbose 5".
Hallo Rudolf,
so, das ist der Mitschnitt eines erneuten Anlernversuches:
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
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
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