ZWave @ culfw

[krikan]

Hi Rudi,wie immer bist Du zu schnell für uns... ,-)

Da stimme ich zu!  Jetzt habe ich mühevoll die morgendlichen Debug-Änderungen nachvollzogen, da sehe ich, dass gerade schon wieder neue Erkenntnisse im svn sind..  Seufz
ITU bringt mir zumindest ein paar neue Erkenntnisse, obwohl vieles zu sehr in die Tiefe geht.

[krikan]

Die Code-Zeile ist im letzten Check-In r10141 doppelt drin:

Code Auswählen Erweitern

+        (($hF & 0x10)==0x10 ? " lowSpeed" : "").

[rudolfkoenig]

Danke, habs entfernt. Habe evtl. das explorer-Flag gefunden, damit kommen noch zusaetzlich 8 Bytes in payload, die ich nicht interpretieren kann. Beispiel:

Code Auswählen Erweitern

2015.12.09 16:59:57.786 5: xxxxxxxx S:35 F:45 f:08 L:24 T:01  E:2000fa4000000000 P:320221740000000000000000000000000000 C:97
2015.12.09 16:59:57.786 5:    F:01000101 singleCast explorer ackReq
2015.12.09 16:59:57.786 5:    f:00001000 seqNum:8


Weiterhin kann man in ZWDongle fuer set/get die FHEM-Namen angeben (wo sinnvoll), also sowas wie "get zwd neighborList Lamp". Das manuelle lookup hat mich genervt.

[krikan]

Das manuelle lookup hat mich genervt.

Danke, mich auch schon länger. Wollte nicht fragen, damit ich nicht als Feature-Request-Hero geführt werde...

Ich haette jetzt gerne mehr Details zu rf.

Hast Du rf bewußt als Bezeichnung gewählt? Bestimmt, aber wie kommst Du darauf (Quellen)?
Im ITU-Dok gibt es auch RF, das dürfte aber wohl nur zufällig gleich sein!?

[rudolfkoenig]

Hast Du rf bewußt als Bezeichnung gewählt?

rf steht fuer Routing-Flag, Eigenkreation. Habe bisher keine Doku gelesen, wird wohl langsam Zeit. Achtung bei Routing: Hinter hopsCount ist ein nibble, was noch nicht separat ausgegeben wird, steht nur im R: an 4. Stelle.

[krikan]

Habe evtl. das explorer-Flag gefunden, damit kommen noch zusaetzlich 8 Bytes in payload, die ich nicht interpretieren kann.

Das unterstütze ich nach mehreren Tests. Zusätzliche Bytes sind mir auch unklar.
Im ITU-T G.9959 steht etwas von verschiedenen Layern und channel configurations, was ich bei kurzem Überfliegen noch nicht verstanden habe. Evtl. kann man daraus noch etwas schließen. EF sind mMn aber nicht explizit erwähnt.

Ich habe aber das Problem, dass ich nur die vom Controller verschickten Telegramme sehe; die Telegramme von den Geräten tauchen im log nicht auf (auch bei 40k Geräten). Mir ist nicht klar, wie ich das ändern kann. Hast Du eine Ahnung, was ich falsch mache?
list von ZWCUL:

Code Auswählen Erweitern

Internals:
   CFGFN
   Clients    :ZWave:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00 00000000 01
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00
   FD         4
   NAME       zw
   NR         319
   PARTIAL
   RAWMSG     zE345C45201450414042000FA4000000000250222
   STATE      Initialized
   TYPE       ZWCUL
   VERSION    V 1.66 CUL868
   homeId     00000000
   homeIdSet  00000000
   nodeIdHex  01
   zw_MSGCNT  87
   zw_TIME    2015-12-09 21:22:45
   Matchlist:
     1:ZWave    .*
     2:STACKABLE_CC ^\*
   Readings:
     2015-12-09 21:22:45   state           Initialized
Attributes:
   noDispatch 1
   verbose    5

[krikan]

Ich habe aber das Problem, dass ich nur die vom Controller verschickten Telegramme sehe; die Telegramme von den Geräten tauchen im log nicht auf (auch bei 40k Geräten). Mir ist nicht klar, wie ich das ändern kann. Hast Du eine Ahnung, was ich falsch mache?

Es geht doch. Habe die ganze Nacht loggen lassen und jetzt sind auch Geraetetelegramme zu sehen. Verstehe aber immer noch nicht, warum vorher nichts zu sehen war. Kann es sein, das etwas verloren geht, wenn der Server-Computer unter Hoechstlast läuft?

[rudolfkoenig]

Kann es sein, das etwas verloren geht, wenn der Server-Computer unter Hoechstlast läuft?

Der Begriff Hoechstlast ist dehnbar, ich glaube aber nicht dran. culfw schreibt die Pakete in einem USB-Puffer von 64-Bytes. Wenn die nicht abgeholt werden, dann kommt nix mehr dazu. Sobald man sie abholt, geht es wieder weiter. Im Sinne der genauen Zeitstempel waere es wuenschenswert, das FHEM ab und zu drankommt. Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.

Wg. unsichtbare Telegramme: die zway.me Fernbedienung Telegramme an den Goodway USB-Stick (und die Antworten) sehe ich auch nicht. Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k? Ich muss vermutlich die Chips auf der Platine untersuchen. Goodway selbst scheint den Stick nicht mehr zu kennen.

[krikan]

Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k?

Nein, wenn man von SDK auf Chipsatz schließen kann, was sich aus der Doku von Sigma mMn ergibt, sollte es 3er Chipsatz sein und der kann kein 100k.
Beim Dongle kannst Du den Chipsatz aber direkt abfragen. Steht in "get <ZWdongle> nodelist" (0x02) im raw-Telegramm (ZW_VERSION liefert Übersetzungshilfe)

Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.

Da die Hauptlast von einem eigenen blocking Modul kommt (das ich immer noch durch EMCD ersetzen will), kann ich das nicht ausschließen, aber sehe es in den Logs nicht und habe es vorher nicht festgestellt. Aber das ist jetzt wohl der KO und werde Deinen Rat befolgen.

[krikan]

Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03)

Der dürfte mit SDK 5.x auch keine EF können. Wenn Deine Feststellungen zu EF auf dem Controller beruhen, würde mich das schon wundern. Hoffe, das ist nicht so.

[A.Harrenberg]

Hi Rudi,

Der Begriff Hoechstlast ist dehnbar, ich glaube aber nicht dran. culfw schreibt die Pakete in einem USB-Puffer von 64-Bytes. Wenn die nicht abgeholt werden, dann kommt nix mehr dazu. Sobald man sie abholt, geht es wieder weiter. Im Sinne der genauen Zeitstempel waere es wuenschenswert, das FHEM ab und zu drankommt. Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.

eines meiner Probleme mit dem RFID-Leser war (oder ist imemr noch) das blockierend IP_CAM Modul. Gibt es eigentlich eine Art "Watchdog" für FHEM der Warnungen auspuckt wenn z.B. länger als 0.x Sekunden nicht getriggert wird/wurde? Oder irgendeine andere Methode mit der man soetwas erkennen kann?

Wg. unsichtbare Telegramme: die zway.me Fernbedienung Telegramme an den Goodway USB-Stick (und die Antworten) sehe ich auch nicht. Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k? Ich muss vermutlich die Chips auf der Platine untersuchen. Goodway selbst scheint den Stick nicht mehr zu kennen.

Wegen der 100k bin ich kurz davor mir einen zweiten CUL zu kaufen... Für 9.6k bräuchte man theoretisch ja sogar noch einen dritten... Es gibt zwar wahrscheinlich kaum Geräte die nur 9.6k können, ich bin mir aber nicht sicher ob 100k/40k Geräte im Fehlerfall nicht sogar noch mal auf 9.6k runterschalten. Die 100k gehen ja auf jeden Fall auf 40k runter.

An sowas hier (Zwave_Radio_Chip) kommt man ja wahrscheinlich nicht ran... Zumindest finde ich den Chip nirgends.

@Krikan: Diese blöden SDK Nummern nerven... Gibt es eine gute Liste die Du mal nennen könntest? Ich finde meist nur listen in denen genau meine SDK / Lib-Version nicht drin ist. Ich hatte mal geschaut und ich meine beim Pätz gelesen zu haben das EF ab SDK 4.5x drin ist.

Gruß,
Andreas.

[rudolfkoenig]

Wenn Deine Feststellungen zu EF auf dem Controller beruhen, würde mich das schon wundern.

EF kam von dem Aeon Switch, der sein ZME Dongle vermisst hat. Hat zunaechst 3-mal eine "normale" Meldung abgesetzt, und zum Schluss eine mit EF.

Gibt es eigentlich eine Art "Watchdog" für FHEM der Warnungen auspuckt wenn z.B. länger als 0.x Sekunden nicht getriggert wird/wurde?

Sowas gibts im HM Umfeld, ich meine es heisst apptime. HM braucht es, weil HM@culfw die Acks in Perl generiert, und HMLAN alle 30s ein keepalive braucht. Deswegen generieren wir die Acks bei ZWave@culfw im Firmware 

[A.Harrenberg]

Hi,

Sowas gibts im HM Umfeld, ich meine es heisst apptime. HM braucht es, weil HM@culfw die Acks in Perl generiert, und HMLAN alle 30s ein keepalive braucht. Deswegen generieren wir die Acks bei ZWave@culfw im Firmware 

danke werde mal schauen ob ich das nutzen kann.

Noch was anderes, weiß einer von euch ob auf dem RaZberry wirklich nur der Transceiver drauf ist und man an die Pins drankommt?

Der müsste dann ja auch das Funkprotokoll ausgeben und die höheren Layer müssten in SW realisiert sein... Ich denke ich muss mir das mal etwas genauer ansehen. Wäre eine Alternative zu mehreren CUL wenn man da direkt an die HW kommt.

Gruß,
Andreas.

[krikan]

Wegen der 100k bin ich kurz davor mir einen zweiten CUL zu kaufen...

Genau darum hoffe ich auf Ankunft von Locuts miniCul. Locutus/Björn haben ZWave bereits in a-culfw aufgenommen.
Bei mir habe ich den Eindruck, dass die 100k-Geräte sehr häufig ins Routing eingebunden sind; selbst wenn ich es aus den Abständen nicht vermuten würde.

Gibt es eine gute Liste die Du mal nennen könntest?

Ja, die berühmte sdkids.xml.
Und Du solltest mal mit zway eine aktuelle Firmware auf Deinen UZB flashen; dann findest Du die neueste. 

[rudolfkoenig]

Habe das ITU Dokument grob durchgelesen, und ein paar Flags angepasst. Routing ist da nicht beschrieben, aber beams. Und alles andere, was wir auch schon wissen
Weiterhin kann man jetzt auf 100k schalten mit "attr ZWCUL dataRate 100k", leider funktioniert das bei mir immer noch nicht, keine Ahnung, wieso.