Z-Wave nach heutigem Update unbrauchbar

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

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

LarsL

09 Februar 2016, 19:43:04
Hallo liebe Gemeinde,
ich weiß nicht ob andere Z-Wave Nutzer auch betroffen sind - aber bei mir geht seit dem Update von heute 09.Feb. nicht mehr wirklich viel.
Ein und Auschalten von Geräten geht noch - wenn auch sehr mit Verzögerung.
Es kommen keinerlei Daten mehr rein von Fibaro Geräten, man kann auch Schalter von anderen Herstellern nicht mehr abfrgen.
Egal was man dor mit GET abfragen will - es kommt ein Timeout.

Bei mir kommt ein Raspberry mit Z-Wave Aufsteckmodul zum Einsatz.

Außer dem UPDATE wurde nichts auf meiner Seite geändert.

Hilfe !!!  :'(

krikan

#1
09 Februar 2016, 19:54:11
Kann ich leider nicht nachvollziehen. Bei mir läuft es ohne Probleme.
Was sagt das Log?
Hast Du es mal mit einem Reboot des Raspi probiert?

LarsL

#2
09 Februar 2016, 20:01:40
Hallo Krikan,

ja natürlich, Reboot und auch noch APT-GET ... das übliche.

Das Log wirft nur Timeouts aus bei Abfragen:
2016.02.09 19:57:40 2 : ZWave: No ACK from WZ after 10s for sent:131c027204251c
2016.02.09 20:00:29 2 : ZWave: No ACK from Schlafzimmer after 10s for sent:13060220022506
und das ist unabhängig was ich abrfagen will.


rudolfkoenig

#3
09 Februar 2016, 20:05:38
Was sagt das Log, wenn du vorher "attr ZWDongle_0 verbose 5" und "attr global mseclog" gesetzt hast?

LarsL

#4
09 Februar 2016, 20:12:36
2016.02.09 20:10:16.652 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220005
2016.02.09 20:10:16.652 5 : SW: 06
2016.02.09 20:10:16.654 5 : ZWAVE dispatch 0004001a06310504220005
2016.02.09 20:10:16.907 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004000306310504220181
2016.02.09 20:10:16.907 5 : SW: 06
2016.02.09 20:10:16.909 5 : ZWAVE dispatch 0004000306310504220181
2016.02.09 20:10:19.301 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220004
2016.02.09 20:10:19.302 5 : SW: 06
2016.02.09 20:10:19.304 5 : ZWAVE dispatch 0004001b06310504220004
2016.02.09 20:10:19.652 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220006
2016.02.09 20:10:19.653 5 : SW: 06
2016.02.09 20:10:19.655 5 : ZWAVE dispatch 0004001a06310504220006
2016.02.09 20:10:20.653 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220005
2016.02.09 20:10:20.653 5 : SW: 06
2016.02.09 20:10:20.655 5 : ZWAVE dispatch 0004001a06310504220005
2016.02.09 20:10:22.653 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220006
2016.02.09 20:10:22.654 5 : SW: 06
2016.02.09 20:10:22.655 5 : ZWAVE dispatch 0004001a06310504220006
2016.02.09 20:10:23.653 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220005
2016.02.09 20:10:23.654 5 : SW: 06
2016.02.09 20:10:23.656 5 : ZWAVE dispatch 0004001a06310504220005
2016.02.09 20:10:24.303 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220005
2016.02.09 20:10:24.305 5 : SW: 06
2016.02.09 20:10:24.308 5 : ZWAVE dispatch 0004001b06310504220005
2016.02.09 20:10:31.303 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220004
2016.02.09 20:10:31.304 5 : SW: 06
2016.02.09 20:10:31.306 5 : ZWAVE dispatch 0004001b06310504220004
2016.02.09 20:10:36.304 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220005
2016.02.09 20:10:36.306 5 : SW: 06
2016.02.09 20:10:36.309 5 : ZWAVE dispatch 0004001b06310504220005
2016.02.09 20:10:40.909 4 : ZWDongle_Read ZWAVE: sending ACK, processing 000400030a3202214400004f5b0000
2016.02.09 20:10:40.910 5 : SW: 06
2016.02.09 20:10:40.912 5 : ZWAVE dispatch 000400030a3202214400004f5b0000
2016.02.09 20:10:42.305 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220004
2016.02.09 20:10:42.306 5 : SW: 06
2016.02.09 20:10:42.308 5 : ZWAVE dispatch 0004001b06310504220004
2016.02.09 20:10:47.305 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220005
2016.02.09 20:10:47.308 5 : SW: 06
2016.02.09 20:10:47.310 5 : ZWAVE dispatch 0004001b06310504220005
2016.02.09 20:10:47.656 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220006
2016.02.09 20:10:47.657 5 : SW: 06
2016.02.09 20:10:47.659 5 : ZWAVE dispatch 0004001a06310504220006
2016.02.09 20:10:53.306 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220004
2016.02.09 20:10:53.307 5 : SW: 06
2016.02.09 20:10:53.308 5 : ZWAVE dispatch 0004001b06310504220004
2016.02.09 20:10:53.752 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220005
2016.02.09 20:10:53.753 5 : SW: 06
2016.02.09 20:10:53.755 5 : ZWAVE dispatch 0004001a06310504220005
2016.02.09 20:10:54.657 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220006
2016.02.09 20:10:54.657 5 : SW: 06
2016.02.09 20:10:54.659 5 : ZWAVE dispatch 0004001a06310504220006
2016.02.09 20:10:56.657 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220005
2016.02.09 20:10:56.659 5 : SW: 06
2016.02.09 20:10:56.661 5 : ZWAVE dispatch 0004001a06310504220005
2016.02.09 20:10:57.657 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001a06310504220006
2016.02.09 20:10:57.658 5 : SW: 06
2016.02.09 20:10:57.660 5 : ZWAVE dispatch 0004001a06310504220006
2016.02.09 20:10:58.307 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220005
2016.02.09 20:10:58.310 5 : SW: 06
2016.02.09 20:10:58.312 5 : ZWAVE dispatch 0004001b06310504220005

Irgendwie kann ich damit nichts anfangen  :-\

LarsL

#5
09 Februar 2016, 20:14:38
oder bei Abfrage

get WZ associationAll

kommt

2016.02.09 20:13:36.171 2 : ZWave get WZ associationGroups
2016.02.09 20:13:36.173 5 : ZWDongle_Write 00131c028505251c (ed191c40)
2016.02.09 20:13:36.174 5 : SW: 010900131c028505251c42
2016.02.09 20:13:36.176 4 : ZWDongle_ReadAnswer arg:associationGroups regexp:^0004001c..85
2016.02.09 20:13:36.177 5 : ACK received, WaitForAck=>2 for 010900131c028505251c42
2016.02.09 20:13:36.179 4 : ZWDongle_Read ZWAVE: sending ACK, processing 011301
2016.02.09 20:13:36.180 5 : SW: 06
2016.02.09 20:13:36.182 5 : ZWAVE dispatch 011301
2016.02.09 20:13:36.215 4 : ZWDongle_Read ZWAVE: sending ACK, processing 00131c00
2016.02.09 20:13:36.215 5 : SW: 06
2016.02.09 20:13:36.217 5 : device ack reveived, removing 010900131c028505251c42 from dongle sendstack
2016.02.09 20:13:36.217 5 : ZWAVE dispatch 00131c00
2016.02.09 20:13:36.256 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001c03850603
2016.02.09 20:13:36.256 5 : SW: 06
2016.02.09 20:13:36.258 4 : ZWDongle_ReadAnswer for associationGroups: 0004001c03850603
2016.02.09 20:13:39.324 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220005
2016.02.09 20:13:39.327 5 : SW: 06
2016.02.09 20:13:39.329 5 : ZWAVE dispatch 0004001b06310504220005
2016.02.09 20:13:40.324 4 : ZWDongle_Read ZWAVE: sending ACK, processing 0004001b06310504220004
2016.02.09 20:13:40.325 5 : SW: 06
2016.02.09 20:13:40.327 5 : ZWAVE dispatch 0004001b06310504220004
2016.02.09 20:13:40.907 4 : ZWDongle_Read ZWAVE: sending ACK, processing 000400030a3202214400004f5c0000
2016.02.09 20:13:40.907 5 : SW: 06
2016.02.09 20:13:40.909 5 : ZWAVE dispatch 000400030a3202214400004f5c0000
2016.02.09 20:13:46.180 2 : ZWave: No ACK from WZ after 10s for sent:131c028505251c

LarsL

#6
09 Februar 2016, 20:54:39
Ich habe gerade den Raspberry komplett vom Strom - und nun kommt wieder alles reingeflattert:

2016-02-09 20:49:34.450 ZWave Spuelmaschine power: 0.4 W
2016-02-09 20:49:35.450 ZWave Spuelmaschine power: 0.5 W
2016-02-09 20:49:37.835 ZWave WZ assocGroup_3: Max 14 Nodes ZWAVE
2016-02-09 20:49:37.842 ZWave WZ assocGroup_2: Max 14 Nodes
2016-02-09 20:49:37.848 ZWave WZ assocGroup_1: Max 14 Nodes ZWAVE
2016-02-09 20:49:37.854 ZWave WZ assocGroups: 3
2016-02-09 20:49:38.450 ZWave Spuelmaschine power: 0.4 W
2016-02-09 20:49:40.772 ZWave PowerDM8000 energy:  203.18 kWh
2016-02-09 20:49:48.955 ZWave WZ assocGroup_3: Max 14 Nodes ZWAVE
2016-02-09 20:49:48.962 ZWave WZ assocGroup_2: Max 14 Nodes
2016-02-09 20:49:48.968 ZWave WZ assocGroup_1: Max 14 Nodes ZWAVE
2016-02-09 20:49:48.973 ZWave WZ assocGroups: 3

Also reicht ein normaler init 6 scheinbar nicht immer ...

Besteht eigentlich die Möglichkeit von dem ZWve Chip ein Backup zu erstellen, für den Fall das der mal den Geist aufgibt?
Master / Slave unterstützt FHEM ja leider nicht so wie ich das irgendwann man gelesen habe.

Danke für die Unterstützung  :)

krikan

#7
09 Februar 2016, 21:01:19
Aktuelle Infos findest Du hier http://forum.fhem.de/index.php/topic,44905.msg403459.html#msg403459 und im dort verlinkten Thread.

rudolfkoenig

#8
09 Februar 2016, 21:57:01
ZitatIch habe gerade den Raspberry komplett vom Strom - und nun kommt wieder alles reingeflattert:
Ich gehe davon aus, dass alles funktioniert, und ich nichts untersuchen muss. Falls das nicht der Fall ist, bitte melden.
Damit es nicht langweilig wird, habe ich das get Code gerade umgebaut (siehe http://forum.fhem.de/index.php/topic,48962.msg407154.html#msg407154), also bei Fehler bitte damit testen (update morgen ab 8). Zu meiner Rettung muss ich sagen, dass ich es getestet habe, und ueberzeugt bin, dass es ab sofort mit mehreren gets besser funktioniert.

@Christian: ich verstehe deinen Link nicht. LarsL verwendet doch kein CUL oder?

krikan

#9
09 Februar 2016, 22:06:07
Zitat von: rudolfkoenig am 09 Februar 2016, 21:57:01
@Christian: ich verstehe deinen Link nicht. LarsL verwendet doch kein CUL oder?
Ja, da hast Du Recht. Der verlinkte Beitrag von Thyraz enthält (zu meiner Rettung) auch einen Link zum Razberry-Backup.  8)
Btw: Danke für den Umbau und get-versionClassAll.

LarsL

#10
10 Februar 2016, 18:46:02
Hallo und Danke euch allen noch einmal.
Wie gesagt wenn ich den PI komplett vom Strom nehme geht dannach wieder alles.
Warum es den ZWave Dongel jedes mal komplett zerbröselt verstehe ich zwar nicht - aber muss ich halt damit leben. Mir persönlich wäre sowieso eine andere Hardwarelösung deutlich lieber. Ich habe hier nicht nur FHEM im Einsatz sondern gut 5 Raspberry Pi für andere Aufgaben - und ich habe schon sehr viele SD Karten abrauchen gesehen :-( Von daher taugt die PI Lösung eigentlich nur zum Basteln und nicht wenn man da wie ich ein Ferienhaus im Osteuropäischen Ausland mit betreiben will.

m8ichael

#11
10 Februar 2016, 23:43:31
Zitat von: LarsL am 10 Februar 2016, 18:46:02
Hallo und Danke euch allen noch einmal.
Wie gesagt wenn ich den PI komplett vom Strom nehme geht dannach wieder alles.
Warum es den ZWave Dongel jedes mal komplett zerbröselt verstehe ich zwar nicht - aber muss ich halt damit leben. Mir persönlich wäre sowieso eine andere Hardwarelösung deutlich lieber. Ich habe hier nicht nur FHEM im Einsatz sondern gut 5 Raspberry Pi für andere Aufgaben - und ich habe schon sehr viele SD Karten abrauchen gesehen :-( Von daher taugt die PI Lösung eigentlich nur zum Basteln und nicht wenn man da wie ich ein Ferienhaus im Osteuropäischen Ausland mit betreiben will.
Hallo,

habe hier auch das gleiche Problem...seit dem Update geht's nur noch so einigermaßen, wobei ich als System Windows nutze. Bekomme ohne Ende Timeouts (wobei, laut Log statt den üblichen 10 Sekunden nun nur noch 3?) und gets funktionieren so gut wie nicht bzw hier die Fehlermeldung IO::Socket::INET: connect: timeout. Habe meinen Stick schon mehrfach vom Strom genommen, Fhem x mal neu gestartet, aber bisher keine wirkliche Lösung.

Warte mal bis morgen ab und werde es dann noch mal näher untersuchen...

Soweit erst einmal...

Michael

rudolfkoenig

#12
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?

A.Harrenberg

#13
11 Februar 2016, 07:47:32
Hi,
Zitat von: rudolfkoenig am 11 Februar 2016, 07:11:44
@m8ichael: Könnte ich bitte ein Log der Probleme mit "attr ZWDongle verbose 5" und "attr global mseclog 5" bekommen?
Tippfehler: "attr global mseclog 1"

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

rudolfkoenig

#14
11 Februar 2016, 08:02:35
Stimmt :), aber 5 funktioniert auch. Hauptsache nicht 0

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

m8ichael

#30
13 Februar 2016, 00:49:11
Hallo Andreas!

Zitat von: A.Harrenberg am 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.

Hier mal die Liste:

Code Auswählen

ile                  Rev   Last Change

fhem.pl               10769 2016-02-08 12:11:51Z rudolfkoenig
95_Alarm.pm           10664 2016-01-30 11:36:17Z pahenning
90_at.pm              10594 2016-01-22 13:27:34Z rudolfkoenig
98_autocreate.pm      10651 2016-01-28 16:18:49Z rudolfkoenig
57_Calendar.pm        10790 2016-02-10 18:33:42Z borisneubert
95_Dashboard.pm       10344 2016-01-03 11:29:48Z talkabout
98_dummy.pm           10530 2016-01-16 19:27:21Z rudolfkoenig
91_eventTypes.pm      10530 2016-01-16 19:27:21Z rudolfkoenig
01_FHEMWEB.pm         10747 2016-02-07 07:39:16Z rudolfkoenig
92_FileLog.pm         10530 2016-01-16 19:27:21Z rudolfkoenig
98_Heating_Control.pm 10429 2016-01-09 17:37:05Z dietmar63
95_holiday.pm         10530 2016-01-16 19:27:21Z rudolfkoenig
98_HTTPMOD.pm          9127 2015-08-24 18:43:31Z ststrobel
91_notify.pm          10694 2016-02-01 06:43:00Z rudolfkoenig
70_ONKYO_AVR.pm       10559 2016-01-17 15:51:02Z loredo
99_SUNRISE_EL.pm      10569 2016-01-19 06:30:28Z rudolfkoenig
98_SVG.pm             10792 2016-02-10 20:20:49Z rudolfkoenig
98_telnet.pm          10551 2016-01-17 11:03:44Z rudolfkoenig
59_Twilight.pm         8743 2015-06-14 12:14:57Z dietmar63
99_Utils.pm           10570 2016-01-19 06:39:23Z rudolfkoenig
98_version.pm         10658 2016-01-29 19:43:10Z markusbloch
59_Weather.pm         10403 2016-01-07 19:44:04Z borisneubert
98_weblink.pm         10530 2016-01-16 19:27:21Z rudolfkoenig
98_WeekdayTimer.pm    10691 2016-01-31 19:23:01Z dietmar63
70_XBMC.pm            10601 2016-01-22 20:49:44Z vbs2
10_ZWave.pm           10782 2016-02-09 20:44:59Z rudolfkoenig
00_ZWDongle.pm        10584 2016-01-21 11:07:44Z rudolfkoenig

Blocking.pm           10343 2016-01-03 10:55:45Z rudolfkoenig
DevIo.pm               8954 2015-07-13 16:01:48Z rudolfkoenig
HttpUtils.pm          10698 2016-02-02 18:36:14Z rudolfkoenig
ONKYOdb.pm             6992 2014-11-16 00:10:16Z loredo
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm       9413 2015-10-09 13:13:11Z rudolfkoenig
TcpServerUtils.pm     10346 2016-01-03 12:34:27Z rudolfkoenig
WinService.pm          5819 2014-05-11 14:17:21Z rudolfkoenig
ZWLib.pm              10786 2016-02-10 06:37:59Z rudolfkoenig


Habe jetzt mal gerade nen radikalen Test gemacht: Habe die Standard-5.7-Version eingespielt. Tja, und damit läuft's ohne Probleme (zumindest kommen die get's sauber durch und auch die nodeList sieht wieder gut aus). Ein paar getestete AT's funktionieren auch. Nehme ich per "update" ein Update vor (Versionsstand dann wie oben), so kommen wieder die Probleme. Insofern schließe ich echte "Empfangsprobleme" nun endgültig aus. Es scheint sich wohl irgendwo ein Bug eingeschlichen haben, der sich auf meinem System auswirkt...  :-[

Gruß

Michael

A.Harrenberg

#31
13 Februar 2016, 07:31:36
Hi,

ja, aber der Fehler deutet ja mehr auf eine Netzwerkverbindung hin, wie gesagt, ersetz mal die ZWave-Befehle durch Befehle an Dummies. Ich denke das wird funktionieren. Dann bleiben die anderen Module die etwas mit Netzwerk zu tun haben, z.B. Weather, Calendar, ....

Ich weiß nicht ob Du evtl. mehr hilfreiche Info bekommst wenn Du mal global verbose = 5 setzt, aber vorsicht, die Logfiles werden dann recht schnell groß...

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

rudolfkoenig

#32
13 Februar 2016, 08:57:31
@m8ichael:

- ich habe gerade mit einem aktuellen FHEM nodeList geprueft, weiterhin ein ZWave get via at gestartet, beides funktioniert ohne Probleme.

- die Ausgabe von deinem nodeList zeigt, dass FHEM keine ZWave Instanzen/Definitionen findet. Eine moegliche Ursache ist das alte ZWave Dongle/Stick mit einem neuen/leeren FHEM Konfiguration zu verwenden, eine Andere ist eine korrupte 10_ZWave.pm Datei, was von FHEM gar nicht geladen wird. Einen Programmierfehler in der letzten ZWave.pm Version (so wie man es anhand des Betreffs danken koennte) kann ich mir als Ursache deiner nodeList Ausgabe nicht vorstellen. Falls ich auf der falschen Faehrte bin: bitte in fhem.cfg "attr global verbose 5" setzen, FHEM starten, als erstes "get ZWDongle nodeList" ausfuehren, und das Log hier anhaengen.

- IO::Socket::INET: connect: timeout bei get, wenn das get ueber at laeuft: Seit der Aenderung in ZWave.pm blockieren per at oder notify abgesetzte ZWave get Befehle FHEM nicht(!) mehr. Als Nebenwirkung kann in einem anderen Modul das erwaehnte Problem auftreten, auch wenn ich noch Schwierigkeiten habe vorzustellen, wie. Um dieses Problem zu debuggen brauche ich auch ein log mit "attr global verbose 5", bitte auch von FHEM-Neustart an, da ich andere Module als Ursache vermute.

m8ichael

#33
13 Februar 2016, 10:17:48
Guten Morgen!

Zitat von: rudolfkoenig am 13 Februar 2016, 08:57:31
@m8ichael:

- ich habe gerade mit einem aktuellen FHEM nodeList geprueft, weiterhin ein ZWave get via at gestartet, beides funktioniert ohne Probleme.

- die Ausgabe von deinem nodeList zeigt, dass FHEM keine ZWave Instanzen/Definitionen findet. Eine moegliche Ursache ist das alte ZWave Dongle/Stick mit einem neuen/leeren FHEM Konfiguration zu verwenden, eine Andere ist eine korrupte 10_ZWave.pm Datei, was von FHEM gar nicht geladen wird. Einen Programmierfehler in der letzten ZWave.pm Version (so wie man es anhand des Betreffs danken koennte) kann ich mir als Ursache deiner nodeList Ausgabe nicht vorstellen. Falls ich auf der falschen Faehrte bin: bitte in fhem.cfg "attr global verbose 5" setzen, FHEM starten, als erstes "get ZWDongle nodeList" ausfuehren, und das Log hier anhaengen.

Hier dann mal das Log:

Code Auswählen

2016.02.13 10:05:48.778 5: Cmd: >get ZWAVE1 nodeList<
2016.02.13 10:05:48.778 4: ZWDongle get ZWAVE1 nodeList
2016.02.13 10:05:48.778 5: ZWDongle_Write 0002 ()
2016.02.13 10:05:48.778 5: SW: 01030002fe
2016.02.13 10:05:48.782 4: ZWDongle_ReadAnswer arg:nodeList regexp:^0102
2016.02.13 10:05:48.782 5: ACK received, removing 01030002fe from dongle sendstack
2016.02.13 10:05:51.783 4: ZWDongle_Read ZWAVE1: sending ACK, processing 010205001dfffff1af0f0000000000000000000000000000000000000000000000000500
2016.02.13 10:05:51.783 5: SW: 06
2016.02.13 10:05:51.787 4: ZWDongle_ReadAnswer for nodeList: 010205001dfffff1af0f0000000000000000000000000000000000000000000000000500
2016.02.13 10:05:51.787 4: name: /fhem?detail=ZWAVE1&dev.getZWAVE1=ZWAVE1&cmd.getZWAVE1=get&arg.getZWAVE1=nodeList&val.getZWAVE1=&XHR=1&addLinks=1&fw_id=146 / RL:162 / text/plain; charset=UTF-8 / Content-Encoding: gzip


Zitat von: rudolfkoenig am 13 Februar 2016, 08:57:31
- IO::Socket::INET: connect: timeout bei get, wenn das get ueber at laeuft: Seit der Aenderung in ZWave.pm blockieren per at oder notify abgesetzte ZWave get Befehle FHEM nicht(!) mehr. Als Nebenwirkung kann in einem anderen Modul das erwaehnte Problem auftreten, auch wenn ich noch Schwierigkeiten habe vorzustellen, wie. Um dieses Problem zu debuggen brauche ich auch ein log mit "attr global verbose 5", bitte auch von FHEM-Neustart an, da ich andere Module als Ursache vermute.

Oh, da habe ich mich falsch ausgedrückt.  ::) Der Fehler kommt entweder, wenn ein Befehl per AT ausgeführt wird, oder man manuell ein "get" absetzt. Log schicke ich!

Viele Grüße

Michael


A.Harrenberg

#34
13 Februar 2016, 10:23:07
Hi Michael,

bitte das Log ab dem Neustart posten damit man sieht was vorher evtl. schon schief gegangen ist.

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

m8ichael

#35
13 Februar 2016, 11:10:24
Hallo zusammen,

anbei das Log.

Könnt ihr da etwas erkennen?

Viele Grüße

Michael

A.Harrenberg

#36
13 Februar 2016, 12:34:22
Hi, ich kann da nicht viel erkennen, aber da meckert irgendwas in Verbindung mit der Heizung das Klammern und auch Anführungszeichen nicht passen. Falls da wirklich was nicht passt dann kommt FHEM natürlich beim Einlesen der cfg Datei mächtig durcheinander. Schau mal ob Du den/die Fehler in der Konfiguration finden kannst...

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

m8ichael

#37
13 Februar 2016, 13:01:31
Hallo Andreas,

Zitat von: A.Harrenberg am 13 Februar 2016, 12:34:22
Hi, ich kann da nicht viel erkennen, aber da meckert irgendwas in Verbindung mit der Heizung das Klammern und auch Anführungszeichen nicht passen. Falls da wirklich was nicht passt dann kommt FHEM natürlich beim Einlesen der cfg Datei mächtig durcheinander. Schau mal ob Du den/die Fehler in der Konfiguration finden kannst...

Ich habe jetzt mal das ganze Heizungsgerödel testweise aus der cfg herausgeschmissen - das Problem besteht jedoch weiterhin. Setze ich ein "get ZWDONGLE nodeList" ab, so erhalte ich bspw. weiterhin die UNKNOWN-Nodes (siehe oben). Und auch die übrigen Probleme bestehen weiterhin...Mist...  :(

Mir ist auch gerade aufgefallen, dass bei einigen Geräten das "Timeout" sofort beim klicken auf "get" kommt. Dabei zufällig wechselnd zwischen "Timeout" und "IO::Socket::INET: connect: timeout". Sehr strange...

Viele Grüße

Michael

A.Harrenberg

#38
13 Februar 2016, 14:07:38
Hi,

mir scheint das da einiges an der cfg durcheinander/kaputt zu sein. Vielleicht hat Rudi noch eine Idee...

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

rudolfkoenig

#39
13 Februar 2016, 15:26:40
Zitatanbei das Log.
Könnt ihr da etwas erkennen?

Ja: keiner der beschriebenen Probleme ist im Log protokolliert.
D.h. ich habe jetzt 10 Minuten lang umsonst FHEM-Logs gelesen.

m8ichael

#40
13 Februar 2016, 15:47:18
Zitat von: rudolfkoenig am 13 Februar 2016, 15:26:40
Ja: keiner der beschriebenen Probleme ist im Log protokolliert.
D.h. ich habe jetzt 10 Minuten lang umsonst FHEM-Logs gelesen.

Sorry, hatte dich so verstanden, dass ich den Log des Systemstarts schicken sollte...  :-[ Hier dann noch mal einen Gesamtlog. Der erste Fehler tritt in Zeile 5568 auf (nodeList --> nur UNKNOWN-Nodes). Danach gibt es ein Problem beim Abfragen der neighborList (Zeile 5648 bzw. Zeile 5744).

Zitat
mir scheint das da einiges an der cfg durcheinander/kaputt zu sein. Vielleicht hat Rudi noch eine Idee...

Macht es Sinn, die cfg nochmal neu zu sortieren? Oder macht das FHEM intern automatisch?

rudolfkoenig

#41
13 Februar 2016, 18:52:07
nodeList bug: im letzten Log konnte das FHEM-ZWDongle-Modul den ZWave-Stick nicht initialisieren, im vorletzten log hat das funktioniert. Das Problem ist zu sehen als Fehlermeldung "ZWAVE1: SOF missing (got 67 instead of 01)"  auf Level 1 im FHEM-Log. Deswegen war das homeId des Sticks nicht bekannt, deswegen konnte nodeList die Nodes nicht finden und hat UNKNOWN gemeldet. Workaround1: "attr ZWAVE1 nodeId c0bcc8ab". Ich habe in 3 Minuten 9 solche Fehlermeldungen gezaehlt, d.h. die Kommunikation zwischen FHEM und ZWave Stick ist kaputt. Das kann entweder an dem Stick alleine, oder an der FHEM@Windows und Genau-Dieser-Stick Kombination liegen.

IO::Socket bzw Timeout Meldungen habe ich im Log nicht gefunden.

rudolfkoenig

#42
13 Februar 2016, 18:57:53
ZitatMacht es Sinn, die cfg nochmal neu zu sortieren? Oder macht das FHEM intern automatisch?
Beim Sortieren muss man vorsichtig sein, da es Abhaengigkeiten gibt: z.Bsp. setzt ein ZWave Instanz das Vorhandensein des passenden ZWDongle voraus.
FHEM sortiert nicht, ich wuesste auch nicht, wozu das in diesem Fall gut sein sollte.

m8ichael

#43
14 Februar 2016, 22:02:26
Hallo zusammen,

habe nun einmal verschiedenste Tests durchgeführt - auch dank deiner guten Hinweise, Rudi...  :) Das Problem scheint doch etwas vielschichtiger zu sein, als ursprünglich von mir angenommen. Einerseits scheint ein Routingproblem innerhalb des Z-Wave-Netzes vorgelegen zu haben. Dieses resultierte wohl aus Nodes, die nicht ordnungsgemäß exkludiert wurden, sodass es zu Fehlroutings und damit zu Timeouts kam. Vielleicht reagiert die neue Version hierauf etwas empfindlicher (geringere Timeout-Zeit?), sodass nach dem Update das Problem aufgetaucht ist, obwohl es ursächlich schon früher bestand. Insofern läuft hier jetzt vieles viel flüssiger und nack's treten so gut wie nicht mehr auf!

Andererseits ist seit dem Update mit dem Fehler "IO::Socket::INET..." ein Problem aufgetaucht, was laut Fhem-Log bei mir erst seit dem Update besteht. Ich habe daraufhin testweise die Version 5.7 eingespielt (ohne anschließende Updates), und bis jetzt ist der Fehler nicht wieder aufgetaucht. Das sagt nicht wirklich etwas, da der Fehler auch mit den Updates nur sporadisch aufgetreten ist (und da auch nur bei at's bzw. manuellen get's), aber ein Test ist es wert...

Ich werde daher weiter testen und berichten!

Gruß

Michael

m8ichael

#44
15 Februar 2016, 23:07:41
Hallo zusammen,

das ist wirklich zum Haareherausraufen: wechsle ich zur 5.7-Ursprungsversion, so läuft alles glatt; spiele ich dann die Updates ein, so taucht wieder mein 'Lieblingsfehler' auf.   >:(  So dann gerade das für mich nichtssagende Errorlog erhalten:
Code Auswählen

2016.02.15 22:45:00.031 5: exec at command ATEingangsbeleuchtungAus
2016.02.15 22:45:00.032 5: Cmd: >set eg.fl.Eingang.Stimmungsbeleuchtung,div.Schalter2 off<
2016.02.15 22:45:00.032 3: ATEingangsbeleuchtungAus: IO::Socket::INET: connect: timeout IO::Socket::INET: connect: timeout
2016.02.15 22:45:00.032 5: redefine at command ATEingangsbeleuchtungAus as *22:45 set eg.fl.Eingang.Stimmungsbeleuchtung,div.Schalter2 off


Oder heute auch bei einem notify:

Code Auswählen

2016.02.15 19:20:30.751 5: Cmd: >set dm.og.sz.Hauptbeleuchtung 42<
2016.02.15 19:20:30.751 4: dummy set dm.og.sz.Hauptbeleuchtung 42
2016.02.15 19:20:30.751 5: Triggering dm.og.sz.Hauptbeleuchtung (1 changes)
2016.02.15 19:20:30.751 5: Notify loop for dm.og.sz.Hauptbeleuchtung 42
2016.02.15 19:20:30.752 5: Triggering dm.og.sz.Hauptbeleuchtung.notify
2016.02.15 19:20:30.752 4: dm.og.sz.Hauptbeleuchtung.notify exec set og.sz.Hauptbeleuchtung dim $EVENT
2016.02.15 19:20:30.752 5: Cmd: >set og.sz.Hauptbeleuchtung dim $EVENT<
2016.02.15 19:20:30.752 3: dm.og.sz.Hauptbeleuchtung.notify return value: IO::Socket::INET: connect: timeout
2016.02.15 19:20:30.754 4: name: /fhem?cmd=set%20dm.og.sz.Hauptbeleuchtung%2042&XHR=1&fw_id=144 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip /


Hat jemand dazu noch eine Idee? Oder muss ich auf der 5.7-Urversion bleiben?

Viele Grüße!

Michael

rudolfkoenig

#45
16 Februar 2016, 10:25:02
Ich habe dein Log analysiert, danach den kompletten Code-Verlauf, der bei einem set durchgelaufen wird 2-mal durchgelesen, und habe keine Idee: das Modul IO::Socket::INET wird nirgendwo aufgerufen. Ich vermute eine "unerwartete" Implementierung einer Funktion unter Windows mit Netzwerk, wuesste aber nicht, wo. Ziemlich sicher: das Problem hat nicht mit der letzten Aenderungen zu tun, sonst haette im Log direkt nach Cmd: eine Zeile mit "ZWave set ..." mit verbose 2 auftauchen muessen: das geaenderte ZWave-Code kommt danach.

Um das Problem einzugrenzen habe ich eine geaenderte fhem.pl und 10_ZWave.pm mit zusaetzlichen Log-Ausgaben auf verbose 1 angehaengt, bitte beide austauschen und laufen lassen.

m8ichael

#46
16 Februar 2016, 18:31:43
Hallo!

Zitat von: rudolfkoenig am 16 Februar 2016, 10:25:02
Ich habe dein Log analysiert, danach den kompletten Code-Verlauf, der bei einem set durchgelaufen wird 2-mal durchgelesen, und habe keine Idee: das Modul IO::Socket::INET wird nirgendwo aufgerufen. Ich vermute eine "unerwartete" Implementierung einer Funktion unter Windows mit Netzwerk, wuesste aber nicht, wo. Ziemlich sicher: das Problem hat nicht mit der letzten Aenderungen zu tun, sonst haette im Log direkt nach Cmd: eine Zeile mit "ZWave set ..." mit verbose 2 auftauchen muessen: das geaenderte ZWave-Code kommt danach.

Um das Problem einzugrenzen habe ich eine geaenderte fhem.pl und 10_ZWave.pm mit zusaetzlichen Log-Ausgaben auf verbose 1 angehaengt, bitte beide austauschen und laufen lassen.

Vielen Dank für deine Mühen! Ich habe mal ein neues Thema eröffnet (siehe http://forum.fhem.de/index.php/topic,49444.0.html).

Viele Grüße

Michael

r26r26

#47
20 Februar 2016, 18:42:07
Hallo Leute,

ich kann derzeit alle gemeldeten Störungen nach dem letzten z-wave Update bei FEHM bestätigen. Bei mir geht nichts mehr.

Anzeichen: es werden keine Readings mehr versendet (Status, Power, etc.)

Ich habe das Update diese Woche laufen lassen. Die bestehenden Geräte haben noch funktioniert, die neuen Geräte leiden alle unter diesen Störungen.

Habt ihr eine Idee, wie das gelöst werden kann?

A.Harrenberg

#48
20 Februar 2016, 19:16:10
Hi,

logfiles und genauere Beschreibung bitte. (fhemwiki.de Welche Infos sollten Anfragen im ZWave-Forum enthalten?)

Vielleicht lassen sich Gemeinsamkeiten erkennen...

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

r26r26

#49
20 Februar 2016, 19:20:33
Hi nochmal,
also ich behaupte mal, dass euch die LOG Daten gar nichts bringen, weil nichts geloggt wird.

Ich habe herausgefunden, dass die Kommunikation nur eine Einbahnstraße ist.

Befehle vom Controller werden versendet und ausgeführt (Einschalten / Auschalten, usw.)

Informationen von den Sensoren / Aktoren gelangen NICHT zum Controller zurück, bzw. nicht zu FHEM.

Test: FEHM Schalter ON = Schalter schaltet ON - FEHM zeigt ON

Schalter manuell am Schalter auf ON = FEHM zeigt keine Veränderung
Schalter manuell am Schalter auf OFF = FEHM zeigt keine Veränderung
FEHM zeigt keine Readings

Im LOG steht wirklich nichts.

m8ichael

#50
20 Februar 2016, 19:21:46
Hallo,

bei mir läuft soweit wieder alles gut. Letztendlich bestanden zwei Fehler, die offenbar durch das Update in Erscheinung getreten sind:


  • Ein Gerät war nicht sauber im Stick exkludiert worden. Dies sorgte für ein falsches Routing und dadurch, dass sich die Timeouts durch das Update wohl geändert haben, insgesamt für eine Fehlfunktion.
  • Besonderheit, die für Windows gilt, mittlerweile aber ausgebügelt wurde.

Viele Grüße

Michael

A.Harrenberg

#51
20 Februar 2016, 20:04:22
Zitat von: r26r26 am 20 Februar 2016, 19:20:33
also ich behaupte mal, dass euch die LOG Daten gar nichts bringen, weil nichts geloggt wird.
[...]
Informationen von den Sensoren / Aktoren gelangen NICHT zum Controller zurück, bzw. nicht zu FHEM.

Test: FEHM Schalter ON = Schalter schaltet ON - FEHM zeigt ON

Schalter manuell am Schalter auf ON = FEHM zeigt keine Veränderung
Schalter manuell am Schalter auf OFF = FEHM zeigt keine Veränderung
FEHM zeigt keine Readings

Im LOG steht wirklich nichts.
Und Du bist wirklich sicher das ein Log mit Level 5 gar nichts anzeigt wenn was vom Gerät gesendet wird?

Ich bekomme mit aktuellem FHEM weiterhin Rückmeldungen z.B. auf get Battery angezeigt. Gerade update gemacht und ausprobiert.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY
Drucken
Nach oben Seiten1 2 3 4 Alle
Benutzer-Aktionen