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...
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).
ZitatP.S.: In der maintainer.txt ist 00_ZWCul.pm gar nicht enthalten...
Danke, habs eingetragen.
Hi Rudi,
Zitat von: rudolfkoenig am 11 März 2017, 08:31:13
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.
Zitat von: rudolfkoenig am 11 März 2017, 08:31:13
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 ;D 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.
a-culfw loggt bei mir problemlos ZWave über ZWCUL.
Hi Rudi,
Zitat von: A.Harrenberg am 11 März 2017, 09:15:53
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 ;D
Scheint soweit i.O. zu sein, empfängt zumindest auf Homematic.
Zitat von: krikan am 11 März 2017, 10:13:07
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.
Zitatalso 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:
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_*
Hi Rudi,
Zitat von: rudolfkoenig am 12 März 2017, 12:23:21
Das klingt nach einem Erpressungsversuch :)
raffiniert gemacht, oder? ;D
Zitat von: rudolfkoenig am 12 März 2017, 12:23:21
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.
Zitat von: rudolfkoenig am 12 März 2017, 12:23:21
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?
Zitat von: rudolfkoenig am 12 März 2017, 12:23:21
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.
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.
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:
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.
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.
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.
ZitatGibt 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.
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.
Hi Rudi,
Zitat von: rudolfkoenig am 31 März 2017, 13:11:57
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.
Zitat von: rudolfkoenig am 31 März 2017, 13:11:57
- 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.
Zitat von: rudolfkoenig am 31 März 2017, 13:11:57
- 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.
Zitat von: rudolfkoenig am 31 März 2017, 13:11:57
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.
@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 :)
Hi,
Zitat von: rudolfkoenig am 01 April 2017, 14:31:49
@Andreas: es eilt nicht :)
ich schau erst mal das ich das überhaupt soweit ans Laufen bekomme... ,-)
Wenn ich dann das gleiche Problem mit 40/100k Empfang habe (wovon ich ausgehe) dann ist da sicherlich ein wenig debugging in der aculfw bzw. bei den Einstellungen des CC1101 angesagt. Ist ja schon eine Weile her das ich mich mit dem CC1101 beschäftigt habe, das wird dauern...
Aber wenn es soweit schon mal prinzipiell funktioniert wäre ja schon mal Klasse!
Gruß,
Andreas.
Hi Rudi,
ich habe mein Gerät jetzt mit der letzten FW geflasht und in Anlehnung an Dein Beispiel so eingerichtet (ich habe ein 433er Modul an der ersten Stelle eingesteckt...):
define mCUL CUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00 0000
attr mCUL rfmode SlowRF
attr mCUL room Maple
attr mCUL verbose 5
define SCC1 STACKABLE mCUL
define z100k ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z100k dataRate 100k
attr z100k room Maple
attr z100k verbose 5
define SCC2 STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k dataRate 40k
attr z40k room Maple
attr z40k verbose 5
define SCC3 STACKABLE z40k
define z9.6 ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z9.6 dataRate 9600
attr z9.6 room Maple
attr z9.6 verbose 5
Mit "deiner" Reihenfolge der Datenraten empfange ich auch nur 9k6 Nachrichten, wenn ich dann testweise einen der anderen Empfänger auf 9k6 umstelle erhalte ich "UNKNOWN msg" Einträge. Daher habe ich die Reihenfolge jetzt mal bewusst umgedreht, diese Einträge bleiben aber... Irgendetwas scheint da beim Stacken nicht zu klappen...
2017.04.02 08:40:51.286 4: CUL_Parse: mCUL ***zE015DFED40810317010011E0600D09003105014209080F
2017.04.02 08:40:51.286 5: mCUL: dispatch ***zE015DFED40810317010011E0600D09003105014209080F
2017.04.02 08:40:51.287 5: z100k: dispatch **zE015DFED40810317010011E0600D09003105014209080F
2017.04.02 08:40:51.287 4: z100k: UNKNOWN msg **zE015DFED40810317010011E0600D09003105014209080F
2017.04.02 08:40:51.326 5: CUL/RAW: /***zE015DFED0181030D400310E005
2017.04.02 08:40:51.326 4: CUL_Parse: mCUL ***zE015DFED0181030D400310E005
2017.04.02 08:40:51.326 5: mCUL: dispatch ***zE015DFED0181030D400310E005
2017.04.02 08:40:51.327 5: z100k: dispatch **zE015DFED0181030D400310E005
2017.04.02 08:40:51.327 4: z100k: UNKNOWN msg **zE015DFED0181030D400310E005
2017.04.02 08:40:51.330 4: ZWDongle_Read ZWDongle_0: rcvd 000400400a600d0900310501420908 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.02 08:40:51.330 5: SW: 06
2017.04.02 08:40:51.331 5: ZWDongle_0: dispatch 000400400a600d0900310501420908
2017.04.02 08:40:51.332 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0a600d0900310501420908 CB:00
2017.04.02 08:40:51.360 5: CUL/RAW: /***zE015DFED01C1030D40031FE04A
2017.04.02 08:40:51.360 4: CUL_Parse: mCUL ***zE015DFED01C1030D40031FE04A
2017.04.02 08:40:51.361 5: mCUL: dispatch ***zE015DFED01C1030D40031FE04A
2017.04.02 08:40:51.361 5: z100k: dispatch **zE015DFED01C1030D40031FE04A
2017.04.02 08:40:51.361 4: z100k: UNKNOWN msg **zE015DFED01C1030D40031FE04A
2017.04.02 08:40:51.390 5: CUL/RAW: /***zE015DFED4003030AE092
2017.04.02 08:40:51.390 4: CUL_Parse: mCUL ***zE015DFED4003030AE092
2017.04.02 08:40:51.390 5: mCUL: dispatch ***zE015DFED4003030AE092
2017.04.02 08:40:51.390 5: z100k: dispatch **zE015DFED4003030AE092
2017.04.02 08:40:51.390 4: z100k: UNKNOWN msg **zE015DFED4003030AE092
Die Nachrichten kommen ja anscheinend von der obersten Ebene die mit 9k6 empfängt, angezeigt werden aber nur Nachrichten mit z100k (zweite Ebene) und mcul (unterste Ebene).
Habe ich jetzt doch einen Fehler beim Stacken gemacht?
Ich bin auch etwas verwundert über die Nachrichten die da vom CUL kommen aber NICHT von meinem ZWDongle angezeigt werden...
Gruß,
Andreas
Hi Rudi,
kleiner Nachtrag, so sieht es aus wenn ich alle drei Empfänger auf 9k6 umstelle... Verstehe ich auch nicht wirklich. Ich hätte erwartet das alle drei dann was dekodieren, aber auch hier nur Einträge mit z100k, dafür aber weniger (gar keine) "UNKNOWN msg"...
2017.04.02 09:13:47.078 4: CUL_Parse: mCUL *zE015DFED40810716010010E07105000000FF0708009D
2017.04.02 09:13:47.078 5: mCUL: dispatch *zE015DFED40810716010010E07105000000FF0708009D
2017.04.02 09:13:47.079 5: z100k e015dfed S:40 F:81 f:0 SN:7 L:16 T:01 R:0010e0 P:7105000000ff070800 C:9d
2017.04.02 09:13:47.079 5: F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:e0
2017.04.02 09:13:47.118 5: CUL/RAW: /*zE015DFED40810716010011E07105000000FF0708009C
2017.04.02 09:13:47.118 4: CUL_Parse: mCUL *zE015DFED40810716010011E07105000000FF0708009C
2017.04.02 09:13:47.118 5: mCUL: dispatch *zE015DFED40810716010011E07105000000FF0708009C
2017.04.02 09:13:47.118 5: z100k e015dfed S:40 F:81 f:0 SN:7 L:16 T:01 R:0011e0 P:7105000000ff070800 C:9c
2017.04.02 09:13:47.118 5: F: singleCast routed, rf:00 hopCnt:1 hopPos:1 hops:e0
2017.04.02 09:13:47.150 4: ZWDongle_Read ZWDongle_0: rcvd 00040040097105000000ff070800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.02 09:13:47.150 5: SW: 06
2017.04.02 09:13:47.152 5: ZWDongle_0: dispatch 00040040097105000000ff070800
2017.04.02 09:13:47.152 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:097105000000ff070800 CB:00
2017.04.02 09:13:47.158 5: CUL/RAW: /*zE015DFED0181070D400310E001
2017.04.02 09:13:47.158 4: CUL_Parse: mCUL *zE015DFED0181070D400310E001
2017.04.02 09:13:47.158 5: mCUL: dispatch *zE015DFED0181070D400310E001
2017.04.02 09:13:47.158 5: z100k e015dfed S:01 F:81 f:0 SN:7 L:0d T:40 R:0310e0 P: C:01
2017.04.02 09:13:47.159 5: F: singleCast routed, rf:03 hopCnt:1 hopPos:0 hops:e0
2017.04.02 09:13:47.193 5: CUL/RAW: /*zE015DFED01C1070D40031FE04E
2017.04.02 09:13:47.193 4: CUL_Parse: mCUL *zE015DFED01C1070D40031FE04E
2017.04.02 09:13:47.194 5: mCUL: dispatch *zE015DFED01C1070D40031FE04E
2017.04.02 09:13:47.194 5: z100k e015dfed S:01 F:c1 f:0 SN:7 L:0d T:40 R:031fe0 P: C:4e
2017.04.02 09:13:47.194 5: F: singleCast ackReq routed, rf:03 hopCnt:1 hopPos:15 hops:e0
2017.04.02 09:13:47.222 5: CUL/RAW: /*zE015DFED4003070AE096
2017.04.02 09:13:47.222 4: CUL_Parse: mCUL *zE015DFED4003070AE096
2017.04.02 09:13:47.222 5: mCUL: dispatch *zE015DFED4003070AE096
2017.04.02 09:13:47.223 5: z100k e015dfed S:40 F:03 f:0 SN:7 L:0a T:e0 P: C:96
2017.04.02 09:13:47.223 5: F: ack
Wenn Du mehr Info benötigt sag Bitte Bescheid.
Gruß,
Andreas.
Ich habe den schwarzen Kasten an meinem PC angeschlossen, ein FHEM mit deiner Definition gestartet, und dann per telnet "dein" Paket aus Beitrag #16 injiziert:
{ Dispatch($defs{mCUL}, "***zE015DFED40810317010011E0600D09003105014209080F", undef) }
Laut Log haben alle Module brav die Daten weitergeschickt, als Ergebnis sehe ich im Log
2017.04.03 12:45:14 5: mCUL: dispatch ***zE015DFED40810317010011E0600D09003105014209080F
2017.04.03 12:45:14 5: z100k: dispatch **zE015DFED40810317010011E0600D09003105014209080F
2017.04.03 12:45:14 5: z40k: dispatch *zE015DFED40810317010011E0600D09003105014209080F
2017.04.03 12:45:14 5: z9.6 e015dfed S:40 F:81 f:0 SN:3 L:17 T:01 R:0011e0 P:600d0900310501420908 C:0f
2017.04.03 12:45:14 5: F: singleCast routed, rf:00 hopCnt:1 hopPos:1 hops:e0
Works as designed. Ich vermute, du arbeitest nicht mit einer aktuellen FHEM, ich musste DevIo/CUL/ZWCUL auch aendern.
Ich kann die gleichen Ausgaben auch ohne Geraet mit contrib/CULsim.pl nachstellen, dafuer muss ich nur die Definition von mCUL aendern auf
define mCUL CUL localhost:12345 0000
Ich habe das Geraet nach meinen Tests nicht abgesteckt, und ich bekomme T, *T und **T Nachrichten.
Das ist deswegen beunruhigend, weil in ZWave Modus keine SlowRF Pakete ankomen sollten, und Ebene 1 ist nicht bestueckt.
Die Initialisierung sollte korrekt abgelaufen sein, hier das Log (etwas gefiltert):
2017.04.03 12:48:05 5: mCUL sending *V
2017.04.03 12:48:05 5: mCUL sending *zi0000000001
2017.04.03 12:48:05 5: mCUL sending *zm4
2017.04.03 12:48:05 5: mCUL sending *zm1
2017.04.03 12:48:06 5: mCUL sending **V
2017.04.03 12:48:06 5: mCUL sending **zi0000000001
2017.04.03 12:48:06 5: mCUL sending **zm4
2017.04.03 12:48:06 5: mCUL sending **zm4
2017.04.03 12:48:06 5: mCUL sending ***V
2017.04.03 12:48:06 5: mCUL sending ***zi0000000001
2017.04.03 12:48:06 5: mCUL sending ***zm4
2017.04.03 12:48:06 5: mCUL sending ***zm9
Hi Rudi,
danke für die RM. Eigentlich sollte mein FHEM aktuell sein, hatte vorher ein "svn update ." gemacht...
Ich schau aber noch mal genauer nach, manchmal werden mir einige Files als geändert markiert und werden nicht vernünftig aktualisiert. Mir ist gestern abend nämlich auch noch aufgefallen das ich mit dem CUL gar nichts mehr empfange ,-(
Was die Empfangsprobleme angeht bin ich noch nicht wirklich weiter gekommen. Mir ist zwar aufgefallen das einige Register des cc1101 nicht wie in der config stehen, das sind aber die frq-calibration register, ich muss das noch mal nachlesen, ich denke aber das sich die im Betrieb sowieso ändern.
In dem Zusammenhang ist mir aber aufgefallen das z.B. ein C99 (auch am CUL) nicht mehr korrekt ausgeführt wird. Im Code sollen eigentlich die Register 0x00-0x30 ausgegeben werden und nach jeweils 8 Registern ein Zeilenumbruch gesendet werden. Es werden nur die ersten 8 Register ausgegeben, danach kommt nichts mehr. Ich habe mir das jetzt mal als eine lange Zeile ausgeben lassen. Anscheinend wird durch das "DNL()" die Ausgabe beendet...
Schreiben konnte ich die Register gestern abend auch irgendwie nicht, ich denke aber das dies dann auch im Zusammenhang mit einem Versionswirrwarr stehen könnte, so wie Du vermutest.
Im Zweifelsfall muss ich mein Testsystem doch mal platt machen und neu aufsetzen.
Gruß,
Andreas.
Hi Rudi,
Zitat von: rudolfkoenig am 03 April 2017, 13:05:19
Ich habe das Geraet nach meinen Tests nicht abgesteckt, und ich bekomme T, *T und **T Nachrichten.
Das ist deswegen beunruhigend, weil in ZWave Modus keine SlowRF Pakete ankomen sollten, und Ebene 1 ist nicht bestueckt.
Die Initialisierung sollte korrekt abgelaufen sein, hier das Log (etwas gefiltert):
in meiner Definition ist slowRF auf der Ebene 1 ja aktiviert, aber ohne Empfänger sollte da natürlich nichts passieren. Könnte sein das dort was mit der internen Initialisierung durcheinander kommt... Wobei da bei Dir ja was in der dritten Ebene ankommt und dann durchgereicht wird... SEHR merkwürdig.
Ich habe ja bereits ein paar Debug-Zeilen in die aculfw eingebaut und konnte gestern schon beobachten das ich mit 100k extrem viele lange Nachrichten habe die dann weggeworfen werden noch bevor eine CS gerechnet wird und auf 40k die Pakete zu 98% wegen falscher CS weggeworfen werden. Ich muss da noch mehr Debug einbauen um mir diese Teilpakete ansehen zu können, habe da aber ein paar Probleme mit dem Kompilieren ,-(
Gruß,
Andreas.
Hi Rudi,
evtl. könnte es sein das bei der Initialisierung bei Dir der erste Bestückte auf SlowRF umgestellt wird, d.h. alles "verschoben" ist. Dann dürfte es aber eigentlich Probleme mit dem letzten ZWave-Kanal geben, der wäre ja physikalisch gar nicht mehr vorhanden.
Ich kann bei mir ja mal das 433erModul abstecken und sehen was passiert.
Gruß,
Andreas.
Hallo Rudi,
ich habe jetzt mal weiter rumprobiert...
Bei mir waren einige ZWave-Dateien wirklich nicht identisch mit der aktuellen Version weil ich da teilweise mal ein paar Logzeilen reingebaut hatte und die jetzt immer mit reingemergt wurden -> funktional habe ich da keine Unterschiede gesehen.
Ich habe mir dann ein neues fhem aus dem SVN gezogen und meine Definition dort in die fhem.cfg gepackt -> Läuft!
Ich habe dann meine Version der 10_ZWave.pm (da sind noch ein paar angefangene Änderungen für einige Klassen drin) rüberkopiert -> Läuft immer noch!
Dann habe ich meine alte cfg rüberkopiert -> Läuft nicht mehr! -> Problem liegt in der cfg datei!
Da ich einige ZWave-Testgeräte mit recht vielen sub-devices habe ist meine Konfig recht umfangreich. Ich habe dann mal angefangen alles mögliche aus- und wieder reinzukommentieren um das Problem einzugrenzen.
In der Version wie hier gepostet funktioniert das bei mir auch, sobald ich aber den z.B. den normal auskommentierten Block für Device 224 (#define ZWave_SWITCH_BINARY_224 ZWave e015dfed 224) einkommentieren funktionert das ganze wieder nicht. Das gleiche passiert auch wenn ich das mit dem nächsten Device 232 mache.
Irgendwie stört sich das System daran das da noch ein ZWDongle mit Geräte im System definiert ist. Ich bin da mit meinem Latein am Ende.
Hast Du noch eine Idee was da passiert und was ich evtl. noch probieren könnte?
Außerdem initialisiert sich das Ding nicht bei jedem Start von FHEM vernünftigt... Beim Starten kommt dann was von "Can't open /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00: Das Gerät oder die Ressource ist belegt", später kommt dann zwar "/dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00 reappeared (mCUL)", es wird aber nicht initialisiert.
Irgendwie ist da bei mir der Wurm drin...
Ich werde jetzt erst mal mit der neuen/nackten Installation weiter an dem Empfangsproblem arbeiten, ich würde aber dennoch gerne verstehen was bei den anderen Prolemen passiert...
attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global comment ./log/fhem-%Y-%m.log
attr global logfile -
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth.\
telnetPort has no associated allowed device with password/globalpassword.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global mseclog 1
attr global stacktrace 1
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
attr ZWDongle_0 neighborListPos 476,165
attr ZWDongle_0 networkKey 0102030405060708090a0b0c0d0e0f10
attr ZWDongle_0 room ZWave
attr ZWDongle_0 verbose 5
#define ZWave_SWITCH_BINARY_224 ZWave e015dfed 224
#attr ZWave_SWITCH_BINARY_224 IODev ZWDongle_0
#attr ZWave_SWITCH_BINARY_224 classes ZWAVEPLUS_INFO SWITCH_BINARY CONFIGURATION ASSOCIATION ASSOCIATION_GRP_INFO MANUFACTURER_SPECIFIC SCENE_ACTIVATION SCENE_ACTUATOR_CONF VERSION FIRMWARE_UPDATE_MD POWERLEVEL SECURITY DEVICE_RESET_LOCALLY HAIL MARK DEVICE_RESET_LOCALLY HAIL BASIC
#attr ZWave_SWITCH_BINARY_224 neighborListPos 139.48240978068472,382.6501109083883
#attr ZWave_SWITCH_BINARY_224 room ZWave
#attr ZWave_SWITCH_BINARY_224 secure_classes SWITCH_BINARY CONFIGURATION ASSOCIATION ASSOCIATION_GRP_INFO MANUFACTURER_SPECIFIC SCENE_ACTIVATION SCENE_ACTUATOR_CONF VERSION POWERLEVEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY HAIL MARK
#attr ZWave_SWITCH_BINARY_224 vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SCENE_ACTUATOR_CONF:1 SECURITY:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
#attr ZWave_SWITCH_BINARY_224 verbose 5
#define FileLog_ZWave_SWITCH_BINARY_224 FileLog ./log/ZWave_SWITCH_BINARY_224-%Y.log ZWave_SWITCH_BINARY_224
#attr FileLog_ZWave_SWITCH_BINARY_224 logtype text
#attr FileLog_ZWave_SWITCH_BINARY_224 room ZWave
#~ define ZWave_ENTRY_CONTROL_232 ZWave e015dfed 232
#~ attr ZWave_ENTRY_CONTROL_232 IODev ZWDongle_0
#~ attr ZWave_ENTRY_CONTROL_232 classes ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY BATTERY POWERLEVEL APPLICATION_STATUS DOOR_LOCK CONFIGURATION ALARM TIME TIME_PARAMETERS SCHEDULE_ENTRY_LOCK USER_CODE NETWORK_SCHEDULE ASSOCIATION ASSOCIATION_GRP_INFO FIRMWARE_UPDATE_MD VERSION MARK
#~ attr ZWave_ENTRY_CONTROL_232 neighborListPos 489.57036157359227,381.18445521066246
#~ attr ZWave_ENTRY_CONTROL_232 room ZWave
#~ attr ZWave_ENTRY_CONTROL_232 secure_classes DOOR_LOCK CONFIGURATION ALARM TIME TIME_PARAMETERS SCHEDULE_ENTRY_LOCK USER_CODE NETWORK_SCHEDULE ASSOCIATION ASSOCIATION_GRP_INFO FIRMWARE_UPDATE_MD VERSION MARK
#~ attr ZWave_ENTRY_CONTROL_232 vclasses ALARM:3 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 DOOR_LOCK:2 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 NETWORK_SCHEDULE:1 POWERLEVEL:1 SCHEDULE_ENTRY_LOCK:1 SECURITY:1 TIME:2 TIME_PARAMETERS:1 USER_CODE:1 VERSION:2 ZWAVEPLUS_INFO:2
#~ define FileLog_ZWave_ENTRY_CONTROL_232 FileLog ./log/ZWave_ENTRY_CONTROL_232-%Y.log ZWave_ENTRY_CONTROL_232
#~ attr FileLog_ZWave_ENTRY_CONTROL_232 logtype text
#~ attr FileLog_ZWave_ENTRY_CONTROL_232 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_8 ZWave e015dfed 8
#~ attr ZWave_SENSOR_MULTILEVEL_8 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_8 WNMI_delay 0.5
#~ attr ZWave_SENSOR_MULTILEVEL_8 classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION SECURITY FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY WAKE_UP
#~ attr ZWave_SENSOR_MULTILEVEL_8 extendedAlarmReadings 2
#~ attr ZWave_SENSOR_MULTILEVEL_8 neighborListPos 89.30388118874806,19.586558272121408
#~ attr ZWave_SENSOR_MULTILEVEL_8 noWakeupForApplicationUpdate 1
#~ attr ZWave_SENSOR_MULTILEVEL_8 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_8 secure_classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC WAKE_UP ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION SECURITY FIRMWARE_UPDATE_MD MARK
#~ attr ZWave_SENSOR_MULTILEVEL_8 vclasses ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
#~ attr ZWave_SENSOR_MULTILEVEL_8 verbose 5
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_8 FileLog ./log/ZWave_SENSOR_MULTILEVEL_8-%Y.log ZWave_SENSOR_MULTILEVEL_8
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_8 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_8 room ZWave
#~ define ZWave_SWITCH_BINARY_9 ZWave e015dfed 9
#~ attr ZWave_SWITCH_BINARY_9 IODev ZWDongle_0
#~ attr ZWave_SWITCH_BINARY_9 classes SWITCH_BINARY METER MANUFACTURER_SPECIFIC VERSION BASIC ALARM CONFIGURATION SWITCH_ALL ASSOCIATION INDICATOR PROTECTION CRC_16_ENCAP
#~ attr ZWave_SWITCH_BINARY_9 neighborListPos 754.720426600999,143.38266358334994
#~ attr ZWave_SWITCH_BINARY_9 room ZWave
#~ attr ZWave_SWITCH_BINARY_9 useCRC16 1
#~ attr ZWave_SWITCH_BINARY_9 vclasses ALARM:1 ASSOCIATION:1 BASIC:1 CONFIGURATION:1 CRC_16_ENCAP:1 INDICATOR:1 MANUFACTURER_SPECIFIC:2 METER:2 PROTECTION:2 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1
#~ define FileLog_ZWave_SWITCH_BINARY_9 FileLog ./log/ZWave_SWITCH_BINARY_9-%Y.log ZWave_SWITCH_BINARY_9
#~ attr FileLog_ZWave_SWITCH_BINARY_9 logtype text
#~ attr FileLog_ZWave_SWITCH_BINARY_9 room ZWave
#~ define ZWave_SWITCH_BINARY_23 ZWave e015dfed 23
#~ attr ZWave_SWITCH_BINARY_23 IODev ZWDongle_0
#~ attr ZWave_SWITCH_BINARY_23 classes ZWAVEPLUS_INFO SWITCH_BINARY SWITCH_MULTILEVEL COLOR_CONTROL CONFIGURATION SWITCH_ALL METER CLOCK ASSOCIATION ASSOCIATION_GRP_INFO MANUFACTURER_SPECIFIC VERSION FIRMWARE_UPDATE_MD POWERLEVEL MARK DEVICE_RESET_LOCALLY HAIL
#~ attr ZWave_SWITCH_BINARY_23 neighborListPos 516.459876529764,15.945958798350532
#~ attr ZWave_SWITCH_BINARY_23 room ZWave
#~ attr ZWave_SWITCH_BINARY_23 vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CLOCK:1 COLOR_CONTROL:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 HAIL:1 MANUFACTURER_SPECIFIC:2 METER:3 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:2 VERSION:2 ZWAVEPLUS_INFO:2
#~ define FileLog_ZWave_SWITCH_BINARY_23 FileLog ./log/ZWave_SWITCH_BINARY_23-%Y.log ZWave_SWITCH_BINARY_23
#~ attr FileLog_ZWave_SWITCH_BINARY_23 logtype text
#~ attr FileLog_ZWave_SWITCH_BINARY_23 room ZWave
#~ define zwc ZWCUL /dev/serial/by-id/usb-busware.de_CUL868-if00 00000000 01
#~ attr zwc dataRate 100k
#~ attr zwc intruderMode 1
#~ attr zwc room ZWave
#~ attr zwc verbose 5
#~ define ZWave_SWITCH_REMOTE_53 ZWave e015dfed 53
#~ attr ZWave_SWITCH_REMOTE_53 IODev ZWDongle_0
#~ attr ZWave_SWITCH_REMOTE_53 classes BATTERY CONFIGURATION PROTECTION VERSION MANUFACTURER_SPECIFIC ASSOCIATION MULTI_CHANNEL_ASSOCIATION SCENE_CONTROLLER_CONF NODE_NAMING WAKE_UP
#~ attr ZWave_SWITCH_REMOTE_53 neighborListPos 756.9044901947922,330.70291845582113
#~ attr ZWave_SWITCH_REMOTE_53 room ZWave
#~ attr ZWave_SWITCH_REMOTE_53 vclasses ASSOCIATION:2 BATTERY:1 CONFIGURATION:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL_ASSOCIATION:2 NODE_NAMING:1 PROTECTION:1 SCENE_CONTROLLER_CONF:1 VERSION:1 WAKE_UP:2
#~ attr ZWave_SWITCH_REMOTE_53 verbose 5
#~ define FileLog_ZWave_SWITCH_REMOTE_53 FileLog ./log/ZWave_SWITCH_REMOTE_53-%Y.log ZWave_SWITCH_REMOTE_53
#~ attr FileLog_ZWave_SWITCH_REMOTE_53 logtype text
#~ attr FileLog_ZWave_SWITCH_REMOTE_53 room ZWave
#~ define ZWave_SWITCH_MULTILEVEL_64 ZWave e015dfed 64
#~ attr ZWave_SWITCH_MULTILEVEL_64 IODev ZWDongle_0
#~ attr ZWave_SWITCH_MULTILEVEL_64 classes ZWAVEPLUS_INFO BASIC SWITCH_BINARY SWITCH_MULTILEVEL SENSOR_BINARY ALARM SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC
#~ attr ZWave_SWITCH_MULTILEVEL_64 neighborListPos 8.562616990831259,152.07853627485053
#~ attr ZWave_SWITCH_MULTILEVEL_64 room ZWave
#~ attr ZWave_SWITCH_MULTILEVEL_64 vclasses ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:7 SWITCH_BINARY:1 SWITCH_MULTILEVEL:1 VERSION:2 ZWAVEPLUS_INFO:2
#~ attr ZWave_SWITCH_MULTILEVEL_64 verbose 5
#~ define FileLog_ZWave_SWITCH_MULTILEVEL_64 FileLog ./log/ZWave_SWITCH_MULTILEVEL_64-%Y.log ZWave_SWITCH_MULTILEVEL_64
#~ attr FileLog_ZWave_SWITCH_MULTILEVEL_64 logtype text
#~ attr FileLog_ZWave_SWITCH_MULTILEVEL_64 room ZWave
#~ attr FileLog_ZWave_SWITCH_MULTILEVEL_64 verbose 5
#~ define ZWave_SWITCH_MULTILEVEL_64.01 ZWave e015dfed 16385
#~ attr ZWave_SWITCH_MULTILEVEL_64.01 IODev ZWDongle_0
#~ attr ZWave_SWITCH_MULTILEVEL_64.01 classes SWITCH_MULTILEVEL
#~ attr ZWave_SWITCH_MULTILEVEL_64.01 room ZWave
#~ define FileLog_ZWave_SWITCH_MULTILEVEL_64.01 FileLog ./log/ZWave_SWITCH_MULTILEVEL_64.01-%Y.log ZWave_SWITCH_MULTILEVEL_64.01
#~ attr FileLog_ZWave_SWITCH_MULTILEVEL_64.01 logtype text
#~ attr FileLog_ZWave_SWITCH_MULTILEVEL_64.01 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_64.02 ZWave e015dfed 16386
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 event-aggregator DHT11Mean300:300:linear:mean
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 stateFormat temperature
#~ attr ZWave_SENSOR_MULTILEVEL_64.02 userReadings DHT11Mean300 { sprintf('%0d', (ReadingsNum("ZWave_SENSOR_MULTILEVEL_64.02", "temperature",0)));;}
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_64.02 FileLog ./log/ZWave_SENSOR_MULTILEVEL_64.02-%Y.log ZWave_SENSOR_MULTILEVEL_64.02
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.02 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.02 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_64.03 ZWave e015dfed 16387
#~ attr ZWave_SENSOR_MULTILEVEL_64.03 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_64.03 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_64.03 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_64.03 stateFormat humidity
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_64.03 FileLog ./log/ZWave_SENSOR_MULTILEVEL_64.03-%Y.log ZWave_SENSOR_MULTILEVEL_64.03
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.03 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.03 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_64.04 ZWave e015dfed 16388
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 event-aggregator LuminanceMean300:300:linear:mean
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 stateFormat luminance
#~ attr ZWave_SENSOR_MULTILEVEL_64.04 userReadings LuminanceMean300 { sprintf('%0d', (ReadingsNum("ZWave_SENSOR_MULTILEVEL_64.04", "luminance",0)));;}
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_64.04 FileLog ./log/ZWave_SENSOR_MULTILEVEL_64.04-%Y.log ZWave_SENSOR_MULTILEVEL_64.04
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.04 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.04 room ZWave
#~ define ZWave_ALARM_64.05 ZWave e015dfed 16389
#~ attr ZWave_ALARM_64.05 IODev ZWDongle_0
#~ attr ZWave_ALARM_64.05 classes ALARM SENSOR_BINARY
#~ attr ZWave_ALARM_64.05 room ZWave
#~ attr ZWave_ALARM_64.05 stateFormat alarm
#~ define FileLog_ZWave_ALARM_64.05 FileLog ./log/ZWave_ALARM_64.05-%Y.log ZWave_ALARM_64.05
#~ attr FileLog_ZWave_ALARM_64.05 logtype text
#~ attr FileLog_ZWave_ALARM_64.05 room ZWave
#~ define ZWave_SWITCH_BINARY_64.06 ZWave e015dfed 16390
#~ attr ZWave_SWITCH_BINARY_64.06 IODev ZWDongle_0
#~ attr ZWave_SWITCH_BINARY_64.06 classes SWITCH_BINARY
#~ attr ZWave_SWITCH_BINARY_64.06 room ZWave
#~ define FileLog_ZWave_SWITCH_BINARY_64.06 FileLog ./log/ZWave_SWITCH_BINARY_64.06-%Y.log ZWave_SWITCH_BINARY_64.06
#~ attr FileLog_ZWave_SWITCH_BINARY_64.06 logtype text
#~ attr FileLog_ZWave_SWITCH_BINARY_64.06 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_64.07 ZWave e015dfed 16391
#~ attr ZWave_SENSOR_MULTILEVEL_64.07 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_64.07 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_64.07 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_64.07 stateFormat temperature
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_64.07 FileLog ./log/ZWave_SENSOR_MULTILEVEL_64.07-%Y.log ZWave_SENSOR_MULTILEVEL_64.07
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.07 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.07 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_64.08 ZWave e015dfed 16392
#~ attr ZWave_SENSOR_MULTILEVEL_64.08 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_64.08 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_64.08 event-aggregator Luftdruck2:300:linear:mean
#~ attr ZWave_SENSOR_MULTILEVEL_64.08 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_64.08 stateFormat LuftdruckNN
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_64.08 FileLog ./log/ZWave_SENSOR_MULTILEVEL_64.08-%Y.log ZWave_SENSOR_MULTILEVEL_64.08
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.08 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_64.08 room ZWave
#~ define SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 SVG FileLog_ZWave_SENSOR_MULTILEVEL_64.02:SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1:CURRENT
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 captionLeft 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 endPlotNow 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 fixedrange 2days
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 plotsize 800,240
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.02_1 room test,Z-Uno_Diagramme
#~ define SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1 SVG FileLog_ZWave_SENSOR_MULTILEVEL_64.04:SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1:CURRENT
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1 captionLeft 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1 endPlotNow 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1 fixedrange 2days
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.04_1 room Z-Uno_Diagramme
#~ define SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 SVG FileLog_ZWave_SENSOR_MULTILEVEL_64.08:SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1:CURRENT
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 captionLeft 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 endPlotNow 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 fixedrange 2days
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 plotsize 800,240
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.08_1 room Z-Uno_Diagramme,test
#~ define ZWave_Node_64.9 ZWave e015dfed 16393
#~ attr ZWave_Node_64.9 IODev ZWDongle_0
#~ attr ZWave_Node_64.9 room ZWave
#~ attr ZWave_Node_64.9 stateFormat temperature
#~ define FileLog_ZWave_Node_64.9 FileLog ./log/ZWave_Node_64.9-%Y.log ZWave_Node_64.9
#~ attr FileLog_ZWave_Node_64.9 logtype text
#~ attr FileLog_ZWave_Node_64.9 room ZWave
#~ define SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1 SVG FileLog_ZWave_SENSOR_MULTILEVEL_64.03:SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1:CURRENT
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1 captionLeft 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1 endPlotNow 1
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1 fixedrange 2days
#~ attr SVG_FileLog_ZWave_SENSOR_MULTILEVEL_64.03_1 room Z-Uno_Diagramme
#~ define ZWave_SENSOR_MULTILEVEL_65 ZWave e015dfed 65
#~ attr ZWave_SENSOR_MULTILEVEL_65 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_65 classes ZWAVEPLUS_INFO DEVICE_RESET_LOCALLY MANUFACTURER_SPECIFIC POWERLEVEL FIRMWARE_UPDATE_MD VERSION SENSOR_MULTILEVEL MULTI_CHANNEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION BATTERY MARK BASIC
#~ attr ZWave_SENSOR_MULTILEVEL_65 neighborListPos 6.580839306765824,224.50537212769495
#~ attr ZWave_SENSOR_MULTILEVEL_65 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_65 vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 BASIC:2 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SENSOR_MULTILEVEL:7 VERSION:2 ZWAVEPLUS_INFO:2
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_65 FileLog ./log/ZWave_SENSOR_MULTILEVEL_65-%Y.log ZWave_SENSOR_MULTILEVEL_65
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_65 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_65 room ZWave
#~ define Qubino_CH1_Temp1_65.01 ZWave e015dfed 16641
#~ attr Qubino_CH1_Temp1_65.01 IODev ZWDongle_0
#~ attr Qubino_CH1_Temp1_65.01 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH1_Temp1_65.01 room ZWave
#~ attr Qubino_CH1_Temp1_65.01 stateFormat temperature
#~ define FileLog_Qubino_CH1_Temp1_65.01 FileLog ./log/Qubino_CH1_Temp1_65.01-%Y.log Qubino_CH1_Temp1_65.01
#~ attr FileLog_Qubino_CH1_Temp1_65.01 logtype text
#~ attr FileLog_Qubino_CH1_Temp1_65.01 room ZWave
#~ define Qubino_CH2_Direction_65.02 ZWave e015dfed 16642
#~ attr Qubino_CH2_Direction_65.02 IODev ZWDongle_0
#~ attr Qubino_CH2_Direction_65.02 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH2_Direction_65.02 room ZWave
#~ attr Qubino_CH2_Direction_65.02 stateFormat direction
#~ define FileLog_Qubino_CH2_Direction_65.02 FileLog ./log/Qubino_CH2_Direction_65.02-%Y.log Qubino_CH2_Direction_65.02
#~ attr FileLog_Qubino_CH2_Direction_65.02 logtype text
#~ attr FileLog_Qubino_CH2_Direction_65.02 room ZWave
#~ define Qubino_CH3_Velocity_65.03 ZWave e015dfed 16643
#~ attr Qubino_CH3_Velocity_65.03 IODev ZWDongle_0
#~ attr Qubino_CH3_Velocity_65.03 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH3_Velocity_65.03 room ZWave
#~ attr Qubino_CH3_Velocity_65.03 stateFormat velocity
#~ define FileLog_Qubino_CH3_Velocity_65.03 FileLog ./log/Qubino_CH3_Velocity_65.03-%Y.log Qubino_CH3_Velocity_65.03
#~ attr FileLog_Qubino_CH3_Velocity_65.03 logtype text
#~ attr FileLog_Qubino_CH3_Velocity_65.03 room ZWave
#~ define Qubino_CH4_WindGust_65.04 ZWave e015dfed 16644
#~ attr Qubino_CH4_WindGust_65.04 IODev ZWDongle_0
#~ attr Qubino_CH4_WindGust_65.04 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH4_WindGust_65.04 room ZWave
#~ attr Qubino_CH4_WindGust_65.04 stateFormat velocity
#~ define FileLog_Qubino_CH4_WindGust_65.04 FileLog ./log/Qubino_CH4_WindGust_65.04-%Y.log Qubino_CH4_WindGust_65.04
#~ attr FileLog_Qubino_CH4_WindGust_65.04 logtype text
#~ attr FileLog_Qubino_CH4_WindGust_65.04 room ZWave
#~ define Qubino_CH5_WindTemp_65.05 ZWave e015dfed 16645
#~ attr Qubino_CH5_WindTemp_65.05 IODev ZWDongle_0
#~ attr Qubino_CH5_WindTemp_65.05 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH5_WindTemp_65.05 room ZWave
#~ attr Qubino_CH5_WindTemp_65.05 stateFormat temperature
#~ define FileLog_Qubino_CH5_WindTemp_65.05 FileLog ./log/Qubino_CH5_WindTemp_65.05-%Y.log Qubino_CH5_WindTemp_65.05
#~ attr FileLog_Qubino_CH5_WindTemp_65.05 logtype text
#~ attr FileLog_Qubino_CH5_WindTemp_65.05 room ZWave
#~ define Qubino_CH6_WindChill_65.06 ZWave e015dfed 16646
#~ attr Qubino_CH6_WindChill_65.06 IODev ZWDongle_0
#~ attr Qubino_CH6_WindChill_65.06 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH6_WindChill_65.06 room ZWave
#~ attr Qubino_CH6_WindChill_65.06 stateFormat temperature
#~ define FileLog_Qubino_CH6_WindChill_65.06 FileLog ./log/Qubino_CH6_WindChill_65.06-%Y.log Qubino_CH6_WindChill_65.06
#~ attr FileLog_Qubino_CH6_WindChill_65.06 logtype text
#~ attr FileLog_Qubino_CH6_WindChill_65.06 room ZWave
#~ define Qubino_CH7_Rain_65.07 ZWave e015dfed 16647
#~ attr Qubino_CH7_Rain_65.07 IODev ZWDongle_0
#~ attr Qubino_CH7_Rain_65.07 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH7_Rain_65.07 room ZWave
#~ attr Qubino_CH7_Rain_65.07 stateFormat rain
#~ define FileLog_Qubino_CH7_Rain_65.07 FileLog ./log/Qubino_CH7_Rain_65.07-%Y.log Qubino_CH7_Rain_65.07
#~ attr FileLog_Qubino_CH7_Rain_65.07 logtype text
#~ attr FileLog_Qubino_CH7_Rain_65.07 room ZWave
#~ define Qubino_CH8_Humidity1_65.08 ZWave e015dfed 16648
#~ attr Qubino_CH8_Humidity1_65.08 IODev ZWDongle_0
#~ attr Qubino_CH8_Humidity1_65.08 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH8_Humidity1_65.08 room ZWave
#~ attr Qubino_CH8_Humidity1_65.08 stateFormat humidity
#~ define FileLog_Qubino_CH8_Humidity1_65.08 FileLog ./log/Qubino_CH8_Humidity1_65.08-%Y.log Qubino_CH8_Humidity1_65.08
#~ attr FileLog_Qubino_CH8_Humidity1_65.08 logtype text
#~ attr FileLog_Qubino_CH8_Humidity1_65.08 room ZWave
#~ define Qubino_CH9_Temp2_65.09 ZWave e015dfed 16649
#~ attr Qubino_CH9_Temp2_65.09 IODev ZWDongle_0
#~ attr Qubino_CH9_Temp2_65.09 classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH9_Temp2_65.09 room ZWave
#~ attr Qubino_CH9_Temp2_65.09 stateFormat temperature
#~ define FileLog_Qubino_CH9_Temp2_65.09 FileLog ./log/Qubino_CH9_Temp2_65.09-%Y.log Qubino_CH9_Temp2_65.09
#~ attr FileLog_Qubino_CH9_Temp2_65.09 logtype text
#~ attr FileLog_Qubino_CH9_Temp2_65.09 room ZWave
#~ define Qubino_CH10_Humidity2_65.0a ZWave e015dfed 16650
#~ attr Qubino_CH10_Humidity2_65.0a IODev ZWDongle_0
#~ attr Qubino_CH10_Humidity2_65.0a classes ZWAVEPLUS_INFO VERSION SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO BATTERY MARK BASIC
#~ attr Qubino_CH10_Humidity2_65.0a room ZWave
#~ attr Qubino_CH10_Humidity2_65.0a stateFormat humidity
#~ define FileLog_Qubino_CH10_Humidity2_65.0a FileLog ./log/Qubino_CH10_Humidity2_65.0a-%Y.log Qubino_CH10_Humidity2_65.0a
#~ attr FileLog_Qubino_CH10_Humidity2_65.0a logtype text
#~ attr FileLog_Qubino_CH10_Humidity2_65.0a room ZWave
#~ define test_Qubino at +*00:05:00 get Qubino_CH1_Temp1_65.01 smStatus;; get Qubino_CH2_Direction_65.02 smStatus;; get Qubino_CH3_Velocity_65.03 smStatus;; get Qubino_CH4_WindGust_65.04 smStatus;; get Qubino_CH5_WindTemp_65.05 smStatus;; get Qubino_CH6_WindChill_65.06 smStatus;; get Qubino_CH7_Rain_65.07 smStatus;; get Qubino_CH8_Humidity1_65.08 smStatus;; get Qubino_CH9_Temp2_65.09 smStatus;; Qubino_CH10_Humidity2_65.0a smStatus;;
#~ attr test_Qubino disable 1
#~ attr test_Qubino room ZWave
#~ define SVG_FileLog_Qubino_CH10_Humidity2_65.0a_1 SVG FileLog_Qubino_CH10_Humidity2_65.0a:SVG_FileLog_Qubino_CH10_Humidity2_65.0a_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH10_Humidity2_65.0a_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH10_Humidity2_65.0a_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH1_Temp1_65.01_1 SVG FileLog_Qubino_CH1_Temp1_65.01:SVG_FileLog_Qubino_CH1_Temp1_65.01_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH1_Temp1_65.01_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH1_Temp1_65.01_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH2_Direction_65.02_1 SVG FileLog_Qubino_CH2_Direction_65.02:SVG_FileLog_Qubino_CH2_Direction_65.02_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH2_Direction_65.02_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH2_Direction_65.02_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH3_Velocity_65.03_1 SVG FileLog_Qubino_CH3_Velocity_65.03:SVG_FileLog_Qubino_CH3_Velocity_65.03_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH3_Velocity_65.03_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH3_Velocity_65.03_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH4_WindGust_65.04_1 SVG FileLog_Qubino_CH4_WindGust_65.04:SVG_FileLog_Qubino_CH4_WindGust_65.04_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH4_WindGust_65.04_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH4_WindGust_65.04_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH5_WindTemp_65.05_1 SVG FileLog_Qubino_CH5_WindTemp_65.05:SVG_FileLog_Qubino_CH5_WindTemp_65.05_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH5_WindTemp_65.05_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH5_WindTemp_65.05_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH6_WindChill_65.06_1 SVG FileLog_Qubino_CH6_WindChill_65.06:SVG_FileLog_Qubino_CH6_WindChill_65.06_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH6_WindChill_65.06_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH6_WindChill_65.06_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH7_Rain_65.07_1 SVG FileLog_Qubino_CH7_Rain_65.07:SVG_FileLog_Qubino_CH7_Rain_65.07_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH7_Rain_65.07_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH7_Rain_65.07_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH8_Humidity1_65.08_1 SVG FileLog_Qubino_CH8_Humidity1_65.08:SVG_FileLog_Qubino_CH8_Humidity1_65.08_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH8_Humidity1_65.08_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH8_Humidity1_65.08_1 room Qubino_Diagramme
#~ define SVG_FileLog_Qubino_CH9_Temp2_65.09_1 SVG FileLog_Qubino_CH9_Temp2_65.09:SVG_FileLog_Qubino_CH9_Temp2_65.09_1:CURRENT
#~ attr SVG_FileLog_Qubino_CH9_Temp2_65.09_1 endPlotNow 1
#~ attr SVG_FileLog_Qubino_CH9_Temp2_65.09_1 room Qubino_Diagramme
#~ define ZWave_WALL_CONTROLLER_81 ZWave e015dfed 81
#~ attr ZWave_WALL_CONTROLLER_81 IODev ZWDongle_0
#~ attr ZWave_WALL_CONTROLLER_81 classes ZWAVEPLUS_INFO MULTI_CMD POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION SCENE_CONTROLLER_CONF MULTI_CHANNEL_ASSOCIATION BATTERY WAKE_UP DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO CENTRAL_SCENE MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL DOOR_LOCK
#~ attr ZWave_WALL_CONTROLLER_81 room ZWave
#~ attr ZWave_WALL_CONTROLLER_81 secure_classes MULTI_CMD MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION DOOR_LOCK MULTI_CHANNEL
#~ attr ZWave_WALL_CONTROLLER_81 vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CENTRAL_SCENE:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 DOOR_LOCK:0 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:0 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SCENE_ACTIVATION:0 SCENE_CONTROLLER_CONF:1 SECURITY:1 SWITCH_ALL:0 SWITCH_MULTILEVEL:0 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
#~ attr ZWave_WALL_CONTROLLER_81 verbose 5
#~ define FileLog_ZWave_WALL_CONTROLLER_81 FileLog ./log/ZWave_WALL_CONTROLLER_81-%Y.log ZWave_WALL_CONTROLLER_81
#~ attr FileLog_ZWave_WALL_CONTROLLER_81 logtype text
#~ attr FileLog_ZWave_WALL_CONTROLLER_81 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82 ZWave e015dfed 82
#~ attr ZWave_SENSOR_MULTILEVEL_82 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82 classes ZWAVEPLUS_INFO BASIC SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC
#~ attr ZWave_SENSOR_MULTILEVEL_82 room ZWave
#~ attr ZWave_SENSOR_MULTILEVEL_82 vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SENSOR_MULTILEVEL:7 VERSION:2 ZWAVEPLUS_INFO:2
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82-%Y.log ZWave_SENSOR_MULTILEVEL_82
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82.01 ZWave e015dfed 20993
#~ attr ZWave_SENSOR_MULTILEVEL_82.01 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82.01 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_82.01 room ZWave
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82.01 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82.01-%Y.log ZWave_SENSOR_MULTILEVEL_82.01
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.01 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.01 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82.02 ZWave e015dfed 20994
#~ attr ZWave_SENSOR_MULTILEVEL_82.02 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82.02 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_82.02 room ZWave
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82.02 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82.02-%Y.log ZWave_SENSOR_MULTILEVEL_82.02
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.02 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.02 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82.03 ZWave e015dfed 20995
#~ attr ZWave_SENSOR_MULTILEVEL_82.03 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82.03 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_82.03 room ZWave
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82.03 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82.03-%Y.log ZWave_SENSOR_MULTILEVEL_82.03
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.03 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.03 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82.04 ZWave e015dfed 20996
#~ attr ZWave_SENSOR_MULTILEVEL_82.04 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82.04 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_82.04 room ZWave
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82.04 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82.04-%Y.log ZWave_SENSOR_MULTILEVEL_82.04
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.04 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.04 room ZWave
#~ define ZWave_SENSOR_MULTILEVEL_82.05 ZWave e015dfed 20997
#~ attr ZWave_SENSOR_MULTILEVEL_82.05 IODev ZWDongle_0
#~ attr ZWave_SENSOR_MULTILEVEL_82.05 classes SENSOR_MULTILEVEL
#~ attr ZWave_SENSOR_MULTILEVEL_82.05 room ZWave
#~ define FileLog_ZWave_SENSOR_MULTILEVEL_82.05 FileLog ./log/ZWave_SENSOR_MULTILEVEL_82.05-%Y.log ZWave_SENSOR_MULTILEVEL_82.05
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.05 logtype text
#~ attr FileLog_ZWave_SENSOR_MULTILEVEL_82.05 room ZWave
#~ define ZWave_Node_64.39 ZWave e015dfed 16423
#~ attr ZWave_Node_64.39 IODev ZWDongle_0
#~ attr ZWave_Node_64.39 room ZWave
#~ define FileLog_ZWave_Node_64.39 FileLog ./log/ZWave_Node_64.39-%Y.log ZWave_Node_64.39
#~ attr FileLog_ZWave_Node_64.39 logtype text
#~ attr FileLog_ZWave_Node_64.39 room ZWave
#~ define ZWave_Node_64.13 ZWave e015dfed 16397
#~ attr ZWave_Node_64.13 IODev ZWDongle_0
#~ attr ZWave_Node_64.13 room ZWave
#~ define FileLog_ZWave_Node_64.13 FileLog ./log/ZWave_Node_64.13-%Y.log ZWave_Node_64.13
#~ attr FileLog_ZWave_Node_64.13 logtype text
#~ attr FileLog_ZWave_Node_64.13 room ZWave
#~ define SVG_FileLog_ZWave_ALARM_64.05_2 SVG FileLog_ZWave_ALARM_64.05:SVG_FileLog_ZWave_ALARM_64.05_2:CURRENT
#~ attr SVG_FileLog_ZWave_ALARM_64.05_2 captionLeft 1
#~ attr SVG_FileLog_ZWave_ALARM_64.05_2 endPlotNow 1
#~ attr SVG_FileLog_ZWave_ALARM_64.05_2 fixedrange 2days
#~ attr SVG_FileLog_ZWave_ALARM_64.05_2 room Z-Uno_Diagramme
#~ define ZWave_ENTRY_CONTROL_89 ZWave e015dfed 89
#~ attr ZWave_ENTRY_CONTROL_89 IODev ZWDongle_0
#~ attr ZWave_ENTRY_CONTROL_89 classes ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC VERSION DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO WAKE_UP CONFIGURATION SWITCH_BINARY BATTERY POWERLEVEL FIRMWARE_UPDATE_MD SECURITY ALARM USER_CODE ENTRY_CONTROL INDICATOR MARK
#~ attr ZWave_ENTRY_CONTROL_89 noWakeupForApplicationUpdate 1
#~ attr ZWave_ENTRY_CONTROL_89 room ZWave
#~ attr ZWave_ENTRY_CONTROL_89 secure_classes ALARM USER_CODE VERSION DEVICE_RESET_LOCALLY WAKE_UP SWITCH_BINARY BATTERY MANUFACTURER_SPECIFIC ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION POWERLEVEL ENTRY_CONTROL INDICATOR MARK
#~ attr ZWave_ENTRY_CONTROL_89 vclasses ALARM:2 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 ENTRY_CONTROL:1 FIRMWARE_UPDATE_MD:2 INDICATOR:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SECURITY:1 SWITCH_BINARY:1 USER_CODE:1 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
#~ attr ZWave_ENTRY_CONTROL_89 verbose 5
#~ define FileLog_ZWave_ENTRY_CONTROL_89 FileLog ./log/ZWave_ENTRY_CONTROL_89-%Y.log ZWave_ENTRY_CONTROL_89
#~ attr FileLog_ZWave_ENTRY_CONTROL_89 logtype text
#~ attr FileLog_ZWave_ENTRY_CONTROL_89 room ZWave
#~ define ZWave_SENSOR_NOTIFICATION_92 ZWave e015dfed 92
#~ attr ZWave_SENSOR_NOTIFICATION_92 IODev ZWDongle_0
#~ attr ZWave_SENSOR_NOTIFICATION_92 classes ZWAVEPLUS_INFO BASIC SENSOR_BINARY ALARM CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC
#~ attr ZWave_SENSOR_NOTIFICATION_92 room ZWave
#~ attr ZWave_SENSOR_NOTIFICATION_92 secure_classes ZWAVEPLUS_INFO SENSOR_BINARY ALARM CONFIGURATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO ASSOCIATION VERSION MANUFACTURER_SPECIFIC MULTI_CHANNEL
#~ attr ZWave_SENSOR_NOTIFICATION_92 vclasses ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 VERSION:2 ZWAVEPLUS_INFO:2
#~ attr ZWave_SENSOR_NOTIFICATION_92 verbose 5
#~ define FileLog_ZWave_SENSOR_NOTIFICATION_92 FileLog ./log/ZWave_SENSOR_NOTIFICATION_92-%Y.log ZWave_SENSOR_NOTIFICATION_92
#~ attr FileLog_ZWave_SENSOR_NOTIFICATION_92 logtype text
#~ attr FileLog_ZWave_SENSOR_NOTIFICATION_92 room ZWave
define myHmUART HMUARTLGW /dev/ttyUSB0
define SVG_Hideki_14_4 SVG FileLog_Hideki_14_4:SVG_Hideki_14_4:CURRENT
attr SVG_Hideki_14_4 label "Hideki_14_4 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_Hideki_14_4 room Plots
define mCUL CUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00 0000
attr mCUL rfmode SlowRF
attr mCUL room Maple
attr mCUL verbose 5
define SCC1 STACKABLE mCUL
attr SCC1 room Maple
attr SCC1 verbose 5
define z100k ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z100k dataRate 100k
attr z100k room Maple
attr z100k verbose 5
define SCC2 STACKABLE z100k
attr SCC2 room Maple
attr SCC2 verbose 5
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k dataRate 40k
attr z40k room Maple
attr z40k verbose 5
define SCC3 STACKABLE z40k
attr SCC3 room Maple
attr SCC3 verbose 5
define z9.6 ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z9.6 dataRate 9600
attr z9.6 room Maple
attr z9.6 verbose 5
define CUL_1 CUL /dev/ttyACM1@9600 1134
Gruß,
Andreas.
Danke fuer dein Bericht: die Match-Regexps waren ungenau spezifiziert, deswegen landeten die *z Daten im ZWave Modul, und nicht im ZWDongle. Habs gefixt und eingecheckt.
Hi Rudi,
ok, dann war das ja nichts wirklich "schlimmes".
Bei den 40k und 100k Datenraten kommt bei mir momentan nur jede Menge Müll an, bisher habe ich dort kein einziges echtes Paket gesehen ,-(
Ich werde dann jetzt mal versuchen den ZWCul wieder ans Laufen zu bekommen um damit dann gezielt auf einer Datenrate Testpakete zu senden.
Gruß,
Andreas.
Hi,
also mein ZWCUL funktioniert nun wieder...
Wenn ich jetzt ein Paket mit 40k sende wird es auch brav vom MapleCul empfangen und richtig dekodiert. Das gleiche gilt auch für 100k, zumindest nachdem ich bemerkt habe das ich für mein Testpaket bei 100k eine neue CS mit CRC16 rechnen muss...
Also funktioniert der MapleCUL prinzipiell. Reichweite muss ich mal probieren, momentan ist der Abstand nur ~40cm.
Momentan scheinen alle meine Geräte nur auf 9k6 zu senden (wahrscheinlich weil der Controller nicht mehr reagiert da ich das Testsystem ja gerade quasi abgeschaltet habe, und die Geräte dann auf die niedrigste Datenrate gehen). Der ZWCUL empfängt jedenfalls auch auf 40k oder 100k nichts, so wie der MapleCUL.
Do/Fr könnte ich mal versuchen das ganze dann doch in mein Testsytem einzubauen, sollte ja mit dem Patch jetzt funktionieren und dann schauen ob dann auch auf 40k/100k was kommt und den Maple mal etwas weiter weg legen...
Gruß,
Andreas.
P.S.: Gerade auch mal senden auf 40k/100k getestet, kommt auch beim ZWCUL an. Damit wäre das Ding eigentlich in Ordnung ;-)
Hallo Rudi,
zwischendurch schau ich mir immer mal an was da auf dem MapleCUL so alles ankommt... Wie gesagt funktioniert der auf allen Datenraten, Reichweite habe ich aber immer noch nicht getestet.
Was mir aber auffällt das die komplette Kommunikation mit einem Z-UNO über 9k6 abläuft. Ein get nodeinfo liefert 40k mit speedext 100K. Ein anderer Z-Uno läuft schön mit 100k.
Alle vom Gerät gesendeten Statusmeldungen kommen per 9k6, Befehle vom Controller werden aber auch mit 9k6 gesendet.
Hast Du eine Ahnung wieso der Dongle hier nicht die höheren Datenraten nutzt? NO_ACK oder CAN habe ich den Übertragungen bisher noch nicht wirklich entdeckt, das Ding steht auch nur <1m vom Dongle entfernt.
Wie war das noch mal mit diesem komischen Patent auf Schalterrückmeldung. War das generell oder "darf/durfte" das auf 9k6? Das Patent soll ja abgelaufen sein, die Implementierung könnte sowas aber evtl. noch berücksichtigen.
Der Z-Uno hat 9 sub-devices, wobei in FHEM komischerweise jetzt auch noch ein subdevice .13 und ein sub-device .39 auftaucht. 7 von den sub-device senden automatisch eine Status, wie gesagt alles in 9k6...
Ich habe ja dummerweise mal die ganzen Devices in der fhem.cfg auskommentiert und bei der Aktion die Inhalte aus der fhem.save verloren, aber da sollte doch eigentlich nichts zur Datenrate drin stehen, oder? Die Datenrate lässt sich doch über das API von dem ZWave-Dongle gar nicht beeinflussen oder doch?
Ich würde das Device nur sehr ungerne zum Debuggen exkludieren, da hängen etliche Graphen mit dran...
Gruß,
Andreas.
Ich gehe davon aus, dass der Controller dein Problem-Z-UNO (PZU) vergeblich versucht hat auf 40k und 100k zu erreichen, und deswegen auf 9.6 gegangen ist. Aus der Geschichte: CUL 3.1 ist unfaehig RFR mit 250k zu machen (ich meine selbst HM geht nicht), nur SlowRf, das aber ohne Probleme. Da war was beim Platinenlayout schiefgegangen, CUL 3.2 hat keine Probleme. Evtl. hat das PZU auch einen Hardware-Fehler.
ZitatIch würde das Device nur sehr ungerne zum Debuggen exkludieren, da hängen etliche Graphen mit dran...
Verstehe ich nicht: enthalten die Graphen die Node-Id der PZU? Selbst dann koennte man den Neuen doch umbennen, oder uebersehe ich was?
ZitatWie war das noch mal mit diesem komischen Patent auf Schalterrückmeldung. War das generell oder "darf/durfte" das auf 9k6?
Das Patent-Workaround hat nichts direkt mit 9.6k zu tun. Das Patent (was abgelaufen ist) bezieht sich auf das Melden der "ein/aus" Wertes beim druecken des Knopfes am Geraet. Workaround: beim Drueckn des Knopfes ein NIF zu senden (das kommt mW generell auf 9.6), woraufhin die HA-Software ein "get status" absetzen kann, das dann gerne auf 40k/100k.
Hi Rudi,
Zitat von: rudolfkoenig am 11 April 2017, 11:09:24
Ich gehe davon aus, dass der Controller dein Problem-Z-UNO (PZU) vergeblich versucht hat auf 40k und 100k zu erreichen, und deswegen auf 9.6 gegangen ist.
ja, soweit stimme ich Dir zu. Mein Kenntnisstand bzw. Vermutung ist das bei Problemen ein Re-Transmit passiert, dann ein routingversuch und dann eine niedrigere Datenrate probiert wird.
Aber wenn ein Gerät z.B. eine Weile nicht erreichbar ist (z.B. wegen Batterieproblemen), dann würde der Controller auf 9k6 runtergehen. Aber meine Deutung des Protokolls wäre das wenn er das Gerät wieder (auf 9k6) erreichen kann das er dann auch wieder auf die höheren Datenraten wechselt. Das passiert hier aber nicht...
Zitat von: rudolfkoenig am 11 April 2017, 11:09:24
Aus der Geschichte: CUL 3.1 ist unfaehig RFR mit 250k zu machen (ich meine selbst HM geht nicht), nur SlowRf, das aber ohne Probleme. Da war was beim Platinenlayout schiefgegangen, CUL 3.2 hat keine Probleme. Evtl. hat das PZU auch einen Hardware-Fehler.
Den Zusammenhang mit den CUL verstehe ich nicht, ich betreibe das Netzwerk weiterhin mit einem UZB-Dongle und nicht mit einem CUL. Mein Cul und der MapleCUL "lauschen" nur. (HomeId 00000000 und kein Intrudermode gesetzt)
Hardwarefehler würde ich eigentlich ausschliessen wollen, kann ich aber ohne Exkludierung nicht nachweisen...
Ich könnte evtl. mal versuchen eine "gefakte" Nachricht mit 40k oder 100k über einen der CULs an das "PZU" zu schicken und sehen was dann passiert.
Zitat von: rudolfkoenig am 11 April 2017, 11:09:24
Verstehe ich nicht: enthalten die Graphen die Node-Id der PZU? Selbst dann koennte man den Neuen doch umbennen, oder uebersehe ich was?
Alle Namen (auf die Filelogs) enthalten natürlich die Node-Id und die Child-Id... da wäre schon einiges umzubennen. Und meist mache ich bei solchen Aktionen irgendeinen blöden Fehler...
Ich werde erst noch mal versuchen dem Ding die gefakten Nachrichten zu schicken, falls da nichts bei rauskommt werde ich mal versuchen das Ding erneut einzubinden.
Zitat von: rudolfkoenig am 11 April 2017, 11:09:24
Das Patent-Workaround hat nichts direkt mit 9.6k zu tun. Das Patent (was abgelaufen ist) bezieht sich auf das Melden der "ein/aus" Wertes beim druecken des Knopfes am Geraet. Workaround: beim Drueckn des Knopfes ein NIF zu senden (das kommt mW generell auf 9.6), woraufhin die HA-Software ein "get status" absetzen kann, das dann gerne auf 40k/100k.
Ok, ich hatte irgendwie abgespeichert das dieses Patent in der niedrigen Datenrate nicht gelten würde. Falls es wirklich nur daraus besteht den NIF zu senden dürfte das keine Auswirkung haben.
Was passiert jetzt mit Deinem MapleCUL? Kannst Du den selbst flashen oder willst Du ihn mir schicken und ich flashe den? Weil funktionieren tut er ja ,-)
Problem mit dem MapleCUL ist das mir das Log-File "explodiert". Wenn da alle 9 sub-device alle ~30 Sekunden ein Statusupdate senden und dann für jede Nachricht da gefühlt 10 Zeilen zusätzlich vom MapleCUL in das Log geschrieben werden habe ich nach ein / zwei Stunden da etliche Megabyte an Logfile...
Darin was zu suchen und zu analysieren ist auch nicht soo einfach.
Gruß,
Andreas.
ZitatWas passiert jetzt mit Deinem MapleCUL? Kannst Du den selbst flashen oder willst Du ihn mir schicken und ich flashe den? Weil funktionieren tut er ja ,-)
Ich habe es gerade geflasht, es meldet sich nun mit
V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_0E (F-Band: 868MHz)Am Empfang hat sich nichts geaendert: es hat zwar einen einzelnen 40k Paket empfangen (immerhin mit der richtigen homeId :) ), aber ich habe jeweils 2 gets an zwei unterschiedliche Geraete abgesetzt, das eine ist direkt erreichbar (== 4 Funktelegramme pro get), das Andere wird geroutet (14 Funktelegramme pro get). Ein an der gleichen Stelle eingestecktes CUL hat (soweit ich es zaehlen kann) alle Nachrichten gemeldet, bei mir laeuft alles auf 40k. D.h mapleCUN:1 vs. CUL:36.
So ist der MapleCUN fuer mich wertlos, ich wuerde es dir gerne zurueckschicken.
Hallo Rudi,
ok, dann schick das Ding bitte zurück, ich schick' Dir meine Packstationsadresse per PN.
Ich werde hier dann auch mal gegen meinen CUL testen, vielleicht ist da ja beim Aufbau was nicht in Ordnung.
Gruß,
Andreas.
Hallo Rudi,
leider liegt es wohl doch nicht nur an dem einen Gerät.
Ich habe jetzt mal einen 1:1 Vergleich mit 100k zwischen dem CUL und dem MapleCUL gemacht. Bei mir ist das Verhältnis zwar deutlich besser als bei Dir und es steht 176 zu 68, aber das ist auch nur rund 1/3 der Nachrichten ,-(
Es fehlen irgendwie alle ACK Nachrichten (das sind die mit der leeren Payload), aber auch ein paar "normale" Nachrichten.
Werde das auch noch mal mit 9k6 und 40k wiederholen, evtl. ist es ja abhängig von der Datenrate...
Jetzt muss ich wohl doch in der a-culfw debuggen um zu sehen was da passiert. :(
176 68
2017.04.13 21:28:12.740 5: zwc e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:988089f19533135f70f8 C:56f5 2017.04.13 21:28:12.819 5: z100k e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:988089f19533135f70f8 C:56f5
2017.04.13 21:28:12.819 5: zwc e015dfed S:01 F:03 f:0 SN:8 L:0b T:67 P: C:b0f9
2017.04.13 21:28:12.846 5: zwc e015dfed S:01 F:41 f:0 SN:e L:26 T:67 P:988190d7b319c04d8bd33c5dd5a885fb509d894fa871b308d51580 C:d485 2017.04.13 21:28:12.850 5: z100k e015dfed S:01 F:41 f:0 SN:e L:26 T:67 P:988190d7b319c04d8bd33c5dd5a885fb509d894fa871b308d51580 C:d485
2017.04.13 21:28:12.852 5: zwc e015dfed S:67 F:03 f:0 SN:e L:0b T:01 P: C:da60
2017.04.13 21:28:12.878 5: zwc e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1 2017.04.13 21:28:12.886 5: z100k e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1
2017.04.13 21:28:12.886 5: zwc e015dfed S:01 F:03 f:0 SN:9 L:0b T:67 P: C:87c9
2017.04.13 21:28:12.926 5: zwc e015dfed S:01 F:41 f:0 SN:f L:15 T:67 P:9880d46525bfc93244ac C:ba71 2017.04.13 21:28:12.933 5: z100k e015dfed S:01 F:41 f:0 SN:f L:15 T:67 P:9880d46525bfc93244ac C:ba71
2017.04.13 21:28:12.934 5: zwc e015dfed S:67 F:03 f:0 SN:f L:0b T:01 P: C:ed50
2017.04.13 21:28:12.966 5: zwc e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98817ac304f7ac579f6cd3bdfccfd496832fa72faa6dd0 C:1d29 2017.04.13 21:28:12.967 5: z100k e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98817ac304f7ac579f6cd3bdfccfd496832fa72faa6dd0 C:1d29
2017.04.13 21:28:12.970 5: zwc e015dfed S:01 F:03 f:0 SN:a L:0b T:67 P: C:de99
2017.04.13 21:28:12.985 5: zwc e015dfed S:67 F:41 f:0 SN:b L:0d T:01 P:9840 C:aa52 2017.04.13 21:28:12.991 5: z100k e015dfed S:67 F:41 f:0 SN:b L:0d T:01 P:9840 C:aa52
2017.04.13 21:28:12.994 5: zwc e015dfed S:01 F:03 f:0 SN:b L:0b T:67 P: C:e9a9
2017.04.13 21:28:13.057 5: zwc e015dfed S:01 F:41 f:0 SN:1 L:15 T:67 P:988003c370fbc9d96465 C:1e2f 2017.04.13 21:28:13.065 5: z100k e015dfed S:01 F:41 f:0 SN:1 L:15 T:67 P:988003c370fbc9d96465 C:1e2f
2017.04.13 21:28:13.067 5: zwc e015dfed S:67 F:03 f:0 SN:1 L:0b T:01 P: C:f651
2017.04.13 21:28:13.093 5: zwc e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881a910a0592feb270cdc3bf51903e77954aa415d6f88 C:5c53 2017.04.13 21:28:13.099 5: z100k e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881a910a0592feb270cdc3bf51903e77954aa415d6f88 C:5c53
2017.04.13 21:28:13.101 5: zwc e015dfed S:01 F:03 f:0 SN:c L:0b T:67 P: C:6c39
2017.04.13 21:28:24.210 5: zwc e015dfed S:01 F:41 f:0 SN:2 L:0d T:67 P:9840 C:39da 2017.04.13 21:28:24.214 5: z100k e015dfed S:01 F:41 f:0 SN:2 L:0d T:67 P:9840 C:39da
2017.04.13 21:28:24.215 5: zwc e015dfed S:67 F:03 f:0 SN:2 L:0b T:01 P: C:af01
2017.04.13 21:28:24.228 5: zwc e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:9880bf84d646835e12e8 C:391d 2017.04.13 21:28:24.240 5: z100k e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:9880bf84d646835e12e8 C:391d
2017.04.13 21:28:24.240 5: zwc e015dfed S:01 F:03 f:0 SN:d L:0b T:67 P: C:5b09
2017.04.13 21:28:24.314 5: zwc e015dfed S:01 F:41 f:0 SN:3 L:26 T:67 P:98814180cb9ba04b061dcde35ffbad0dda37bf0a35fb540e35f711 C:2373 2017.04.13 21:28:24.320 5: z100k e015dfed S:01 F:41 f:0 SN:3 L:26 T:67 P:98814180cb9ba04b061dcde35ffbad0dda37bf0a35fb540e35f711 C:2373
2017.04.13 21:28:24.326 5: zwc e015dfed S:67 F:03 f:0 SN:3 L:0b T:01 P: C:9831
2017.04.13 21:28:24.346 5: zwc e015dfed S:67 F:41 f:0 SN:e L:0d T:01 P:9840 C:8905 2017.04.13 21:28:24.355 5: z100k e015dfed S:67 F:41 f:0 SN:e L:0d T:01 P:9840 C:8905
2017.04.13 21:28:24.355 5: zwc e015dfed S:01 F:03 f:0 SN:e L:0b T:67 P: C:0259
2017.04.13 21:28:24.393 5: zwc e015dfed S:01 F:41 f:0 SN:4 L:15 T:67 P:9880bf8ab30c97e64aed C:21e5 2017.04.13 21:28:24.402 5: z100k e015dfed S:01 F:41 f:0 SN:4 L:15 T:67 P:9880bf8ab30c97e64aed C:21e5
2017.04.13 21:28:24.403 5: zwc e015dfed S:67 F:03 f:0 SN:4 L:0b T:01 P: C:1da1
2017.04.13 21:28:24.431 5: zwc e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:9881f33915c3f7e9714f2d413ed6bf5e93495ad733493e C:4b4f 2017.04.13 21:28:24.440 5: z100k e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:9881f33915c3f7e9714f2d413ed6bf5e93495ad733493e C:4b4f
2017.04.13 21:28:24.440 5: zwc e015dfed S:01 F:03 f:0 SN:f L:0b T:67 P: C:3569
2017.04.13 21:28:24.450 5: zwc e015dfed S:67 F:41 f:0 SN:1 L:0d T:01 P:9840 C:ecfc
2017.04.13 21:28:24.461 5: zwc e015dfed S:01 F:03 f:0 SN:1 L:0b T:67 P: C:2e68
2017.04.13 21:28:24.538 5: zwc e015dfed S:01 F:41 f:0 SN:5 L:15 T:67 P:9880f575eb28ff559323 C:b6bc 2017.04.13 21:28:24.548 5: z100k e015dfed S:01 F:41 f:0 SN:5 L:15 T:67 P:9880f575eb28ff559323 C:b6bc
2017.04.13 21:28:24.548 5: zwc e015dfed S:67 F:03 f:0 SN:5 L:0b T:01 P: C:2a91
2017.04.13 21:28:24.574 5: zwc e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:9881930215bacf25d947d0cd8946f5cb7c970f3720ddf4 C:c390 2017.04.13 21:28:24.581 5: z100k e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:9881930215bacf25d947d0cd8946f5cb7c970f3720ddf4 C:c390
2017.04.13 21:28:24.581 5: zwc e015dfed S:01 F:03 f:0 SN:2 L:0b T:67 P: C:7738
2017.04.13 21:28:31.680 5: zwc e015dfed S:01 F:41 f:0 SN:6 L:0d T:67 P:9840 C:b0dc 2017.04.13 21:28:31.688 5: z100k e015dfed S:01 F:41 f:0 SN:6 L:0d T:67 P:9840 C:b0dc
2017.04.13 21:28:31.689 5: zwc e015dfed S:67 F:03 f:0 SN:6 L:0b T:01 P: C:73c1
2017.04.13 21:28:31.708 5: zwc e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:9880dd08585304270e09 C:54b3 2017.04.13 21:28:31.712 5: z100k e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:9880dd08585304270e09 C:54b3
2017.04.13 21:28:31.713 5: zwc e015dfed S:01 F:03 f:0 SN:3 L:0b T:67 P: C:4008
2017.04.13 21:28:31.747 5: zwc e015dfed S:01 F:41 f:0 SN:7 L:26 T:67 P:9881ff79a2204ea82707d19829b0a796ec90ddcf07442992cde237 C:3949 2017.04.13 21:28:31.751 5: z100k e015dfed S:01 F:41 f:0 SN:7 L:26 T:67 P:9881ff79a2204ea82707d19829b0a796ec90ddcf07442992cde237 C:3949
2017.04.13 21:28:31.753 5: zwc e015dfed S:67 F:03 f:0 SN:7 L:0b T:01 P: C:44f1
2017.04.13 21:28:31.778 5: zwc e015dfed S:67 F:41 f:0 SN:4 L:0d T:01 P:9840 C:cfab 2017.04.13 21:28:31.787 5: z100k e015dfed S:67 F:41 f:0 SN:4 L:0d T:01 P:9840 C:cfab
2017.04.13 21:28:31.787 5: zwc e015dfed S:01 F:03 f:0 SN:4 L:0b T:67 P: C:c598
2017.04.13 21:28:31.817 5: zwc e015dfed S:01 F:41 f:0 SN:8 L:15 T:67 P:98809336ec28232c8d1a C:1bda 2017.04.13 21:28:31.825 5: z100k e015dfed S:01 F:41 f:0 SN:8 L:15 T:67 P:98809336ec28232c8d1a C:1bda
2017.04.13 21:28:31.826 5: zwc e015dfed S:67 F:03 f:0 SN:8 L:0b T:01 P: C:68c0
2017.04.13 21:28:31.859 5: zwc e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:9881a5d5156e954ac009813e38539317dff72723de1882 C:756a 2017.04.13 21:28:31.859 5: z100k e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:9881a5d5156e954ac009813e38539317dff72723de1882 C:756a
2017.04.13 21:28:31.860 5: zwc e015dfed S:01 F:03 f:0 SN:5 L:0b T:67 P: C:f2a8
2017.04.13 21:28:31.874 5: zwc e015dfed S:67 F:41 f:0 SN:6 L:0d T:01 P:9840 C:8b28
2017.04.13 21:28:31.883 5: zwc e015dfed S:01 F:03 f:0 SN:6 L:0b T:67 P: C:abf8
2017.04.13 21:28:31.919 5: zwc e015dfed S:01 F:41 f:0 SN:9 L:15 T:67 P:9880ce28079ffef2f5ea C:46c5 2017.04.13 21:28:31.927 5: z100k e015dfed S:01 F:41 f:0 SN:9 L:15 T:67 P:9880ce28079ffef2f5ea C:46c5
2017.04.13 21:28:31.929 5: zwc e015dfed S:67 F:03 f:0 SN:9 L:0b T:01 P: C:5ff0
2017.04.13 21:28:31.955 5: zwc e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:9881d7dbb97f1043d1ca915d7399ce723111f83283d561 C:34eb 2017.04.13 21:28:31.960 5: z100k e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:9881d7dbb97f1043d1ca915d7399ce723111f83283d561 C:34eb
2017.04.13 21:28:31.962 5: zwc e015dfed S:01 F:03 f:0 SN:7 L:0b T:67 P: C:9cc8
2017.04.13 21:28:36.036 5: zwc e015dfed S:01 F:41 f:0 SN:a L:0d T:67 P:9840 C:3bf7
2017.04.13 21:28:36.046 5: zwc e015dfed S:67 F:03 f:0 SN:a L:0b T:01 P: C:06a0
2017.04.13 21:28:36.061 5: zwc e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:9880f90c23cfaa184177 C:2d03 2017.04.13 21:28:36.068 5: z100k e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:9880f90c23cfaa184177 C:2d03
2017.04.13 21:28:36.071 5: zwc e015dfed S:01 F:03 f:0 SN:8 L:0b T:67 P: C:b0f9
2017.04.13 21:28:36.119 5: zwc e015dfed S:01 F:41 f:0 SN:b L:26 T:67 P:98814890dec24cacf03633ebcfc0e55f8f7ef9922aff8a5d5cec52 C:d40c 2017.04.13 21:28:36.125 5: z100k e015dfed S:01 F:41 f:0 SN:b L:26 T:67 P:98814890dec24cacf03633ebcfc0e55f8f7ef9922aff8a5d5cec52 C:d40c
2017.04.13 21:28:36.125 5: zwc e015dfed S:67 F:03 f:0 SN:b L:0b T:01 P: C:3190
2017.04.13 21:28:36.150 5: zwc e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1 2017.04.13 21:28:36.158 5: z100k e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1
2017.04.13 21:28:36.159 5: zwc e015dfed S:01 F:03 f:0 SN:9 L:0b T:67 P: C:87c9
2017.04.13 21:28:36.191 5: zwc e015dfed S:01 F:41 f:0 SN:c L:15 T:67 P:9880da854a7032dd8dea C:b6e0 2017.04.13 21:28:36.199 5: z100k e015dfed S:01 F:41 f:0 SN:c L:15 T:67 P:9880da854a7032dd8dea C:b6e0
2017.04.13 21:28:36.218 5: zwc e015dfed S:67 F:03 f:0 SN:c L:0b T:01 P: C:b400
2017.04.13 21:28:36.230 5: zwc e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:9881109ed407cef5ce539cd6a5b1da3ff1e962b6496022 C:4baf
2017.04.13 21:28:36.235 5: zwc e015dfed S:01 F:03 f:0 SN:a L:0b T:67 P: C:de99
2017.04.13 21:28:36.250 5: zwc e015dfed S:67 F:41 f:0 SN:b L:0d T:01 P:9840 C:aa52
2017.04.13 21:28:36.258 5: zwc e015dfed S:01 F:03 f:0 SN:b L:0b T:67 P: C:e9a9
2017.04.13 21:28:36.306 5: zwc e015dfed S:01 F:41 f:0 SN:d L:15 T:67 P:9880efd569829c2999aa C:6786 2017.04.13 21:28:36.315 5: z100k e015dfed S:01 F:41 f:0 SN:d L:15 T:67 P:9880efd569829c2999aa C:6786
2017.04.13 21:28:36.316 5: zwc e015dfed S:67 F:03 f:0 SN:d L:0b T:01 P: C:8330
2017.04.13 21:28:36.342 5: zwc e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881b33e472cd6782a16b980939bef0139a8933b716100 C:4668 2017.04.13 21:28:36.351 5: z100k e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881b33e472cd6782a16b980939bef0139a8933b716100 C:4668
2017.04.13 21:28:36.351 5: zwc e015dfed S:01 F:03 f:0 SN:c L:0b T:67 P: C:6c39
2017.04.13 21:28:41.463 5: zwc e015dfed S:01 F:41 f:0 SN:e L:0d T:67 P:9840 C:b2f1 2017.04.13 21:28:41.492 5: z100k e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:9880cc8bec44b90870f8 C:f1d5
2017.04.13 21:28:41.469 5: zwc e015dfed S:67 F:03 f:0 SN:e L:0b T:01 P: C:da60
2017.04.13 21:28:41.491 5: zwc e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:9880cc8bec44b90870f8 C:f1d5
2017.04.13 21:28:41.494 5: zwc e015dfed S:01 F:03 f:0 SN:d L:0b T:67 P: C:5b09
2017.04.13 21:28:41.567 5: zwc e015dfed S:01 F:41 f:0 SN:f L:26 T:67 P:9881b74d515132fa76f3e31a1fe693d41666cc220e58e93772acfe C:c4a0 2017.04.13 21:28:41.572 5: z100k e015dfed S:01 F:41 f:0 SN:f L:26 T:67 P:9881b74d515132fa76f3e31a1fe693d41666cc220e58e93772acfe C:c4a0
2017.04.13 21:28:41.572 5: zwc e015dfed S:67 F:03 f:0 SN:f L:0b T:01 P: C:ed50
2017.04.13 21:28:41.596 5: zwc e015dfed S:67 F:41 f:0 SN:e L:0d T:01 P:9840 C:8905
2017.04.13 21:28:41.606 5: zwc e015dfed S:01 F:03 f:0 SN:e L:0b T:67 P: C:0259
2017.04.13 21:28:41.646 5: zwc e015dfed S:01 F:41 f:0 SN:1 L:15 T:67 P:98802013d45f43907bae C:e572 2017.04.13 21:28:41.652 5: z100k e015dfed S:01 F:41 f:0 SN:1 L:15 T:67 P:98802013d45f43907bae C:e572
2017.04.13 21:28:41.654 5: zwc e015dfed S:67 F:03 f:0 SN:1 L:0b T:01 P: C:f651
2017.04.13 21:28:41.681 5: zwc e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:988153d63def486073a70366202420d3478566c451ebd2 C:e285 2017.04.13 21:28:41.687 5: z100k e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:988153d63def486073a70366202420d3478566c451ebd2 C:e285
2017.04.13 21:28:41.688 5: zwc e015dfed S:01 F:03 f:0 SN:f L:0b T:67 P: C:3569
2017.04.13 21:28:41.702 5: zwc e015dfed S:67 F:41 f:0 SN:1 L:0d T:01 P:9840 C:ecfc 2017.04.13 21:28:41.712 5: z100k e015dfed S:67 F:41 f:0 SN:1 L:0d T:01 P:9840 C:ecfc
2017.04.13 21:28:41.712 5: zwc e015dfed S:01 F:03 f:0 SN:1 L:0b T:67 P: C:2e68
2017.04.13 21:28:41.754 5: zwc e015dfed S:01 F:41 f:0 SN:2 L:15 T:67 P:98805abb12ef12f241db C:7202 2017.04.13 21:28:41.761 5: z100k e015dfed S:01 F:41 f:0 SN:2 L:15 T:67 P:98805abb12ef12f241db C:7202
2017.04.13 21:28:41.762 5: zwc e015dfed S:67 F:03 f:0 SN:2 L:0b T:01 P: C:af01
2017.04.13 21:28:41.790 5: zwc e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:9881ac103d8a01b2ecae786465665a36206fe37105c830 C:64c5 2017.04.13 21:28:41.798 5: z100k e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:9881ac103d8a01b2ecae786465665a36206fe37105c830 C:64c5
2017.04.13 21:28:41.799 5: zwc e015dfed S:01 F:03 f:0 SN:2 L:0b T:67 P: C:7738
2017.04.13 21:28:44.378 5: zwc e015dfed S:01 F:41 f:0 SN:3 L:0d T:67 P:9840 C:938b
2017.04.13 21:28:44.386 5: zwc e015dfed S:67 F:03 f:0 SN:3 L:0b T:01 P: C:9831
2017.04.13 21:28:44.400 5: zwc e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:98807adf6ec6735dee25 C:1315 2017.04.13 21:28:44.411 5: z100k e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:98807adf6ec6735dee25 C:1315
2017.04.13 21:28:44.411 5: zwc e015dfed S:01 F:03 f:0 SN:3 L:0b T:67 P: C:4008
2017.04.13 21:28:44.471 5: zwc e015dfed S:01 F:41 f:0 SN:4 L:26 T:67 P:988197ce9c3ac753a06724feae74291b80447ac7c19f1036bcfe75 C:0d53 2017.04.13 21:28:44.474 5: z100k e015dfed S:01 F:41 f:0 SN:4 L:26 T:67 P:988197ce9c3ac753a06724feae74291b80447ac7c19f1036bcfe75 C:0d53
2017.04.13 21:28:44.478 5: zwc e015dfed S:67 F:03 f:0 SN:4 L:0b T:01 P: C:1da1
2017.04.13 21:28:44.502 5: zwc e015dfed S:67 F:41 f:0 SN:4 L:0d T:01 P:9840 C:cfab
2017.04.13 21:28:44.510 5: zwc e015dfed S:01 F:03 f:0 SN:4 L:0b T:67 P: C:c598
2017.04.13 21:28:44.564 5: zwc e015dfed S:01 F:41 f:0 SN:5 L:15 T:67 P:9880cea4dc36e3ca58a7 C:e8c0 2017.04.13 21:28:44.571 5: z100k e015dfed S:01 F:41 f:0 SN:5 L:15 T:67 P:9880cea4dc36e3ca58a7 C:e8c0
2017.04.13 21:28:44.571 5: zwc e015dfed S:67 F:03 f:0 SN:5 L:0b T:01 P: C:2a91
2017.04.13 21:28:44.600 5: zwc e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:98814cd2cd1238deb6a8664ee748ce11cfb12584ee99b2 C:329f 2017.04.13 21:28:44.605 5: z100k e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:98814cd2cd1238deb6a8664ee748ce11cfb12584ee99b2 C:329f
2017.04.13 21:28:44.606 5: zwc e015dfed S:01 F:03 f:0 SN:5 L:0b T:67 P: C:f2a8
2017.04.13 21:28:44.619 5: zwc e015dfed S:67 F:41 f:0 SN:6 L:0d T:01 P:9840 C:8b28
2017.04.13 21:28:44.628 5: zwc e015dfed S:01 F:03 f:0 SN:6 L:0b T:67 P: C:abf8
2017.04.13 21:28:44.672 5: zwc e015dfed S:01 F:41 f:0 SN:6 L:15 T:67 P:9880938a4a80436b8ddb C:73f6 2017.04.13 21:28:44.678 5: z100k e015dfed S:01 F:41 f:0 SN:6 L:15 T:67 P:9880938a4a80436b8ddb C:73f6
2017.04.13 21:28:44.678 5: zwc e015dfed S:67 F:03 f:0 SN:6 L:0b T:01 P: C:73c1
2017.04.13 21:28:44.705 5: zwc e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:9881863bb792330d7e60225fc21b93725463a4f874fbfc C:d985 2017.04.13 21:28:44.711 5: z100k e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:9881863bb792330d7e60225fc21b93725463a4f874fbfc C:d985
2017.04.13 21:28:44.711 5: zwc e015dfed S:01 F:03 f:0 SN:7 L:0b T:67 P: C:9cc8
2017.04.13 21:28:47.297 5: zwc e015dfed S:01 F:41 f:0 SN:7 L:0d T:67 P:9840 C:1a8d
2017.04.13 21:28:47.306 5: zwc e015dfed S:67 F:03 f:0 SN:7 L:0b T:01 P: C:44f1
2017.04.13 21:28:47.322 5: zwc e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:9880a8ccb9ebf1b6014d C:49d9 2017.04.13 21:28:47.329 5: z100k e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:9880a8ccb9ebf1b6014d C:49d9
2017.04.13 21:28:47.330 5: zwc e015dfed S:01 F:03 f:0 SN:8 L:0b T:67 P: C:b0f9
2017.04.13 21:28:47.371 5: zwc e015dfed S:01 F:41 f:0 SN:8 L:26 T:67 P:9881774fafb89a455f14de5583fb1bdeedf3a8e730d88ec0597b88 C:5c5b 2017.04.13 21:28:47.371 5: z100k e015dfed S:01 F:41 f:0 SN:8 L:26 T:67 P:9881774fafb89a455f14de5583fb1bdeedf3a8e730d88ec0597b88 C:5c5b
2017.04.13 21:28:47.373 5: zwc e015dfed S:67 F:03 f:0 SN:8 L:0b T:01 P: C:68c0
2017.04.13 21:28:47.396 5: zwc e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1
2017.04.13 21:28:47.406 5: zwc e015dfed S:01 F:03 f:0 SN:9 L:0b T:67 P: C:87c9
2017.04.13 21:28:47.439 5: zwc e015dfed S:01 F:41 f:0 SN:9 L:15 T:67 P:98800ca06cd1e7f5b873 C:bc5c 2017.04.13 21:28:47.446 5: z100k e015dfed S:01 F:41 f:0 SN:9 L:15 T:67 P:98800ca06cd1e7f5b873 C:bc5c
2017.04.13 21:28:47.447 5: zwc e015dfed S:67 F:03 f:0 SN:9 L:0b T:01 P: C:5ff0
2017.04.13 21:28:47.475 5: zwc e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98818de321949fb0ef471a9bc3c80c8f0ab5a8a5d411b7 C:f707 2017.04.13 21:28:47.481 5: z100k e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98818de321949fb0ef471a9bc3c80c8f0ab5a8a5d411b7 C:f707
2017.04.13 21:28:47.482 5: zwc e015dfed S:01 F:03 f:0 SN:a L:0b T:67 P: C:de99
2017.04.13 21:28:47.496 5: zwc e015dfed S:67 F:41 f:0 SN:b L:0d T:01 P:9840 C:aa52
2017.04.13 21:28:47.506 5: zwc e015dfed S:01 F:03 f:0 SN:b L:0b T:67 P: C:e9a9
2017.04.13 21:28:47.548 5: zwc e015dfed S:01 F:41 f:0 SN:a L:15 T:67 P:988049b326247efe8103 C:d6fe 2017.04.13 21:28:47.554 5: z100k e015dfed S:01 F:41 f:0 SN:a L:15 T:67 P:988049b326247efe8103 C:d6fe
2017.04.13 21:28:47.554 5: zwc e015dfed S:67 F:03 f:0 SN:a L:0b T:01 P: C:06a0
2017.04.13 21:28:47.580 5: zwc e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881790cab10d1304d46105f72804982b195c74150740b C:d870 2017.04.13 21:28:47.586 5: z100k e015dfed S:67 F:41 f:0 SN:c L:22 T:01 P:9881790cab10d1304d46105f72804982b195c74150740b C:d870
2017.04.13 21:28:47.587 5: zwc e015dfed S:01 F:03 f:0 SN:c L:0b T:67 P: C:6c39
2017.04.13 21:28:49.485 5: zwc e015dfed S:01 F:41 f:0 SN:b L:0d T:67 P:9840 C:91a6
2017.04.13 21:28:49.492 5: zwc e015dfed S:67 F:03 f:0 SN:b L:0b T:01 P: C:3190
2017.04.13 21:28:49.510 5: zwc e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:98805222f580e16420bb C:c100 2017.04.13 21:28:49.515 5: z100k e015dfed S:67 F:41 f:0 SN:d L:15 T:01 P:98805222f580e16420bb C:c100
2017.04.13 21:28:49.516 5: zwc e015dfed S:01 F:03 f:0 SN:d L:0b T:67 P: C:5b09
2017.04.13 21:28:49.560 5: zwc e015dfed S:01 F:41 f:0 SN:c L:26 T:67 P:9881f520e4da22570ccc532e42ece6c5547d527f786197023650db C:7dc9 2017.04.13 21:28:49.563 5: z100k e015dfed S:01 F:41 f:0 SN:c L:26 T:67 P:9881f520e4da22570ccc532e42ece6c5547d527f786197023650db C:7dc9
2017.04.13 21:28:49.566 5: zwc e015dfed S:67 F:03 f:0 SN:c L:0b T:01 P: C:b400
2017.04.13 21:28:49.590 5: zwc e015dfed S:67 F:41 f:0 SN:e L:0d T:01 P:9840 C:8905
2017.04.13 21:28:49.638 5: zwc e015dfed S:01 F:41 f:0 SN:d L:15 T:67 P:9880e3fdc61a3a49419c C:1779 2017.04.13 21:28:49.646 5: z100k e015dfed S:01 F:41 f:0 SN:d L:15 T:67 P:9880e3fdc61a3a49419c C:1779
2017.04.13 21:28:49.647 5: zwc e015dfed S:67 F:03 f:0 SN:d L:0b T:01 P: C:8330
2017.04.13 21:28:49.674 5: zwc e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:9881e5e94b48706a9ee5d50917f4e3132567c6c0480600 C:eb9b 2017.04.13 21:28:49.680 5: z100k e015dfed S:67 F:41 f:0 SN:f L:22 T:01 P:9881e5e94b48706a9ee5d50917f4e3132567c6c0480600 C:eb9b
2017.04.13 21:28:49.681 5: zwc e015dfed S:01 F:03 f:0 SN:f L:0b T:67 P: C:3569
2017.04.13 21:28:49.694 5: zwc e015dfed S:67 F:41 f:0 SN:1 L:0d T:01 P:9840 C:ecfc
2017.04.13 21:28:49.706 5: zwc e015dfed S:01 F:03 f:0 SN:1 L:0b T:67 P: C:2e68
2017.04.13 21:28:49.782 5: zwc e015dfed S:01 F:41 f:0 SN:e L:15 T:67 P:9880d7ba00c62bddc6b7 C:0431 2017.04.13 21:28:49.790 5: z100k e015dfed S:01 F:41 f:0 SN:e L:15 T:67 P:9880d7ba00c62bddc6b7 C:0431
2017.04.13 21:28:49.790 5: zwc e015dfed S:67 F:03 f:0 SN:e L:0b T:01 P: C:da60
2017.04.13 21:28:49.820 5: zwc e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:98812e950b3b5cb3909aa1b9a52ad7d7508c03b021687e C:80cd 2017.04.13 21:28:49.828 5: z100k e015dfed S:67 F:41 f:0 SN:2 L:22 T:01 P:98812e950b3b5cb3909aa1b9a52ad7d7508c03b021687e C:80cd
2017.04.13 21:28:49.829 5: zwc e015dfed S:01 F:03 f:0 SN:2 L:0b T:67 P: C:7738
2017.04.13 21:28:52.143 5: zwc e015dfed S:01 F:41 f:0 SN:f L:0d T:67 P:9840 C:18a0 2017.04.13 21:28:52.152 5: z100k e015dfed S:01 F:41 f:0 SN:f L:0d T:67 P:9840 C:18a0
2017.04.13 21:28:52.152 5: zwc e015dfed S:67 F:03 f:0 SN:f L:0b T:01 P: C:ed50
2017.04.13 21:28:52.175 5: zwc e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:9880339b3de71f2a6081 C:3af6 2017.04.13 21:28:52.176 5: z100k e015dfed S:67 F:41 f:0 SN:3 L:15 T:01 P:9880339b3de71f2a6081 C:3af6
2017.04.13 21:28:52.178 5: zwc e015dfed S:01 F:03 f:0 SN:3 L:0b T:67 P: C:4008
2017.04.13 21:28:52.248 5: zwc e015dfed S:01 F:41 f:0 SN:1 L:26 T:67 P:98816677c3eae2f2b64dd351bc36b53c3102339bbdc3956d9a137b C:e5e0 2017.04.13 21:28:52.250 5: z100k e015dfed S:01 F:41 f:0 SN:1 L:26 T:67 P:98816677c3eae2f2b64dd351bc36b53c3102339bbdc3956d9a137b C:e5e0
2017.04.13 21:28:52.273 5: zwc e015dfed S:67 F:03 f:0 SN:1 L:0b T:01 P: C:f651
2017.04.13 21:28:52.279 5: zwc e015dfed S:67 F:41 f:0 SN:4 L:0d T:01 P:9840 C:cfab
2017.04.13 21:28:52.290 5: zwc e015dfed S:01 F:03 f:0 SN:4 L:0b T:67 P: C:c598
2017.04.13 21:28:52.338 5: zwc e015dfed S:01 F:41 f:0 SN:2 L:15 T:67 P:98808906f4fce63c14c0 C:42e7 2017.04.13 21:28:52.343 5: z100k e015dfed S:01 F:41 f:0 SN:2 L:15 T:67 P:98808906f4fce63c14c0 C:42e7
2017.04.13 21:28:52.346 5: zwc e015dfed S:67 F:03 f:0 SN:2 L:0b T:01 P: C:af01
2017.04.13 21:28:52.374 5: zwc e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:9881cc3be40a3f03ddfc502b5c3e89856f2048381803d3 C:153c 2017.04.13 21:28:52.379 5: z100k e015dfed S:67 F:41 f:0 SN:5 L:22 T:01 P:9881cc3be40a3f03ddfc502b5c3e89856f2048381803d3 C:153c
2017.04.13 21:28:52.379 5: zwc e015dfed S:01 F:03 f:0 SN:5 L:0b T:67 P: C:f2a8
2017.04.13 21:28:52.393 5: zwc e015dfed S:67 F:41 f:0 SN:6 L:0d T:01 P:9840 C:8b28 2017.04.13 21:28:52.401 5: z100k e015dfed S:67 F:41 f:0 SN:6 L:0d T:01 P:9840 C:8b28
2017.04.13 21:28:52.402 5: zwc e015dfed S:01 F:03 f:0 SN:6 L:0b T:67 P: C:abf8
2017.04.13 21:28:52.474 5: zwc e015dfed S:01 F:41 f:0 SN:3 L:15 T:67 P:9880713e76fd825c46ee C:cefb 2017.04.13 21:28:52.481 5: z100k e015dfed S:01 F:41 f:0 SN:3 L:15 T:67 P:9880713e76fd825c46ee C:cefb
2017.04.13 21:28:52.483 5: zwc e015dfed S:67 F:03 f:0 SN:3 L:0b T:01 P: C:9831
2017.04.13 21:28:52.510 5: zwc e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:98810e50202abda93e386796031971e46e202ca2ba598e C:825b 2017.04.13 21:28:52.514 5: z100k e015dfed S:67 F:41 f:0 SN:7 L:22 T:01 P:98810e50202abda93e386796031971e46e202ca2ba598e C:825b
2017.04.13 21:28:52.517 5: zwc e015dfed S:01 F:03 f:0 SN:7 L:0b T:67 P: C:9cc8
2017.04.13 21:28:54.134 5: zwc e015dfed S:01 F:41 f:0 SN:4 L:0d T:67 P:9840 C:f45f
2017.04.13 21:28:54.141 5: zwc e015dfed S:67 F:03 f:0 SN:4 L:0b T:01 P: C:1da1
2017.04.13 21:28:54.158 5: zwc e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:98809cb6b5fce1f9c077 C:876d 2017.04.13 21:28:54.166 5: z100k e015dfed S:67 F:41 f:0 SN:8 L:15 T:01 P:98809cb6b5fce1f9c077 C:876d
2017.04.13 21:28:54.166 5: zwc e015dfed S:01 F:03 f:0 SN:8 L:0b T:67 P: C:b0f9
2017.04.13 21:28:54.252 5: zwc e015dfed S:01 F:41 f:0 SN:5 L:26 T:67 P:9881c78abdfb5675479a722b699133e71e379c257886d5f78b7ea6 C:e7cd 2017.04.13 21:28:54.254 5: z100k e015dfed S:01 F:41 f:0 SN:5 L:26 T:67 P:9881c78abdfb5675479a722b699133e71e379c257886d5f78b7ea6 C:e7cd
2017.04.13 21:28:54.258 5: zwc e015dfed S:67 F:03 f:0 SN:5 L:0b T:01 P: C:2a91
2017.04.13 21:28:54.282 5: zwc e015dfed S:67 F:41 f:0 SN:9 L:0d T:01 P:9840 C:eed1
2017.04.13 21:28:54.290 5: zwc e015dfed S:01 F:03 f:0 SN:9 L:0b T:67 P: C:87c9
2017.04.13 21:28:54.344 5: zwc e015dfed S:01 F:41 f:0 SN:6 L:15 T:67 P:9880b15a2e010ba445a6 C:c630 2017.04.13 21:28:54.344 5: z100k e015dfed S:01 F:41 f:0 SN:6 L:15 T:67 P:9880b15a2e010ba445a6 C:c630
2017.04.13 21:28:54.346 5: zwc e015dfed S:67 F:03 f:0 SN:6 L:0b T:01 P: C:73c1
2017.04.13 21:28:54.374 5: zwc e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98819e9986423ca726bd3160bc41b19f54256ac454fb0a C:60a4 2017.04.13 21:28:54.379 5: z100k e015dfed S:67 F:41 f:0 SN:a L:22 T:01 P:98819e9986423ca726bd3160bc41b19f54256ac454fb0a C:60a4
2017.04.13 21:28:54.381 5: zwc e015dfed S:01 F:03 f:0 SN:a L:0b T:67 P: C:de99
2017.04.13 21:28:54.394 5: zwc e015dfed S:67 F:41 f:0 SN:b L:0d T:01 P:9840 C:aa52
2017.04.13 21:28:54.406 5: zwc e015dfed S:01 F:03 f:0 SN:b L:0b T:67 P: C:e9a9
2017.04.13 21:28:54.457 5: zwc e015dfed S:01 F:41 f:0 SN:7 L:15 T:67 P:9880f05c859a08fc7f3f C:eff7 2017.04.13 21:28:54.466 5: z100k e015dfed S:01 F:41 f:0 SN:7 L:15 T:67 P:9880f05c859a08fc7f3f C:eff7
2017.04.13 21:28:54.486 5: zwc e015dfed S:67 F:03 f:0 SN:7 L:0b T:01 P: C:44f1
2017.04.13 21:28:54.505 5: zwc e015dfed S:01 F:03 f:0 SN:c L:0b T:67 P: C:6c39
Gruß,
Andreas.
Hi,
kleiner Nachtrag:
bei 40K sieht es ähnlich aus -> 176 zu 88
Bei 9K6 ist es aber nahezu perfekt: 372 zu 370, wobei der CUL 3 Nachrichten empfangen hat die der MapleCUL nicht gemeldet hat, der MapleCUL hat dafür aber auch eine Nachricht empfangen der CUL nicht gemeldet hat!
Sieht also so aus als ob es was mit der Geschwindigkeit zu tun hätte. Da muss ich wohl mal sehr genau nachschauen wann der Buffer voll ist und wie schnell darauf reagiert wird...
Gruß,
Andreas.
Hallo,
noch ein (anderer) Nachtrag. Mein PZU (Problematischer Z-Uno) ;) läuft wieder mit 100k!
Mir war aufgefallen das einige der Nachrichten geroutet wurden (von einem Gerät das statt 80cm nur 60cm vom Dongle entfernt ist...). Daraufhin habe ich mal ein neighborUpdate bei dem PZU gemacht, seitdem läuft die Kommunikation wieder mit 100k ab. Da ist dann wahrscheinlich was mit der Routinginformation durcheinander gekommen.
Gruß,
Andreas.
ZitatSieht also so aus als ob es was mit der Geschwindigkeit zu tun hätte. Da muss ich wohl mal sehr genau nachschauen wann der Buffer voll ist und wie schnell darauf reagiert wird...
Ich warte noch mit dem Zurueckschicken, wenn es ein FW-Problem ist, dann koennte ich das auch selbst flashen. Es sei denn du brauchst einen zweiten Exemplar: dann melde dich.
Hi Rudi,
nee, zweites Exemplar ist erst mal nicht nötig, außerdem könnte ich mir auch schnell noch eines zusammenlöten, Platine und Teile liegen ja hier.
Aber ich hätte noch mal eine "Debug"-Frage. Ich habe Debug-Zeilen in die a-culfw gepackt und kann mir das seriell am DBG Anschluss ansehen. Ich hätte den Output aber gerne im fhem.log, am besten natürlich von fhem selbst dort mit Zeitstempel etc. reingeschrieben um den zeitlichen Ablauf nachvollziehen zu können.
Gibt es eine Möglichkeit in fhem ein serielles Device einzubinden und den Output einfach in das Logfile schreiben zu lassen oder müsste man hierfür erst ein Modul schreiben?
Da mir die USB-Ports an dem Linux-Server langsam ausgehen habe ich den DBG einfach mit einer der internen UART Ports vom Maple gekreuzt und lese das über den zweiten angelegten USB-/Seriell-Port aus. Der Output geht aber einfach per "screen" auf die Konsole
Gruß,
Andreas.
P.S.: Jetzt muss ich erst mal den normalen CUL neu flashen, da ist auch noch alter Debug-Code von mir drin der jetzt stört... Mal sehen wie das noch mal ging, ist schon so lange her...
ZitatGibt es eine Möglichkeit in fhem ein serielles Device einzubinden und den Output einfach in das Logfile schreiben zu lassen oder müsste man hierfür erst ein Modul schreiben?
Mir ist kein Modul bekannt, der sowas macht, evtl. kannst du mit ECMD was zurechtkonfigurieren.
Ein neues Modul waere aber relativ einfach: DefineFn mit DevIo_OpenDev und ReadFn mit Log3 duerfte reichen.
Hi Rudi,
danke für die Info.
Dann bastel ich mir mal ein Modul... 8)
Noch eine weitere Frage. Die Definition des ersten ZWCUL am ersten Stackable lautet bei mir (nach Deinem Beispiel) "FHEM:DEVIO:SSC1:9600 00000000 01". Was bedeutet in dem Fall die 9600? Das ist dann doch nciht die echte Baudrate, oder?
Gruß,
Andreas.
Jetzt wo du fragst: 9600 ist irrefuehrend. Es muss nur irgendetwas sein, und man kann an dem irgendetwas @baudrate anhaengen. Habe damals den FHEM:DEVIO Patch von jensb (https://forum.fhem.de/index.php/topic,46276.0.html) uebernommen, und deswegen nicht tief ueber die Notwendigkeit einzelner Parameter nachgedacht.
STACKABLE verwendet weder das irgendwas, noch die optionale Baudrate.
Hi Rudi,
ok, dann ist es ja egal und ich kann es so lassen.
Habe mir jetzt zum Testen mal ein 98_logger.pm geschrieben ;D
Läuft soweit, aber der Maple verschluckt anscheinend ab-und-zu ein "\n" am Ende wodurch das Log dann doch nicht so schön ist wie gewünscht.
So ein ACK Paket scheint der Maple gar nicht zu erkennen. Es wird dabei kein Paket wegen falscher Länger oder falscher CS verworfen, es sieht so aus als ob gar nichts ankommt.
Ich kann mir nur vorstellen das der Maple gerade mit was anderem Beschäftigt ist bzw. das der CC gerade wieder initialisiert wird.
Ich werde mal die anderen Protokolle rauswerfen bzw. den Aufruf in der main-schleife auskommentieren soweit ich mir da sicher bin das da nicht noch was wichtiges gemacht wird.
Gruß,
Andreas.
Es gibt eigentlich nichts in der main-schleife zum auskommentieren, da im rf_mode_task() immmer nur das Protokoll aufgerufen wird, das auch aktiviert ist.
Aber du kannst mal ausprobieren, alles zu deaktivieren, was für die MultiCC Funktion dazugekommen ist. Bau dazu das Target MapleCUL_BL und entferne "#define USE_RF_MODE" in der board.h. Dann hast du zwar nur einen Transceiver, aber der Code ist dann am ähnlichsten zur AVR Variante.
Hi Telekatz,
Zitat von: Telekatz am 14 April 2017, 18:38:28
Es gibt eigentlich nichts in der main-schleife zum auskommentieren, da im rf_mode_task() immmer nur das Protokoll aufgerufen wird, das auch aktiviert ist.
Du hast Recht, ich hatte nicht auf das #ifdef geachtet.
Zitat von: Telekatz am 14 April 2017, 18:38:28
Aber du kannst mal ausprobieren, alles zu deaktivieren, was für die MultiCC Funktion dazugekommen ist. Bau dazu das Target MapleCUL_BL und entferne "#define USE_RF_MODE" in der board.h. Dann hast du zwar nur einen Transceiver, aber der Code ist dann am ähnlichsten zur AVR Variante.
Hmm, das ist dann wahrscheinlich der erste Transceiver auf CC0, oder? Da habe ich natürlich ein 433er Modul gesteckt.
Läuft das MapleCUL_BL dann auch mit dem Bootloader zusammen?
Dazu werde ich aber wohl frühestens am Montag kommen. Ich bin aber schon mal recht zufrieden mit dem bisherigen Fortschritt ,-)
Danke,
Andreas.
Die Targets, die mit _BL enden, sind für den Bootloader. Und die Reihenfolge der Transceiver kannst du in der board.h unter CCTRANSCEIVERS ändern.
Hi,
Zitat von: Telekatz am 14 April 2017, 20:14:17
Die Targets, die mit _BL enden, sind für den Bootloader. Und die Reihenfolge der Transceiver kannst du in der board.h unter CCTRANSCEIVERS ändern.
irgendwie war ich eben nicht ganz dabei...
Das _BL für BootLoader steht war mir schon klar, ich hatte das _BL in Deinem Text irgendwie überlesen und dachte ich müsste jetzt die NICHT _BL Variante erzeugen... Also alles gut ,-)
Muss ich den CCCOUNT dann auch auf 1 setzen, oder reicht es das USE_RF_MODE zu entfernen?
Gruß,
Andreas.
CCCOUNT muss nicht geändert werden. Die Anzahl der Transceiver wird anhand des Targets über HAS_MULTI_CC definiert.
Hallo Rudi, hallo Telekatz,
ich habe mir jetzt mal einige Übertragungen mit dem LogicAnalyser angesehen und auch die Laufzeiten grob mit dem HAL_GetTick() ermittelt.
Ich bin etwas verwirrt über die meiner Meinung nach langen Laufzeiten...
Beispiel vom HW-LogicAnalyser (von einem verworfenem Paket, Länge 191):
Zeitdifferenz zwischen GDO2 (RX_FIFO_THR=8 erreicht) bis SPI Übertragung startet: 1,8 ms. -> Finde ich sehr lange. (Wenn ich mich nicht verrechne dann dauert 1Byte über ZWave mit 100kBaud 10 µs. Das würde bedeutet das in der Zeit bereits 180 weitere Zeichen angekommen sein müssten.)
-> Habe mich vertan, es sind kBit und nicht kBaud -> 1,8ms reichen für ca. 22 weitere Byte
Das Auslesen der ersten 8 Byte per SPI dauer dann 280 µs. Die Frequenz der SPI SCKL liegt hier nur bei ca. 280 kHz. Sowohl der Maple als auch der CC1100 dürften hier wesentlich schnellere Datenraten hergeben... (CC1100 bis ca. 6Mhz, beim Maple müsste es einen Mode 4 mit 4,5 MHz geben...) Auch hier könnte man mMn schneller sein, wobei ich allerdings noch nicht gefunden habe wo/wie man die SPI Geschwindigkeit konfiguriert, die Default Geschwindigkeit ist anscheinend in STM32/hal_spi.c über " hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;" definiert. Hier könnten man mMn auf "_16" gehen...
Da die Paketlänge mit 191 über dem max-Wert liegt sollte das Paket verworfen werden und es wird rf_zwave_init() aufgerufen, es folgt jedoch erst einmal eine Pause von 1,3 ms die ich mir nicht erklären kann.
Der Reset und die Initialisierung der CC1100-Register dauert dann noch mal 1,9 ms. Danach folgt eine Pause von 4ms die aber auch im Code so vorgesehen ist. Das nachfolgende zccRX() dauert dann noch mal 875 µs.
D.h. vom Zeitpunkt das die 8 bytes im FIFO-Buffer sind (GDO2 Signal) bis zum Abschluss der Neu-Initialisierung dauert es in diesem Fall 10ms. (Laut meiner Rechnung reicht das für 1000 weitere Bytes die während dieser Zeit übertragen werden können...) -> auch hier, es sind kBit nicht kBaud -> 10ms reichen für ca. 125 weitere Bytes
Eine Auswertung der Ticks aus dem Logfile ergibt ähnliche Ergebnisse.
Für den Fall das die Länge mal in Ordnung sein sollte ergben sich aber teilweise erhebliche längere Laufzeiten bis zu 38 ms, da wundert es mich dann nicht das keine ACK (die in der Regel 1-3 ms nach der Übertragung ankommen) empfangen werden...
Beispiel vom HW-LogicAnalyser (von einem gültigen Paket, Länge 63):
Zeitdifferenz zwischen GDO2 und start der SPI Übertragung: 1,7 ms
Auslesen Fifo_buffer: 285 µs
Pause bis mit dem weiteren Auslesen gestartet wird 1 ms
Zeitdauer Auslesen der restlichen 55 Bytes: 2,2 ms
Pause bis mit zxxRX() weitergemacht wird 3,8 ms
Dauer zxxRX() 930 µs
Gesamtdauer von GDO2 Bit gesetzt bis CC1100 wieder emfpangsbereit: 10ms
Kleine Statistik aus dem Logfile:
335 erkannte Pakete, davon:
112 wegen falscher Länge verworfen, min: 9 ms, max: 10ms, Durchschnitt: 10ms
102 wegen unpassender Länge während des Auslesens verworen, min: 10ms, max: 27ms, Durchschnitt 10ms
121 mit korrekter Chechsumme erkannt, min: 9ms, max: 38ms, Durchschnitt: 17ms
@Rudi: Kannst Du Dich erinnern mit welcher Geschwindigkeit das SPI bei CUL läuft? Ich kann da leider nicht mit dem HW-LogicAnalyser dran...
@Telekatz: Gibt es Interruptroutinen beim MapleCUL? Denke nicht, oder etwa doch?
Gruß,
Andreas.
Der Timer Interrupt für TIM1 wird periodisch aufgerufen (clock_TimerElapsedCallback in clock.c). Außerdem läuft die USB und UART Übertragung Interruptgesteuert ab.
Du solltest aber beachten, dass deine Debugausgaben auch Verzögerungen verursachen. Diese Ausgabe läuft nicht mit Interrupts und es geht erst weiter, wenn alle Bytes übertragen sind.
Um das zu minimieren solltest du direkt in den entsprechenden UART Empfangspuffer schreiben. Dann läuft das nicht erst über UART und wird in der main loop dann direkt über USB gesendet.
dbgu.c:
#include "ringbuffer.h"
extern rb_t UART_Rx_Buffer[];
int fputc(int ch, FILE *f) {
//HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF);
//SWO_PrintChar((uint8_t)ch,0);
rb_put(&UART_Rx_Buffer[0], ch);
return ch;
}
Zitat@Rudi: Kannst Du Dich erinnern mit welcher Geschwindigkeit das SPI bei CUL läuft?
Die SPI Geschwindigkeit wird vom Master bestimmt.
Wir setzen SPSR nicht, wir modifizieren es nur im spi.c per
SPSR |= _BV(SPI2X);das entspricht laut Atmel Doku f
osc/2 -> auf dem CUL sollte der Atmel Chip mit 4MHz senden.
Laut CC1101 Doku haengt die andere Richtung vom extern zugefuehrten SCLK ab, und sollte fuer Burst unter 6.5MHz bleiben. Wenn ich board.h richtig interpretiere, dann kommt SCLK vom Atmel (PB1), weiss gerade nicht, wie/wo man PB1 mit einem Taktgeber verheiratet. Gehe aber auch von etwas im Bereich von 1-4 MHz aus.
Hi Telekatz,
Zitat von: Telekatz am 16 April 2017, 11:15:12
Der Timer Interrupt für TIM1 wird periodisch aufgerufen (clock_TimerElapsedCallback in clock.c). Außerdem läuft die USB und UART Übertragung Interruptgesteuert ab.
Sowas hatte ich befürchtet das USB auch per Interrupt läuft. Dann muss ich mal schauen ob ich mir da auch eine kurze Debug-Message reinschreibe.
Zitat von: Telekatz am 16 April 2017, 11:15:12
Du solltest aber beachten, dass deine Debugausgaben auch Verzögerungen verursachen. Diese Ausgabe läuft nicht mit Interrupts und es geht erst weiter, wenn alle Bytes übertragen sind.
Um das zu minimieren solltest du direkt in den entsprechenden UART Empfangspuffer schreiben. Dann läuft das nicht erst über UART und wird in der main loop dann direkt über USB gesendet.
Ja, ich hatte testweise meinen gesamten Debugcode mal auskommentiert, dann geht das ganze ungefähr 1 bis 1,5 ms schneller, was ich auch schon erheblich finde.
Ich glaube ich werde mir da nicht so sehr die Mühe machen den Debug-Code noch zu optimieren, die Zeit bleibt da bei was anderem liegen, ich fürchte ja das es die DH2() Funktion bzw. die serielle Übertragung über die USB-Schnittstelle.
Ich werde testweise mal den Teiler für die SPI Kommunikation runtersetzen. Weißt Du zufällig wie man das per Befehl umkonfigurieren kann? Ich würde das ansonsten in STM32/hal_spi.c ändern und sehen ob das greift.
Gruß,
Andreas.
Hi Rudi,
Zitat von: rudolfkoenig am 16 April 2017, 11:55:16
Die SPI Geschwindigkeit wird vom Master bestimmt.
Wir setzen SPSR nicht, wir modifizieren es nur im spi.c per
SPSR |= _BV(SPI2X);
das entspricht laut Atmel Doku fosc/2 -> auf dem CUL sollte der Atmel Chip mit 4MHz senden.
ich hatte jetzt auch etwas im Bereich von >1 Mhz erwartet, mit der Tendenz zu 4 Mhz...
Zitat von: rudolfkoenig am 16 April 2017, 11:55:16
Laut CC1101 Doku haengt die andere Richtung vom extern zugefuehrten SCLK ab, und sollte fuer Burst unter 6.5MHz bleiben. Wenn ich board.h richtig interpretiere, dann kommt SCLK vom Atmel (PB1), weiss gerade nicht, wie/wo man PB1 mit einem Taktgeber verheiratet. Gehe aber auch von etwas im Bereich von 1-4 MHz aus.
Die Geschwindigkeit hängt ja immer an SCLK, und das taktet laut meinem LogicAnalyser nur mit 280 Khz, was auch zu dem voreingestellten Frequenzteiler im Code passt. Ich werde das einfach mal auf die 4.5 MHz stellen und schauen was passiert.
Gruß,
Andreas.
Hallo zusammen,
ich habe jetzt mal allen Debugcode entfernt und den Frequenzteiler für SPI auf _16 -> 4.5 MHz gestellt.
a-culfw\trunk\culfw\STM32\hal_spi.c:
//~ hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;
Im LogicAnalyser sieht das Signal für SCLK jetzt nicht mehr soo sauber/gleichmäßig aus, das schwankt da auch schon mal bis 5.3 MHz bei einzelnen Flanken, das sollte aber kein Problem sein solange das unter 6.5 MHz bleibt ...
Die Datenpakete die ich bisher beobachtet haben sind jetzt im Schnitt zwischen 1,5 und 2 ms abgearbeitet, inklusive der ca. 0,8 ms für das zccRX(). Das längste was ich jetzt bisher gesehen habe ist 3,4 ms.
Die Statistik für 100k sieht jetzt auch schon VIEL besser aus:
229 100k Datenpakete: ZWCUL hat 228 erkannt, und nur eine Nachricht "verpasst", MapleCul (auf 100k) hat 223 erkannt, 5 Nachrichten und ein ACK verpasst.
Das sieht schon mal sehr gut aus, ein Datenverlust von < 3% beim Maple, allerdings gegen sehr gute < 0.5% beim CUL.
Ich hatte jetzt noch mal mit Debug-Code probiert und hatte dann teilweise wieder eine fast 4ms lange Pause, das ist dann wahrscheinlich der CDC-Task der dann läuft...
Da der GDO0 Pin per Default als Ausgang geschaltet ist und nur über die Bedatung als 3-state geschaltet wird habe ich den Pin am Maple als Input definiert damit es während des Reset keine Probleme gibt.
a-culfw\trunk\culfw\clib\rf_zwave.c:
void
rf_zwave_init(void)
{
#ifdef USE_HAL
//~ hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_IN_CS_IN);
#else
SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
#endif
Ich werde morgen mal versuchen 40k (und noch mal 9k6) zu testen, ob das jetzt auch besser aussieht.
Gruß,
Andreas.
Edit: Ich habe mal das fw-file angehängt.
Hallo Rudi,
und schon gibt es wieder die ersten Probleme...
der zwc = CUL steht eigentlich auf 100k und hatte auch brav die 100k Pakete empfangen. Jetzt ist mir gerade aurgefallen das er die 40k Pakete empfängt, diese aber mit 100k dekodiert will (2byte CS)
Neustart von FHEM hatte nichts genutzt, gleiches Ergebnis, erst ein "set zwc reopen" hat den wieder auf 100k gesetzt.
Irgendeine Idee woher das jetzt kommen könnte? Es betrifft wie gesagt den CUL und nicht den Maple...
Gruß,
Andreas.
2017.04.16 21:58:55.616 5: zwc e015dfed S:40 F:51 f:0 SN:b L:14 T:01 P:600d07003105012200 C:f1bb
2017.04.16 21:58:55.616 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.617 5: z40k e015dfed S:40 F:51 f:0 SN:b L:14 T:01 P:600d07003105012200f1 C:bb
2017.04.16 21:58:55.617 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.621 4: ZWDongle_Read ZWDongle_0: rcvd 0004004009600d04003105030125 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.623 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:09600d04003105030125 CB:00
2017.04.16 21:58:55.626 5: z40k e015dfed S:01 F:13 f:0 SN:b L:0a T:40 P: C:6b
2017.04.16 21:58:55.628 5: F: ack speedModified
2017.04.16 21:58:55.629 1: ERROR: Unknown packet ze015dfed01130b0a406b
2017.04.16 21:58:55.642 5: z40k e015dfed S:40 F:51 f:0 SN:c L:16 T:01 P:600d08003105084400002718 C:10
2017.04.16 21:58:55.642 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.646 4: ZWDongle_Read ZWDongle_0: rcvd 000400400a600d07003105012200f1 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.648 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0a600d07003105012200f1 CB:00
2017.04.16 21:58:55.649 5: zwc e015dfed S:40 F:51 f:0 SN:c L:16 T:01 P:600d080031050844000027 C:1810
2017.04.16 21:58:55.649 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.653 1: ERROR: Unknown packet ze015dfed01130c0a406c
2017.04.16 21:58:55.653 5: z40k e015dfed S:01 F:13 f:0 SN:c L:0a T:40 P: C:6c
2017.04.16 21:58:55.653 5: F: ack speedModified
2017.04.16 21:58:55.668 5: z40k e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d0900310501420992 C:b9
2017.04.16 21:58:55.668 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.674 4: ZWDongle_Read ZWDongle_0: rcvd 000400400c600d08003105084400002718 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.676 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0c600d08003105084400002718 CB:00
2017.04.16 21:58:55.677 5: zwc e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d09003105014209 C:92b9
2017.04.16 21:58:55.677 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.681 1: ERROR: Unknown packet ze015dfed01130d0a406d
2017.04.16 21:58:55.714 4: ZWDongle_Read ZWDongle_0: rcvd 000400400a600d0900310501420992 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.716 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0a600d0900310501420992 CB:00
2017.04.16 21:58:55.728 5: z40k e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d0900310501420992 C:b9
2017.04.16 21:58:55.728 5: F: singleCast speedModified ackReq
2017.04.16 21:58:55.728 5: zwc e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d09003105014209 C:92b9
2017.04.16 21:58:55.728 5: F: singleCast speedModified ackReq
ZitatJetzt ist mir gerade aurgefallen das er die 40k Pakete empfängt, diese aber mit 100k dekodiert will
Entweder ist zwave_drate umgekippt (unwahrscheinlich), die Initialisierung ist schiefgegangen (eher unwahrscheinlich), oder das CC1101 empfaengt die Daten trotz "falscher" Datenrate (eher wahrscheinlich).
_Wenn_ diese Hypothese stimmt, taucht die Frage auf, ob wir diese Daten akzeptieren sollten: ich bin unentschlossen. Empfaengt man 40k einigermassen zuverlaessig mit der 100k Eingestellung?
Hi Rudi,
Zitat von: rudolfkoenig am 17 April 2017, 10:11:28
Entweder ist zwave_drate umgekippt (unwahrscheinlich), die Initialisierung ist schiefgegangen (eher unwahrscheinlich), oder das CC1101 empfaengt die Daten trotz "falscher" Datenrate (eher wahrscheinlich).
_Wenn_ diese Hypothese stimmt, taucht die Frage auf, ob wir diese Daten akzeptieren sollten: ich bin unentschlossen. Empfaengt man 40k einigermassen zuverlaessig mit der 100k Eingestellung?
sorry, aber die Empfangstheorie kann ich nicht bestätigen. Der cc1100 der auf 40k eingestellt war hat dabei NICHTS empfangen. Selbst wenn die anderen Parameter (Bandbreite, Frequenz) ähnlich sind, die Datenrate unterscheidet sich um den Faktor 2,5, da sollte nichts empfangen werden können.
Ich gehe jetzt eher von einem SW Problem aus. Heute morgen war der Maple cc1100 der auf 40k eingestellt war "stumm"... Erst ein "reopen" hat da wieder Werte ergeben. Interessanterweise traf dies auch auf den CUL mit 100k zu, der Maple 100k lief aber noch.
Mir fällt aber auch auf das nach einem Reset / oder Anschließen des Maple dieser irgendwie nicht immer richtig/vollständig in FHEM initialisiert wird. Manchmal erhalte ich ein "reappeared" und die Zeile mit den möglichen Kommandos vom CUL, aber es werden KEINE Initialisierungswerte von FHEM gesendet (also z.B. die Datenrate eingestellt).
Mir scheint das hier auf beiden Seiten der Software noch was nicht ganz rund läuft. Das Logfile ist 8MB groß, da drin werde ich ohne eine konkreten Verdacht wohl nichts finden. Ich schau aber trotzdem mal ob da ein disappeared/reappeared auftaucht.
Ansonsten muss ich mal schauen das ich mal die Register vom cc1100 dumpe wenn das noch mal passiert, dann wissen wir wenigsten in welchem Mode das Ding zuletzt war.
Gruß,
Andreas.
Hi,
Zitat von: A.Harrenberg am 16 April 2017, 20:30:21
Die Statistik für 100k sieht jetzt auch schon VIEL besser aus:
229 100k Datenpakete: ZWCUL hat 228 erkannt, und nur eine Nachricht "verpasst", MapleCul (auf 100k) hat 223 erkannt, 5 Nachrichten und ein ACK verpasst.
Das sieht schon mal sehr gut aus, ein Datenverlust von < 3% beim Maple, allerdings gegen sehr gute < 0.5% beim CUL.
hier jetzt auch mal die Statistik mit 40k, sieht ähnlich gut aus:
1586 Datenpakete: ZWCUL hat 1579 erkannt, 5 Nachrichten und 2 ACKs nicht, der MapleCUL hat 1557 Nachrichten erkannt, 17 Nachrichten und 12 ACKs nicht.
Das macht wieder <0.5% Datenverlust beim CUL und <2% beim MapleCUL.
Die Frage ist, lohnt es sich diese 2-3% Datenverlust weiter zu analysieren? Mein erster Ansatzpunkt wäre noch mal die Interrupts zu analysieren ob die hier zu Datenverlusten führen könnten.
Empfangsprobleme sollte bei Abständen <1m keine Auftreten, hochfrequente Störungen am Maple könnte ich mir aber durchaus vorstellen, da sind immerhin 4 Transceiver plus der WZ5100 dran...
Gruß,
Andreas.
ZitatDie Frage ist, lohnt es sich diese 2-3% Datenverlust weiter zu analysieren?
Du musst nicht uebertreiben, es sind nur 1.83% :) => Ich wuerde es nicht.
Was mich interessieren wuerde: wieviel erkennt ein ZWDongle im Vergleich?
Hallo Rudi,
ich habe da noch mal ein paar Fragen zum ZWave-Code...
Nach dem Einlesen der ersten 8 Zeichen aus dem Buffer wird die Länge geprüft und das Paket verworfen wenn die Länge ungültig ist. Hierzu wird rf_zwave_init() aufgerufen was den CC resettet, die Register neu setzt und dann per zccRX() wieder auf "Empfang" geht.
uint8_t len=msg[7], off=8;
if(len < 9 || len > MAX_ZWAVE_MSG) {
rf_zwave_init();
//DC('l'); DNL();
return;
}
Ist der Reset hier wirklich nötig? Würde es nicht reichen in SIDLE zu schalten, den Buffer zu flushen und wieder auf Empfang zu schalten? Zum einen könnte das schneller sein, zum anderen stört mich der Reset gerade beim Experimentieren, da dann meine Änderungen in den Registern dauernd wieder überschrieben werden. Spricht was dagegen hier ohne Reset zu arbeiten?
Nachdem dann die (erwartete) Länge bekannt ist, folgt das Einlesen der restlichen Daten. Hierzu gibt es eine eine Schleife mit einem Delay, was in etwa für 1 Byte ausreicht. Warum gibt es dieses Delay für nur ein Byte? Wäre es nicht sinnvoller länger zu warten um dann mehr Bytes in einem Rutsch auslesen zu können? Im Analyser kann ich sehen das dort teilweise nur Häppchen von zwei Bytes ausgelesen werden und es dadurch mehrere Durchgänge braucht bis die Nachricht eingelesen ist. Geschwindigkeitsmäßig dürfte das aber relativ egal sein...
cc1100_writeReg(CC1100_PKTLEN, len );
// 1 byte @ dataRate + 10% margin
uint16_t delay = (zwave_drate[CC_INSTANCE] == DRATE_100k ? 90 :
(zwave_drate[CC_INSTANCE] == DRATE_40k ? 220 : 920));
for(uint8_t mwait=MAX_ZWAVE_MSG-8; mwait > 0; mwait--) {
my_delay_us(delay);
uint8_t flen = cc1100_readReg( CC1100_RXBYTES );
if(flen == 0)
continue;
if(off+flen > len) {
//DC('L'); DNL();
rf_zwave_init();
return;
}
CC1100_ASSERT;
cc1100_sendbyte( CC1100_READ_BURST | CC1100_RXFIFO );
for(uint8_t i=0; i<flen; i++) {
uint8_t d = cc1100_sendbyte( 0 );
if(zwave_drate[CC_INSTANCE] != DRATE_9600)
d ^= 0xff;
msg[off++] = d;
}
CC1100_DEASSERT;
if(off >= len)
break;
}
In dem Teil gibt es dann wieder eine Prüfung auf die Länge indem der aktuelle Offset und die aktuelle Länge des Buffers mit der überträgenen Länge verglichen wird. Auch hier wird wieder rettet... Ich verstehe aber nicht so ganz was hier passiert. Bei meinen Debug-Versuchen habe ich gesehen das diese Prüfung relativ häufig für den Abbruch der Übertragung verantwortlich war. Ich verstehe nur nicht wie da mehr Zeichen im Buffer sein können wenn vorher die PKTLEN doch eingestellt wurde. Nach dem Erreichen der PKTLEN sollte der CC doch aufhören zu empfangen??
Kannst Du DIch noch daran erinnern wie diese kaputten Nachrichten dann aussehen? Ich habe mir das noch nicht genauer angesehen, würde aber dann doch erwarten das da dann Müll hinten dran hängt den man ignorieren kann, oder?
Sagt Dir eigentlich FOC (Frequency Offset Compensation) und FSC (Frequency Synthesizer Calibration) etwas? Ich suche ja immer noch nach einer Möglichkeit die Frequenzen (und die Modulationen) schneller schalten zu können um mit einem Transceiver mehrere Datenraten abdecken zu können. Ich habe zu Testzwecken mal den GDO0 Pin so programmiert das er entweder auf CCA (Clear Channel Assessment), das SyncWort oder CarrierSense reagiert. Diese Signale toggeln ohne Übertragung alle ein wenig, kommen aber teilweise 4ms früher als das FIFO_RX Signal (für 8 Bytes) und sind bei einer Übertragung anscheinend stabil. Ich muss mir die Timings da auch mal für die anderen Geschwindigkeiten anschauen und noch mal rechnen wie schnell man sein müsste. An meine letzten Rechnungen kann ich mich schon nicht mehr erinnern...
Mit der (a-)synchronen Ausgabe über die GDO-Pins hast Du wahrscheinlich auch noch nicht gearbeitet, oder?
Gruß,
Andreas.
ZitatIst der Reset hier wirklich nötig?
Noetig ist zu viel gesagt: ist einfach, und im Zweifel initialisert alles neu. Ich war unsicher am Anfang, und habe ein bisschen "defensiv" Programmiert. Wie lange dauert ein reset? Du kannst natuerlich mit SIDLE experimentieren, falls es zu besseren Ergebnissen fuehrt, dann uebernehme ich es.
ZitatWarum gibt es dieses Delay für nur ein Byte?
Was soll ich sonst in der Zeit tun? Delay ist eine Endlosschleife, ob die innere Schleife kuerzer ist oder nicht, ist doch egal.
ZitatIch verstehe nur nicht wie da mehr Zeichen im Buffer sein können wenn vorher die PKTLEN doch eingestellt wurde.
Ich bin jetzt zu faul zum Nachschauen :), aber ich meine diese Laenge gehoert zum ZWave Protokoll, und wird nicht vom CC1101 ueberprueft. Und irgendwer muss es ja tun.
ZitatSagt Dir eigentlich FOC (Frequency Offset Compensation) und FSC (Frequency Synthesizer Calibration) etwas?
Ja, aber vermutlich weniger als Dir :) Ich meine das CC1101 besteht auf relativ haeufige Kalibrierung (ein Nebeneffekt vom Reset). Einer meiner Theorien, warum der ZWDongle im Nachbar-Thema nach eine Weile nix mehr empfaengt: es hat sich nicht kalibriert. Senden kann (je nach Einstellung) dagegen helfen. Oder (wieder mit passenden Parameter) nach SIDLE wechseln.
ZitatMit der (a-)synchronen Ausgabe über die GDO-Pins hast Du wahrscheinlich auch noch nicht gearbeitet, oder?
Weiss nicht genau, was du meinst, wenn das die Flanken sind: SlowRF arbeitet damit, und das geht wg. Interrupt-Ungenauigkeit geschaetzt bis 2-4kBaud Datenrate gut. Hatten schon mehrere die Idee, die Interrupt-Zeiten bis FHEM zu schicken, und die Daten da zu dekodieren, mW ohne Erfolg.
Hi Rudi,
Zitat von: rudolfkoenig am 17 April 2017, 19:53:01
Du musst nicht uebertreiben, es sind nur 1.83% :) => Ich wuerde es nicht.
Was mich interessieren wuerde: wieviel erkennt ein ZWDongle im Vergleich?
puh, das ist schwierger zu filtern, und die Testnachrichten habe ich vom ZWDongle aus losgeschickt, da muss ich dann ein wenig zählen...
So, 793 Nachrichten (inklusive der ACK) sind beim ZWDongle angekommen, 4 davon fehlen beim CUL (3 Nachrichten, 1 ACK), beim MapleCUL sind es 17 (8 Nachrichten, 9 ACKs).
Ich habe keine Nachricht gefunden die beim CUL oder MapleCUL angekommen ist und nicht beim ZWDongle. Es gibt auch keine Nachrichte die keiner der beiden CUL nicht bekommen hat.
Das war jetzt nur die Richtung DanaLock -> ZWDongle, die Verlustrate ist in der gleichen Größenordung wie in beide Richtungen, d.h. es gibt da keinen signifikanten Unterschied ob das Device oder beide gesendet haben.
Gruß,
Andreas.
Hi Rudi,
Zitat von: rudolfkoenig am 17 April 2017, 21:44:48
Noetig ist zu viel gesagt: ist einfach, und im Zweifel initialisert alles neu. Ich war unsicher am Anfang, und habe ein bisschen "defensiv" Programmiert. Wie lange dauert ein reset? Du kannst natuerlich mit SIDLE experimentieren, falls es zu besseren Ergebnissen fuehrt, dann uebernehme ich es.
wenn Du da keinen triftigen Grund mehr weißt dann werde ich mal damit experimentieren.
Vom Resetbefehl bis zum Beginn des Registerschreibens dauert es ca. 100 µs, das Schreiben der Register dauert dann ca. 370 µs, danach kommt dann eine Pause von 4 ms (hast Du hierfür auch noch eine Idee warum Du die eingefügt hast?), dann kommt das Umschalten in RX, das dauert auch noch mal 80 µs.
Alles in allem dauert das ganze ca. 5,3 ms, was natürlch hauptsächlich durch das Delay von 4ms kommt bevor zxxRX() aufgerufen wird.
Wenn man nur nach Idle wechselt, den Buffer löscht, alle Register neu schreibt und wieder RX enabled müsste man mit ~ 1,2 ms auskommen. Wenn man sich auf die PKTLEN beschränkt dürfte auch 1ms machbar sein.
Zitat von: rudolfkoenig am 17 April 2017, 21:44:48
Was soll ich sonst in der Zeit tun? Delay ist eine Endlosschleife, ob die innere Schleife kuerzer ist oder nicht, ist doch egal.
Zeitlich wird das kaum Unterschied machen. Mein Ansatz wäre so lange zu warten bis der Buffer (fast) voll ist oder die erwartete Anzahl Zeichen angekommen sein müsste und würde dann auslesen. Auslesen über SPI ist ja noch fast 40x schneller als der Empfang der Daten. Ist aber wie gesagt nicht relevant, mich hatte nur interessiert ob es einen besonderen Grund gibt nur auf ein Zeichen zu warten.
Zitat von: rudolfkoenig am 17 April 2017, 21:44:48
Ich bin jetzt zu faul zum Nachschauen :), aber ich meine diese Laenge gehoert zum ZWave Protokoll, und wird nicht vom CC1101 ueberprueft. Und irgendwer muss es ja tun.
Yep, "len" ist aus dem ZWave-Protokoll, len-8 wird dann aber in PKTLEN geschrieben. Meiner Meinung nach müsste der CC dann bei erreichen der Grenze auch aufhören zu emfangen und erst wieder auf das SyncWort warten. Das scheint er aber ganz offensichtlich nicht zu tun.
Zitat von: rudolfkoenig am 17 April 2017, 21:44:48
Ja, aber vermutlich weniger als Dir :) Ich meine das CC1101 besteht auf relativ haeufige Kalibrierung (ein Nebeneffekt vom Reset). Einer meiner Theorien, warum der ZWDongle im Nachbar-Thema nach eine Weile nix mehr empfaengt: es hat sich nicht kalibriert. Senden kann (je nach Einstellung) dagegen helfen. Oder (wieder mit passenden Parameter) nach SIDLE wechseln.
Habe das State Diagramm von CC noch nicht wirklich studiert, meiner Meinung wird durch zccRX() auch eine Kalibrierung angestossen, daher dauert es auch ~800µs bis das Ding wieder empfangsbereit ist. Ohne Kalibrierung müsste der in 75µs wieder bereit sein. Ob diese Kalibrierung wirklich nötig ist kann ich momentan mangels Messung/Erfahrung nicht sagen, kann mir aber nicht vorstellen das es sooo viel ausmacht.
Ich muss mich da mal ein wenig mehr einlesen und danach versuchen Messungen zu machen um zu sehen ob der PLL dann wirklich schneller ist.
Zitat von: rudolfkoenig am 17 April 2017, 21:44:48
Weiss nicht genau, was du meinst, wenn das die Flanken sind: SlowRF arbeitet damit, und das geht wg. Interrupt-Ungenauigkeit geschaetzt bis 2-4kBaud Datenrate gut. Hatten schon mehrere die Idee, die Interrupt-Zeiten bis FHEM zu schicken, und die Daten da zu dekodieren, mW ohne Erfolg.
Laut Datenblatt kann der cc auf den GDO Pins eine asynchrone serielle Ausgabe oder auch eine synchrone serielle Ausgabe machen. Ich will das auch nicht a la "Slow RF" auswerten, sondern mit dem LogicAnalyzer in HW ansehen wollen. Bisher kann ich da allerdings nur Datenmüll entziffern, in sehr seltenen Fällen sehe ich einen Burst von 0x55 Werten was unserem invertierten SyncByte entspricht. Das nachfolgende 0x0F bzw. 0xF0 kann ich aber schon nicht mehr entziffern. Die Invertierung im Protokoll bei 40k und 100k ist zum Debuggen auch unschön, dazu muss ich nämlich immer alle Werte aus dem Logikanalyzer nachträglich invertieren um das mit den dekodierten Werten zu vergleichen... Leider bietet mein Programm diese Option nicht schon in der Auswertung ,-)
Ich schau mal bei "Slow RF" was die da machen und wie die den cc programmiert haben.
Jetzt muss ich nur mal beobachten ob der MapleCUL (oder auch der CUL) sich mal wieder weghängen und mal schauen ob sich das auch noch herausbekommen lässt.
Gruß,
Andreas.
ZitatPause von 4 ms (hast Du hierfür auch noch eine Idee warum Du die eingefügt hast?)
Ich meine es von rf_moritz.c uebernommen zu haben. Da steht was von // 4ms: Found by trial and error
Hi Rudi,
Zitat von: rudolfkoenig am 18 April 2017, 07:29:31
Ich meine es von rf_moritz.c uebernommen zu haben. Da steht was von // 4ms: Found by trial and error
ok, danke für den Hinweis.
Werde das erst mal so lassen und im ersten Schritt mal versuchen im Betrieb ohne den Reset auszukommen. Wenn das Ding beim ersten Initialisieren 4ms braucht ist das ja nicht weiter schlimm...
Gruß,
Andreas.
Hallo Rudi,
hier mal wieder was Neues zur Info:
Als ich eben nach Hause kam hat einer der MapleCUL (40k) nicht mehr reported... Der normale CUL war zufällig auf 40k, daher konnte ich sehen das dort "Traffic" war aber eben keine Werte von dem z40k Maple kamen.
Der Maple an sich reagierte normal, der 100k MapleCUL hat auch noch Werte ausgespukt, ich habe dann mal die register ausgelesen, die waren soweit ok, das einzig merkwürdige war das Register 0x2B AGCTEST, das stand auf 0x7F, normal steht das auf 0x3F und soll laut Doku nicht beschrieben werden. Ob das Register während des Betriebs auch andere Werte anzeigen kann konnte ich bisher nicht herausbekommen. Die Beschreibung des Registers lautet "For test only. Do not write to this register"...
Dummerweise habe ich keine Messung mit dem LogicAnalyzer gemacht ob der GDO2 Pin noch irgendwie reagiert sondern habe mal ein dummy-wert gesendet. Danach wurden sofort wieder Werte übertragen.
Ich hatte schon ein paar Mal das keine Werte mehr kamen, meist habe ich dann ein reopen gemacht oder den Maple resettet... Das gleiche hatte ich aber auch schon bei dem CUL, ich gehe daher davon aus das es sich hier nicht um ein Problem mit der a-culfw oder dem Maple handelt, sondern um ein generelles Problem wie wir mit dem CC1101 umgehen.
Ich bastel mir noch ein paar weitere Funktionen in die a-culfw bzw. in den ZWCUL um auch die Statusregister >0x30 auszulesen und dann mal ein paar Funktionen um Abläufe mit SRES, SCAL, SRX, STX etc. antriggern zu können.
Ich muss mir auch noch mal ansehen wie wir zwischen RX und TX umschalten, ob wir da direkt hin-und-her schalten oder ob wir über IDLE gehen und dann eine neue SCAL auslösen oder nicht. Irgendwie hat das Senden ja das Empfangsproblem gelöst...
Gibt es ähnliche Rückmeldungen beim CUL auch mit anderen Protokollen? Wenn das wirklich daran liegt das man lange auf RX bleibt und keine neue Kalibrierung macht und das Ding dann irgendwie wegläuft müsste man ja nur über einen Timer ab und zu mal IDLE-SCAL-RX aufrufen. Das dürfte aber recht schwer nachzustellen sein. Ich werde mir auch mal Logmeldungen in rf_zwave_init einbauen um zu sehen ob/wann der CC1101 initialisiert wird.
Gruß,
Andreas.
Hallo Telekatz,
ich hoffe Du bekommst das hier mit...
Welche Time und Interrupts sind den beim Maple-Mini bereits bereits, bzw. welche sind "frei"? Ich muss zugeben das ich mir das noch nicht so richtig angesehen haben, aber ich denke das Du für SlowRF da an CC0/CC1/CC2 was "vorgesehen" hast, oder?
Wenn ich das richtig verstehe kann der Maple bis zu 16 Interrupts, das dürfte dann wohl mehr oder weniger kein Problem darstellen, oder? Timer habe ich mir noch nicht angesehen, hier ist aber auch noch nicht klar ob ich wirklich einen Timer brauche.
Danke schon mal,
Andreas.
Der Maple nutzt aktuell die Timer TIM1-TIM3. TIM4 brauche ich dann noch für SlowRF an CC2. Übrig ist dann nur noch der System Tick Timer.
Zusätzlich werden noch die Interrupts für USB, UART1-3, EXTI0 und EXTI4 verwendet.
Hi,
ok, Interrupts scheinen ja wirklich nicht das Problem zu sein, muss mir die Belegung der EXT lines aber mal im Detail anschauen, nicht das dann genau doch
Ist denn TIM1-TIM3 auch für die SlowRF Varianten "vorgesehen"? Falls ich Timer benötige, könnte ich doch die nutzen die Du auch für die jeweiligen CC "vorgesehen" hattest. Es liest sich ja so das TIM4 für CC2 ist, welche sind dann für CC0 und CC1? Solange ich mich an das Schema halte wäre ja alles iO.
Kannst Du mir mal eine Stelle irgendwo im Code nennen wo ein Interrupt mit dem ganzen HAL-Gedöns configuriert wird?
Danke,
Andreas.
TIM1 bedient den periodischen Interrupt in clock.c. Falls du einen Timer benötigst, denke ich, dass man für clock.c auch den System Tick Timer verwenden kann und TIM1 dadurch frei wird.
TIM2, TIM3 und TIM4 ist dann für CC0, CC1 und CC2 vorgesehen.
Konfiguriert werden die Interrupts in den entsprechenden HAL Dateien im STM32 Ordner (hal_timer.c, hal_gpio.c, hal_usart.c). die Interrupt Handler sind in stm32f1xx_it.c im MapleCUN Verzeichniss.
Hi,
Zitat von: Telekatz am 08 Mai 2017, 09:43:39
TIM1 bedient den periodischen Interrupt in clock.c. Falls du einen Timer benötigst, denke ich, dass man für clock.c auch den System Tick Timer verwenden kann und TIM1 dadurch frei wird.
TIM2, TIM3 und TIM4 ist dann für CC0, CC1 und CC2 vorgesehen.
Ich würde dann schon auch TIM2/3/4 nutzen, da läuft dann ja kein SlowRF gleichzeitig auf dem "Slot"
Zitat von: Telekatz am 08 Mai 2017, 09:43:39
Konfiguriert werden die Interrupts in den entsprechenden HAL Dateien im STM32 Ordner (hal_timer.c, hal_gpio.c, hal_usart.c). die Interrupt Handler sind in stm32f1xx_it.c im MapleCUN Verzeichniss.
Ah, ok, schaue ich mir dann heute Abend mal an. Ist schon 'ne Weile her das ich mal "ernsthaft" Microcontroller programmiert habe, mal sehen ob ich daraus schlau werde. Muss aber auch erst mal den code schreiben und den mal gepollt auf Funktion testen, bevor ich den dann in den Interrupt hänge.
Ich habe bei meinen Tests übrigens mal das LAN-Modul abgesteckt (da ich mit dem lose rumliegenden Modul einen Kurzschluss auf meinem überfüllten Schreibtisch ausgelöst hatte...) und habe dabei festgestellt das jetzt die CC-Module (bzw. die rf_zwave_func) nahezu doppelt so schnell/häufig aufgerufen werden. Der LAN-/Netzwerkcode scheint also eine ganz schöne Latenz zu verursachen, und das obwohl ja nicht mal ein Kabel drin steckt. Muss ich mir bei Gelegenheit auch mal ansehen was da so passiert und ob ich evtl. darauf achten/reagieren muss was so passiert.
Danke,
Andreas.