Selbstbau CUN (MapleCUN)

[A.Harrenberg]

Hi,

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.

puh, dann habe ich ja unbewusst alles richtig gemacht indem ich für das nicht existierende CC0 slowRF ausgewählt habe.

Danke für die Klarstellung,
Andreas.

[fhem-challenge]

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.
Du könntest noch in der board.h die Reihenfolge der Module ändern, um CC1 zu Überspringen:

Code Auswählen Erweitern

#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}  },\                         
}

Ahhh... okay. Dann verstehe ich das und meine Beobachtungen passen zur Realität.

Ist ja auch nur eine Ausnahme, da meine eine Platinen ein Defekt hat. Meine produktive Platinen hat das Problem ja nicht.


Viele Grüße!



Andreas

[stenny73]

Hi,na so ein ZM3102 ist schon uralt und eigentlich auch nirgends wirklich zu bekommen.

Ich habe mir es Razberry2 gekauft den ich an einen UART anschliessen wollte. Habe die Teil zwar jetzt hier, bin aber noch nicht dazu gekommen das auszuprobieren. Wird diese Woche auch knapp und dann bin ich 2 Wochen in Urlaub. Aber ich gehe davon aus das das funktioniert, ebenso wie der HMUART den ich an die andere UART klemmen will ,-)

Gruß,
Andreas.

Hi

Klingt doch gut.....
Der zm3102 ist schon älter ist klar ein Nachfolger davon wäre schon sinnvoller.

Ich schaue im Moment nur was ich bei mir ändern könnte und das Teil sieht halt interessant aus.... die Alternative von busWare ist da schon extrem teurer.

stenny


Gesendet von iPhone mit Tapatalk

[A.Harrenberg]

Hi,

Klingt doch gut.....
Der zm3102 ist schon älter ist klar ein Nachfolger davon wäre schon sinnvoller.

also einen Nachfolger wird es nicht geben, habe mit dem Entwickler von zwave.me deswegen schon mal diskutiert, er empfiehlt das Razberry-Modul zu nehmen. Leider ist das relativ teuer da man ja die Lizenz für ZWay gleich mitkauft und ohne Lizenz wird das Ding nicht vertrieben.

Ich habe in den sauren Apfel gebissen und mit das Modul gekauft. Habe in einem Raspi noch ein altes Razberry, das neue soll aber eine bessere Antenne haben, daher habe ich nicht das vorhandene Modul verplant.

Habe jetzt diese Woche nicht mehr so viel Zeit und bin dann 2 Wochen unterwegs, daher werde ich erst Anfang April dazu kommen das Modul mal an die UART dran zu hängen und damit rumzuspielen. Mir fällt nur gerade so auf das es in dem Gehäuse dann doch schon recht eng zugehen wird, ein Homematic-UART Modul (und das LAN-Modul) müssen ja auch noch da rein.

Ich schaue im Moment nur was ich bei mir ändern könnte und das Teil sieht halt interessant aus.... die Alternative von busWare ist da schon extrem teurer.

Welche Alternative meinst Du denn?
Die Frage ist ja was Du da draufpacken willst. Meine "produktive" Platine wird wohl ein 433 + ein oder zwei 868 Module bekommen und dann eben Homematic und ZWave auf den UART Schnittstellen. Das ganze plane ich dann etwas günstiger in der Wohnung zu platzieren und per POE mit Strom zu versorgen.

Gruß,
Andreas.

[fhem-challenge]

Guten Tag,

nachdem ich nun unendlich nach der Lösung der noch offenen Problematik gesucht habe, ist diese zumindest reproduzierbar und auf den "AutoDetect" der CC1101 Module zu fixieren.

Bei mir läuft NUR und ausschliesslich die Version:

V 1.23.07 a-culfw Build: private build (unknown) MapleCUNx4 (F-Band: 868MHz)

Alle Versionen mit der automatischen Erkennung der CC1101-Module funktionieren bei mir reproduzierbar nicht. D.h. es wird immer nur der erste CC1101 erkannt, alle folgenden nicht (es wird auch bei dem cmd kein * angeboten).

Wenn ich auf der gleichen! Platine den MapleMini mit V 1.23.07 drauf stecke, läuft alles.
Wenn ich auf eben diese Platine den mapleCUN mit culfw_1.24.01_build_205  stecke, wird nur der erste CC1101 erkant.

Ich vermute ein Problem im "Autodecet", etwas anderes kann es kaum noch sein. GGf. gibt es hier auch deutliche Fertigungsstreugungen in der Herstellung der Module. Sodass ggf. einige Module nicht (schnell genug) verfügbar sind, wenn das "AutoDecet" das Modul abfragt.

Frage: Kann man die AutoDetection der der culfw etwas verzögern, oder ggf. zweimal durchlaufen lassen ?

Ich habe als:

CC0 = 868 slowRF
CC1 = 433 slowRF
CC2 = 868 HM
CC3 = leer


Viele Grüße!



Andreas

[Telekatz]

Ich hab hier mal ein paar Verzögerungen eingebaut. Kannst du auch mal die Ausgaben an DBG aufnehmen?

[fhem-challenge]

Ich hab hier mal ein paar Verzögerungen eingebaut. Kannst du auch mal die Ausgaben an DBG aufnehmen?

Prima, danke!


.... leider klappts noch nicht. Der erste CC1101 wird erkannt, alle weiteren nicht.

Ich habe noch eine zweite (identische) Platine, auf der ist die gleiche Anordnung der CC1101, mit dem einzigen Unterschied, dass an CC1 kein 433 Stamp gelötet ist, sondern ein CC1101 433 Modul gesteckt ist. Mit dem gesteckten Modul werden alle CC1101 erkannt. Deshalb vermute ich stark die Fertigungsstreuung zwischen den Modulen (oder Stamps).



Anbei die debug Ausgabe:

Code Auswählen Erweitern

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 13:48:23 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:08:D6:C0
IP : 192.168.100.243
GW : 192.168.100.254
SN : 255.255.255.0
=======================================
-I- init USB
-I- Detected CC0: PN 0x00  VER 0x14
-I- Not detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- Autodetect result: 0x85
-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]



Viele Grüße!


Andreas

[RaspiLED]

Hi,
Wie ist das PanStamp drauf? Mit Adapter an gleichen 10 Pins oder direkt? Mal durchgemessen, nicht das doch Hardware schuld ist.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[Telekatz]

Das liegt nicht an Fertigungsstreuungen, das liegt an den chinesischen Kopierkünsten. Das Problem hatte ich diese Woche auch schon. Ich nehme an, dein zweites Modul ist das hier:
https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html

Das wird zwar als CC1101 Modul verkauft, frägt man aber das Versionsregister ab gibt es sich als CC113L aus. Der CC113L ist zwar eigentlich nur ein Receiver, trotzdem funktioniert bei mir auch senden mit diesem Modul. Auf dem Chip selber ist keine Aufdruck vorhanden.

Hier gibt es das gleiche Modul, diesmal aber korrekt beschrieben und mit lesbarer Beschriftung:
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html

Es gibt wohl noch eine andere Version dieses Moduls, eventuell wirklich mit CC1101:
https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html

Mit der angefügten Version wird auch der CC113L erkannt.

[fhem-challenge]

Das liegt nicht an Fertigungsstreuungen, das liegt an den chinesischen Kopierkünsten. Das Problem hatte ich diese Woche auch schon. Ich nehme an, dein zweites Modul ist das hier:
https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html

Das wird zwar als CC1101 Modul verkauft, frägt man aber das Versionsregister ab gibt es sich als CC113L aus. Der CC113L ist zwar eigentlich nur ein Receiver, trotzdem funktioniert bei mir auch senden mit diesem Modul. Auf dem Chip selber ist keine Aufdruck vorhanden.

Hier gibt es das gleiche Modul, diesmal aber korrekt beschrieben und mit lesbarer Beschriftung:
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html

Es gibt wohl noch eine andere Version dieses Moduls, eventuell wirklich mit CC1101:
https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html

Mit der angefügten Version wird auch der CC113L erkannt.

Ja, exakt --> Volltreffer.

Damit wird der CC113 erkannt und alles läuft.

Prima und vielen Dank!

Gruss

Andreas

[Ranseyer]

Da ich auch ein paar blaue Module (ohne lesbaren Aufdruck) bestellt habe, schon mal im voraus Danke !

[Funsailor]

Hallo,
ich habe gestern meine MapleCul mit 3 CC-Einheiten in Betrieb genommen.

https://forum.fhem.de/index.php/topic,50990.msg607361.html#msg607361 und folgende Diskussion

Stand der Dinge:
Inzwischen habe ich den Maple Cul an FHEM laufen, die Kommunikation mit den Homematic und den MAX Geräte funktioniert einwandfrei.
Nur der alte CUN für die 433MHz Geräte hängt noch an meinem BananaPi und blockiert einen USB_Port.


Das Problem mit dem konfigurieren der Einheiten besteht weiterhin.

Die drei CULs laufen, state ist "Initialized".
Ich habe auf CC0 (mapleCUL1) und CC1 (mapleCUL2) je einen CC1101 mit  868MHz bestückt und auf dem CC2 (mapleCUL3) ein 434 MHz Modul.

mapleCUL1 ist im Homematic rfmode, mapleCUL2 im Max rfmode. Die Umstellung der Frequenz im mapleCUL2 auf 868 MHz war kein Problem. Bei diesen Devices kann ich aber z.B.: die bWidth nicht umstellen.

mapleCUL3 soll die 434MHz Devices bedienen. Allerdings kann ich das Device nicht auf 434MHz umstellen.

Woran kann das liegen?

[RaspiLED]

Hi,
433.920 Mhz? Oder was genau ist der Fehler bei verbose 5 im Log?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[Telekatz]

mapleCUL1 ist im Homematic rfmode, mapleCUL2 im Max rfmode. Die Umstellung der Frequenz im mapleCUL2 auf 868 MHz war kein Problem. Bei diesen Devices kann ich aber z.B.: die bWidth nicht umstellen.

mapleCUL3 soll die 434MHz Devices bedienen. Allerdings kann ich das Device nicht auf 434MHz umstellen.

Woran kann das liegen?

Folgende Einschränkungen gibt es für den Betrieb mit mehreren Transceivern:

• SlowRF funktioniert nur an CC0 und CC1.
• MBUS funktioniert an jedem Transceiver aber insgesamt nicht an mehr als einem Transceiver gleichzeitig.
• KOPP_FC funktioniert nur an CC0.

Die restlichen Protokolle funktionieren an allen Transceivern und auch mehrfach gleichzeitig.

Die bWidth Einstellung ist nur für SlowRF, nicht für Homematix oder Max.

[RaspiLED]

Hi,
Naja, gibt es bei SlowRF nicht auch Geräte die neben der Frequenz liegen?

Aus dem CUL-Wiki:"Praktisch ist die Genauigkeit der Sendefrequenz der meisten SlowRF Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.
Frequenz und Bandbreite können daher im SlowRF Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden."
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...