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

Begonnen von the ratman, 27 Februar 2017, 22:04:03

Vorheriges Thema - Nächstes Thema

A.Harrenberg

Hallo Rudi,
Zitat2017.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...

  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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi Rudi,

und weiter geht es... ;)

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

  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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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  ;D
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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

ZitatMir ist aber auch nach laengerem experimentieren kein wirklicher Erfolg gelungen.
Heisst das, dass du dem Geraet ein NIF geschickt hast?


ZitatProtokollebene 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:
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
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

rudolfkoenig

Zitatmü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.

Zitatwie 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.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.
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
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

A.Harrenberg

Hi Torsten,
Zitat von: ToKa am 12 März 2017, 12:34:06
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

Zitat von: ToKa am 12 März 2017, 12:34:06
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

ToKa

Hallo Andreas,

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

Gruß
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight