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

[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