ZWCUL & STACKABLE_CC

[A.Harrenberg]

Hallo Rudi,

ich versuche gerade diesen 4fach CUL mit 1x433 und 3x868 CC1101 in Betrieb zu nehmen.

a.) Das Ding läuft mit der a-culfw und nicht mit der normalen culfw.
b.) Die Transmitter werden normalerweise als STACKABLE_CC eingebunden, ich musste allerdings feststellen das STACKABLE_CC nur mit CUL und nicht mit ZWCUL funktioniert und bei CUL der rfMode kein ZWave bietet...

Da Du für alle drei Module der Maintainer bist kannst Du mir das wohl am ehesten weiterhelfen. Wo müsste ich jetzt ansetzen um das Ganze zusammen ans laufen zu bekommen? Kann man STACKABLE_CC soweit anpassen damit es mit ZWCUL umgehen kann oder müsste man ein STACKABLE_ZWCUL entwickeln? Oder eher in a-culfw ansetzen und ZWave als rfMode zu ermöglichen?

Interessanterweise wird beim ZWCUL als "Client" :ZWave:STACKABLE_CC: eingetragen, wobei ich nicht die geringste Ahnung habe was mir das sagen sollte...

Wäre nett wenn Du mich in die richtige Richtung schubsen könntest.

Gruß,
Andreas.

P.S.: In der maintainer.txt ist 00_ZWCul.pm gar nicht enthalten...

[rudolfkoenig]

Wg a) darfst du dich an dem entsprechenden Maintainer wenden

b) bleibt wohl auf meinem Tisch, ich schau das spaeter an. Wie ist die Reihenfolge der Module festgelegt?
Mir schwebt

CUL (fuer 433)
STACKABLE_CUL + ZWCUL
STACKABLE_CUL + ZWCUL
STACKABLE_CUL + ZWCUL

vor. So ein bisschen wie STACKABLE_CC + TCM (wg. dem EnOceanPi).

P.S.: In der maintainer.txt ist 00_ZWCul.pm gar nicht enthalten...

Danke, habs eingetragen.

[A.Harrenberg]

Hi Rudi,

Wg a) darfst du dich an dem entsprechenden Maintainer wenden

yep... Falls nötig, soweit ich das sehe ist da rf_zwave.c unverändert enthalten.

b) bleibt wohl auf meinem Tisch, ich schau das spaeter an. Wie ist die Reihenfolge der Module festgelegt?
Mir schwebt

CUL (fuer 433)
STACKABLE_CUL + ZWCUL
STACKABLE_CUL + ZWCUL
STACKABLE_CUL + ZWCUL

vor. So ein bisschen wie STACKABLE_CC + TCM (wg. dem EnOceanPi).

Reihenfolge hängt von der Bestückung ab. Ich habe es so aufgelötet wie Du vorgeschlagen hast ,-) Die Briefmarken würde man wohl auch nicht zerstörungsfrei runterbekommen...
Bin mir aber nicht gaanz sicher was passiert wenn z.B. der erste Slot nicht bestückt ist. Ich habe gerade mal das 433 abgezogen (das ist das einzige was gesteckt ist) und die alle 4 Einträge werden als initialized angezeigt und die drei 868 Module empfangen weiterhin Homematic.

Da nur die beiden ersten Module SLOWRF können (wg. Timermangen im ARM) sollte man ein 433 Modul dort platzieren.

Wäre es denn möglich das STACKABLE_CC so flexibel zu machen das man bei jeder Ebene entscheiden kann ob mal ZWCUL oder CUL haben möchte? Ansonsten wäre ja auch kein Mischbetrieb ZWAVE + HOMEMATIC möglich.

Ich schaue mal das ich eine zweite Platine zusammenlöte, die könnte ich Dir dann geben  In Ermangelung von vernünftigen Antennen würde ich da die normalen Pigtails drauflöten (habe ich momentan bei mir auf drauf). Da wären dann aber nur 3x 868 drauf und kein 433, ich habe momentan nur das eine Modul und brauche das selber.

Gruß,
Andreas.

[krikan]

a-culfw loggt bei mir problemlos ZWave über ZWCUL.

[A.Harrenberg]

Hi Rudi,

Ich schaue mal das ich eine zweite Platine zusammenlöte, die könnte ich Dir dann geben

also ein CUL/CUN mit 3x 868MHz wäre jetzt fertig 
Scheint soweit i.O. zu sein, empfängt zumindest auf Homematic.

a-culfw loggt bei mir problemlos ZWave über ZWCUL.

Was das angeht ist es wohl erst mal kompatibel. Was aber bei dem ganzen mehrfach CUL/CUN Zeug dann noch oben drauf kommt weiß ich noch nicht so genau.

Gruß,
Andreas.

[rudolfkoenig]

also ein CUL/CUN mit 3x 868MHz wäre jetzt fertig  (https://forum.fhem.de/Smileys/default/grin.gif)

Das klingt nach einem Erpressungsversuch

Ich bin dabei ein 16_STACKABLE als Nachfolger von 16_STACKABLE_CC zu bauen, was zwar etwas komplizierter aber generischer ist. Gedanke: STACKABLE selbst ist kein IODev mehr, sondern leitet die Daten an frei definierbare IODevs weiter. Wuerde damit das TSSTACKED Modul und die TCM Sonderbehandlung in STACKABLE_CC ueberfluessig machen.

Definition waere damit:

Code Auswählen Erweitern

define CUL_1 CUL /dev/cu.usbmodemfa141 0000

define CUL_1_STACK STACKABLE CUL_1
define ZWCUL_1 FHEM:DEVIO:CUL_1_STACK:9600

define ZWCUL_1_STACK STACKABLE ZWCUL_1
define ZWCUL_2 FHEM:DEVIO:ZWCUL_1_STACK:9600

define ZWCUL_2_STACK STACKABLE ZWCUL_2
define ZWCUL_3 FHEM:DEVIO:ZWCUL_3_STACK:9600

Nachteil: kein autocreate von ZWCUL_*

[A.Harrenberg]

Hi Rudi,

Das klingt nach einem Erpressungsversuch

raffiniert gemacht, oder? 

Ich bin dabei ein 16_STACKABLE als Nachfolger von 16_STACKABLE_CC zu bauen, was zwar etwas komplizierter aber generischer ist. Gedanke: STACKABLE selbst ist kein IODev mehr, sondern leitet die Daten an frei definierbare IODevs weiter. Wuerde damit das TSSTACKED Modul und die TCM Sonderbehandlung in STACKABLE_CC ueberfluessig machen.

Das wäre ja schön, dann ist es danach ja wirklich universel nutzbar. Meine erste Assoziation mit STACKABLE war auch eher in diese Richtung, ich musste dann aber feststellen das es quasi (immer) ein CUL-Device ist.

Code Auswählen Erweitern

define CUL_1 CUL /dev/cu.usbmodemfa141 0000
define ZWCUL_2_STACK STACKABLE ZWCUL_2
define ZWCUL_3 FHEM:DEVIO:ZWCUL_3_STACK:9600


Hier müsste es in der letzten Zeile aber "define ZWCUL_3 FHEM:DEVIO:ZWCUL_2_STACK:9600" heißen, oder?

Nachteil: kein autocreate von ZWCUL_*

Damit könnte ich leben, betrifft das denn dann auch andere Module wie das CUL selbst?

Gruß,
Andreas.

P.S.: wg. der Hardware, ich wollte eines von den Dingern für "FHEM" zur Verfügung stellen, das könntest Du sein, wir könnten das evtl. aber auch an User schicken um gesniffte Logdateien zu bekommen um Merkwürdigkeiten zu klären. Evtl. beschaffe ich mir auch noch eine weitere Platine und könnte auch zwei Geräte zur Verfügung stellen. Ein "Sniffer" wollte ich selbst nutzen, eine weitere Platine bei mir produktiv einsetzen, damit wäre dann man Hardwarevorrat aufgebraucht.

[rudolfkoenig]

Habe die erste Version von 16_STACKABLE.pm eingecheckt. Ich habe mir ein CUL+SCC Simulator geschrieben (contrib/CULsim.pl), und damit getestet, am Wochenende versuche ich es mit dem Geraet von Andreas.

Ich sehe STACKABLE als Nachfolger von STACKABLE_CC, da generischer, und erlaubt die Reinitialisierung der Ebene-2+ Module nach einem reconnect. Ich musste 00_CUL.pm und 00_ZWCUL.pm anpassen, die verwenden ab sofort auch DevIo_Write, statt den eigenen, leicht modifizierten Kopien dieser Funktion.

[rudolfkoenig]

Mein Test dem Geraet von Andreas:
- nach dem Einstecken erscheinen 3 USB-Geraete auf dem PC, ich kann aber nur mit dem ersten "sinnvoll" reden, wozu die anderen beiden gut sind, habe es nicht herausgefunden.
- es sind 3 CC1101 Module aufgeloetet, es steht jeweils 868MHz auf der Platine. Wenn man V,*V,**V,***V ausprobiert, dann kriegt man jeweils eine "normale" Versions-Antwort, der Reihe nach mit 868,433,868,868 als MHz-Angabe. Das mit 433 verwirrt mich etwas.
- Die Antworten auf ?, *?, **?, ***? sind auf Anhieb fuer mich auch unschluessig: sie werden immer kuerzer, die letzten beiden unterstuetzen kein FS20, nur noch ZWave (und E alias RWE?). Ich habe auf allen 4 Boards FS20 aktiviert, ohne Auswirkung: Pakete habe ich keine Empfangen.

Fuer ZWave Tests habe ich folgende fhem.cfg zum Monitoring verwendet:

Code Auswählen Erweitern

attr global logfile -
attr global modpath .
attr global statefile ./log/fhem.state.zwcul.scc
 
define zBase ZWCUL /dev/cu.usbmodemd0482191@38400 00000000 01
attr zBase.6 dataRate 9600
attr zBase verbose 5
   
define SCC1 STACKABLE zBase
define z9.6 ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z9.6 verbose 5
attr z9.6 dataRate 9600
   
define SCC2 STACKABLE z9.6
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k verbose 5
attr z40k dataRate 40k
 
define SCC3 STACKABLE z40k
define z100k ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z100k verbose 5
attr z100k dataRate 100k


wobei zBase nie was empfaengt, vermutlich entspricht es der unbestueckten Stelle. Das neue STACKABLE Modul scheint zuverlaessig zu funktionieren, ich habe FHEM haeufig gestartet oder den USB-Stecker gezogen/reingesteckt, mit jeweils dem erwarteten Verhalten.

Was ich sonst gemerkt habe:
- 9.6k Nachrichten werden zuverlaessig empfangen.
- 40k und 100k Nachrichten werden zwar empfangen, gefuehlt aber nur in <5% der Faelle. Ich konnte leider keine Systematik feststellen, wann es funktioniert, geschweige denn, wieso nicht.
- ein an der gleichen Stelle eingesteckter "original" CUL war deutlich zuverlaessiger, und hat gefuehlt in 100% der Faelle die Nachricht angezeigt. Natuerlich nur bei der einen eingestellten Datenrate.
- Ein Tausch der Datenraten-Zuordnung zu den einzelnen SCC-Ebenen hilft nicht: 9600 wird empfangen, 40k/100k nicht bzw. sehr selten.

@Andreas:  Hardware-Debugging ist nicht meine Staerke, und in a-culfw will ich mich im Moment auch nicht einarbeiten.
Da das Geraet in diesem Zustand fuer mich sinnlos ist, wuerde ich es gerne zurueck- oder irgendwohin weiterschicken.

[Ranseyer]

Hallo Rudolf,

das Gerät das du vor dir liegen hast ist eine recht frühe HW-Version des MAPLE-CUL.

Ich habe versucht das zu dokumentieren: https://wiki.fhem.de/wiki/MapleCUN
Das ist nur begonnen: https://wiki.fhem.de/wiki/MapleCUX-Platinen

Die zweite und dritte serielle Schnittstelle kannst Du ignorieren. Darüber könnte man weitere Serielle-HW an die freien UARTs des MAPLE hängen (mySensors, HM-MOD2-UART oder wie das heißt).

Die Einrichtung siehe dem ersten Wiki Eintrag funktioniert ganz gut bei mir.

[rudolfkoenig]

Danke, das erklaert Einiges. Gibt es einen Grund, warum es zwei Wiki-Seiten mit stark ueberlappenden Inhalt gibt?

Es bleibt trotztem dabei:
- Ich habs nochmal probiert, und bewusst nur Ebene zwei (*X21) aktiviert: ich kann kein FS20 empfangen.
- Empfang von ZWave auf 40k/100k ist sehr schlecht bzw. unbrauchbar.

[Ranseyer]

Gibt es einen Grund, warum es zwei Wiki-Seiten mit stark ueberlappenden Inhalt gibt?

Ja, weil die zweite noch absolut unfertig ist, ich aber die SW-Seite von der Umsetzung trennen will und bei der HW auch auf Details eingehen will die immer wieder gefragt werden.
Die HW hat auch nur teilweise mit MAPLE-CUX zu tun, zumindest dann wenn man erweitert:
-HM*UART
-MySensors
-RS485
-1Wire
-...

Zum Empfang von div Protokollen kann evtl Telekatz etwas sagen. Ich sende ihm mal den Link zu dieser Diskussion per PN.

[Telekatz]

SlowRF geht aktuell nur an in den ersten beiden Ebenen. Das kein FS20 in der zweiten Ebene empfangen wird liegt daran, dass nach einem Reset des EEPROMS die default Frequenz für diese Ebene bei 433MHz liegt. Für FS20 musst du noch die Frequenz umstellen. Außerdem hast du noch eine ältere Version der Firmware installiert. Bei der aktuellen Version würde ***V nicht funktionieren wenn der vierte Transceiver nicht bestückt ist.

Zu ZWave kann ich nichts sagen, da habe ich keine Geräte zum testen.

[A.Harrenberg]

Hi Rudi,

Mein Test dem Geraet von Andreas:
- nach dem Einstecken erscheinen 3 USB-Geraete auf dem PC, ich kann aber nur mit dem ersten "sinnvoll" reden, wozu die anderen beiden gut sind, habe es nicht herausgefunden.

das sind die beiden UART-Schnittstellen auf dem Gerät.

- es sind 3 CC1101 Module aufgeloetet, es steht jeweils 868MHz auf der Platine. Wenn man V,*V,**V,***V ausprobiert, dann kriegt man jeweils eine "normale" Versions-Antwort, der Reihe nach mit 868,433,868,868 als MHz-Angabe. Das mit 433 verwirrt mich etwas.

das dürfte der default der internen Initialisierung sein. Ich hatte das bei mir mit der stackable_cc und allen Module auf "Homematic"-Mode probiert, alle Transceiver haben empfangen.

- Die Antworten auf ?, *?, **?, ***? sind auf Anhieb fuer mich auch unschluessig: sie werden immer kuerzer, die letzten beiden unterstuetzen kein FS20, nur noch ZWave (und E alias RWE?). Ich habe auf allen 4 Boards FS20 aktiviert, ohne Auswirkung: Pakete habe ich keine Empfangen.

FS20 habe ich nicht, die Antworten müsste ich mir mal selber ansehen.

Fuer ZWave Tests habe ich folgende fhem.cfg zum Monitoring verwendet:

[...]

wobei zBase nie was empfaengt, vermutlich entspricht es der unbestueckten Stelle. Das neue STACKABLE Modul scheint zuverlaessig zu funktionieren, ich habe FHEM haeufig gestartet oder den USB-Stecker gezogen/reingesteckt, mit jeweils dem erwarteten Verhalten.

Was ich sonst gemerkt habe:
- 9.6k Nachrichten werden zuverlaessig empfangen.
- 40k und 100k Nachrichten werden zwar empfangen, gefuehlt aber nur in <5% der Faelle. Ich konnte leider keine Systematik feststellen, wann es funktioniert, geschweige denn, wieso nicht.
- ein an der gleichen Stelle eingesteckter "original" CUL war deutlich zuverlaessiger, und hat gefuehlt in 100% der Faelle die Nachricht angezeigt. Natuerlich nur bei der einen eingestellten Datenrate.
- Ein Tausch der Datenraten-Zuordnung zu den einzelnen SCC-Ebenen hilft nicht: 9600 wird empfangen, 40k/100k nicht bzw. sehr selten.

@Andreas:  Hardware-Debugging ist nicht meine Staerke, und in a-culfw will ich mich im Moment auch nicht einarbeiten.
Da das Geraet in diesem Zustand fuer mich sinnlos ist, wuerde ich es gerne zurueck- oder irgendwohin weiterschicken.

Empfangsprobleme mit 40/100 k wären natürlich dumm, da dies ja ~98% der Übertragungen wären...

Ich bin jetzt wieder zu Hause und kann mich nächste Woche hoffentlich etwas intensiver damit beschäftigen. Anscheinend gibt es zwischenzeitlich auch eine neuere Version der Firmware die zumindest die "V" Probleme beheben sollten. Ich werde mein Gerät mal updaten und schauen was ich damit hinbekomme.
Ich werde mir mal den ZWave-Code in der aculfw anschauen ob dort wirklich alles identisch zur originalen culfw umgesetzt ist. Nicht das bei der Initialisierung des CC1100 was fehlt.
Wenn ich hier weiterkomme kannst Du mir das Ding ja mal zurückschicken dann kann ich es auch updaten.

Vielen Dank schonmal für das neue STACKABLE Modul!

Gruß,
Andreas.

[rudolfkoenig]

@Telekatz: Danke fuer den Hinweis, haette ich selbst denken koennen. Nach der Umstellung der Ebene2 auf 868MHz funkioniert es. Am Anfang kam zwar eine Menge o.* (fuer CUL_REDIRECT ?), aber nach einem Neustart von FHEM schaut es mit SlowRF (vulgo FS20) ok aus. Btw. die "letzte" Ebene ist bestueckt, nur die Erste nicht (also die mit V ohne *).

Fuer mich bleibt also nur das Problem des unbrauchbaren Empfangs bei ZWave@40k oder 100k, alles andere verstehe ich jetzt, bzw. es funktoniert wie gewollt.

@Andreas: es eilt nicht