Selbstbau CUN (MapleCUN)

Ranseyer · 12 März 2017, 10:53:06

Ahh OK, du nutzt Variante 3:

1) Firmware die nicht nür Bootloader gebaut ist direkt seriell flashen
2) Firmware per USB passend zu vorhandenem USB Bootloader flashen
3) USB Bootloader per USB-umbiegen zu anderem Stand und dann per USB flashen

Variante 3 ist die komplizierteste und somit am fehlerträchtigsten. (Ich nutze die deshalb nicht)
Mir wäre lieber gewesen den schlechteren, aber originalen MAPLE-USB Bootloader zu nutzen. Aber ich kann nicht abschätzen ob damit irgendwann mal der Speicherplatz knapp wird bei neuen Versionen.

A.Harrenberg · 12 März 2017, 11:10:34

Hi,

ja mag sein das es die komplizierteste ist, aber nach meinem bisherigen Kenntnisstand doch die einzige Möglichkeit wenn man den Bootloader nicht per seriellem Bootloader updaten möchte.
Man muss den Bootloader ja auf jeden Fall upgraden, und das geht soweit ich weiss nur per Flash Loader / stm32flash über die serielle oder eben über den Updater-Sketch.

Sooo kompliziert finde ich die Vorgehensweise jetzt aber auch nicht, Hauptproblem an der Geschichte scheint mir dfu-util zu sein. Mag sein das es unter Linux besser läuft, ich habe nur keine native Linux-Maschine hier, das sind alles virtuelle und da ist das mit den USB Schnittstellen auch nicht immer so problemlos.

Ich werde das aber vielleicht doch mal unter Linux probieren und schauen ob dort das flashen mit dfu-util ohne Fehler bis zu Ende läuft.

Gruß,
Andreas.

Ranseyer · 12 März 2017, 11:30:02

Ja das ist korrekt, wer nur per USB flashen will kann nur:
-es so machen wie du schreibst
-sich selbst die FW kompilieren passend zum Original MAPLE Bootloader (kann ich nicht sagen was exakt zu ändern wäre)

fhem-challenge · 12 März 2017, 12:44:42

The never never never ending story...

nachdem ich nun die firmware vom 6.3.2017 geflashed habe, und! er nun endlich wieder den W5100 erkennt, lässt sich der MapleCUN nicht wirklich in FHEM instalieren.

define mapleCUN1 CUL 192.168.100.218:2323 3442 ... funktioniert

ein ccconf zeigt auch alle zu erwartenden Parameter korrekt. Und er ist auch erreichbar.

define mapleCUN2 STACKABLE_CC mapleCUN1

... funktioniert hingegen nicht.

Code Auswählen

2017.03.12 12:33:27 3: Opening mapleCUN1 device 192.168.100.218:2323
2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
2017.03.12 12:33:29 3: mapleCUN1 device opened
<<<ab hier wurde der zewite stackable definiert >>>
2017.03.12 12:35:39 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
2017.03.12 12:35:42 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
2017.03.12 12:35:45 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
<<<hier der Versuch eines ccconf des zweiten >>>
2017.03.12 12:35:59 2: mapleCUN2: unknown message  (*C0D is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z

und Debugausgabe sagt, er würde drei CC1101 finden und 2323,2324,2325 TCP binden.

Code Auswählen

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
 MAC : 00:80:41:16:D4:95
 IP : 192.168.100.218
 GW : 192.168.100.254
 SN : 255.255.255.0
=======================================
-I- Detected CC0: PN 0x00  VER 0x14 
-I- Detected CC1: PN 0x00  VER 0x14 
-I- Detected CC2: PN 0x00  VER 0x14 
-I- Not detected CC3: PN 0x00  VER 0x00 
-I- Detected ethernet 
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]

Macht er aber nicht (siehe nmap).

Hinweis: Ich habe drei CC1101 auf der Platine. Stecke ich den MapleMini mit der uralten Firmware auf die Platinen, geht alles sofort. Stecke ich den MapleMini mit der Version: MapleCUNx4_W5100_BL.bin (6.3.2017) drauf, lässt sich nur! ein CC1101 installieren.

Am USB sehe ich auch drei Schnittstellen.

Da ich leider den MapleCUN schon produktiv habe, und ich meine CUNO's sowie MaxCubes (geflashed) weggestellt hatte, muss ich also bei der UraltFirmware zunächst bleiben, die hatte wochenlang gut funktiniert.

Nach meiner Wahrnehmung sollte doch ...

MapleCUNx4_W5100_BL.bin --> die CC1101 Module erkennen ?
MapleCUNx4_W5100_BL.bin --> den W5100 (oder W5500) erkennen (das macht er ja nun auch mittlerweile) ?

Nachtrag:

und, wie zu erwarten war, ist nur TCP:2323 erreichbar:

Code Auswählen

root@fhem:~# nmap -sT 192.168.100.218

Starting Nmap 6.47 ( http://nmap.org ) at 2017-03-12 12:50 CET
Nmap scan report for 192.168.100.218
Host is up (0.00016s latency).
Not shown: 999 filtered ports
PORT     STATE SERVICE
2323/tcp open  3d-nfsd
MAC Address: 00:80:41:16:D4:95 (VEB Kombinat Robotron)

Nmap done: 1 IP address (1 host up) scanned in 18.24 seconds

(off topic: witzig finde ich die Vendor Zuordnung für den MapleCUN: MAC Address: 00:80:41:16:D4:95 (VEB Kombinat Robotron)) ... ich denke mir demnächst eine andere MAC address aus

Derzeit gehen mir die Ideen aus, was es noch sein könnte

Viele Grüße!

Andreas

A.Harrenberg · 12 März 2017, 14:33:43

Hallo Andreas,

Irgendwie sieht es so aus als ob da ein "*" zu viel in den Kommandos drin stecken würde.

Hast Du vielleicht noch irgendwo eine "Leiche" gestackt?? Also etwas das sich auch auf den mapleCUN1 stacken will oder bereits hat? Ich würde mal bei "unsorted"/"everything" suchen ob da nicht vielleicht noch was anderes aktiv ist.

Was passiert denn wenn Du das ganze mal mit ganz neuen Namen machst?

Ich habe mit der Firmware hier jetzt zwei Platinen gebaut die 3x868 haben, allerdings auf CC1, CC2, CC3, CC0 ist momentan "leer", bei einer Platine war da aber auch schon ein 433 Modul drauf und hat funktioniert. Getestet habe ich das ganze aber nur ganz kurz als Homematic.

Gruß,
Andreas.

fhem-challenge · 12 März 2017, 15:00:55

Zitat von: A.Harrenberg am 12 März 2017, 14:33:43
Hallo Andreas,

Irgendwie sieht es so aus als ob da ein "*" zu viel in den Kommandos drin stecken würde.

Hast Du vielleicht noch irgendwo eine "Leiche" gestackt?? Also etwas das sich auch auf den mapleCUN1 stacken will oder bereits hat? Ich würde mal bei "unsorted"/"everything" suchen ob da nicht vielleicht noch was anderes aktiv ist.

Was passiert denn wenn Du das ganze mal mit ganz neuen Namen machst?

Ich habe mit der Firmware hier jetzt zwei Platinen gebaut die 3x868 haben, allerdings auf CC1, CC2, CC3, CC0 ist momentan "leer", bei einer Platine war da aber auch schon ein 433 Modul drauf und hat funktioniert. Getestet habe ich das ganze aber nur ganz kurz als Homematic.

Gruß,
Andreas.

Hi Andreas,

nein keine Leiche. Ich habe zum Test auch ein neues/nacktes FHEM laufen.

Erklären würde es auch nciht, dass ich mit "nmap" keinen Port sehe, d.h. dass lediglich 2323 gebunden wird, aber die anderen CC1101 mit 2324,2325 ... nicht.

Das wäre ja unabhängig vom FHEM.

Ich habe hier recht unstabile Variationen. Nur und einzig die UraltFirmware läuft extrem stabil (man gut, das ich die hier noch habe). Die ...W5100_BL läuft bei mir auch auf zwei STM32, aber recht instabil.

Ich habe nun einmal die Spannung an dem W5100 gemessen. Die liegt mit 4.6V nicht gerade sehr hoch. Absolut verrückt ist, dass ich (bei einem eher schlechten USB Kabel) hier dann auch 4.3 V am W5100 habe (und damit auch am STM32). Komisch ist, dass genau mit 4.3V das ganze besser läuft, als mit 4.6V.

Ich frage mich nun, ob der W5100 wirklich mit den auf der Platine vorgesehenen 5V überhaupt "zufrieden" ist. Der W5100 selbst, braucht ja nur 3V3, ein AMS1117 (5V->3V3) ist ja auf dem W5100 drauf.
Dennoch, bei allen SPannungsversorgungsvarianten bleibt eines bestehen:

1.) gleiche Platine (die alte MapleCUN ohne Aufdruck) läuft alles! mit der Alt-Firmware
2.) Stecke ich die Firmware vom 6.3.2017 drauf, läufts sehr unstabil.
3.) Ich habe sogar, um den STM32 auszuschliessen, den gleichen Maple Mini mal mit der Alt-Firmware, dann mit der neuen Firmware geflashed. Der Effekt ist reproduzierbar.

... und genau das ist mein Grund für die Ratlosigkeit.

Ich muss bei der Alt-Firmware bleiben (es läuft stabil) und die rfmodes=slowRF sowie HM tun das, was ich brauche. Wenn ich hier den Code de facto einfriere, stört es nicht besonders, weil ich bei slowRF nicht besonders viel Entwicklung zukünftig erwarte.

Viele Grüße!

Andreas

Telekatz · 12 März 2017, 15:04:55

Ich hab mal deine Konfiguration nachgebaut, kann aber deinen Fehler nicht nachvollziehen. Bei mir läuft es.

Code Auswählen

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
 MAC : 00:80:41:E0:D5:7E
 IP : 192.168.69.131
 GW : 192.168.0.1
 SN : 255.255.255.0
=======================================
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x14
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]

Die Ports werden mit nmap erkannt:

Code Auswählen

pi@server ~ $ sudo nmap -sT 192.168.69.131 -p2323-2325

Starting Nmap 6.00 ( http://nmap.org ) at 2017-03-12 14:40 CET
Nmap scan report for WIZnet.fritz.box (192.168.69.131)
Host is up (0.00074s latency).
PORT     STATE SERVICE
2323/tcp open  3d-nfsd
2324/tcp open  unknown
2325/tcp open  ansysli
MAC Address: 00:80:41:E0:D5:7E (VEB Kombinat Robotron)

Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds

Und über eine Verbindung mit Port 2323 lassen sich alle drei CC1101 Module ansprechen:

Code Auswählen

V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
*V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 433MHz)
**V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
*? (1 is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
**? (1 is unknown) Use one of b C A Z N E L Y V X f z
C30 = 00 /  0
*C30 = 00 /  0
**C30 = 00 /  0
C31 = 14 / 20
*C31 = 14 / 20
**C31 = 14 / 20

Das kommt mir bei dir komisch vor:

Code Auswählen

2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
Da fehlt das * Kommando für den STACKABLE_CC. Das sollte aber drinn sein, wenn der zweite CC erkannt wird. Was liefert version hier zurück?

Zitat von: fhem-challenge am 12 März 2017, 15:00:55
Erklären würde es auch nciht, dass ich mit "nmap" keinen Port sehe, d.h. dass lediglich 2323 gebunden wird, aber die anderen CC1101 mit 2324,2325 ... nicht.

Die CC1101 sind alle über Port 2323 erreichbar. Die anderen Ports sind für die seriellen Schnittstellen des Maple.

zentis666 · 12 März 2017, 17:54:58

Hallo,

ich hab mal ne Frage bezüglich Homematic-Protokoll:
wenn ich das richtig verstanden habe kann man die Homematic-Funkmodule für Raspberry anstatt der CC1101 Funkmodule einsetzen.

Könnte ich diese eigentlich genau wie ein "original" HomeMatic Funk-LAN-Gateway mit einer CCU2 verbinden oder funktioniert
das dann nur mit fhem / vccu? Anbindung des Moduls an fhem wäre ja - genau wie HomeMatic Funk-LAN-Gateway - per HMUARTLGW.

Gruß
Sven

A.Harrenberg · 12 März 2017, 18:34:58

Hi,

Zitat von: zentis666 am 12 März 2017, 17:54:58
ich hab mal ne Frage bezüglich Homematic-Protokoll:
wenn ich das richtig verstanden habe kann man die Homematic-Funkmodule für Raspberry anstatt der CC1101 Funkmodule einsetzen.

so ein Raspberry Modul wird nicht anstelle eines CC1101 genutzt sondern an eine der beiden UART Schnittstellen angeschlossen. Am Raspi geht das auf eine interne Serielle Schnittstelle, bei der Schaltung hier an interne Serielle vom Maple und das wird dann an die zweite/dritte USB-Schnittstelle bzw. an die Ports 2324 und 2325 gelegt.

Zitat von: zentis666 am 12 März 2017, 17:54:58
Könnte ich diese eigentlich genau wie ein "original" HomeMatic Funk-LAN-Gateway mit einer CCU2 verbinden oder funktioniert
das dann nur mit fhem / vccu? Anbindung des Moduls an fhem wäre ja - genau wie HomeMatic Funk-LAN-Gateway - per HMUARTLGW.

Hier kann ich Dir jetzt nicht mehr wirklich weiterhelfen, aber ich denke nicht das Du diese HW an eine CCU2 weiterreichen kannst. Aber eine CCU2 kenne ich nicht daher ist das hier nur meine Einschätzung.

Gruß,
Andreas.

fhem-challenge · 12 März 2017, 19:37:14

Zitat von: Telekatz am 12 März 2017, 15:04:55
Ich hab mal deine Konfiguration nachgebaut, kann aber deinen Fehler nicht nachvollziehen. Bei mir läuft es.

Code Auswählen Erweitern
-I- Getting new Started Project -- -I- MapleCUNx4 -I- Compiled: Mar 6 2017 18:53:31 -- -I- init Flash -I- init Timer -I- init EEprom -I- init Ethernet WIZCHIP Initialized success. ===== W5100 NET CONF : Static ===== MAC : 00:80:41:E0:D5:7E IP : 192.168.69.131 GW : 192.168.0.1 SN : 255.255.255.0 ======================================= -I- Detected CC0: PN 0x00 VER 0x14 -I- Detected CC1: PN 0x00 VER 0x14 -I- Detected CC2: PN 0x00 VER 0x14 -I- Not detected CC3: PN 0x00 VER 0x00 -I- Detected ethernet -I- init USB -I- init Complete 0:TCP server start 0:Socket opened 1:TCP server start 1:Socket opened 2:TCP server start 2:Socket opened 0:Listen, TCP server, port [2323] 1:Listen, TCP server, port [2324] 2:Listen, TCP server, port [2325]

Die Ports werden mit nmap erkannt:
Code Auswählen Erweitern
pi@server ~ $ sudo nmap -sT 192.168.69.131 -p2323-2325 Starting Nmap 6.00 ( http://nmap.org ) at 2017-03-12 14:40 CET Nmap scan report for WIZnet.fritz.box (192.168.69.131) Host is up (0.00074s latency). PORT STATE SERVICE 2323/tcp open 3d-nfsd 2324/tcp open unknown 2325/tcp open ansysli MAC Address: 00:80:41:E0:D5:7E (VEB Kombinat Robotron) Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds

Und über eine Verbindung mit Port 2323 lassen sich alle drei CC1101 Module ansprechen:
Code Auswählen Erweitern
V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz) *V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 433MHz) **V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz) ? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z * *? (1 is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z * **? (1 is unknown) Use one of b C A Z N E L Y V X f z C30 = 00 / 0 *C30 = 00 / 0 **C30 = 00 / 0 C31 = 14 / 20 *C31 = 14 / 20 **C31 = 14 / 20

Das kommt mir bei dir komisch vor:
Code Auswählen Erweitern
2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
Da fehlt das * Kommando für den STACKABLE_CC. Das sollte aber drinn sein, wenn der zweite CC erkannt wird. Was liefert version hier zurück?
Die CC1101 sind alle über Port 2323 erreichbar. Die anderen Ports sind für die seriellen Schnittstellen des Maple.

Danke,

also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.

version liefert: V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)

Ich habe jetzt auch: B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z * ... als valid commands bei der Initialisierung.

Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?

Ich vermute eine leichte Hardwareabhängigkeit, die sich nur bei neueren releases der Firmware bemerkbar macht (ggf. verändertes Timing bei der Initialisierung des W5100 o.Ä.).

Viele Grüße!

Andreas

Ranseyer · 12 März 2017, 20:08:27

Anscheinend hat der Wiki Artikel einige verwirrt, weil sich die SW weiter entwickelt hat.
Ich habe somit den Part zum Flashen rausgenommen: https://wiki.fhem.de/wiki/MapleCUN#Firmware_.2F_Flashen

Telekatz · 12 März 2017, 20:10:27

Zitat von: fhem-challenge am 12 März 2017, 19:37:14
also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.

Der erste CC ist über TCP:2323 erreichbar, alle weiteren über STACKABLE_CC des jeweils vorherigen CC.

Zitat von: fhem-challenge am 12 März 2017, 19:37:14
Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?

Ja, das gibt aktuell Probleme. Die weiteren CC können dann nicht mehr über * erreicht werden.

fhem-challenge · 12 März 2017, 20:17:53

Zitat von: fhem-challenge am 12 März 2017, 19:37:14

Danke,

also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.

version liefert: V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)

Ich habe jetzt auch: B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z * ... als valid commands bei der Initialisierung.

Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?

Ich vermute eine leichte Hardwareabhängigkeit, die sich nur bei neueren releases der Firmware bemerkbar macht (ggf. verändertes Timing bei der Initialisierung des W5100 o.Ä.).

Viele Grüße!

Andreas

Ich konkretisiere meine Beobachtung einmal:

Wenn CC= beschaltet ist, CC1 nicht, CC3 und/oder CC4 wieder beschaltet sind, gibts Probleme.

Ich bekomme in diesem Fall lediglich CC0 (ccconf gibt etwas zurück). ALle weiteren CC(2-4) geben nichts zurück.

D.h. das beim parsen der CC's die Reihenfolge eingehalten bleiben muss. In meinem Fall einer TestPlatine ist es so, dass ich wg. des Auslöten eines Stamp Modules diesen (da die Leiterbahn da sich abgehoben haben) nicht mehr verwendet werden kann. Ich muss also hier CC=, CC2,CC3 berschalten, und genau das macht Probleme in FHEM.

Viele Grüße!

Andreas

A.Harrenberg · 12 März 2017, 20:29:21

Hi,

Zitat von: Telekatz am 12 März 2017, 20:10:27
Der erste CC ist über TCP:2323 erreichbar, alle weiteren über STACKABLE_CC des jeweils vorherigen CC.
Ja, das gibt aktuell Probleme. Die weiteren CC können dann nicht mehr über * erreicht werden.

also ich habe CC0 NICHT bestückt, dafür dann CC1/2/3 mit 868 Modulen. Das scheint aber zumindest bei meinem Kurztest mit Homematic zu funktionieren. Ich habe das mal mit der CUL Variante und auch mal mit der CUN Variante probiert und jedesmal das nicht existente CC0 als CUL eingebunden und dann drei mal "gestackt".

Macht die Konfiguration denn auch Probleme? Das wäre dumm da die Dinger ja als Briefmarke aufgelötet sind, und meine bestellten 434 Module dummerweise falsch mit 8 pin Header geliefert wurden.

Oder sind es bloss "Lücken" zwischen bestückten Modulen die Probleme machen?

Gruß,
Andreas.

Telekatz · 12 März 2017, 21:05:26

Solange du für den nicht existierenden CC0 kein FastRF Protokoll einstellst, gibt es kein Problem. Es sind die Lücken dazwischen, die für Probleme sorgen. Ist das jeweils nächste Modul nicht erkannt worden, wird das * Kommando für den Zugriff darauf auch nicht angeboten. Auf alle weiteren kann man dann auch nicht mehr zugreifen.

Zitat von: fhem-challenge am 12 März 2017, 20:17:53
D.h. das beim parsen der CC's die Reihenfolge eingehalten bleiben muss. In meinem Fall einer TestPlatine ist es so, dass ich wg. des Auslöten eines Stamp Modules diesen (da die Leiterbahn da sich abgehoben haben) nicht mehr verwendet werden kann. Ich muss also hier CC=, CC2,CC3 berschalten, und genau das macht Probleme in FHEM.

Du könntest noch in der board.h die Reihenfolge der Module ändern, um CC1 zu Überspringen:

Code Auswählen

#define CCCOUNT             4
#define CCTRANSCEIVERS    {\
                          { {CC1100_0_OUT_BASE, CC1100_0_CS_BASE, CC1100_0_IN_BASE},\
                            {CC1100_0_OUT_PIN,  CC1100_0_CS_PIN,  CC1100_0_IN_PIN}  },\
                          { {CC1100_2_OUT_BASE, CC1100_2_CS_BASE, CC1100_2_IN_BASE},\
                            {CC1100_2_OUT_PIN,  CC1100_2_CS_PIN,  CC1100_2_IN_PIN}  },\
                          { {CC1100_3_OUT_BASE, CC1100_3_CS_BASE, CC1100_3_IN_BASE},\
                            {CC1100_3_OUT_PIN,  CC1100_3_CS_PIN,  CC1100_3_IN_PIN}  },\
                          { {CC1100_1_OUT_BASE, CC1100_1_CS_BASE, CC1100_1_IN_BASE},\
                            {CC1100_1_OUT_PIN,  CC1100_1_CS_PIN,  CC1100_1_IN_PIN}  },\                          
}