Stapeln von Busware SCC / CCD CUL am Rasperry Pi

pipp37 · 22 Januar 2015, 12:26:08

Hallo.
Ich mache mal ein neues Thema auf, weil mir die korrekte Funktion nicht ganz klar ist.
Sorry für diese umfangreichen Daten aber ich denke, dass man mir so vielleicht leichter helfen kann.

Meine Konfiguration:

RasperryPi -B (kein Plus)
1. CUL = Busware SCC433
2. CUL = Busware SCC868 am 1. SCC aufgesteckt
3. CUL = Busware CCD868 am 2. SCC aufgesteckt

Flashed Firmware culfw:
1. SCC433: http://forum.fhem.de/index.php/topic,14348.345.html culfw_1.62.05 aus Antwort #352
2. SCC868 1.62 aus dem SVN Trunk 20.1.2015
3. CCD868 1.62 aus dem SVN Trunk 20.1.2015

CCD = http://busware.de/tiki-index.php?page=CCD_Installation
SCC = http://busware.de/tiki-index.php?page=SCC_Installation

Busware schreibt!

Zitat
FHEM
SCC itself and stacking support currently requires latest FHEM-svn revision 5274+ !

after freeing the serial line and un-resetting the radio as descibed above you may add in fhem.cfg:
for a Rapberry Pi:
define SCC CUL /dev/ttyAMA0@38400 1234

for a Banana Pi:
define SCC CUL /dev/ttyS2@38400 1234

If you own more than one SCC you can pile them up and may define them chained like this. Make sure you define attribute rfmode properly:
define SCC1 STACKABLE_CC SCC
attr SCC1 rfmode MAX

define SCC2 STACKABLE_CC SCC1
attr SCC2 rfmode SlowRF

define SCC3 STACKABLE_CC SCC2
attr SCC3 rfmode HomeMatic

Die Konfiguration in fhem.cfg sollte demnach lauten:

Code Auswählen


####  Busware Infos - stackable
# http://busware.de/tiki-index.php?page=SCC_Installation
# after freeing the serial line and un-resetting the radio as descibed above you may add in fhem.cfg:
# for a Rapberry Pi:
define SCC CUL /dev/ttyAMA0@38400 1234
attr SCC room CUL

# If you own more than one SCC you can pile them up and may define them chained like this.
# Make sure you define attribute rfmode properly:

define SCC1 STACKABLE_CC SCC
attr SCC1 rfmode SlowRF
attr SCC1 room CUL

define SCC2 STACKABLE_CC SCC1
attr SCC2 rfmode MAX
attr SCC2 room CUL

define SCC3 STACKABLE_CC SCC2
attr SCC3 rfmode WMBus_T
attr SCC3 room CUL

# Intertechno IT-1500 Steckdosen
define myITSwitch IT 000000000F FF F0
attr myITSwitch IODev SCC1
attr myITSwitch model itswitch

Diese Konfiguration funktioniert nicht!

Nach dem lesen der Logs wird beim ersten
define SCC CUL /dev/ttyAMA0@38400 1234
das 1. CUL bereits konfiguriert und nicht erst mit dem Befehl
define SCC1 STACKABLE_CC SCC

Anbei die ganzen Infos mit dem Logfile (verbose=5).

Es folgt die bei mir funktionierende Konfiguration ...

pipp37 · 22 Januar 2015, 12:58:24

Und nun die bei mir funktionierene Init Funktion!

Code Auswählen


# 1. CUL = Busware SCC433
define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 rfmode SlowRF
attr SCC1 room CUL

# 2. CUL = Busware SCC868
define SCC2 STACKABLE_CC SCC1
attr SCC2 rfmode MAX
attr SCC2 room CUL

# 3. CUL = Busware CCD868
define SCC3 STACKABLE_CC SCC2
attr SCC3 rfmode WMBus_T
attr SCC3 room CUL

# Intertechno IT-1500 Steckdosen
define myITSwitch IT 000000000F FF F0
attr myITSwitch IODev SCC1
attr myITSwitch model itswitch

Das Problem mir dieser Konfiguration ist folgendes.
Beim ersten Start von Fhem nach einem Reboot passt alles.
Wenn ich mit service fhem stop beende und wieder mit service fhem start starte, erhalte ich im Log Unmengen folgender Zeilen.

Code Auswählen


2015.01.22 12:40:25 5: SCC1 dispatch *5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF
2015.01.22 12:40:25 4: CUL_Parse: SCC2 5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF
2015.01.22 12:40:25 5: Triggering SCC2 (1 changes)
2015.01.22 12:40:25 5: Notify loop for SCC2 UNKNOWNCODE 5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF
2015.01.22 12:40:25 4: eventTypes: STACKABLE_CC SCC2 UNKNOWNCODE 5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF -> UNKNOWNCODE 5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF
2015.01.22 12:40:25 2: SCC2: unknown message 5F72E5737358DF4BEDD3944A6EBEA8DE9F0BCB7D7D5AE347B4E969B068BF
2015.01.22 12:40:25 5: CUL/RAW: /**Z1D69B
2015.01.22 12:40:25 5: CUL/RAW: **Z1D69B/068BF63E4883BF0C
2015.01.22 12:40:25 5: CUL/RAW: **Z1D69B068BF63E4883BF0C/ABA8DB52
2015.01.22 12:40:25 5: CUL/RAW: **Z1D69B068BF63E4883BF0CABA8DB52/FE6FD4D2791D2EE9
2015.01.22 12:40:25 5: CUL/RAW: **Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9/FFE9321FEDA6BC7B
2015.01.22 12:40:25 5: CUL/RAW: **Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7B/D
*5D57
2015.01.22 12:40:25 5: SCC1 dispatch **Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7BD
2015.01.22 12:40:25 5: SCC2 dispatch *Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7BD
2015.01.22 12:40:25 4: CUL_Parse: SCC3 Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7BD -107.5
2015.01.22 12:40:25 5: SCC3 dispatch Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7
2015.01.22 12:40:25 5: Triggering SCC3 (1 changes)
2015.01.22 12:40:25 5: Notify loop for SCC3 UNKNOWNCODE Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7
2015.01.22 12:40:25 4: eventTypes: STACKABLE_CC SCC3 UNKNOWNCODE Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7 -> UNKNOWNCODE Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7
2015.01.22 12:40:25 3: SCC3: Unknown code Z1D69B068BF63E4883BF0CABA8DB52FE6FD4D2791D2EE9FFE9321FEDA6BC7, help me!
2015.01.22 12:40:25 5: CUL/RAW: *5D57/C67FFE59F2B36D9C924B931CF3
*1DA8DE9F0BCB7D7D5AE347B4E97E74D4214DD61A3AEEA063F3B71A0D63DB0E

Ich vermute, dass dabei die SCC mit culfw nicht richtig konfiguriert werden.

Workaround:

Code Auswählen


service fhem stop
echo 0 > /sys/class/gpio/gpio17/value
echo 1 > /sys/class/gpio/gpio17/value
service fhem start

Anbei die Bilder und die Logdatei (verbose 5).

pirmanji · 26 Januar 2015, 23:06:31

Hallo,

ich habe ebenfalls ein Problem mit dem Stapeln:

Vor kurzem habe ich mir einen Busware SCC 433Mhz bestellt, so dass die Konfiguration meines Raspberry jetzt so aussieht:

SCC 433Mhz und darauf ein COC 868MHz.
Definiert habe ich die Geräte wie folgt:

----------------------------------------------------------------
define COC CUL /dev/ttyAMA0@38400 1234
attr COC rfmode SlowRF
attr COC room Devices

define SCC1 STACKABLE_CC COC
attr SCC1 rfmode SlowRF
attr SCC1 room Devices

define OWio2 OWX COC
attr OWio2 IODev COC
attr OWio2 buspower real
attr OWio2 dokick 1
attr OWio2 interval 300
attr OWio2 room Devices
----------------------------------------------------------------

Der 433MHz SCC ist gedacht, um diverse CUL_TX Temperatursensoren auszuwerten. Der COC um FS20 Komponenten zu bedienen. Dies funktioniert soweit auch gut, jedoch werden seit Installation des SCC keine 1-Wire Geräte mehr erkannt.
Mir fiel nach einigem Suchen auf, dass mit obiger Konfig mit der COC-Definition in Wirklichkeit der SCC angesprochen wird und mit "SCC1" über STACKABLE_CC in Wirklichkeit der COC. Mittels ein-/ausschalten der LEDs über FHEM konnte ich dies zweifelsfrei bestätigen. Somit vermute ich, dass die One-Wire-Definition auf dem SCC landet, und Anfragen über One-Wire-Devices ins Leere gehen. Tatsächlich zeigt das als "COC" definierte Device (in Wirklichkeit der SCC) wiederholt:

"raw ? (ORb is unknown) Use one of m B b C F i A Z G M Y R T V W X e f * l t u x"

Ich vermute, dass hier ein 1-Wire Reading duch den SCC empfangen wird, der damit nichts anfangen kann (Fragezeichen)

Leider weiss ich mir nach diversem Experimentieren nicht mehr recht zu helfen und meine Internetrechergen waren auch nicht wegweisend. Deshalb hier die Frage nach Hilfe:
Wie kann ich FHEM dazu bringen mittels der Definitionen in der fhem.cfg tatsächlich das korrekte Gerät anzusteuern - oder liegt es an etwas anderem, dass die 1-Wire Geräte (lediglich zwei DS18B20 Temperatursensoren, welche bisher zuverlässig ihren Dienst getan hatten) nicht mehr erkannt werden? Der Raspberry hängt an einem 2A Netzteil. Auch der Versuch einen DS18B20 direkt an den 1-Wire Port anzuschließen, führte nicht dazu, dass dieser erkannt wurde, so dass ich nicht mehr von einem Problem mit der Spannungsversorgung ausgehe (real- und parasitic-Power - beides probiert!).

Für Hilfe bin ich sehr dankbar!!!

Viele Grüße,
Christian

rudolfkoenig · 27 Januar 2015, 06:37:22

Kann bitte jemand bestaetigen, dass auf ein COC weitere SCC Module gestapelt werden koennen?
Das waere mir naemlich neu.

pirmanji · 27 Januar 2015, 07:33:02

Hallo,

laut Busware geht das:
http://busware.de/tiki-index.php?page=SCC
"on top you can add a final existing extensions COC, CCD etc. or B+ model/Banana Pi with a stacking adapter"

Ich hatte die Bestellung des SCC mit der Bitte um Nachricht abgeschickt, wenn die Anordnung Raspberry - SCC - COC nicht funktionieren sollte. Die bestellte Ware kam und es funktioniert auch in der angegebenen Reihenfolge - außer dass in FHEM die Devices vertauscht werden und das OWX keine 1-Wire Geräte findet.

Viele Grüße!

rudolfkoenig · 27 Januar 2015, 08:01:27

In den qulfw Quellen ist * (die fuer Stacking verantwortliche Funktion) fuer COC (culfw/Devices/COC/COC.c) nicht definiert, in SCC schon. D.h. wenn die Aussage von busware stimmt, dann brauchst du auf dem COC eine neue culfw Version, mit dem in COC.c selbst eingebauten

Code Auswählen

#ifdef HAS_STACKING
  { '*', stacking_func },
#endif

pipp37 · 27 Januar 2015, 13:14:56

Zitat von: rudolfkoenig am 27 Januar 2015, 08:01:27
In den qulfw Quellen ist * (die fuer Stacking verantwortliche Funktion) fuer COC (culfw/Devices/COC/COC.c) nicht definiert, in SCC schon. D.h. wenn die Aussage von busware stimmt, dann brauchst du auf dem COC eine neue culfw Version, mit dem in COC.c selbst eingebauten
Code Auswählen Erweitern
#ifdef HAS_STACKING { '*', stacking_func }, #endif

Gilt das auch für das Busware CCD - Interface welches bei mir auf den 2 SCC "on top" gesteckt ist?
Das würde auch meine Probleme erklären.
Danke.

rudolfkoenig · 27 Januar 2015, 14:24:39

@pipp37: ja.

Nach etwas nachdenken: es ist nicht garantiert, dass man stacking_func von der SCC unveraendert fuer COC/CCD verwenden kann, das haengt auch noch von der Verdrahtung der jeweiligen MCUs ab.

pipp37 · 27 Januar 2015, 15:33:30

Zitat von: rudolfkoenig am 27 Januar 2015, 14:24:39
@pipp37: ja.

Nach etwas nachdenken: es ist nicht garantiert, dass man stacking_func von der SCC unveraendert fuer COC/CCD verwenden kann, das haengt auch noch von der Verdrahtung der jeweiligen MCUs ab.

Danke. Ich habe schon, bevor ich den Nachtrag gelesen habe, die Stacking Änderung am CCD kompiliert und geflasht.
Zumindest geht alles wie vorher.
Da ich den CCD nur für WMBUS nutze, habe ich im Moment keine Fehler und Fastforward Daten werden vom CCD nach wie vor empfangen.

pirmanji · 28 Januar 2015, 21:49:45

Guten Abend,

ich hatte die Stacking-Abschnitte aus der SCC in die COC-Firmware übernommen, compiliert und geflashed. Einen Unterschied machte dies nicht. Immer noch wird der SCC als erstes gefunden (also auf die CUL-Definition) und der COC auf die STACKABLE_CC-Definition. Das OWX Modul ging dann immer auf den SCC, welches die 1-Wire Befehle nicht kennt. So zumindest erkläre ich mir die Problematik.

Letztlich habe ich den COC jetzt mit der radio_only Firmware geflashed und die OneWire-Anbindung über owfs mittels der OWServer/OWDevice Module realisiert. Das funktioniert sehr gut, so dass ich für meinen Teil erstmal zufrieden bin.

Ich stelle mich aber gerne zur Verfügung, wenn ich irgendetwas in der Kombination COC / SCC testen sollte!

Viele Grüße und danke für die Hilfe!!!
Christian

gosinus · 25 Februar 2015, 21:29:43

Guten Abend,

ich habe einen SCC auf meinen Pi2 installiert und wollte nachfragen wie ich die Sendeleistung einstellen kann?

set mySCC raw x05-08 funktioniert nicht.

Vielen Dank

Gruß

rudolfkoenig · 26 Februar 2015, 07:16:44

Zitatset mySCC raw x05-08 funktioniert nicht.

Und wie kommt man zu dieser Schlussfolgerung?

gosinus · 28 Februar 2015, 21:35:28

mit probieren

- set SCC raw x08

danach

- get SCC ccconf und nichts verändert sich, auch nicht nach einem reboot keine Veränderung

habe einen SCC V 1.63.01

rudolfkoenig · 28 Februar 2015, 23:00:35

Mwn gibt es z.Zt. keine einfache Moeglichkeit zu pruefen, welcher x-Wert gesetzt ist, ccconf zeigt es sicher nicht an.
Man kann natuerlich die richtigen eeprom Adressen auslesen (get CUL raw R**), und aus diesem Wert auf das x-Wert schliessen.

Mellowback · 31 Dezember 2016, 10:44:15

Hallo zusammen,

ich möchte gerne zwei busware SCC betreiben (Homematic und WMBus_T).
Auf beiden Modulen läuft die Version V 1.66 CSM868.

Ich habe den zweiten SCC wie folgt in die fhem.cfg hinterlegt:

define SCC1 CUL /dev/ttyAMA0@38400 1234
attr SCC1 alias CUL SCC 1 HomeMatic
attr SCC1 group CUL
attr SCC1 hmId 000002
attr SCC1 icon scc_868
attr SCC1 rfmode HomeMatic
attr SCC1 room Technikraum

define SCC2 STACKABLE_CC SCC1
attr SCC2 alias SCC2 868Mhz WMBus_T(TechemHKV)
attr SCC2 group CUL
attr SCC2 icon scc_868
attr SCC2 rfmode WMBus_T
attr SCC2 room Technikraum

Beide SCC sind laut webinterface im Status initialized.
Denn noch kann ich nur über den ersten senden und empfangen.

Habe ich irgendetwas vergessen ?
Muss ich Geräte die ich ansprechen will über den Zweiten SCC definieren das er über SCC2 gehen soll ?

Vorab Danke für jede Hilfe

Stapeln von Busware SCC / CCD CUL am Rasperry Pi

gosinus

gosinus