Z-Wave nach heutigem Update unbrauchbar

Begonnen von LarsL, 09 Februar 2016, 19:43:04

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 2 3 4 Alle
Benutzer-Aktionen

m8ichael

#15
11 Februar 2016, 10:41:01
Zitat von: rudolfkoenig am 11 Februar 2016, 07:11:44
Das Problem von LarsL scheint ein Hardware/ZWave-Dongle Problem zu sein, das von m8ichael ein Problem des letzten Updates, vmtl. wg. Windows, deswegen sind solche Betreff Zeilen irrefuehrend. Insb. da updates haeufig sind, will ich nicht alles unter einem Thema sammeln.

@m8ichael: Könnte ich bitte ein Log der Probleme mit "attr ZWDongle verbose 5" und "attr global mseclog 5" bekommen?

Jupp, schicke ich nachher mal...


m8ichael

#16
11 Februar 2016, 17:07:38 Letzte Bearbeitung: 11 Februar 2016, 17:16:37 von m8ichael
Hallo,

hier nun mal ein Log:

Code Auswählen

2016.02.11 17:01:58.770 2: ZWave get eg.wz.Sofabeleuchtung swbStatus
2016.02.11 17:01:58.770 5: ZWDongle_Write 0013190225022519 (c0bcc8ab)
2016.02.11 17:01:58.770 5: SW: 01090013190225022519e5
2016.02.11 17:01:58.775 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^00040019..25
2016.02.11 17:01:58.775 5: ACK received, WaitForAck=>2 for 01090013190225022519e5
2016.02.11 17:02:01.775 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:02:01.775 5: SW: 06
2016.02.11 17:02:01.778 5: ZWAVE1 dispatch 011301
2016.02.11 17:02:01.778 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:02:01.778 5: SW: 06
2016.02.11 17:02:01.781 5: ZWAVE1 dispatch 011301
2016.02.11 17:02:01.781 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:02:01.781 5: SW: 06
2016.02.11 17:02:01.785 5: ZWAVE1 dispatch 011301
2016.02.11 17:02:01.785 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:02:01.785 5: SW: 06
2016.02.11 17:02:01.789 5: ZWAVE1 dispatch 011301
2016.02.11 17:02:01.789 4: ZWDongle_Read ZWAVE1: sending ACK, processing 001319000003
2016.02.11 17:02:01.789 5: SW: 06
2016.02.11 17:02:01.793 5: device ack reveived, removing 01090013190225022519e5 from dongle sendstack
2016.02.11 17:02:01.793 5: ZWAVE1 dispatch 001319000003
2016.02.11 17:02:01.793 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.02.11 17:02:01.793 4: ZWAVE1 transmit OK for 19
2016.02.11 17:02:01.793 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001903250300
2016.02.11 17:02:01.793 5: SW: 06
2016.02.11 17:02:01.797 4: ZWDongle_ReadAnswer for swbStatus: 0004001903250300
2016.02.11 17:02:01.797 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:19 ARG:03250300
2016.02.11 17:02:07.179 2: ZWave get eg.wz.Sofabeleuchtung neighborList
2016.02.11 17:02:07.179 5: ZWDongle_Write 0080190100 (c0bcc8ab)
2016.02.11 17:02:07.180 5: SW: 0106008019010061
2016.02.11 17:02:07.184 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2016.02.11 17:02:07.184 5: ACK received, removing 0106008019010061 from dongle sendstack
2016.02.11 17:02:10.184 1: ZWAVE1: SOF missing (got 80 instead of 01)
2016.02.11 17:02:10.184 5: ZWDongle_Read SOF Error -> sending NACK
2016.02.11 17:02:10.184 5: SW: 15
2016.02.11 17:02:13.186 1: ZWAVE1: SOF missing (got 00 instead of 01)
2016.02.11 17:02:13.186 5: ZWDongle_Read SOF Error -> sending NACK
2016.02.11 17:02:13.186 5: SW: 15
2016.02.11 17:02:16.189 2: ZWave: No ACK from eg.wz.Sofabeleuchtung after 3s for sentget:80190100


Der Status kann (seit heute) wieder abgefragt werden, jedoch funktioniert das Abfragen der neighborList seit dem Update nicht mehr. Generell scheint es Probleme bei Abfragen zu geben, wenn diese etwas länger dauern. Allerdings irritiert mich auch der Hinweis in den Logs, dass bereits nach 3s ein Timeout gesetzt wird. War das nicht bisher bei 10s? Könnte hier das Problem bestehen?

Viele Grüße

Michael

det.

#17
11 Februar 2016, 18:25:02
Von mir auch Zustimmung zum Thema,
Von 4 Fibraro Rollos war heute früh nur 1 offen und gestern ging ein Licht nicht aus. Sorry, bei mir steht nicht viel im Log wegen verbose2
Code Auswählen
2016.02.11 06:15:03 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_3 after 3s for sentset:1303032501FF2503
2016.02.11 06:15:03 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_6 after 3s for sentset:1306032501FF2506
LG
det.

m8ichael

#18
11 Februar 2016, 18:41:18
So, großer Mist...  :( Gerade bemerkt, dass offenbar auch at's bei mir nicht mehr korrekt funktionieren:

Code Auswählen

2016.02.11 17:34:18.000 3: ATEingangsbeleuchtungEin: IO::Socket::INET: connect: timeout
IO::Socket::INET: connect: timeout
2016.02.11 17:35:14.470 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004001a028407
2016.02.11 17:35:14.470 5: SW: 06
2016.02.11 17:35:14.474 5: ZWAVE1 dispatch 0004001a028407
2016.02.11 17:35:14.474 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:028407
2016.02.11 17:35:16.490 5: ZWDongle_Write 00131a028408251a (c0bcc8ab)
2016.02.11 17:35:16.490 5: SW: 010900131a028408251a4e
2016.02.11 17:35:16.593 5: ACK received, WaitForAck=>2 for 010900131a028408251a4e
2016.02.11 17:35:16.593 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:35:16.593 5: SW: 06
2016.02.11 17:35:16.597 5: ZWAVE1 dispatch 011301
2016.02.11 17:35:16.697 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00131a000006
2016.02.11 17:35:16.697 5: SW: 06
2016.02.11 17:35:16.700 5: device ack reveived, removing 010900131a028408251a4e from dongle sendstack
2016.02.11 17:35:16.700 5: ZWAVE1 dispatch 00131a000006
2016.02.11 17:35:16.700 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2016.02.11 17:35:16.700 4: ZWAVE1 transmit OK for 1a
2016.02.11 17:36:14.003 3: ATEingangsbeleuchtungEin: IO::Socket::INET: connect: timeout
IO::Socket::INET: connect: timeout
2016.02.11 17:36:30.749 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000d03800344
2016.02.11 17:36:30.749 5: SW: 06
2016.02.11 17:36:30.753 5: ZWAVE1 dispatch 0004000d03800344
2016.02.11 17:36:30.753 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:03800344
2016.02.11 17:36:30.854 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000d06430301420898
2016.02.11 17:36:30.854 5: SW: 06
2016.02.11 17:36:30.857 5: ZWAVE1 dispatch 0004000d06430301420898
2016.02.11 17:36:30.857 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:06430301420898
2016.02.11 17:36:30.957 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000d044608007f
2016.02.11 17:36:30.957 5: SW: 06
2016.02.11 17:36:30.961 5: ZWAVE1 dispatch 0004000d044608007f
2016.02.11 17:36:30.961 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:044608007f
2016.02.11 17:36:31.061 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000d028407
2016.02.11 17:36:31.061 5: SW: 06
2016.02.11 17:36:31.064 5: ZWAVE1 dispatch 0004000d028407
2016.02.11 17:36:31.064 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:028407
2016.02.11 17:36:33.080 5: ZWDongle_Write 00130d028408250d (c0bcc8ab)
2016.02.11 17:36:33.080 5: SW: 010900130d028408250d4e
2016.02.11 17:36:33.184 5: ACK received, WaitForAck=>2 for 010900130d028408250d4e
2016.02.11 17:36:33.184 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:36:33.184 5: SW: 06
2016.02.11 17:36:33.188 5: ZWAVE1 dispatch 011301
2016.02.11 17:36:33.288 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130d000003
2016.02.11 17:36:33.288 5: SW: 06
2016.02.11 17:36:33.292 5: device ack reveived, removing 010900130d028408250d4e from dongle sendstack
2016.02.11 17:36:33.292 5: ZWAVE1 dispatch 00130d000003
2016.02.11 17:36:33.292 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.02.11 17:36:33.292 4: ZWAVE1 transmit OK for 0d
2016.02.11 17:38:37.788 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000c03800343
2016.02.11 17:38:37.788 5: SW: 06
2016.02.11 17:38:37.792 5: ZWAVE1 dispatch 0004000c03800343
2016.02.11 17:38:37.792 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:03800343
2016.02.11 17:38:37.893 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000c064303014207d0
2016.02.11 17:38:37.893 5: SW: 06
2016.02.11 17:38:37.897 5: ZWAVE1 dispatch 0004000c064303014207d0
2016.02.11 17:38:37.897 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:064303014207d0
2016.02.11 17:38:37.997 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000c044608007f
2016.02.11 17:38:37.997 5: SW: 06
2016.02.11 17:38:38.001 5: ZWAVE1 dispatch 0004000c044608007f
2016.02.11 17:38:38.001 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:044608007f
2016.02.11 17:38:38.102 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000c028407
2016.02.11 17:38:38.102 5: SW: 06
2016.02.11 17:38:38.106 5: ZWAVE1 dispatch 0004000c028407
2016.02.11 17:38:38.106 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:028407
2016.02.11 17:38:40.122 5: ZWDongle_Write 00130c028408250c (c0bcc8ab)
2016.02.11 17:38:40.122 5: SW: 010900130c028408250c4e
2016.02.11 17:38:40.227 5: ACK received, WaitForAck=>2 for 010900130c028408250c4e
2016.02.11 17:38:40.227 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.02.11 17:38:40.227 5: SW: 06
2016.02.11 17:38:40.231 5: ZWAVE1 dispatch 011301
2016.02.11 17:38:40.332 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130c000003
2016.02.11 17:38:40.332 5: SW: 06
2016.02.11 17:38:40.336 5: device ack reveived, removing 010900130c028408250c4e from dongle sendstack
2016.02.11 17:38:40.336 5: ZWAVE1 dispatch 00130c000003
2016.02.11 17:38:40.336 4: ZWAVE1 CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.02.11 17:38:40.336 4: ZWAVE1 transmit OK for 0c


Das würde dann auch erklären, warum heute morgen erneut das Aufwecklicht nicht (mehr) funktionierte.

Viele Grüße

Michael

A.Harrenberg

#19
11 Februar 2016, 19:15:41
Hi Michael,
Zitat von: m8ichael am 11 Februar 2016, 17:07:38
Code Auswählen

2016.02.11 17:02:07.179 2: ZWave get eg.wz.Sofabeleuchtung neighborList
2016.02.11 17:02:07.179 5: ZWDongle_Write 0080190100 (c0bcc8ab)
2016.02.11 17:02:07.180 5: SW: 0106008019010061
2016.02.11 17:02:07.184 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2016.02.11 17:02:07.184 5: ACK received, removing 0106008019010061 from dongle sendstack
2016.02.11 17:02:10.184 1: ZWAVE1: SOF missing (got 80 instead of 01)
2016.02.11 17:02:10.184 5: ZWDongle_Read SOF Error -> sending NACK
2016.02.11 17:02:10.184 5: SW: 15
2016.02.11 17:02:13.186 1: ZWAVE1: SOF missing (got 00 instead of 01)
2016.02.11 17:02:13.186 5: ZWDongle_Read SOF Error -> sending NACK
2016.02.11 17:02:13.186 5: SW: 15
2016.02.11 17:02:16.189 2: ZWave: No ACK from eg.wz.Sofabeleuchtung after 3s for sentget:80190100


Der Status kann (seit heute) wieder abgefragt werden, jedoch funktioniert das Abfragen der neighborList seit dem Update nicht mehr. Generell scheint es Probleme bei Abfragen zu geben, wenn diese etwas länger dauern. Allerdings irritiert mich auch der Hinweis in den Logs, dass bereits nach 3s ein Timeout gesetzt wird. War das nicht bisher bei 10s? Könnte hier das Problem bestehen?
ich denke nicht das dies irgendwas mit den Updates/Änderungen zu tun hat.
Im Log ist zu erkennen das der Befehl gesendet wird "ZWDongle_Write 0080190100 (c0bcc8ab)" und dann auf die Antwort gewartet wird. In der Antwort gibt es aber einen Fehler, der "Kenner" für SOF (Start of Frame) wurde als "80" empfangen und nicht als "01", daher wird dem Gerät ein NACK = NO_ACK geschickt. Normalerweise sollte das Geräte die Anwort daraufhin noch einmal senden. Das ist hier aber nicht passiert und deshalb gibt es den Timeout.
Kann es sein das Du aufgrund der vorherigen Probleme irgendwas an der Position von Geräten bzw. dem Dongle geändert hast? Hier machen ein paar Zentimeter oder eine etwas andere Richtung teilweise schon recht viel aus.

Die Tatsache das ein "kaputtes" Paket empfangen wurde deutet auf Empfangsprobleme hin. Das das Gerät nach dem NO_ACK nicht noch mal gesendet hat könnte ebenfalls bedeutet das auch in Senderichtung nicht alles funktioniert...

Ich denke das Rudi sich das aber auch noch mal anschaut.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

#20
11 Februar 2016, 19:19:27
Hi det,
Zitat von: det. am 11 Februar 2016, 18:25:02
Von mir auch Zustimmung zum Thema,
Von 4 Fibraro Rollos war heute früh nur 1 offen und gestern ging ein Licht nicht aus. Sorry, bei mir steht nicht viel im Log wegen verbose2
Code Auswählen
2016.02.11 06:15:03 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_3 after 3s for sentset:1303032501FF2503
2016.02.11 06:15:03 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_6 after 3s for sentset:1306032501FF2506
könntest Du bitte auch mal ein Logfile mit verbose = 5 für das ZWave-Device und einem gesetzten attribut mseclog = 1 in "global" (siehe fhemwiki.de Welche Infos sollten Anfragen im ZWave-Forum enthalten?) mit etwas mehr "Kontext" drum herum posten?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

#21
11 Februar 2016, 19:24:12
Hi Michael,
Zitat von: m8ichael am 11 Februar 2016, 18:41:18
So, großer Mist...  :( Gerade bemerkt, dass offenbar auch at's bei mir nicht mehr korrekt funktionieren:

Code Auswählen

2016.02.11 17:34:18.000 3: ATEingangsbeleuchtungEin: IO::Socket::INET: connect: timeout
IO::Socket::INET: connect: timeout

also an den reinen ZWave Sachen ist nichts zu erkennen, die Fehlermeldung für das at ist aber schon merkwürdig. Das scheint ein anderes Problem zu sein. Kannst Du mal die Definition von dem at posten?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

det.

#22
11 Februar 2016, 21:19:10
Zitat von: A.Harrenberg am 11 Februar 2016, 19:19:27
Hi det,könntest Du bitte auch mal ein Logfile mit verbose = 5 für das ZWave-Device und einem gesetzten attribut mseclog = 1 in "global" (siehe fhemwiki.de Welche Infos sollten Anfragen im ZWave-Forum enthalten?) mit etwas mehr "Kontext" drum herum posten?

Gruß,
Andreas.
Hallo Andreas,
Danke für Deine Hilfe. LOG Inhalt kommt morgen Abend!
LG
det.

m8ichael

#23
11 Februar 2016, 21:42:35
Hallo!

Zitat von: A.Harrenberg am 11 Februar 2016, 19:24:12
Hi Michael,also an den reinen ZWave Sachen ist nichts zu erkennen, die Fehlermeldung für das at ist aber schon merkwürdig. Das scheint ein anderes Problem zu sein. Kannst Du mal die Definition von dem at posten?

Na klar, ist allerdings nichts besonderes definiert:

Code Auswählen

Internals:
   COMMAND    set eg.fl.Eingang.Stimmungsbeleuchtung,div.Schalter2 on
   DEF        *{sunset_abs("HORIZON=-2.0");} set eg.fl.Eingang.Stimmungsbeleuchtung,div.Schalter2 on
   NAME       ATEingangsbeleuchtungEin
   NR         66
   NTM        17:36:09
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 17:36:09
   TIMESPEC   {sunset_abs("HORIZON=-2.0");}
   TRIGGERTIME 1455294969
   TRIGGERTIME_FMT 2016-02-12 17:36:09
   TYPE       at
   Readings:
     2016-02-11 17:36:14   state           Next: 17:36:09
Attributes:


Mag aber auch sein, dass hier zwei getrennte Probleme vorliegen. Zumindest funktioniert seit ein paar Tagen auch das Aufwecklicht nicht mehr zuverlässig - nachdem es über Wochen/Monate ohne Probleme lief. Hier mal die Definition:

Code Auswählen

Internals:
   COMMAND    {
if ( Value("dmArbeitstagWakeup") eq "1" ) {
  if (Value("dmWakeup") eq "Automatisch") {
    fhem("set og.sz.Hauptbeleuchtung dim 12");
    fhem('define tmpwakeup1 at 05:50 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 18") } }');
    fhem('define tmpwakeup2 at 05:55 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 23") } }');
    fhem('define tmpwakeup3 at 06:00 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 25") } }');
    fhem('define tmpwakeup4 at 06:15 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 30") } }');
    fhem('define tmpwakeup5 at 06:25 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 40") } }');
    fhem('define tmpwakeup6 at 06:30 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 50") } }');
    fhem('define tmpwakeup7 at 06:39:59 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 80") } }');
  }
  if (Value("dmWakeup") eq "Aussetzen") {
    fhem("set dmWakeup Automatisch");
  }
}
}
   DEF        *05:45 {
if ( Value("dmArbeitstagWakeup") eq "1" ) {
  if (Value("dmWakeup") eq "Automatisch") {
    fhem("set og.sz.Hauptbeleuchtung dim 12");
    fhem('define tmpwakeup1 at 05:50 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 18") } }');
    fhem('define tmpwakeup2 at 05:55 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 23") } }');
    fhem('define tmpwakeup3 at 06:00 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 25") } }');
    fhem('define tmpwakeup4 at 06:15 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 30") } }');
    fhem('define tmpwakeup5 at 06:25 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 40") } }');
    fhem('define tmpwakeup6 at 06:30 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 50") } }');
    fhem('define tmpwakeup7 at 06:39:59 { if ( Value("og.sz.Hauptbeleuchtung") =~ /on|dim/ ) { fhem("set og.sz.Hauptbeleuchtung dim 80") } }');
  }
  if (Value("dmWakeup") eq "Aussetzen") {
    fhem("set dmWakeup Automatisch");
  }
}
}
   NAME       ATWakeup
   NR         30
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 05:45:00
   TIMESPEC   05:45
   TRIGGERTIME 1455252300
   TRIGGERTIME_FMT 2016-02-12 05:45:00
   TYPE       at
   Readings:
     2016-02-11 13:41:49   state           Next: 05:45:00
Attributes:



Merkwürdig hierbei: Die ersten ein bis zwei Stufen funktionieren, danach passiert dann oftmals nichts mehr, oder eine der letzten Stufen greift erst wieder.

Viele Grüße

Michael

m8ichael

#24
11 Februar 2016, 21:54:55
Hi!

Zitat von: A.Harrenberg am 11 Februar 2016, 19:15:41
Hi Michael,ich denke nicht das dies irgendwas mit den Updates/Änderungen zu tun hat.
Im Log ist zu erkennen das der Befehl gesendet wird "ZWDongle_Write 0080190100 (c0bcc8ab)" und dann auf die Antwort gewartet wird. In der Antwort gibt es aber einen Fehler, der "Kenner" für SOF (Start of Frame) wurde als "80" empfangen und nicht als "01", daher wird dem Gerät ein NACK = NO_ACK geschickt. Normalerweise sollte das Geräte die Anwort daraufhin noch einmal senden. Das ist hier aber nicht passiert und deshalb gibt es den Timeout.
Kann es sein das Du aufgrund der vorherigen Probleme irgendwas an der Position von Geräten bzw. dem Dongle geändert hast? Hier machen ein paar Zentimeter oder eine etwas andere Richtung teilweise schon recht viel aus.

Die Tatsache das ein "kaputtes" Paket empfangen wurde deutet auf Empfangsprobleme hin. Das das Gerät nach dem NO_ACK nicht noch mal gesendet hat könnte ebenfalls bedeutet das auch in Senderichtung nicht alles funktioniert...

Ich denke das Rudi sich das aber auch noch mal anschaut.

Gruß,
Andreas.

Ich habe die letzten Tage tatsächlich nichts geändert, weder bei der Hardware noch bei den FHEM-Einstellungen. Hatte dann das besagte Update gemacht, und seitdem treten die Probleme auf - zuvor lief alles sehr stabil. Es gab zwar hin und wieder laut dem Log Empfangsprobleme - aber spätestens beim erneuten Senden war alles ok...

Viele Grüße

Michael

det.

#25
12 Februar 2016, 11:11:37
Hallo Andreas,
sorry, habe auch nichts geändert - aber die IT Selbstheilungskräfte haben mal wieder gewirkt. Gestern Abend und Heute früh alles wie gewünscht auf- und zugegangen, im LOG steht nichtss was Dir helfen könnte oder müsste.
War Fehlalarm - einmalige Dysfunktion.
LG
det.

rudolfkoenig

#26
12 Februar 2016, 19:12:19
Zitatfunktioniert das Abfragen der neighbourList seit dem Update nicht mehr.
Ich konnte das nicht feststellen, nur eine falsche Fehlermeldung taucht im Log auf: "ZWave: No ACK from <NAME> after 3s for sentset:48xx". Ich habe diese Meldung jetzt entfernt. Nach durchlesen aller Beitrege bin ich der Ansicht, dass es hier keine offenen Punkte mehr gibt. Wenn doch, dann bitte das Problem nochmal beschreiben.

m8ichael

#27
13 Februar 2016, 00:18:34
Hallo!

Zitat von: rudolfkoenig am 12 Februar 2016, 19:12:19
Ich konnte das nicht feststellen, nur eine falsche Fehlermeldung taucht im Log auf: "ZWave: No ACK from <NAME> after 3s for sentset:48xx". Ich habe diese Meldung jetzt entfernt. Nach durchlesen aller Beitrege bin ich der Ansicht, dass es hier keine offenen Punkte mehr gibt. Wenn doch, dann bitte das Problem nochmal beschreiben.

Leider bestehen bei mir nach wie vor massive Probleme. So wird bei at's zu 95% der Fehler "IO::Socket::INET: connect: timeout" herausgeworfen, und die geplante Aktion wird nicht ausgeführt - es scheint, als wäre irgendetwas z-wave-technisches ganz böse durcheinander gekommen. Wenn ich einen "get"-Befehl absetzen möchte, passiert im schlechtesten Fall gar nichts - bestenfalls bekomme ich einen "Timeout"-Fehler.

Hingegen kann ich die Aktoren manuell ohne Probleme und ohne Verzögerung ganz normal schalten. Empfangsprobleme schließe ich daher aus - zumal das System jetzt mittlerweile seit Wochen stabil lief.

Bin ein wenig mit meinem Latein am Ende...  :(

Michael

m8ichael

#28
13 Februar 2016, 00:23:36
Oh...gerade mal bei meinem Stick ein "get nodeList" abgesetzt:

Code Auswählen

ZWAVE1 nodeList => ZWAVE1 UNKNOWN_2 UNKNOWN_3 UNKNOWN_4 UNKNOWN_5 UNKNOWN_6 UNKNOWN_7 UNKNOWN_8 UNKNOWN_9 UNKNOWN_10 UNKNOWN_11 UNKNOWN_12 UNKNOWN_13 UNKNOWN_14 UNKNOWN_15 UNKNOWN_16 UNKNOWN_17 UNKNOWN_21 UNKNOWN_22 UNKNOWN_23 UNKNOWN_24 UNKNOWN_25 UNKNOWN_26 UNKNOWN_27 UNKNOWN_28 UNKNOWN_30 UNKNOWN_32 UNKNOWN_33 UNKNOWN_34 UNKNOWN_35 UNKNOWN_36


Das sieht ja nicht gut aus...  :-[

A.Harrenberg

#29
13 Februar 2016, 00:36:51
Hi,

sag mal, was hast Du sonst noch in FHEM "am Laufen"? Welche Module nutzt Du? Tipp mal "version" in das Befehlsfeld und poste mal die Liste.

Ich gehe weiterhin davon aus das da ein anderes Modul "querschiesst". Ich habe auch nicht die geringste Ahnung woher "IO::Socket::INET: connect: timeout" kommt, aber ich bezweifle das dies von ZWave kommt.

Woher kommt "sunset" bei den at Befehlen, kann das entsprechende Modul vielleicht der Auslöser sein?
Könntest Du vielleicht in den at Befehlen mal "dummies" schalten statt der ZWave-Geräte? Wenn die Fehler dann immer noch kommen liegt es nicht an ZWave...

Die Nodelist sieht wirklich nicht gut aus, ich denke Du solltest aber erst mal den Test mit dummies in den at machen damit klar ist ob ZWave die Ursache oder das "Opfer" ist...

Gruß,
Andreas.



FB 7360, Homematic und ZWave
Support for ZWave-SECURITY
Drucken
Nach oben Seiten 1 2 3 4 Alle
Benutzer-Aktionen