[erledigt] nach 1 jahr betrieb neue, sinnlose readings?

[the ratman]

hiho

ich hab 2 "Fibaro FIBEFGMS-001-ZW5 5G 4-in-1 Multisensor".
seit heute gibts bei einem neue readings:

Code Auswählen Erweitern

particulateMatter 49 micro-g/m3
tankCapacity 0 cbmdas ganze rennt über nen usb-stick.
ich bin etwas verwirrt. kann mir da jemand auf die sprünge helfen?

[A.Harrenberg]

Hi,

das dürften Pakete sein die wegen Übertragungsfehler mehrfache bitfehler haben aber bei denen die Checksumme dann doch wieder gestimmt hat. Leider ist die Checksumme im ZWave Protokoll sehr einfach gehalten... Readings löschen und ignorieren.

Gruß,
Andreas.

[the ratman]

thx für die info - bin ich beruhigt.

zum glück hab ich ja nur mehr 2 stk. zwave. sobald ich die beim fenster raus gekübelt hab, ist bis aufs licht alles homematik. dann ist endlich ruhe mit den komischen dingern.

[DeeSPe]

Ich habe mittlerweile eine ganze Liste an lustigen Readings die sich so auf meinen Z-Wave Geräten ansammeln und die ich hin und wider lösche.
Es handelt sich immer um Readings die das Gerät auf keinen Fall besitzen kann.

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:
Fibaro Motion Sensoren:

Code Auswählen Erweitern

barometricPressure
direction
generalPurpose
particulateMatter
position
power
time
tankCapacity
dewpoint
volatileOrganicCompound
CO2-level
humidity

Und diese bei den Fibaro Wall Plugs:

Code Auswählen Erweitern

alarm_type_04
battery
humidity
direction
luminance
temperature
velocity
wakeup
rain
formaldehydeLevel
electricalResistivity
undef
water
distance

Gruß
Dan

[tomspatz]

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:

Das muss dann allerdings bei jedem device einzeln eingetragen werden.
"global" fällt ja in diesem Falle weg.
Schade

[DeeSPe]

Das muss dann allerdings bei jedem device einzeln eingetragen werden.
"global" fällt ja in diesem Falle weg.
Schade

Genau!

Gruß
Dan

[krikan]

Hier mal eine kleine Liste was ich so schon alles gelöscht und in supressReading eingefügt habe:

Die schönere Lösung wäre, wenn wir die Command Class CRC16 Encapsulation erforschen und für den Versand einbauen würden. Dann wäre das Problem afaik behoben, wenn ich die CC richtig verstehe. Mir ist noch nicht klar, wie man bei spontanen Nachrichten die CRC16 erzwingt; das habe ich bisher nicht sicher experimentell hinbekommen. Bei get-Abfragen funktioniert das automatisch: Wenn get-Abfrage CRC16 gekapselt ist, dann kommt auch CRC16 zurück. Weiteres Problem: Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead. Also müsste man das im Oprimalfall auch noch bei den Routen nach 100k und 40k im Versand unterscheiden!?

[A.Harrenberg]

Hi Christian,

Die schönere Lösung wäre, wenn wir die Command Class CRC16 Encapsulation erforschen und für den Versand einbauen würden. Dann wäre das Problem afaik behoben, wenn ich die CC richtig verstehe.

zumindest ist die Checksumme dann weniger tolerant gegenüber Fehlern, eine 100% Sicherheit ist es dann zwar immer noch nicht, aber um Größenordnungen besser als die einfache Standard-Checksumme.

Mir ist noch nicht klar, wie man bei spontanen Nachrichten die CRC16 erzwingt; das habe ich bisher nicht sicher experimentell hinbekommen. Bei get-Abfragen funktioniert das automatisch: Wenn get-Abfrage CRC16 gekapselt ist, dann kommt auch CRC16 zurück.

Das die Antwort so generiert wird wie die Anfrage ist ja im ZWave-Standard so vorgesehen. Ob sich das Device dann für die spontanen Nachrichten den Zustand merkt wäre geschickt, aber das müsste man wirklich mal probieren.

Weiteres Problem: Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead. Also müsste man das im Oprimalfall auch noch bei den Routen nach 100k und 40k im Versand unterscheiden!?

Problem dabei ist herauszubekommen ob eine Route nun wirklich 100K ist oder vielleicht ja über ein 40K geroutet wird. Ausserdem schalten die Dinger bei Übertragungsproblemen auf 40k runter wenn ich das richtig in Erinnerung habe. Und das wird vom Dongle nicht gemeldet, "wir" wissen letztendlich nicht ob ein 100k Gerät auch wirklich mit 100k sendet.

Das wird spannend!

Gruß,
Andreas.

[krikan]

Ob sich das Device dann für die spontanen Nachrichten den Zustand merkt wäre geschickt, aber das müsste man wirklich mal probieren.

Habe ich leider nicht definitiv feststellen können. Hatte vor laengerer Zeit mit einem Fibaro FGMS experimentiert und eigentlich den Eindruck, dass der sich das merkt, da eine Zeit lang nur noch CRC16-Nachrichten kamen. Aber dann kam die Ernüchterung nach einigen Stunden: Plötzlich waren die Nachrichten wieder ohne CRC16 und ich hatte die Lust am Thema verloren. Ob das an einem Fehler in meinem CRC16-Stackversandmanipulations-Spagetti-Code lag oder andere Ursachen hatte, habe ich nicht mehr analysiert.

Problem dabei ist herauszubekommen ob eine Route nun wirklich 100K ist oder vielleicht ja über ein 40K geroutet wird. Ausserdem schalten die Dinger bei Übertragungsproblemen auf 40k runter wenn ich das richtig in Erinnerung habe. Und das wird vom Dongle nicht gemeldet, "wir" wissen letztendlich nicht ob ein 100k Gerät auch wirklich mit 100k sendet.

Ist ja nur die Kür. Keine Ahnung, ob uns dabei evtl. routeFor von ZWDongle hilft.

Gruß, Christian

[A.Harrenberg]

Hi,

ich bin zeitgleich noch in einem Thread wo jemand einen CU(L|N) mit 4x Radio + 2 UART auf Basis von einem MAPLE-Mini baut. Ich habe mir mal ein paar Platinen reserviert. Wenn das so klappt wie ich mir das vorstelle könnte man da 3 CC1101 mit 868MHz drauf machen und die fest auf 9.6k, 40k und 100k stellen und dann (hoffentlich) als stacked_cc mit ZWCul einbinden.

Damit hätten wir dann das ultimative sniffing-device, damit könnte man dann auch unterscheiden mit welcher Geschwindigkeit gesendet wurde.

Allerdings habe ich momentan weder die Platine, noch die Bauteile noch eine Ahnung davon ob die der ZWave-Code auch per stacked_cc eingebunden werden ,-)

Allerdings fällt mir jetzt auf das ich bei dem Design des SendStacks sowas wie CRC16 oder TRANSPORT_SERVICE auch berücksichtigen müsste und das bisher nicht getan habe... 

Gruß,
Andreas.

[rudolfkoenig]

Bei 100k Routen ist CRC16 überflüssig und verursacht unnötigen Overhead.

Meiner Ansicht nach ist der Overhead zu vernachlaessigen, und wir sollten es implementieren.
Ich habe bloss den Eindruck, dass viele Geraete CRC16 nicht unterstuetzten, ist also kein Allheitmittel.

Kann mir bitte jemand nochmal die Reihenfolge der Pack-Klassen zeigen?

[A.Harrenberg]

Hi Rudi,

hier eine kleine Grafik mit der entsprechenden Textseite. Das ganze stammt aus "sds13783-1_z-wave_transport-encapsulation_command_class_specification.pdf". Es gab irgendwo auch noch eine andere Darstellung mit einer Tabelle, die finde ich aber gerade nicht mehr.

Security-Nachrichten dürfen aber anscheinend nicht CRC16 verpackt werden.

Ich schau mal ob ich die Logik auch in den SendStack integriert bekomme...

Gruß,
Andreas.

[A.Harrenberg]

Hi,

ok, angehängt jetzt die Tabelle die ich meinte, die ist aber "veraltet", da fehlt der Level mit der neuen Klasse "SUPERVISION".

Gruß,
Andreas.

[krikan]

Andere Übersicht in http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf unter "3.8
Encapsulation order overview" (PDF-Seite 39ff.) mit Erläuterung.

Security-Nachrichten dürfen aber anscheinend nicht CRC16 verpackt werden.

wird dort auch bestätigt.

[krikan]

da fehlt der Level mit der neuen Klasse "SUPERVISION".

Geräte scheint es dazu aber noch nicht zu geben; genau wie bei SECURITY V2.

[rudolfkoenig]

Dann haben wir jetzt schon ein Problem: Wir machen erst MULTI_CHANNEL, und dann MULTI_CMD.  Ist vmtl. keinem bisher aufgefallen, da man an WAKE_UP+MULTI_CHANNEL Kombinationen selten was sendet (es ist der typische Fernbedienungsknopf), und MULTI_CMD in FHEM per Attribut aktiviert werden muss. Leider ist die Umstellung der Reihenfolge nicht ganz trivial.

[krikan]

Ich habe bloss den Eindruck, dass viele Geraete CRC16 nicht unterstuetzten, ist also kein Allheitmittel.

Mein Eindruck dabei ist, dass CRC16 genau die gefühlten Problemkandidaten haben; unter anderem der FGMS. Interessanterweise kann ich diese kaputten Nachrichten auch nicht in der hier immer wieder berichteten Häufigkeit feststellen. Bekomme die eigentlich nur bei (wilden) Inklusionsexperimenten.

Dann haben wir jetzt schon ein Problem:

MULTI_CMD wird vermutlich kaum jemand nutzen; ist doch eigentlich bisher nur bei den dem Stella-Z als mögliche Lösung gehandelt worden. Darum mMn unwichtig und stört mich nicht; wissen wir ja jetzt. CRC16 halte ich dann für bedeutender.

[A.Harrenberg]

Hi,

Geräte scheint es dazu aber noch nicht zu geben; genau wie bei SECURITY V2.

ja, Supervision ist auch zum ersten Mal in SECURITY_S2 erwähnt.
Bis es da Geräte gibt wird es noch ein wenig dauern, aber SECURITY_S2 ist ja für neue Zertifiizierungen ab April Pflicht, und damit dann auch Supervision.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Dann haben wir jetzt schon ein Problem: Wir machen erst MULTI_CHANNEL, und dann MULTI_CMD.  Ist vmtl. keinem bisher aufgefallen, da man an WAKE_UP+MULTI_CHANNEL Kombinationen selten was sendet (es ist der typische Fernbedienungsknopf), und MULTI_CMD in FHEM per Attribut aktiviert werden muss. Leider ist die Umstellung der Reihenfolge nicht ganz trivial.

ich bin ja auch erst jetzt über die Encapsulation gestolpert, obwohl SECURITY ja eine davon ist...

Ich schau mir MULIT_CHANNEL noch mal an, das wird soweit ich mich erinnere ja noch vor dem Absenden an den SendStack erledigt. Ich würde versuchen ALLES in den SendStack zu verlagern, stehe da aber noch ziemlich am Anfang. Bisher läuft gerade mal ein unverschlüsseltes SET...

Gruß,
Andreas.

[A.Harrenberg]

Hi Christian,

MULTI_CMD wird vermutlich kaum jemand nutzen; ist doch eigentlich bisher nur bei den dem Stella-Z als mögliche Lösung gehandelt worden. Darum mMn unwichtig und stört mich nicht; wissen wir ja jetzt. CRC16 halte ich dann für bedeutender.

da ich ja gerade sowieso den Stack "umbaue" sollte das Design aber schon so sein da diese ganzen Encapsulation auch ohne großes Gemurkse implemntierbar sind. Ob dann in der ersten Ausbaustufe MULTI_CMD drin ist wird sich dann ja zeigen 

Gruß,
Andreas.

[krikan]

Hi Christian,da ich ja gerade sowieso den Stack "umbaue" sollte das Design aber schon so sein da diese ganzen Encapsulation auch ohne großes Gemurkse implemntierbar sind.

Perfektionist. 
Ich wollte doch nur den Aenderungswiderstand wegen "nicht ganz trivial" herabsetzen.   

[rudolfkoenig]

Ich habe jetzt ein Attribut "useCRC16" implementiert, leider kann ich es mangels passende Geraete nicht testen.

da ich ja gerade sowieso den Stack "umbaue"

Wenn du damit $hash->{SendStack} meinst: machs mir bitte nicht zu schwer, ein "leicht erweitere" waere mir deutlich lieber....

[A.Harrenberg]

Hi Rudi,

Ich habe jetzt ein Attribut "useCRC16" implementiert, leider kann ich es mangels passende Geraete nicht testen.
Wenn du damit $hash->{SendStack} meinst: machs mir bitte nicht zu schwer, ein "leicht erweitere" waere mir deutlich lieber....

noch schlimmer, ich habe angefangen addToSendStack und processSendStack neu zu schreiben... Der Aufbau von $hash->{SendStack} ist momentan prinzipiell noch gleich, ich bin mir aber nicht sicher ob ich nicht auch eine Kennzeichnung für Verschlüsselte Nachrichten benötige oder ob ich mir das in einem separaten Statusflag merken kann.

Mir geht es darum den Ablauf durch die "ack" und "msg" Nachrichten besser steuerbar zu machen um dann auch die Security, oder jetzt allgemein die "Encapsulation" darin unterzubringen. Hier überlege ich momentan sogar eigene Timer für das ack und msg laufen zu lassen, welche unabhängig von denen im ZWDongle_SendStack sind, damit auch "no_ack" oder "no_msg" einfacher im Ablauf zu erfassen sind. Das ist aber noch nicht ganz ausgegoren. Alternativ dazu, und wahrscheinlich sinnvoller, müsste die Kommunikation vom ZWDongel_Sendstack zurück an den Device_SendStack verbessert werden.

Ich habe mir mal einen Ablauf für eine "einfache verschlüsselte spontane" Nachricht genauer angeschaut und mal angefangen zu überlegen was dabei alles schief gehen kann und an welchen Stellen... Das ist schon recht komplex. Für eine verschlüsselte GET Abfrage die in zwei verschlüsselten Nachrichten ankommt wird das dann noch interessanter.

Aktuell sehe ich noch nicht wie ein re-transmit einer Nachricht aufgrund fehlendem ACK vom Device erkennen kann falls die CB-id "00" ist. Soweit ich das bisher beobachtet habe ist bei den verschlüsselten Nachrichten die CB-id aber immer "00". Da müsste ich schauen ob ich da alternativ eine Art Nonce-ID nutzen kann.

Gruß,
Andreas.

[rudolfkoenig]

noch schlimmer, ich habe angefangen addToSendStack und processSendStack neu zu schreiben...

Hmmm. Diese Funktionen sind zentral, und ich muss sie "richtig" verstehen, d.h. mit allen Nebenwirkungen, und das kriege ich bei einem groesseren Patch meist nicht mit. Ich dachte fuer security reicht ein  Hook, so wie bei CRC16.

Vorschlag: du schreibst alle Probleme die dir einfallen + deine Anforderungen fuer Security auf, und ich implementiere sie.

[A.Harrenberg]

Hallo Rudi,

ist mir schon klar das diese Funktion zentral ist...
Das mit dem beschreiben aller möglichen Probleme und der Formulierung der Anforderungen ist aber auch nicht trivial.

Ich schau mir heute mal an wie Du das mit dem CRC16 gemacht hast und versuche mal die Anforderungen sauber zu formulieren/dokumentieren.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Hmmm. Diese Funktionen sind zentral, und ich muss sie "richtig" verstehen, d.h. mit allen Nebenwirkungen, und das kriege ich bei einem groesseren Patch meist nicht mit. Ich dachte fuer security reicht ein  Hook, so wie bei CRC16.

Vorschlag: du schreibst alle Probleme die dir einfallen + deine Anforderungen fuer Security auf, und ich implementiere sie.

Also so ein einfacher Hook wie für CRC16 reicht mMn schon mal nicht aus, sowas in der Art ist ja bereits implementiert.

Aber wie erkläre ich das jetzt alles, das wird ein seitenlanger Roman werden, und ich weiß Du magst so was langes nicht... Ich versuch mich kurz zu halten:

Grob skiziert läuft das mit Security momentan so ab:

- Am Ende von ZWave_Cmd() wird per ZWave_secIsSecureClass geprüft ob eine Verschlüsselung notwendig ist
- Falls ja kommt $msg in den secStack und stattdessen wird ein "getNonce" auf den Stack gelegt und per secStart wird der SendStack blockiert
- Wenn die Nonce ankommt wird über ZWave_Parse ZWave_secNonceReceived() aufgerufen. Hier wird die Nachricht wieder vom Stack geholt, verschlüsselt und auf den Stack gelegt. Falls der Befehl ein "set" war wird mit secEnd() der Stack wieder freigeben
- Falls der Befehl ein "get" war, bleibt der Stack blockiert bis eine verschlüsselte (evtl. auch eine zweigeteilte) Nachricht eintrifft. Dort wird dann die Nachricht entschlüsselt, per dispatch geparst und secEnd() aufgerufen.

Momentan bekannte Probleme bei der dieser Implementierung:

1.) Wenn die verschlüsselte Nachricht ausbleibt gibt es momentan keine vernünftige Reaktion. Es gibt nur meinen sehr einfachen Timer der mit secStart losläuft und nach 6 Sekunden secEnd() aufruft. Hier müsste neben der Fehlermeldung noch der Befehl vom Stack entfernt werden damit das System wenigstens stabil weiterlaufen kann, auch wenn dann der aktuelle Befehl verlorengeht.

2.) secStart() und Timer starten sobald der "get NONCE" auf den Stack gelegt wird. Das funktioniert bei schlafenden WAKE_UP Geräten nicht. Hierfür hatte ich schon angefangen den Start des Timers in processSendStack zu verlagern und erst beim wirklichen Versenden zu tirggern.

3.) Falls bereits Befehle auf dem Stack liegen (WAKE_UP) und ein Gerät eine verschlüsselte Nachricht senden will kommt zuerst ein "NonceRequest". Die Nonce wird auch über ZWave_Parse() -> ZWave_secNonceRequestReceived() erzeugt, aber normal an den Stack ANGEHÄGT und dadurch nicht verschickt (Gerät schläft offiziell noch, Antriggern des Stacks funktioniert nicht da mehr als ein Befehl drin liegt)

4.) Probleme mit mehrfachen NonceRequest wegen Übertragungsfehler und fehlendem ACK dürften durch das zwischenspeichern von mehr als einer "aktiven" Nonce halbwegs abgefangen werden

5.) Falls während einer verschlüsselten Kommunikation bei aktiviertem secStart() eine weitere NonceRequest kommt, weil z.B. der Sensor noch mal ausgelöst hat ist derweitere Ablauf danach nicht mehr vorhersehbar.

6.) Keine Überprüfung ob die Antwort des Gerätes zum Request gehört. Theoretisch ist z.B. möglich das man die Batterie abfragen will, dazu eine Nonce anfordert, diese bekommt, damit die Anfrage verschlüsselt und verschickt. Dann kommt vom Gerät ein NonceRequest den man beantwortet und dann beantwortet. Aber in der Antwort könnte z.B. auch ein Sensoralarm stecken weil der gerade ausgelöst hat und der NonceRequest dazu gehörte. Die Anfrage nach dem Batteriestatus bleibt dann unbeantwortet obwohl kein TimeOut, CAN oder NO_ACK zugeschlagen hat.

7.) Doppelt gesendete Nonce (wg. fehlendem ACK am Gerät) könnten dazu führen das der nächste Befehl vom Stack genommen wird und mit einer dann ungültigen NONCE verschlüsselt wird. Hier müssen doppelte Nachrichten erkannt werden oder die letzten x empfangenen Nonce zwischengespeichert werden um doppelte zu Nonce zu erkennen.

8.) Bisher ist keine Prüfung drin ob die Nachricht in eine verschlüsselte Nachricht passt. Das versenden einer zweigeteilten Nachricht ist noch gar nicht implementiert...

Für eine "unsolicited" Nachricht hatte ich angefangen den Ablauf mal darzustellen, ist mal als yEd File bzw. als HTML/PNG angehängt. Da hatte ich mal Timer eingetragen (ob die nun in 00_ZWDongle oder 10_ZWave laufen wäre ja egal), allerdings habe ich da noch kein "LOCK" drin um weitere Kommunikation zu verhindern. (In dem Ding ist auch der Ablauf für eine einfache bzw. zweigeteilte Antwort parallel enthalten)

"Anforderung" wäre dann z.B. so einen Ablauf mit Absicherung über Timer und ggf. nötigen Retries darzustellen und das ganze mit einem "LOCK" ähnlich wie secStart() / secEnd() zu belegen, wobei dieser "LOCK" auch bei normalen "get" Befehlen nötig ist.

Je nachdem wie was für Änderungen Du planst müsste man evtl. ein paar "Wrapper"-Funktionen für die Security Sachen schreiben bzw. anpassen. Wenn Du mir dann sagst was Du an "Interface" bräuchst kann ich das natürlich anpassen.

So, doch wieder recht lange geworden...

Gruß,
Andreas.

[krikan]

zu useCRC16:

Habe ein wenig mit dem FGMS getestet. Bei assocationAll und configAll stoppt die Abarbeitung reproduzierbar. Hier für associationAll:

Log:

Code Auswählen Erweitern


2017.03.03 14:18:22.032 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.03 14:18:22.033 5: SW: 06
2017.03.03 14:18:22.034 5: ZWDongle_0: dispatch 0004000b028407
2017.03.03 14:18:22.034 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:028407 CB:00
2017.03.03 14:18:22.035 5: ZWDongle_Write 00130b0656018505DF4A2501 (e345c452)
2017.03.03 14:18:22.036 5: SW: 010d00130b0656018505DF4A25018a
2017.03.03 14:18:22.049 5: ACK received, WaitForAck=>2 for 010d00130b0656018505DF4A25018a
2017.03.03 14:18:22.050 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.03 14:18:22.050 5: SW: 06
2017.03.03 14:18:22.051 5: ZWDongle_0: dispatch 011301
2017.03.03 14:18:22.077 4: ZWDongle_Read ZWDongle_0: rcvd 001301000004 (request ZW_SEND_DATA), sending ACK
2017.03.03 14:18:22.077 5: SW: 06
2017.03.03 14:18:22.078 5: device ack reveived, removing 010d00130b0656018505DF4A25018a from dongle sendstack
2017.03.03 14:18:22.078 5: ZWDongle_0: dispatch 001301000004
2017.03.03 14:18:22.079 4: CMD:ZW_SEND_DATA ID:00 ARG:0004 CB:01
2017.03.03 14:18:22.079 4: ZWDongle_0 transmit OK for CB 01, target ZWave_SENSOR_BINARY_11
2017.03.03 14:18:22.087 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b07560185060315a2 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.03 14:18:22.087 5: SW: 06
2017.03.03 14:18:22.089 5: ZWDongle_0: dispatch 0004000b07560185060315a2
2017.03.03 14:18:22.089 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:07560185060315a2 CB:00
2017.03.03 14:18:22.091 3: ZWave get ZWave_SENSOR_BINARY_11 association 1
2017.03.03 14:18:59.797 4: ZWDongle_Read ZWDongle_0: rcvd 0004001e083202213200000000 (request APPLICATION_COMMAND_HANDLER), sending ACK


Sendstack sieht dann so aus:

Code Auswählen Erweitern

sentackget: 130b0656018505DF4A2501
get: 130b038502012503

[rudolfkoenig]

Sendstack sieht dann so aus:

Danke. Habe eine leicht geaenderte neue Version eingecheckt.

Kann jemand mir ein Testgeraet mit CRC16 empfehlen?
Muss nicht "sinnvoll" sein, nur moeglichst viele Klassen unterstuetzen.
Die ohne Batterie werden bevorzugt

[ToKa]

Die neuen Fibaro Zwischenstecker FGWPF-102 Gen5  unterstützen CRC16.

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        d14c12e6 14
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     11
   NAME       ZWave_SWITCH_BINARY_14
   NR         695
   STATE      neighborUpdate
   TYPE       ZWave
   ZWAVE1_MSGCNT 11
   ZWAVE1_RAWMSG 0048cc22
   ZWAVE1_TIME 2017-03-02 23:45:07
   ZWaveSubDevice no
   homeId     d14c12e6
   isWakeUp
   lastMsgSent 1488494702.16806
   nodeIdHex  0e
   Readings:
     2017-03-02 23:39:04   model           FIBARO System FGWP102-ZW5 Wall Plug
     2017-03-02 23:39:04   modelConfig     fibaro/fgwp102-zw5.xml
     2017-03-02 23:39:04   modelId         010f-0602-1001
     2017-03-02 23:46:50   neighborList    E2.fl.SD.LEDLampe E2.ku.SD.Tischleuchte
     2017-03-02 23:45:07   neighborUpdate  done
     2017-03-02 23:41:32   reportedState   on
     2017-03-02 23:45:02   state           neighborUpdate
     2017-03-02 23:41:32   timeToAck       0.086
     2017-03-02 23:41:32   transmit        OK
Attributes:
   IODev      ZWAVE1
   classes    ZWAVEPLUS_INFO APPLICATION_STATUS ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION CRC_16_ENCAP DEVICE_RESET_LOCALLY FIRMWARE_UPDATE_MD MANUFACTURER_SPECIFIC METER MULTI_CHANNEL_ASSOCIATION ALARM POWERLEVEL SECURITY SENSOR_MULTILEVEL SWITCH_BINARY VERSION
   room       ZWave
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:2 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:1 SENSOR_MULTILEVEL:5 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2

Gruß
Torsten

[throbin]

Hi,

der Dimmer 2 von FIBARO kann anscheinend auch CRC_16:

Code Auswählen Erweitern


Internals:
   DEF        dad62400 28
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     13
   NAME       DG_Zimmer_Dimmer_Z1
   NR         104
   STATE      off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 13
   ZWDongle_0_RAWMSG 0004001c06310504220000
   ZWDongle_0_TIME 2017-03-03 23:06:36
   ZWaveSubDevice no
   endpointChildren ZWave_ZWAVEPLUS_INFO_28.01,ZWave_ZWAVEPLUS_INFO_28.02
   homeId     dad62400
   isWakeUp
   nodeIdHex  1c
   Readings:
     2016-12-13 20:19:04   mcCapability_01 ZWAVEPLUS_INFO BASIC VERSION SWITCH_MULTILEVEL ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER SENSOR_MULTILEVEL ALARM
     2016-12-13 20:19:04   mcEndpoints     total 2, different
     2016-12-13 20:19:04   model           FIBARO System FGD212 Dimmer 2
     2016-12-13 20:19:04   modelConfig     fibaro/fgd212.xml
     2016-12-13 20:19:04   modelId         010f-0102-1000
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC SWITCH_MULTILEVEL DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL SECURITY FIRMWARE_UPDATE_MD CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL PROTECTION ALARM SWITCH_ALL APPLICATION_STATUS MARK SCENE_ACTIVATION
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SECURITY:1 SENSOR_MULTILEVEL:4 SWITCH_ALL:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2


[A.Harrenberg]

Hallo Rudi,

2017.03.04 08:40:58.240 1: PERL WARNING: Use of uninitialized value $iomsg in concatenation (.) or string at ./FHEM/10_ZWave.pm line 4269.

in der letzten Änderung ($msg -> $iomsg) hast Du einen Bug eingebaut...

Code Auswählen Erweitern

  my $iomsg = ZWave_addCRC16($msg) if($hash->{useCRC16});
  IOWrite($hash,
          $hash->{homeId}.($hash->{route}?",".$hash->{route}:""),
          "00$iomsg");
  $ss->[0] = "sent$type:$msg";

Im IOWrite wird auch $iomsg genutzt, das ist aber nicht definiert wenn man kein CRC16 nutzt...

Da mir nicht ganz klar ist warum Du das geändert hast kann ich das auch nicht korrigieren.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

anbei ein kleiner Patch  (nicht für das Problem einen Post früher) für die CRC16 Berechnung. Da wurden die führenden Nullen nicht zurückgegeben...
(Außerdem ist da schon mal der Name einer neuen Klasse drin....)

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

und weiter geht es...

Der Code in processSendStack erkennt durch CRC16 jetzt die Antwort nicht mehr.   

Code Auswählen Erweitern

  if($type eq "get" && $hash->{CL} && !ZWave_isWakeUp($hash)) {
    if(!$hash->{asyncGet}) {            # Wait for the result for frontend cmd
      my $tHash = { hash=>$hash, CL=>$hash->{CL}, re=>"^000400${id}..$cmdId"};
      $hash->{asyncGet} = $tHash;
      InternalTimer(gettimeofday()+4, sub {
        asyncOutput($tHash->{CL}, "Timeout reading answer for $cmd");
        delete($hash->{asyncGet});
      }, $tHash, 0);
    }
  }

Die Antwort auf ein get kommt an, im Frontend kommt dann aber der Timeoutfehler.

Gruß,
Andreas.

[rudolfkoenig]

Danke fuer den Patch, habs eingebaut.
Und auch das CRC16 Senden gefixt (merke an mich: auch dann testen, wenn man das eigentliche Problem nicht testen kann).
Habs eingecheckt und fuer update zur Verfuegung gestellt.

[A.Harrenberg]

Hi Rudi,

Kommunikation läuft jetzt wieder 
CRC16 läuft auch soweit. Frage mich allerdings wieso das mit den fehlenden Nullen bisher gar nicht aufgefallen ist...

Der Codeschnipsel den ich wegen des Timeout gepostet habe gehört natürlich zu ZWave_Cmd und nicht zu ZWave_processSendStack.

Von meinen Geräten hat jetzt nur die Greenwave-Steckdose CRC16, kann also auch nicht soo viel testen. Das Ding sendet manuelles Schalten nicht, hat dafür aber so ein komisches Farbrad. Die dazu gehörenden spontanten Nachrichten kommen jedenfalls weiterhin ohne CRC16 an. Habe auch mal den PowerReportThreshold runter gesetzt, gleicher Effekt, die sponatanen Nachrichten kommen ohne CRC16, manuelle Abfragen werden aber richtig mit CRC16 beantwortet.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,
wenn Du am Ablauf/Stack sowieso was änderst, könntest Du ein paar zusätzlich (interne) Informationen erzeugen?
Um ZWave auf einem CUL (besser) zu unterstützen wäre eine Information über die maximale Geschwindigkeit der Node, sowie einer bevorzugten oder zuletzt genutzen Geschwindigkeit hilfreich.

Soweit ich den Standard verstanden habe müsste man bei einem NO_ACK / RETRY auch die Geschwindigkeit runtersetzten, auch dafür wäre die Info hilfreich.

Die Info könnte man dann nutzen um verschiedene CULs anzusprechen. Alternativ könnte man das in ZWCul verlagern und dort eine Schicht einbauen die evtl. mehrere CULs ansteuern kann.

Gruß,
Andreas.

[krikan]

useCRC16:
Bisher wird die WakeupNoMoreInformation trotz gesetztem Attribut nicht mit CRC16 geschützt.

[krikan]

useCRC16
Meine (wilde) Vermutung zum Schutz von spontanen Nachrichten mit  CRC16:
Spontane Nachrichten vom Geraet an den Controller sind nur CRC16 geschützt, wenn dem Geraet bekannt ist, dass der Controller CRC16 unterstützt. Die Info bekommt das Geraet über die nodeInfo vom Controller mitgeteilt. setNIF bzw. sendNIF könnten dort -wie bei SECURITY vermutet- eine Rolle spielen. Mir ist aber auch nach laengerem experimentieren kein wirklicher Erfolg gelungen. Habe zum Beispiel nicht herausfinden können, wann das Geraet die nodeInfo vom Controller abfragt. Protokollebene oder normale ZWave-Nachricht? Vermutlich ersteres. Soweit mein erfolgloser Stand zum Thema zur Dokumentation und für Ideen bin ich natürlich auch offen...

[rudolfkoenig]

Mir ist aber auch nach laengerem experimentieren kein wirklicher Erfolg gelungen.

Heisst das, dass du dem Geraet ein NIF geschickt hast?

Protokollebene oder normale ZWave-Nachricht? Vermutlich ersteres.

Wenn Ersteres, dann muesste der Controller das automatisch schicken, oder man muesste das per ControllerBefehl freischalten. Funktioniert CRC16 bei der Konkurrenz? Wenn ja, muessten wir schauen, wie sie den Controller initialisieren.

Auch wenn man es nicht freischaltet, muesste der Controller ein NIF an das Geraet sendet (dann halt ohne CRC16). Ich habe Inklusion mit ZWCul beobachtet, und kann mich nicht daran erinnern. Auch bei einer Assotiation zweier Geraete muesste sowas mitgeteilt werden, wuesste aber nicht, wie das erfolgen soll. Gibt es ein "request APPLICATION_UPDATE" Befehl?

[ToKa]

Hallo zusammen,

müsste beim Controller unter Caps nicht auch CRC16 aufgeführt sein? Bei meinem razberry2 finde ich aber nur diese Caps:

Code Auswählen Erweitern

Vers:5 Rev:4 ManufID:0147 ProductType:0400 ProductID:0002 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5

Einige Einträge mit unknown sind allerdings vorhanden.

Ich habe ein paar Geräte, die CRC16 können. Ich unterstütze Euch gerne, wie kann ich das denn am einfachsten testen bzw. erkennen, ob nach Akvtivieren von useCRC16 auch CRC16 genutzt wird?

Beste Grüße
Torsten

[rudolfkoenig]

müsste beim Controller unter Caps nicht auch CRC16 aufgeführt sein?

Nicht, wenn es "logisch" spezifiziert ist, da CRC16 nicht vom Controller gemacht wird. Weiterhin ist uns kein CRC16 Controller-Flag bekannt. Command-Class != Controller-Flag.

wie kann ich das denn am einfachsten testen bzw. erkennen, ob nach Akvtivieren von useCRC16 auch CRC16 genutzt wird?

Durch Loggen der RAW-Meldungen, und da suchen nach 5601
Alternativ in 10_ZWave.pm die Log-Zeile mit "Forum #23494" aktivieren.

[A.Harrenberg]

Hi,

stimme da mit Rudi überein. CRC16 ist eine logische Befehlsklasse und keine Controllerfunktion.

Der NIF schien bei Security einen einfluss zu haben, ich vermute im Nachhinein das dort die Timer angaben wichtig waren, da Security lt. Spezifikation zwingend timeouts implementieren muss.

Gruß,
Andreas.

[ToKa]

Hallo zusammen,

habe mit einem Fibaro FGWP102-ZW5 Wall Plug getestet und konnte folgendes feststellen:
1. Einschalten am Stecker wird zwar an Controller / fhem gemeldet, aber ohne CRC16
2. Abfragen des Gerätes erfoglt mit CRC16, enden aber mit einem timeout. Ich nehme an, das liegt daran, dass es keine direkte Route zum Controller gibt und die Geräte dazwischen kein CRC16 unterstützen.

Code Auswählen Erweitern

2017.03.12 12:19:59.061 3: ZWave set E2.ku.SD.Tischleuchte on
2017.03.12 12:19:59.089 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:19:59.196 4: ZWDongle_Read ZWAVE1: rcvd 00130c00000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:19:59.198 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:0c
2017.03.12 12:19:59.198 4: ZWAVE1 transmit OK for CB 0c, target E2.ku.SD.Tischleuchte
2017.03.12 12:19:59.312 4: ZWDongle_Read ZWAVE1: rcvd 0004000e032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:19:59.314 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:032503ff CB:00
2017.03.12 12:20:00.436 4: ZWDongle_Read ZWAVE1: rcvd 0004000e06310504220009 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:20:00.437 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:06310504220009 CB:00
2017.03.12 12:20:24.715 3: ZWave get E2.ku.SD.Tischleuchte meter 1
2017.03.12 12:20:24.722 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:20:24.850 4: ZWDongle_Read ZWAVE1: rcvd 00130d00000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:20:24.851 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:0d
2017.03.12 12:20:24.851 4: ZWAVE1 transmit OK for CB 0d, target E2.ku.SD.Tischleuchte
2017.03.12 12:20:27.110 3: ZWave get E2.ku.SD.Tischleuchte meter 1
2017.03.12 12:20:29.717 2: ZWave: No ACK from E2.ku.SD.Tischleuchte after 5s for sentackget:130e03320108250d
2017.03.12 12:20:30.305 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:20:30.417 4: ZWDongle_Read ZWAVE1: rcvd 00130e00000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:20:30.419 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:0e
2017.03.12 12:20:30.419 4: ZWAVE1 transmit OK for CB 0e, target E2.ku.SD.Tischleuchte
2017.03.12 12:20:34.708 3: ZWave get E2.ku.SD.Tischleuchte meter 1
2017.03.12 12:20:35.284 2: ZWave: No ACK from E2.ku.SD.Tischleuchte after 5s for sentackget:130e03320108250e
2017.03.12 12:20:35.292 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:20:35.419 4: ZWDongle_Read ZWAVE1: rcvd 00130f00000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:20:35.421 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:0f
2017.03.12 12:20:35.421 4: ZWAVE1 transmit OK for CB 0f, target E2.ku.SD.Tischleuchte
2017.03.12 12:20:40.286 2: ZWave: No ACK from E2.ku.SD.Tischleuchte after 5s for sentackget:130e03320108250f
2017.03.12 12:20:43.882 3: ZWave get E2.ku.SD.Tischleuchte meter 0
2017.03.12 12:20:43.889 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:20:44.020 4: ZWDongle_Read ZWAVE1: rcvd 00131000000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:20:44.022 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:10
2017.03.12 12:20:44.022 4: ZWAVE1 transmit OK for CB 10, target E2.ku.SD.Tischleuchte
2017.03.12 12:20:44.152 4: ZWDongle_Read ZWAVE1: rcvd 0004000e0e56013202214400000000000005ea (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:20:44.154 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:0e56013202214400000000000005ea CB:00
2017.03.12 12:20:44.154 4: CRC FIX, MSG: (32022144000000000000)
2017.03.12 12:20:56.039 3: ZWave get E2.ku.SD.Tischleuchte powerlevel
2017.03.12 12:20:56.047 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:20:56.175 4: ZWDongle_Read ZWAVE1: rcvd 00131100000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:20:56.177 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:11
2017.03.12 12:20:56.177 4: ZWAVE1 transmit OK for CB 11, target E2.ku.SD.Tischleuchte
2017.03.12 12:20:56.301 4: ZWDongle_Read ZWAVE1: rcvd 0004000e08560173030000e6e3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:20:56.302 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:08560173030000e6e3 CB:00
2017.03.12 12:20:56.303 4: CRC FIX, MSG: (73030000)
2017.03.12 12:22:23.651 3: ZWave set E2.ku.SD.Tischleuchte off
2017.03.12 12:22:23.677 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.03.12 12:22:23.785 4: ZWDongle_Read ZWAVE1: rcvd 00131200000d (request ZW_SEND_DATA), sending ACK
2017.03.12 12:22:23.787 4: CMD:ZW_SEND_DATA ID:00 ARG:000d CB:12
2017.03.12 12:22:23.787 4: ZWAVE1 transmit OK for CB 12, target E2.ku.SD.Tischleuchte
2017.03.12 12:22:23.902 4: ZWDongle_Read ZWAVE1: rcvd 0004000e03250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:22:23.904 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:03250300 CB:00
2017.03.12 12:22:24.536 4: ZWDongle_Read ZWAVE1: rcvd 0004000e06310504220000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.03.12 12:22:24.537 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:06310504220000 CB:00

Gruß
Torsten

[A.Harrenberg]

Hi Torsten,

habe mit einem Fibaro FGWP102-ZW5 Wall Plug getestet und konnte folgendes feststellen:
1. Einschalten am Stecker wird zwar an Controller / fhem gemeldet, aber ohne CRC16

yupp, das "normale" Verhalten das wir bisher bei allen CRC16 Geräte festgestellt haben

2. Abfragen des Gerätes erfoglt mit CRC16, enden aber mit einem timeout. Ich nehme an, das liegt daran, dass es keine direkte Route zum Controller gibt und die Geräte dazwischen kein CRC16

Yupp und Nope...

Yupp, die Abfrage endet "vermeintlich" mit einem Timeout, da die Antwort jetzt in einem CRC16 Paket verpackt ist und mit der CRC16 Klasse gesendet wird. Die aktuelle Implementierung des Stacks wartet aber auf ein Paket mit der Klasse der Frage. Daher kommt es hier zu einem Timeout. Wenn Du Dir mal die Zeitstempel der entsprechenden Readings anschaust wirst Du feststellen das die Anfrage doch angekommen ist. Ich habe das bereits an Rudi gemeldet und er wird das im Rahmen des Umbaus sicherlich berücksichtigen. Da das aber nicht gerade trivial ist könnte es was dauern mit der Umsetzung.

Nope, das hat nichts mit der Route zu tun das die Geräte dazwischen kein CRC16 können. Das interessiert die gar nicht. Die nehmen die Nachricht so wie sie ist und schicken sie weiter. Selbst wenn man es schafft denen eine kaputtes Phantasienachricht zu schicken würde diese weitergeleitet. Dabei interessieren nur die Routinginformationen die im Kopf der Nachricht stecken. Die "Payload" ist dabei egal.

Selbst Geräte die z.B. keine Security können routen dennoch solche Pakete erfolgreich weiter.

Gruß,
Andreas.

[ToKa]

Hallo Andreas,

danke für die Erklärung, wieder etwas gelernt...

Gruß
Torsten

[A.Harrenberg]

Hi,

für die ganzen Befehlsklassen gibt es ja mittlerweile die offizielle Spezifikation frei verfügbar. Bei den ganzen Controllersachen aber nicht, daher sind da auch noch etliche Capabilities "unknown", wobei selbst bei denen wo wir den Namen kennen nicht wirklich viele Informationen verfügbar sind.

Gruß,
Andreas.

[krikan]

Heisst das, dass du dem Geraet ein NIF geschickt hast?

Ja, habe wilde Experimente mit setNIF und sendNIF gemacht. Von gefühlten 100 Versuchen, aber nur einmal nicht reproduzierbarer Erfolg. Denke mittlerweile fast an Zufall. 

Funktioniert CRC16 bei der Konkurrenz? Wenn ja, muessten wir schauen, wie sie den Controller initialisieren.

Aus der Erinnerung an mein ZWCUL Log des Firmwareupdates über Fibaro HCL bei einem Bekannten ging das dort. Wie:?
ozw werde ich mal probieren.

Gibt es ein "request APPLICATION_UPDATE" Befehl?

Mir nicht bekannt. Suche noch.

[A.Harrenberg]

Hi,

ich habe mal eine Frage in das Forum bei ZWave-Public gestellt, vielleicht gibt es ja von dort einen Hinweis. Sollte ich von dort eine Antwort erhalten werde ich das hier kundtun.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

eine (ernüchternde) Antwort gibt es schon:

A sending node should normally read the NIF of the receiver in order to ensure that it can handle the CRC-16 encapsulated commands. It can then subsequently decide to use CRC-16 for unsolicited traffic.

Slave nodes or nodes issuing commands via Association Groups do not read the NIFs of other nodes before transmitting and there is no other mechanism allowing a node to start issuing commands with the CRC-16 encapsulation, at the moment.

Da normale nodes hier wohl unter "slave nodes" fallen kann man die Geräte wohl nicht dazu bringen CRC16 auch bei spontanen Nachrichten oder über assoziationen zu nutzen.

Damit ist der Sinn der Klasse mal grob verfehlt implementiert ,-(

Dann bleibt nur darauf zu warten das die neuen Geräte jetzt alle SECURITY unterstützen und damit eine ziemlich gute Checksumme haben.

Gruß,
Andreas.

[krikan]

Würde bedeuten, dass ich bei meinen 2 vermuteten spontanen CRC16-geschützten Nachrichten, einem Irrtum aufgesessen bin.  Würde leider zu den vielen erfolglosen Tests passen, aber gefaellt mir nicht...

[A.Harrenberg]

Hi Christian,

Würde bedeuten, dass ich bei meinen 2 vermuteten spontanen CRC16-geschützten Nachrichten, einem Irrtum aufgesessen bin.  Würde leider zu den vielen erfolglosen Tests passen, aber gefaellt mir nicht...

hast Du denn ein Log? Kann man das doch noch irgendwie nachvollziehen?

Ich kann aber nachvollziehen das es bei Nachrichten an Mitglieder von Assoziationsgruppen nicht gehen kann. Dort trägt der Controller Werte ein, die Node selbst weiß rein gar nichts von der Zielnode.
Ich kann mich auch nicht erinnern das wie das bei der Inklusion aussieht ob das auf Protokoll (also Funkebene) der NIF vom Controller gesendet wird oder ob die Node das abfragen kann. Mit dem NIF stehe ich sowieso immer wieder ein klein wenig auf dem Kriegsfuß.

Gefallen tut mir das Verhalten auch nicht, wäre aber typisch für eine zu schlecht spezifizierte Anforderung...

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Grob skiziert läuft das mit Security momentan so ab:

Gibt es da aktuell Aktivitäten bzgl. SendStack?
Mit S2 Security habe ich jedenfalls noch nicht mal angefangen, momentan beschäftigte ich mich eher damit doch noch alle Datenraten mit dem CUL zu realisieren. Gibt zwar erste Erfolge aber auch ein paar Rückschläge...
Wenn es funktionieren sollte, dann muss Zwcul auch noch erweitert werden...
Gruß aus Moskau,
Andreas.

[rudolfkoenig]

Gibt es da aktuell Aktivitäten bzgl. SendStack?

Wenn man vom fortlaufenden schlechten Gewissen absieht, nicht wirklich
Ich hole aber das Thema mal wieder nach oben.

[A.Harrenberg]

Hallo Rudi,

Wenn man vom fortlaufenden schlechten Gewissen absieht, nicht wirklich
Ich hole aber das Thema mal wieder nach oben.

ein schlechtes Gewissen solltest Du nicht haben, war nur Neugierig ob ich mir vielleicht schon mal was ansehen könnte.

Habe ja selbst auch ein klein wenig ein schlechtes Gewissen weil ich noch nicht mit S2 angefangen habe, aber momentan ist das die Programmierung des CC1101 doch recht zeitintensiv und ohne ein entsprechendes Testgerät wird das mit S2 auch erst mal schwierig werden. Die S2-Implemetierung im Z-UNO ist zwar für eine der nächsten Versionen angekündigt, das kann aber auch noch ein paar Monate dauern. Bis dahin könnte es durchaus auch ein "normales" Geräte geben was schon mit S2 zertifiziert ist.

Der Umbau des Stack muss aber die ganzen "Transport encapsulation" mechanismen (CRC16, Multichannel, S1, S2, Supervision und Transport Service) unterstützen damit das alles zusammenarbeiten kann. Diese "Hierachie der encapsulation" muss dabei irgendwie abgebildet werden.

Gruß,
Andreas.