Hallo ich habe heute zwei SCC - Stackable Module auf meinen PI gebaut.
In die Fhem.cfg hatte ich dann folgende Zeilen eingetragen, so wie im installation guid beschrieben.
Ich verstehe das so das SCC zunächst die STACKABLE Module allgemein definiert und SCC1 und SCC2 dann die beiden eigentlichen Module definiert.
define SCC CUL /dev/ttyAMA0@38400 1234
define SCC1 STACKABLE_CC SCC
attr SCC1 rfmode HomeMatic
define SCC2 STACKABLE_CC SCC1
attr SCC2 rfmode SlowRF
Mein Problem war dann jedoch das SCC2 immer disconnect war. Ich habe dann folgendes gemacht und siehe das so funktioniert.
define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 alias CUL SCC 1 HomeMatic
attr SCC1 rfmode HomeMatic
attr SCC1 hmId 000002
attr SCC1 icon scc_868
attr SCC1 room 31_Homeserver
attr SCC1 group CUL
define SCC2 STACKABLE_CC SCC1
attr SCC2 alias CUL SCC 2 SlowRF
attr SCC2 rfmode SlowRF
attr SCC2 icon scc_868
attr SCC2 room 31_Homeserver
attr SCC2 group CUL
Nun meine Frage, ist das so richtig beim Einsatz von zwei Modulen?
Gruß
cerberus
Korrekt is die zweite Vorgehensweise. Das erste SCC wird genau wie ein CUL angesprochen, alle weiteren ueber das SCC Modul. Eigentlich sollte das auch automatisch von FHEM so angelegt werden, sobald die Geraete was empfangen.
Rudolf, danke dir für deine Antwort :)
Gruß
cerberus
Hallo, ich habe in letzter Zeit massive Probleme mit SlowRF.
Aufgefallen ist es mir dabei das mein Licht im Flur seit einiger Zeit nicht mehr zuverlässig geschaltet wird. Ich habe dort ein simples Notify welches zwei FS20 Zwischenstecker, welche die gleiche Adresse verwenden, schaltet sobald ein Bewegungsmelder auslöst. Mir ist ausgefallen das entweder die beiden Schalter garnicht reagieren obwohl ein set on vom notify gesendet wird oder aber nur einer der beiden reagiert. Der Status im Frontend wird auf on gesetzt aber ob das SCC dann sendet kann ich nicht sagen. Ich weiß nicht ob es nun am SCC liegt, denn mit dem COC ging es immer. Am Anfang, als ich die SCC eingebaut habe ist mit dieser Fehler jedoch auch nicht aufgefallen. Könnte es auch an einer der letzten FHEM Updates liegen? Ach ja, im LOG sehe ich noch sowas wie global define licht_flur, weiß nicht was das bedeuten soll.
Gruß
cerberus
Das log (auf Verbose 5) haette ich auch gerne. Da muesste sowas wie "SW: *F12345678" auftauchen.
Bitte beobachten, ob es geschaltet wird, wenn so eine Zeile kommt, oder kommt die Zeile gar nicht?
Wichtig zu wissen, wieviele SCC's du einsetzt, und welcher oben bzw. unten ist.
Danach koennen wir mit weitere Debug-Befehlen weitersuchen.
Das SCC ist neu und relativ wenig verbreitet, deswegen vermute ich das Problem in dieser Ecke.
Danke Rudolf,
ich werde heute Abend, wenn ich zu Hause bin, den LOG auf Verbose 5.
Die beiden SCC´s sind in der Reihenfolge wie im letzten Beitag von mir zu sehen eingebaut. Also 2 Stück, eines mir SlowRF und eines auf HomeMatic. Ich muss dazu sagen das ich vor den beiden SCC´s aber noch ein CW2 USV Platine habe, ich hoffe nicht das es deswegen Probleme gibt.
Gruß
cerberus
Hallo Rudolf, ich habe jetzt mal den LOG hoch gesetzt und folgendes im LOG gesehen. Was mich irritiert ist das ich als IODevice SCC2 angegeben habe jedoch im LOG aber SCC1 sendet. Oder sehe ich das falsch.
2014.05.23 21:08:08 5: CUL/RAW: /*F304C16
2014.05.23 21:08:08 5: CUL/RAW: *F304C16/1120
2014.05.23 21:08:08 5: SCC1 dispatch *F304C161120
2014.05.23 21:08:08 4: CUL_Parse: SCC2 F304C161120 -58
2014.05.23 21:08:08 5: SCC2 dispatch 810b04xx0101a001304c160011
2014.05.23 21:08:08 4: FS20 Bewegungsmelder_Flur_C1 on
2014.05.23 21:08:08 5: Triggering Bewegungsmelder_Flur_C1 (1 changes)
2014.05.23 21:08:08 5: Notify loop for Bewegungsmelder_Flur_C1 on
2014.05.23 21:08:08 5: batteryStatus: not on any display, ignoring notify
2014.05.23 21:08:08 5: Triggering notify_Licht_Flur
2014.05.23 21:08:08 4: notify_Licht_Flur exec {
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");;
}
}
2014.05.23 21:08:08 5: Cmd: >{
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");
}
}<
2014.05.23 21:08:08 5: Cmd: >set Licht_Flur on-for-timer 120<
2014.05.23 21:08:08 3: FS20 set Licht_Flur on-for-timer 120
2014.05.23 21:08:08 5: SCC1 sending *F304c18395f
2014.05.23 21:08:08 4: CUL_send: SCC1*F 30 4c 1839 5f
2014.05.23 21:08:08 4: Follow: +00:02:00 setstate Licht_Flur off
2014.05.23 21:08:08 5: Triggering global (1 changes)
2014.05.23 21:08:08 5: Notify loop for global DEFINED Licht_Flur_timer
2014.05.23 21:08:08 5: Triggering Licht_Flur (1 changes)
2014.05.23 21:08:08 5: Notify loop for Licht_Flur An-für-Zeit
2014.05.23 21:08:08 5: batteryStatus: not on any display, ignoring notify
2014.05.23 21:08:09 5: CUL/RAW: /*T853195
2014.05.23 21:08:09 5: CUL/RAW: *T853195/01E7
2014.05.23 21:08:08 5: SCC1 sending *F304c18395f
2014.05.23 21:08:08 4: CUL_send: SCC1*F 30 4c 1839 5f
Das untere SCC1 ist als HomeMatic configuriert, SCC2 steckt drauf, und sollte die Daten als FS20 senden.
Wenn man mit dem SCC2 reden will, dann muss man SCC1 bitten, die Daten an dem SCC2 weiterzureichen. Das erkennt SCC1 an dem *. Die beknackte Formatierung in der zweiten Zeile ist dem HomeMatic-Fuzzies zu verdanken, und sollte nicht stoeren.
Von der FHEM Seite schaut das richtig aus, ich vermute ein culfw Problem, entweder beim weiterreichen der Daten (im SCC1) oder beim annehmen (im SCC2). Oder das SCC2 hat ein Problem mit dem Senden. Blinkt denn das LED des SCC2 bei der Aktion (so denn es eins hat)? Kann man mit dem SCC2 ordentlich reden (get SCC2 version, usw)?
Rudolf, danke für deine Antwort. Kurios ist, dass ich die Actoren aber über das Frontend, ohne ein Notify dazwischen zu haben, schalten kann.
Ich frage mich was da anders ist?
hier der LOG dazu:
014.05.23 23:04:47 4: HTTP FHEMWEB:192.168.178.21:54433 GET /fhem?XHR=1&cmd.Licht_Flur=set%20Licht_Flur%20An&room=13_Flur
2014.05.23 23:04:47 5: Cmd: >set Licht_Flur An<
2014.05.23 23:04:47 3: FS20 set Licht_Flur on
2014.05.23 23:04:47 5: SCC1 sending *F304c1811
2014.05.23 23:04:47 4: CUL_send: SCC1*F 30 4c 1811
2014.05.23 23:04:47 5: Triggering Licht_Flur (1 changes)
2014.05.23 23:04:47 5: Notify loop for Licht_Flur An
2014.05.23 23:04:47 5: batteryStatus: not on any display, ignoring notify
2014.05.23 23:04:47 4: /fhem?XHR=1&cmd.Licht_Flur=set%20Licht_Flur%20An&room=13_Flur / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.23 23:04:49 4: HTTP FHEMWEB:192.168.178.21:54433 GET /fhem?XHR=1&cmd.Licht_Flur=set%20Licht_Flur%20Aus&room=13_Flur
2014.05.23 23:04:49 5: Cmd: >set Licht_Flur Aus<
2014.05.23 23:04:49 3: FS20 set Licht_Flur off-for-timer
2014.05.23 23:04:49 5: SCC1 sending *F304c1818
2014.05.23 23:04:49 4: CUL_send: SCC1*F 30 4c 1818
2014.05.23 23:04:49 5: Triggering Licht_Flur (1 changes)
2014.05.23 23:04:49 5: Notify loop for Licht_Flur Aus
2014.05.23 23:04:49 5: batteryStatus: not on any display, ignoring notify
2014.05.23 23:04:49 4: /fhem?XHR=1&cmd.Licht_Flur=set%20Licht_Flur%20Aus&room=13_Flur / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.23 23:04:53 4: Connection closed for FHEMWEB:192.168.178.21:54431
2014.05.23 23:04:53 4: HTTP FHEMWEB:192.168.178.21:54433 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-05.log
Ich haette jetzt mal eine klare Beschreibung, was geht, was nicht, und das jeweils mit Log belegt. Sonst muss ich zu viel raten.
Halo Rudolf, ich werde nochmal einige LOG´s anfertigen. Es scheint so zu sein das dieses Problem sporadisch auftritt. Das bedeutet das ich die Actoren manuell immer schalten kann aber diese nicht immer schalten wenn sie per notify geschaltet werden, obwohl ich im Frontend eben den Staus on sehe. Wenn es dunkel ist teste ich nochmal.
Gruß
cerberus
Also, ich habe verschiedenen Situationen:
Situation 1 Der Bewegungsmelder löst aus aber nur ein Aktor von zweien mit gleicher Adresse schaltet.
2014.05.24 20:52:34 5: CUL/RAW: /*F304C16
2014.05.24 20:52:34 5: CUL/RAW: *F304C16/111D
2014.05.24 20:52:34 5: SCC1 dispatch *F304C16111D
2014.05.24 20:52:34 4: CUL_Parse: SCC2 F304C16111D -59.5
2014.05.24 20:52:34 5: SCC2 dispatch 810b04xx0101a001304c160011
2014.05.24 20:52:34 4: FS20 Bewegungsmelder_Flur_C1 on
2014.05.24 20:52:34 5: Triggering Bewegungsmelder_Flur_C1 (1 changes)
2014.05.24 20:52:34 5: Notify loop for Bewegungsmelder_Flur_C1 on
2014.05.24 20:52:34 5: batteryStatus: not on any display, ignoring notify
2014.05.24 20:52:34 5: Triggering notify_Licht_Flur
2014.05.24 20:52:34 4: notify_Licht_Flur exec {
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");;
}
}
2014.05.24 20:52:34 5: Cmd: >{
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");
}
}<
2014.05.24 20:52:34 5: Cmd: >set Licht_Flur on-for-timer 120<
2014.05.24 20:52:34 3: FS20 set Licht_Flur on-for-timer 120
2014.05.24 20:52:34 5: SCC1 sending *F304c18395f
2014.05.24 20:52:34 4: CUL_send: SCC1*F 30 4c 1839 5f
2014.05.24 20:52:34 4: Follow: +00:02:00 setstate Licht_Flur off
2014.05.24 20:52:34 5: Triggering global (1 changes)
2014.05.24 20:52:34 5: Notify loop for global DEFINED Licht_Flur_timer
2014.05.24 20:52:34 5: Triggering Licht_Flur (1 changes)
2014.05.24 20:52:34 5: Notify loop for Licht_Flur An-für-Zeit
2014.05.24 20:52:34 5: batteryStatus: not on any display, ignoring notify
2014.05.24 20:52:40 5: CUL/RAW: /*TE57945
2014.05.24 20:52:40 5: CUL/RAW: *TE57945/82E4
2014.05.24 20:52:40 5: SCC1 dispatch *TE5794582E4
2014.05.24 20:52:40 4: CUL_Parse: SCC2 TE5794582E4 -88
2014.05.24 20:52:40 5: SCC2 dispatch TE5794582
Situation 2 Der Bewegungsmelder löst aus aber kein Aktor schaltet.
2014.05.24 20:53:26 5: CUL/RAW: /*F304C16
2014.05.24 20:53:26 5: CUL/RAW: *F304C16/1124
2014.05.24 20:53:26 5: SCC1 dispatch *F304C161124
2014.05.24 20:53:27 4: CUL_Parse: SCC2 F304C161124 -56
2014.05.24 20:53:27 5: SCC2 dispatch 810b04xx0101a001304c160011
2014.05.24 20:53:27 4: FS20 Bewegungsmelder_Flur_C1 on
2014.05.24 20:53:27 5: Triggering Bewegungsmelder_Flur_C1 (1 changes)
2014.05.24 20:53:27 5: Notify loop for Bewegungsmelder_Flur_C1 on
2014.05.24 20:53:27 5: batteryStatus: not on any display, ignoring notify
2014.05.24 20:53:27 5: Triggering notify_Licht_Flur
2014.05.24 20:53:27 4: notify_Licht_Flur exec {
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");;
}
}
2014.05.24 20:53:27 5: Cmd: >{
if (Value("Licht_Flur_Auto") eq "An") {
fhem("set Licht_Flur on-for-timer 120");
}
}<
2014.05.24 20:53:27 5: Cmd: >set Licht_Flur on-for-timer 120<
2014.05.24 20:53:27 3: FS20 set Licht_Flur on-for-timer 120
2014.05.24 20:53:27 5: SCC1 sending *F304c18395f
2014.05.24 20:53:27 4: CUL_send: SCC1*F 30 4c 1839 5f
2014.05.24 20:53:27 4: Follow: +00:02:00 setstate Licht_Flur off
2014.05.24 20:53:27 5: Triggering global (1 changes)
2014.05.24 20:53:27 5: Notify loop for global DEFINED Licht_Flur_timer
2014.05.24 20:53:27 5: Triggering Licht_Flur (1 changes)
2014.05.24 20:53:27 5: Notify loop for Licht_Flur An-für-Zeit
2014.05.24 20:53:27 5: batteryStatus: not on any display, ignoring notify
Situation 3 Das mauelle schalten on/off über das WEBFrontend funktioniert immer
2014.05.24 21:15:02 5: Cmd: >set Licht_Flur An<
2014.05.24 21:15:02 3: FS20 set Licht_Flur on
2014.05.24 21:15:02 5: SCC1 sending *F304c1811
2014.05.24 21:15:02 4: CUL_send: SCC1*F 30 4c 1811
2014.05.24 21:15:02 5: Triggering Licht_Flur (1 changes)
2014.05.24 21:15:02 5: Notify loop for Licht_Flur An
2014.05.24 21:15:02 5: batteryStatus: not on any display, ignoring notify
2014.05.24 21:15:02 4: /fhem?XHR=1&cmd.Licht_Flur=set%20Licht_Flur%20An&room=13_Flur / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.24 21:15:04 5: CUL/RAW: /*T075900
2014.05.24 21:15:04 5: CUL/RAW: *T075900/BA00F9
2014.05.24 21:15:04 5: SCC1 dispatch *T075900BA00F9
2014.05.24 21:15:04 4: CUL_Parse: SCC2 T075900BA00F9 -77.5
2014.05.24 21:15:04 5: SCC2 dispatch 810c04xx0909a00107590000ba00
Gruß
cerberus
Hat vermutlich nix direkt mit SCC/FHEM/culfw zu tun, da die Befehle von FHEM immer gleich an das SCC weitergegeben werden.
Vorschlaege:
- Relative Position der Antennen aendern/verbessern
- Sendestaerke im SCC erhoehen
- bessere Antenne in SCC einsetzen
Falls ein FS20 Repeater im Spiel ist, dann sind weitere Moeglichkeiten denkbar.
Ich habe jeweils eine 15 cm Antenne auf einem Magnetfuß an den SCC´s, so wie vorher bei dem COC auch. ich habe den Eindruck das es nur dann nicht funktioniert wenn zuvor das SCC vom Bewegungsmelder etwas empfangen hat und dann gleich wieder senden soll.
Wie ich die Sendestärke erhöhen kann konnte ich in der commandref nicht sehen.
Gruß
cerberus
set SCC2 raw x09
Siehe auch http://culfw.de/commandref.html#cmd_X
Hallo Rudolf, auch das verändern der Sendestärke und ein umpositionieren der Antennen hat nichts an der Situation verändert.
Gruß
cerberus
Dann bin ich erstmal ratlos
Ich habe jetzt mal das PIUSV Modul raus geworfen und beobachte mal ob es daran liegt. Sobald ich Erkenntnisse habe schreibe ich es hier rein.
Gruß
cerberus
So, jetzt habe ich nochmal so einiges getestet.
Zuerst habe ich die PIUSV Plaine ausgebaut, das het jedoch nicht den Erfolg gebracht. Also lag es daran nicht.
Dann habe ich einen Taster eingerichtet mit dem ich über notify das Licht schalte, das hat funktioniert.
Nun kam ich darauf das der IR Melder ja mit zwei Kanälen senden C1 zum schalten des Licht Flur und C2 zum erfassen von Bewegung für die Alarmanlage. Also dachte ich mir, vielleicht kann das SCC nicht senden wenn es noch den zweiten Kanal empfängt. Also habe ich das Senden des ON für den Actor um eine Sekunde verzögert und siehe da es funktioniert. Dieser Workaround ist sicher nicht die Dauerlösung.
Gruß
cerberus
Problem: IR Sendet erst C1 (ca 0.23 Sek lang), dann Pause (laenge unbekannt), dann C2 (nochmal 0.23s lang). FHEM empfaengt C1, und sendet per notify C3 mit 0.3s Verzoegerung (0.3 ist fest eingebaut in CUL.pm), ebenfalls 0.23s. Ohne weitere Verzoegerung im notify ueberlappt sich C2 und C3 soweit, dass der Empfaenger nicht reagiert.
Erklaerung der 0.3s Verzoegerung: da FS20 immer 3 Pakete (ca 0.075s) sendet, aber FHEM nicht weiss, welchen der 3 bekommen hat, wartet sicherheitshalber, bevor es mit Senden anfaengt. Theoretisch muessten 0.15s reichen, praktisch sind 0.3 besser.
Evtl. hilft das vertauschen von C1 und C2
So, ich komme gerade nach Hause und das Licht im Flur ist wie gewünscht an gegangen. Ich habe auf Rudolf´s Tipp hin ma dasl SCC1 auf SlowRF und SCC2 auf HomeMatic Mode umgestellt und bisher funktioniert es soweit. Ich muss jetzt mal beobachten in wie weit es sich auf andere Funktionen bemerkbar macht, ansonsten wäre das erstmal eine Lösung.
Ich weiß nicht ob hier ggf. noch etwas an der CUL FW getan werden kann.
Gruß
cerberus
Ich meinte eigentlich die Signale der IR-Melder (C1 und C2) zu vertauschen, damit erst die Alarmanlage und dann FHEM benachrichtigt wird.
Ach so, verstehe. Das werde ich dann auch noch machen, dazu muss ich aber der IR Melder umprogrammieren, da C1 nur bei Dunkelheit und C2 immer sendet.
Ich melde mich wieder wenn es vollbracht ist, muss gleich auf Arbeit.
Gruß
cerberus
Hallo,
passt zwar nicht genau hier rein aber trozdem.
Stehe gerade vor der entscheidung ob ich einen stapelbarer CC1101 oder eine CC1101-USB-Lite 868MHz (CUL) nehme für meinen PI.
Könne die das gleiche? Kann der SCC auch umschalten zwischen 433/868? Wie sieht es hier mit der FW weiterentwicklung aus? Können die die gleichen Geräte ansteuern?
Danke
Hallo,
wenn es dir um 868MHz geht schau dir doch mal den CUNO an.
Ist ein CUL nur mit Lan-Port.
Lässt sich besser positionieren als ein CUL da er nicht vom USB-Anschluss abhängig ist.
LAN lässt sich auch per D-Lan "verlängern" - USB nicht so einfach.
Grundsätzlich können alle das "gleiche" inkl. automatischer Umschaltung 433/868 (behaupte ich mal http://busware.de/tiki-index.php?page=SCC (http://busware.de/tiki-index.php?page=SCC))mit allen zugehörigen Einschränkungen (Empfangsstärke/Sendestärke) da das Funkteil nicht auf die jeweils andere Frequenz abgestimmt ist.
Grüße
Danke
Hallo,
habe heute 2 scc bekommen 1x 868 1x 433
So das ist in meiner Conf:
define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 alias SCC1 MAX
attr SCC1 group CUL
attr SCC1 rfmode MAX
attr SCC1 room CUL
define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 433Mhz SlowRF
attr SCC2 group CUL
attr SCC2 rfmode SlowRF
attr SCC2 room CUL
Log:
2014.06.16 12:07:46 3: Opening SCC1 device /dev/ttyAMA0
2014.06.16 12:07:46 3: Setting SCC1 baudrate to 38400
2014.06.16 12:07:46 3: SCC1 device opened
2014.06.16 12:07:55 1: Cannot init /dev/ttyAMA0, ignoring it (SCC1)
2014.06.16 12:07:55 2: Switched SCC1 rfmode to MAX
2014.06.16 12:07:55 2: Switched SCC2 rfmode to SlowRF
2014.06.16 12:07:55 1: Including ./log/fhem.save
Was mache ich Falsch?
Danke
Vermutlich hast du die Console nicht stillgelegt, und der "sitzt" auf AMA0.
Sollte an mehreren Stellen dokumentiert sein.
Meinst du das hier?
Hat nicht gebracht:
2014.06.16 13:25:30 1: Cannot init /dev/ttyAMA0, ignoring it (SCC1)
http://www.gtkdb.de/index_36_2451.html
Ja, das habe ich gemeint.
Es geht weiter mit "screen /dev/ttyAMA0" (oder vergleichbares) und "V<return>"
Ok hier gibt die Anleitung:
http://busware.de/tiki-index.php?page=SCC_Installation
Für alle die sich nicht so auskennen wir ich:
Man muss in der /etc/init.d/fhem unter Start folgendes einfügen.
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value