Hallo seit heute funktionierte der Z-wave Rückkanal nicht mehr, d.h. FHEM bekommt nicht mit, wenn ich manuell den Lichttaster betätige - Schalten manuell und über FHEM Web funktioniert. Dafür füllt sich das LOG mit:
2015.03.16 18:53:21 3: Unknown ZWave device 00070606 1026, please define it
das zugehörige Device ist wie folgt definiert:
define Licht_Decke ZWave d8cb2fe1 1026
attr Licht_Decke IODev ZWDongle_1
attr Licht_Decke classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
attr Licht_Decke group Schalter
attr Licht_Decke room Küche
die weiteren z-wave Device dto.
2015.03.16 18:22:01 3: Unknown ZWave device 00070606 4, please define it
2015.03.16 18:15:27 3: Unknown ZWave device 00070606 6, please define it
2015.03.16 18:15:24 3: Unknown ZWave device 00070606 7, please define it
2015.03.16 18:15:15 3: Unknown ZWave device 00070606 3, please define it
2015.03.16 18:05:20 3: Unknown ZWave device 00070606 8, please define it
Ein Blick auf die Definition des ZWDongle und ich hätte mir den Post sparen können,
die Home id war gestern noch d8cb2fe1 und jetzt 00070606 ???
Da ich erst 8 Device seit ca 3 Wochen im Einsatz habe - Lösung, bei allen die Home id geändert - geht wieder, aber im Wiederholungsfall und bei den Schaltern, die gerade im Zulauf sind wäre das weniger fein.
Der Stick ist ein Z-Wave USB Stick (ZME_UZB1)
Gibt es dafür eine Erklärung oder eine Lösung sowas in Zukunft zu vermeiden?
und hat sich auch genau so von allein nach einem 2015.03.16 19:28:41 1: /dev/ttyACM1 reappeared (ZWDongle_1)
2015.03.16 19:28:41 3: Setting ZWDongle_1 baudrate to 115200
2015.03.16 19:28:41 1: /dev/ttyACM1 disconnected, waiting to reappear (ZWDongle_1)
wieder auf den alten Wert zurückgesetzt...
Ueblicherweise aendert sich die Definition eine ZWDongle nicht von alleine, wenn das reproduzierbar auftritt, dann bin ich an Details interessiert, damit ich es fixen kann. Habe bisher davon auch nichts gehoert.
Nach Studium der Quellen hat sich rausgestellt, dass homeId eigentlich ueberfluessig ist, und man alles auch ohne diese Nummer implementieren koennte, allerdings waere der Umbau aufwendig.
Ich habe bei meinen Aeon Labs Z-Stick hin und wieder das Problem,
dass nach einen "shutdown restart" die Meldung:
ZWDongle HomeID is not set
im Log steht. Es funktioniert dann auch kein Z-Wave.
Nach einen erneuten "shutdown restart" passt dann wieder alles.
Hat mich jetzt nicht weiter gestört, da das Problem nur alle paar Wochen mal
nach einen restart auftaucht und sich leicht beheben lässt.
Vielleicht ist es aber ein ähnliches Problem wie bei dir.
VG
Florian
Zitat von: rudolfkoenig am 17 März 2015, 10:22:45
Ueblicherweise aendert sich die Definition eine ZWDongle nicht von alleine, wenn das reproduzierbar auftritt, dann bin ich an Details interessiert, damit ich es fixen kann. Habe bisher davon auch nichts gehoert.
Nach Studium der Quellen hat sich rausgestellt, dass homeId eigentlich ueberfluessig ist, und man alles auch ohne diese Nummer implementieren koennte, allerdings waere der Umbau aufwendig.
Danke für die rasche Antwort, ich hoffe die gewünschten Details nicht liefern zu müssen - im Falle das Phanomen tritt einfach nicht wieder auf.
habe nun nach Umstellung auf den ZME_UZB1, Migration auf DbLog u.a. häufiger dieses Phänomen mit der Meldung "ZWDongle HomeID is not set".
Versuche nun die HomeId als Attribut in 00_ZWDongle.pm zu fixieren
171c171
< $hash->{AttrList}= "do_not_notify:1,0 dummy:1,0 model:ZWDongle disable:0,1";
---
> $hash->{AttrList}= "do_not_notify:1,0 dummy:1,0 model:ZWDongle disable:0,1 homeId";
631a632,633
> } elsif($attr eq "homeId") {
> $hash->{homeId} = $value;
Werde beobachten ob es hilft.
Update:
hatte wieder einen Fehler beim lesen der HomeId nach dem Neustart.
Die Fehlermeldung mit leerer HomeId blieb aus - es wird die HomeId aus dem Attribut verwendet :)
Das im ersten Post beschriebene Problem habe ich auch schon beobachtet. Nachdem ich einen Fibaro Wall Plug erfolgreich mit meinem Z-Wave Dongle (ZME_UZB1) in Betrieb genommen habe und das ganze einige Tage erfolgreich lief, tauchten im Log folgende Meldungen auf:
UNDEFINED ZWave_Endpoint_4.0 ZWave 00040606 4, please define it
Bei nähere Untersuchung habe ich ebenfalls festgestellt, dass sich die homeid meines ZWave-Dongles von geändert hat.
Abhilfe schafft ein get ZWDongle homeId oder ein shutdown restart.
Mir ist aufgefallen, dass der Dongle im Auslieferungszustand schon 3 mir unbekannte Geräte in der nodeList hatte (alles BINARY_SWITCHES). Jetzt habe ich gestern alles nochmal neu aufgesetzt, die drei unbekannten Geräte aus dem Dongle entfernt und nochmal alles neu inkludiert und assoziiert.
Hier noch ein list ZWDongle (von heute)
Internals:
CallbackNr 8
Clients :ZWave:
DEF /dev/ttyACM1@115200
DeviceName /dev/ttyACM1@115200
FD 20
NAME ZWDongle
NR 429
PARTIAL
RAWMSG 00040006028407
ReadTime 1430992110.56141
STATE Initialized
TYPE ZWDongle
ZWDongle_MSGCNT 1723
ZWDongle_TIME 2015-05-07 11:48:30
homeId c9cde420
nrNAck 0
.clientArray:
ZWave
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1430948703.27789
VALUE ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed
Matchlist:
1:ZWave .*
Readings:
2015-05-02 22:10:53 caps Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 UNKNOWN_01 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_0f 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 UNKNOWN_1b UNKNOWN_1f MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER UNKNOWN_26 UNKNOWN_27 UNKNOWN_28 UNKNOWN_29 UNKNOWN_2a UNKNOWN_2b UNKNOWN_2c UNKNOWN_40 ZW_GET_NODE_PROTOCOL_INFO UNKNOWN_43 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 UNKNOWN_4f ZW_SET_LEARN_MODE ZW_ENABLE_SUC ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID UNKNOWN_5d UNKNOWN_5f ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE UNKNOWN_65 UNKNOWN_66 UNKNOWN_77 UNKNOWN_7f UNKNOWN_8f ZW_SEND_DATA_ROUTE_DEMO UNKNOWN_92 UNKNOWN_97 UNKNOWN_b3 UNKNOWN_b5 UNKNOWN_b6 UNKNOWN_b7 UNKNOWN_b8 UNKNOWN_b9 ZW_ARE_NODES_NEIGHBOURS ZW_TYPE_LIBRARY UNKNOWN_be UNKNOWN_d1 UNKNOWN_d2 UNKNOWN_d3 UNKNOWN_ee UNKNOWN_f1 UNKNOWN_f3 UNKNOWN_f4
2015-05-06 23:54:28 ctrlCaps PRIMARY
2015-05-06 22:05:52 homeId HomeId:c9cde420 CtrlNodeId:01
2015-05-06 22:05:05 isFailedNode_2 016201
2015-05-06 22:04:27 isFailedNode_3 016201
2015-05-06 20:00:23 isFailedNode_4 016200
2015-05-06 23:42:56 neighborList_1 5
2015-05-06 23:43:18 neighborList_5
2015-05-06 23:54:41 neighborList_6 5
2015-05-06 22:03:09 nodeInfo_1 STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
2015-05-06 22:03:22 nodeInfo_2 SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
2015-05-04 11:05:34 nodeInfo_3 SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
2015-05-04 11:04:36 nodeInfo_4 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-05-06 22:31:57 nodeInfo_5 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-05-06 22:32:05 nodeInfo_6 ROUTING_SLAVE SENSOR_BINARY sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-05-06 22:30:19 nodeList 1,5,6
2015-05-06 21:57:56 state opened
SendStack:
Attributes:
room ZWave
Heute morgen habe ich im Log folgende Meldung entdeckt:
UNDEFINED ZWave_Endpoint_21.0 ZWave c9cde420 21, please define it
Diesmal scheint es aber kein Problem mit der honeId zu sein.
Sobald das homeId-Problem wieder auftaucht, werde ich nähere Informationen liefern.
Ich beschäftige mich erst seit ein paar Tagen mit Z-Wave. Kann aber hoffentlich in Zukunft etwas mehr beisteuern.
Gruß,
Gero
Hallo zusammen,
auch in meinem System tritt dieses Phänomen in (leider) unregelmäßigen Abständen und (leider) nicht reproduzierbar auf.
Heute nach einem Restart vonn FHEM folgende Logeinträge:
2015.05.07 13:33:50 3: Opening ZW_Dongle device /dev/ttyACM0
2015.05.07 13:33:50 3: Setting ZW_Dongle baudrate to 115200
2015.05.07 13:33:50 3: ZW_Dongle device opened
2015.05.07 13:33:51 1: ERROR: ZW_Dongle homeId is not set!
2015.05.07 13:33:51 1: ZW_Dongle: wrong checksum: received 05, computed 32 for 100004000e0a32020601080120d79c88
Kurz danach (wegen eingeschaltetem autocreate?) folgende Einträge:
2015.05.07 13:37:19 3: UNDEFINED ZWave_Endpoint_9.0 ZWave 000e0a32 9, please define it
2015.05.07 13:37:19 2: autocreate: define ZWave_Endpoint_9.0 ZWave 000e0a32 9
2015.05.07 13:37:20 2: autocreate: define FileLog_ZWave_Endpoint_9.0 FileLog /opt/fhem/log/ZWave_Endpoint_9.0-%Y-%m.log ZWave_Endpoint_9.0
2015.05.07 13:38:02 3: UNDEFINED ZWave_Endpoint_11.0 ZWave 000e0a32 11, please define it
2015.05.07 13:38:02 2: autocreate: define ZWave_Endpoint_11.0 ZWave 000e0a32 11
2015.05.07 13:38:02 2: autocreate: define FileLog_ZWave_Endpoint_11.0 FileLog /opt/fhem/log/ZWave_Endpoint_11.0-%Y-%m.log ZWave_Endpoint_11.0
2015.05.07 13:41:30 3: UNDEFINED ZWave_Endpoint_8.0 ZWave 000e0a32 8, please define it
2015.05.07 13:41:30 2: autocreate: define ZWave_Endpoint_8.0 ZWave 000e0a32 8
2015.05.07 13:41:30 2: autocreate: define FileLog_ZWave_Endpoint_8.0 FileLog /opt/fhem/log/ZWave_Endpoint_8.0-%Y-%m.log ZWave_Endpoint_8.0
2015.05.07 13:44:56 3: UNDEFINED ZWave_Endpoint_20.0 ZWave 000e0a32 20, please define it
2015.05.07 13:44:56 2: autocreate: define ZWave_Endpoint_20.0 ZWave 000e0a32 20
2015.05.07 13:44:56 2: autocreate: define FileLog_ZWave_Endpoint_20.0 FileLog /opt/fhem/log/ZWave_Endpoint_20.0-%Y-%m.log ZWave_Endpoint_20.0
Für mich verwunderlich, dass (diesmal?; werde beim erneuten Auftreten berichten) nicht für alle Nodes (habe insgesamt 9 ZWave-Komponenten im Verwendung) entsprechende UNDEFINED Meldungen kamen, sondern nur für die nodes 8,9, 11 und 20 (diese sind auch verschiedene Geräte Fibaro Wall-Plug, Fibaro Bewegungssensor, Danfoss Thermostat).
Habe dann alle neu erzeugten ZWave-Devices und Filelogs gelöscht, FHEM erneut gestartet und es kamen keine der obigen Meldungen.
Vielleicht helfen diese Infos etwas bei der Eingrenzung des Themas?
Viele Grüße,
Andreas
Hilft leider nicht, aber ich hab den Patch von fhem-me eingespielt.
@fhem-me: das naechste mal bitte mit diff -u und Doku...
Hallo Zusammen,
z.Zt. betreibe ich unter dem Protokoll ZWave nur den USB-Dongle und einen Philio Technology Corporation PSM02-1 Slim Multi-Sensor zum Erfahrung sammeln.
Nach einem ,,shutdown restart" hatte auch ich folgende Fehler im Log:
2015.05.23 12:27:09 3: ZWDongle_0 device opened
2015.05.23 12:27:10 1: ERROR: ZWDongle_0 homeId is not set!
2015.05.23 12:27:10 1: ZWDongle_0: wrong checksum: received 0c, computed fe for 01
2015.05.23 12:27:10 1: ZWDongle_0: SOF missing (got 00 instead of 01)
2015.05.23 12:27:10 1: Including ./log/fhem.save
2015.05.23 12:27:12 1: usb create starting
2015.05.23 12:27:12 1: usb create end
Beseitigen kann ich diesen Fehler bisher nur durch ein händisches
set ZWDongle_0 reopen
Muss für den Patch vom 09.05.2015 beim ZWDongle noch etwas spezielles definiert werden oder ist der Fehler leider immer noch vorhanden?
Stimmt die Reihenfolge (,,device opened" und später erst ,,usb create")?
Mein Update-Stand ist der 23.05.2015.
LG
Holger
Der Patch erlaubt es, dass man (manuell) das Attribut homeId setzt, das hat dann Vorrang.
Die Reihenfolge "open" vs. "usb create" ist ok: zunaechst werden alle definierten Geraete geoeffnet, danach schaut das per notify ausgeloeste "usb create", ob noch was Neues zu finden ist, zwecks Plug&Play.
Evtl. behebt dein Problem das seit gestern per update verfuegbare Patch (http://forum.fhem.de/index.php?topic=37418.0).
Anfängerfrage: manuelles Setzen sieht vermutlich (in meinem Fall) so aus:
attr ZWDongle_0 homeId fc8cd07e
Zur Not kann ich ja ansonsten in meinem Startinit-Notify das reopen verewigen. Zuerst probiere ich aber den Patch und das Attribut aus.
Danke.
Holger
Hallo Holger,
Ein Bild sagt mehr als viele Worte...
Und vielen Dank an die Entwickler, der Patch löst das Problem dauerhaft.
Das Problem mit der homeId ist noch nicht ganz behoben. Ein Patch ist in Arbeit.
Gruß,
Gero
Hallo,
da ich auch mit der aktuellsten Version und gesetztem homeId-Attribut beim Start von fhem die Fehlermeldung
ERROR: ZWDongle homeId is not set!gesehen habe, habe ich mir mal die Mühe gemacht, das Problem zu debuggen.
Ich verwende das ZWave.Me ZME_UZB1 Dongle mit zwei ZWave-Devices, von denen eines batteriebetrieben ist. Ich tippe darauf, dass das Problem durch ein etwas seltsames Verhalten des Dongles verursacht wird. Evtl. tritt es bei anderen Dongle nicht auf.
Das Problem läßt sich bei mir zu 100% nachstellen, indem ich das Wakeupintervall des batteriebetriebenen ZWave-Devices niedrig einstelle (zum Test 1 Minute), und dann fhem für mehrere Minuten beende.
Beobachtung:
Während fhem nicht läuft, sammeln sich im Dongle die wakeup-notifications an.
Beim Start von fhem wird zuerst versucht mit ZWDongle_Clear alle alten Daten des Dongles auszulesen und zu verwerfen.
Jedoch werden nur maximal 63 Byte gelesen und verarbeitet. Danach kommen selbst mit einem erhöhten ReadTimeout keine Daten mehr.
Wahrscheinlich stopt das Dongle seine Sendeaktivität, weil der USB-Stack vollgelaufen ist.
Der nächste Befehl, der von fhem gesendet wird (get caps) wird vom Dongle korrekt beantwortet.
Dieses Senden scheint aber den internen SendStack des Dongles zu reaktivieren. Daher kommt beim nächsten Lesen (getriggert durch get homeId) wieder ein neuer Schwung wakeup-notifications.
Diese Nachrichten führen in der Funktion ZWDongle_Parse->...-> ZWave_Parse zu der oben genannten Fehlermeldung.
Der Befehl zum Lesen der homeId wird mit einem CANCEL vom Dongle quittiert. Da dieser Befehl aber nicht im $hash->{SendStack} vorhanden ist, kann er nicht erneut gesendet werden und damit erhalten wir keine homeId.
Patch:
1. In der Funktion ZWaveDongle_Clear wird zum einen ZWDongle_ReadAnswer mit einer regexp aufgerufen, die niemals matched, damit alle Nachrichten auch mit einem ACK quittiert werden. Und zum anderen wird $hash->{PARTIAL} geleert.
2. Die Funktion ZWDongle_Parse gibt die Daten nur an Dispatch weiter, wenn $hash->{STATE} auf "Initialized" steht.
3. Beim ZWDongle_Write wird sich der letzte gesendete Befehl gemerkt, um ihn bei einem CANCEL erneut zu senden. An dieser Stelle bin ich mir nicht ganz sicher mit dem Patch.
Evtl. könnte auch der SendStack verwendet werden. Aber ich weiß nicht, warum
- nur Kommandos die auf /^13/ matchen auf den SendStack kommen
- bei einem NACK und bei einem SOF der komplette SendStack gelöscht wird.
- bei einem ACK die Nachricht auf dem SendStack verbleibt
- die Funktion ZWave_HandleSendStack die Nachricht vom SendStack entfernt. Damit sind keine Retransmits mehr möglich.
Um also die Funktionalität des SendStacks nicht zu gefährden, habe ich erstmal die etwas defensiviere Vorgehensweise über $hash->{LastMsg} gewählt.
Vielleicht sehe ich mir den SendStack noch einmal genauer an.
Hier noch ein Log mit vielen Ausgaben (mit Patch), um da Verhalten des Dongles zu verdeutlichen:
Zitat
2015.05.28 10:47:58 3: ZWDongle device opened
2015.05.28 10:47:58 1: ZWDongle_DoInit start
# ZWDongle_Clear
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer arg:Clear regexp:never matching regexp
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 63 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 010800040006028407740108000400060284077401080004000602840774010800040006028407740108000400060284077401080004000602840774010800
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL: 010800
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: timeout
# ZWDongle_Get("caps")
2015.05.28 10:47:58 1: ZWDongle_Write msg 07
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01030007fb
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer arg:caps regexp:^0107
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 8 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 06012b0107050101
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL: 012b0107050101
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 21 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 012b01070501011504000001fe83ff88cf1f0000fb9f7da067008080
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL: 012b01070501011504000001fe83ff88cf1f0000fb9f7da067008080
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 17 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 012b01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a000a
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a00
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg 01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a00
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: returning 01070501011504000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000401a00
# ZWDongle_Get("caps") war erfolgreich
# ZWDongle_Get("homeId")
2015.05.28 10:47:58 1: ZWDongle_Write msg 20
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01030020dc
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer arg:homeId regexp:^0120
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 11 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 0108000400060284077418
# hier empfangen wir eine weitere wakeup-notifications
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle: CANCEL received, retransmitting last message.
# ZWDongle_Get("homeId") wird mit CANCEL beantwortet
2015.05.28 10:47:58 1: ZWDongle_Write msg 20
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01030020dc
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 15 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 010c000400050631050422001dfb18
# hier kommt eine weitere alte Nachricht vom Dongle
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 000400050631050422001d
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle: CANCEL received, retransmitting last message.
# ZWDongle_Get("homeId") wird mit wieder CANCEL beantwortet
2015.05.28 10:47:58 1: ZWDongle_Write msg 20
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01030020dc
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 11 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 0108000400060284077418
# hier empfangen wir eine weitere wakeup-notifications
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 00040006028407
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle: CANCEL received, retransmitting last message.
# ZWDongle_Get("homeId") wird mit wieder CANCEL beantwortet
2015.05.28 10:47:58 1: ZWDongle_Write msg 20
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01030020dc
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 2 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 0601
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL: 01
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 9 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 01080120c9cde4200117
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 0120c9cde42001
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg 0120c9cde42001
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: returning 0120c9cde42001
# endlich wird ZWDongle_Get("homeId") korrekt beantwortet
2015.05.28 10:47:58 1: ZWDongle_Write msg 1c20
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 0104001c20c7
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer arg:random regexp:^011c
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 1 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 06
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 22 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 0125011c01200135e7d0ffeea745bf85a5501ed3bdc7
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL: 0125011c01200135e7d0ffeea745bf85a5501ed3bdc7
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 17 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 0125011c01200135e7d0ffeea745bf85a5501ed3bdc73c7dbbf98c657b86a307b1efbf6559cece
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 011c01200135e7d0ffeea745bf85a5501ed3bdc73c7dbbf98c657b86a307b1efbf6559ce
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg 011c01200135e7d0ffeea745bf85a5501ed3bdc73c7dbbf98c657b86a307b1efbf6559ce
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: returning 011c01200135e7d0ffeea745bf85a5501ed3bdc73c7dbbf98c657b86a307b1efbf6559ce
2015.05.28 10:47:58 1: ZWDongle_Write msg 06640f
2015.05.28 10:47:58 1: ZWDongle_Write SimpleWrite msg 01050006640f97
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer arg:Clear regexp:never matching regexp
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 1 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 06
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: read 7 bytes
2015.05.28 10:47:58 1: ZWDongle RAW buffer: 01050106640f96
2015.05.28 10:47:58 1: ZWDongle_Read ZWDongle: 0106640f
2015.05.28 10:47:58 1: ZWDongle_Parse not initialized
2015.05.28 10:47:58 1: ZWDongle_Read returning local msg undef
2015.05.28 10:47:58 1: ZWDongle_Read hash PARTIAL:
2015.05.28 10:47:58 1: ZWDongle_ReadAnswer: select
2015.05.28 10:47:59 1: ZWDongle_ReadAnswer: timeout
2015.05.28 10:47:59 1: ZWDongle_Write msg 0301020100
2015.05.28 10:47:59 1: ZWDongle_Write SimpleWrite msg 0107000301020100f9
2015.05.28 10:47:59 1: ZWDongle_DoInit end
2015.05.28 10:47:59 1: ZWDongle_Define end
Gruß,
Gero
Die Ursache des Problems ist, das man als "Abnehmer" alle Meldungen mit "ACK" bestaetigen muss. Passiert das nicht, werden die Daten erneut gesendet. Deine Aenderung der Regexp in ZWDongle_Clear sollte das Problem loesen, das habe ich eingecheckt.
Beim CANCEL die Letzte Nachricht weiderholt zu schicken ist mAn falsch, ich hatte schon deswegen eine Endlosschleife, weil ich eine Nachricht senden wollte, was der Dongle nicht akzeptieren wollte. Keine Ahnung, wieso, lag irgendwie an der Reihenfolge.
SendStack Erklaerungen: 13 ist ZW_SEND_DATA, also Nachricht an ZWave Geraet, nicht an das ZWDongle selbst. Warum es bei SOF-Fehler geloescht wird, weiss ich auch nicht mehr, vmtl. hatte ich Probleme damit. Verbleiben bei Protokoll-ACK ist mAn ok, erst ein "ZW_SEND_DATA:OK" (1300..) entfernt die Nachricht.
Zitat von: rudolfkoenig am 28 Mai 2015, 12:12:20
Die Ursache des Problems ist, das man als "Abnehmer" alle Meldungen mit "ACK" bestaetigen muss. Passiert das nicht, werden die Daten erneut gesendet. Deine Aenderung der Regexp in ZWDongle_Clear sollte das Problem loesen, das habe ich eingecheckt.
Das hat bei mir leider nicht gereicht. Das Log lief mit meinem Patch. Leider sieht man es nicht im Log, aber es werden beim Clear alle gelesenen Nachrichten mit einem ACK quittiert. Trotzdem kommen beim Versuch die homeId zu holen weitere Nachrichten aus dem Dongle. Vermutlich ist es ein Bug im Dongle. Es wäre interessant zu testen, ob sich andere Dongles anders verhalten.
Zitat von: rudolfkoenig am 28 Mai 2015, 12:12:20
Beim CANCEL die Letzte Nachricht weiderholt zu schicken ist mAn falsch, ich hatte schon deswegen eine Endlosschleife, weil ich eine Nachricht senden wollte, was der Dongle nicht akzeptieren wollte. Keine Ahnung, wieso, lag irgendwie an der Reihenfolge.
Leider habe ich bisher keine Beschreibung gefunden, wo man genau nachlesen kann, was das CANCEL bedeutet und wie darauf reagiert werden soll. Ich habe nur zwei Stellen im Internet gefunden, die auf ein erneutes Senden vom letzten Frame hinweisen.
http://www.homegenie.it/forum/index.php?topic=780.0
http://www.openremote.org/display/docs/Discover+Controller+Z-Wave+Devices
Das Wiederholen der Nachricht, war bei mir die einzige Chance irgendwann eine Antwort zu erhalten.
Hast du einen besseren Link?
openzwave antwortet übrigens auf ein CAN mit bis zu 7 Wiederholungen.
Dort findet man auch ein paar Erklärungen:
Falls man ein Kommando gesendet hat und auf ein ACK wartet, aber ein anderes Frame (SOF) kommt:
// This can happen on any normal network when a transmission overlaps an unexpected
// reception and the data in the buffer doesn't contain the ACK. The controller will
// notice and send us a CAN to retransmit.
Und falls man ein CAN empfängt:
// This is the other side of an unsolicited ACK. As mentioned there if we receive a message
// just after we transmitted one, the controller will notice and tell us to retransmit here.
// Don't increment the transmission counter as it is possible the message will never get out
// on very busy networks with lots of unsolicited messages being received. Increase the amount
// of retries but only up to a limit so we don't stay here forever.
Bei einem NACK sollte die Nachricht auch wiederholt werden (begrenzt durch eine maximale Anzahl an Retrys), da es auf einen Empfangsfehler auf der Gegenseite hinweist.
Ich werde mir das ganze nochmal genauer ansehen.
Habe deine LastMsg aenderungen doch hinzugefuegt, ergaenzt mit einem RetransmitCount (5-mal).
Ich kann das Problem zwar selbst nicht reproduzieren, aber Andreas hat vermutlich das gleiche Problem hier (http://forum.fhem.de/index.php/topic,37121.msg299204.html#msg299204).
Okay. Da bist du mir etwas zuvor gekommen. Ich habe nochmal recherchiert und mit das Z-Wave Transport Layer genauer angesehen.
Anbei ein Patch mit einigen Verbesserungen in der Low-Level-Kommunikation.
- Alle Nachrichten laufen jetzt über den sendStack
- Bei NACK und CAN gibt es Retransmits, die auf eine maximale Anzahl beschränkt sind.
- Das Auswerten von ZW_SEND_DATA:OK findet jetzt ebenfalls in der Datei 00_ZWDongle.pm statt. Damit ist der Aufruf von ZWave_HandleStack aus der 10_ZWave.pm überflüssig. Ich habe ihn aber erstmal drin gelassen und verwende in der 00_ZWDongle.pm eine andere Funktion, um keinen Patch für zwei Dateien zu liefern.
- Das Senden der nächsten Nachricht, wird jetzt schneller getriggert.
- Es wird sichergestellt, dass die Nachricht wakeupNoMoreInformation für ein Device nicht vor anderen Nachrichten auf dem sendStack stehen kann. Das führt manchmal bei einem notify auf das wakeup zu Problemen.
- Ich habe das Logging, dass ich zum Debuggen benötigt habe erstmal im Patch drin gelassen. In Zeile 24 befindet sich eine Konstante DEBUG_LL, die das Debuggen des Startups (missing homeId) vereinfacht, wenn sie auf 1 gesetzt wird.
Ich habe den Patch nach bestem Wissen und Gewissen getestet. Bei mir läuft die Kommunikation mit der mir zur Verfügung stehenden Hardware absolut fehlerfrei. Jetzt kann ich auch endlich bei einem batteriebetriebenden Gerät zig ConfigParameter auf einen Schwung abrufen und bekomme auch zuverlässig alle Antworten.
Ich bin mir bewußt, dass der Patch ziemlich viele und weitgehende Änderungen beinhaltet. Aber ich wollte ihn dir trotzdem nicht vorenthalten.
Mein Vorschlag wäre einige freiwillige Tester zu suchen, bevor der Patch offiziell ins SVN geht.
Gruß,
Gero
P.S.: Das Auftreten von CANCEL Nachrichten ist übrigens normal. Es gibt Nachrichten, bei denen nach dem SEND_DATA:OK noch eine unsolicited Message mit dem eigentlich angefragten Wert kommt (z.B. get battery). Wenn nach solchen Nachrichten direkt nach SEND_DATA:OK die nächste Nachricht gesendet wird, wird diese mit CANCEL neu angefordert, da zuerst die unsolicited Message verarbeitet werden mußte. Trotzdem ist das Senden der nächsten Nachricht nach SEND_DATA:OK eine übliche Praxis. Nur bei openzwave habe ich eine komplexere Lösung gefunden. Dort gibt es quasi für jeden Befehl gewisse Merkmale für die zu erwartende Antwort, die vor dem Versenden des nächsten Befehls abgewartet wird. Allerdings halte ich diese Vorgehensweise für etwas übertrieben und für schwer pflegbar.
- ueblicherweise nehme ich so viele Aenderungen auf einmal nicht an: wenn moeglich, mir sowas in Haeppchen fuettern.
- wenn moeglich, beim Patch auf die Zeilenbreite von 80 Zeichen achten.
- DEBUG_LL kann man einfacher mit "attr ZWDongle verbose 5" realisieren, fuers debuggen beim Starten braucht man aber doch attr global verbose 5.
- habe first_index aus sentimentalen Gruenden entfernt (List::MoreUtils gibts nicht auf dem FB7270-er Perl).
- der Timeout von 1 Sekunde in Clear ist mir zu lang. Muss das sein?
- ich habe in ZWave_ProcessSendStack nach dem ersten InternalTimer ein return eingebaut.
- warum ist MaxSendRetries variabel? Reicht 3 als Festwert nicht?
- warum pruefst du unter "application messages are removed" nicht auf 01....13 sondern auf ......13?
- warum wird beim NACK ein resend durchgefuehrt?
- habe die DEBUG Konstanten entfernt, einige debug messages auch, andere umformuliert.
- habe selbst getestet, und eingecheckt.
Hallo,
heute morgen neu nach dem Update:2015.05.31 09:07:36 2: SERIAL_API_SET_TIMEOUTS: ACK:64 BYTES:0f
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
Ich habe heute nicht so viel Zeit. Die Familie will beschäftigt werden. Aber trotzdem kurz ein paar Antworten:
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- ueblicherweise nehme ich so viele Aenderungen auf einmal nicht an: wenn moeglich, mir sowas in Haeppchen fuettern.
Kann ich verstehen. Aber in soviele Häppchen konnte ich den Patch nicht teilen.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- wenn moeglich, beim Patch auf die Zeilenbreite von 80 Zeichen achten.
Werde ich die nächsten Male drauf achten.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- DEBUG_LL kann man einfacher mit "attr ZWDongle verbose 5" realisieren, fuers debuggen beim Starten braucht man aber doch attr global verbose 5.
Ist okay. Wenn ich ein spezielles Problem beim Startup debugge, sind mir die Ausgaben mit attr global verbose 5 meist zu viel. Daher beschränke ich so etwas gerne auf ein Modul.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- habe first_index aus sentimentalen Gruenden entfernt (List::MoreUtils gibts nicht auf dem FB7270-er Perl).
Okay
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- der Timeout von 1 Sekunde in Clear ist mir zu lang. Muss das sein?
Bei meinem Dongle wird bei einem Timeout von 0.3 Sekunden beim Clear häufiger nichts gelesen, obwohl Daten anliegen.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- ich habe in ZWave_ProcessSendStack nach dem ersten InternalTimer ein return eingebaut.
Sollte okay sein. Ich werde es mir morgen nochmal genau ansehen.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- warum ist MaxSendRetries variabel? Reicht 3 als Festwert nicht?
Das ist ein bisschen von einem anderen Code inspiriert worden. Dadurch dürfen mehr CAN als NACK Nachrichten auftreten. 3 CAN Nachrichten habe ich gerade beim Startup schon häufiger gesehen.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- warum pruefst du unter "application messages are removed" nicht auf 01....13 sondern auf ......13?
Muß ich mir nochmal genauer ansehen.
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- warum wird beim NACK ein resend durchgefuehrt?
Ein NACK ist ein Anzeichen dafür, dass die Gegenseite eine Nachricht nicht korrekt empfangen hat (z.B. Checksum-Error oder SOF-Error). In solchen Fällen sollte die Nachricht wiederholt werden.
Gruß,
Gero
Zitat von: det. am 31 Mai 2015, 12:08:43
Hallo,
heute morgen neu nach dem Update:2015.05.31 09:07:36 2: SERIAL_API_SET_TIMEOUTS: ACK:64 BYTES:0f
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
Mit welcher Version genau? Aus dem SVN oder per fhem update?
Der Fehler dürfte mit der aktuellen Version nicht mehr auftreten, da die Nachrichten erst Dispatched werden, nachdem der Dongle auf initialized steht.
Gruß,
Gero
Hallo Gero,
mit der Version aus dem heutigen Update von kurz nach 9 Uhr. Werde mal die neue Version aus dem SVN testen. ...meine Familie ist schon groß und aus dem Hause...
Hallo Gero,
Zitat von: gero am 07 Mai 2015, 12:02:12
Mir ist aufgefallen, dass der Dongle im Auslieferungszustand schon 3 mir unbekannte Geräte in der nodeList hatte (alles BINARY_SWITCHES). Jetzt habe ich gestern alles nochmal neu aufgesetzt, die drei unbekannten Geräte aus dem Dongle entfernt und nochmal alles neu inkludiert und assoziiert.
ich habe einen ZWave.me UZB und habe auch 2 unbekannte bzw. nicht vorhandenen Geräte in der Nodelist. Wie hast Du die denn aus der Liste rausbekommen?
Ein set removefailednode funktioniert(e) bei mir nicht. Um das noch mal zu bestätigen habe ich es während des Schreibens hier noch mal probiert und bei einem Gerät hat es funktioniert, das andere ist immer noch drin und lässt sich nicht entfernen.
Hier mal das Log für das get nodelist und das set removefailed node 3
2015.05.31 14:22:00.427 5: ZWDongle_Write msg 02
2015.05.31 14:22:00.427 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.05.31 14:22:00.427 5: ZWave_ProcessSendStack: sending msg 01030002fe
2015.05.31 14:22:00.427 5: SW: 01030002fe
2015.05.31 14:22:00.428 4: ZWDongle_ReadAnswer arg:nodeList regexp:^0102
2015.05.31 14:22:00.568 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.568 5: ZWDongle RAW buffer: 06
2015.05.31 14:22:00.568 5: ZWDongle_0: ACK received
2015.05.31 14:22:00.568 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:00.568 5: ZWDongle_Read returning local msg undef hash PARTIAL:
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 2 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 0125
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 4 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 012501020500
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 012501020500
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 0125010205001d
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d
2015.05.31 14:22:00.660 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.660 5: ZWDongle RAW buffer: 0125010205001d05
2015.05.31 14:22:00.660 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05
2015.05.31 14:22:00.664 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.664 5: ZWDongle RAW buffer: 0125010205001d0500
2015.05.31 14:22:00.665 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d0500
2015.05.31 14:22:00.667 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.667 5: ZWDongle RAW buffer: 0125010205001d050000
2015.05.31 14:22:00.667 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000
2015.05.31 14:22:00.669 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.669 5: ZWDongle RAW buffer: 0125010205001d05000000
2015.05.31 14:22:00.669 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05000000
2015.05.31 14:22:00.672 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.672 5: ZWDongle RAW buffer: 0125010205001d0500000000
2015.05.31 14:22:00.672 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d0500000000
2015.05.31 14:22:00.676 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.676 5: ZWDongle RAW buffer: 0125010205001d050000000000
2015.05.31 14:22:00.677 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000000000
2015.05.31 14:22:00.680 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.680 5: ZWDongle RAW buffer: 0125010205001d05000000000000
2015.05.31 14:22:00.680 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05000000000000
2015.05.31 14:22:00.687 5: ZWDongle_ReadAnswer: read 2 bytes
2015.05.31 14:22:00.687 5: ZWDongle RAW buffer: 0125010205001d050000000000000000
2015.05.31 14:22:00.687 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000000000000000
2015.05.31 14:22:00.690 5: ZWDongle_ReadAnswer: read 23 bytes
2015.05.31 14:22:00.690 5: ZWDongle RAW buffer: 0125010205001d05000000000000000000000000000000000000000000000000000000000500c1
2015.05.31 14:22:00.690 5: ZWDongle_Read -> sending ACK
2015.05.31 14:22:00.690 5: SW: 06
2015.05.31 14:22:00.691 5: ZWDongle_Read ZWDongle_0: processing 010205001d05000000000000000000000000000000000000000000000000000000000500
2015.05.31 14:22:00.691 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:00.692 5: ZWDongle_Read returning local msg 010205001d05000000000000000000000000000000000000000000000000000000000500 hash PARTIAL:
2015.05.31 14:22:00.692 5: ZWDongle_ReadAnswer: returning 010205001d05000000000000000000000000000000000000000000000000000000000500
2015.05.31 14:22:11.365 5: ZWDongle_Write msg 6103
2015.05.31 14:22:11.365 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.05.31 14:22:11.365 5: ZWave_ProcessSendStack: sending msg 010400610399
2015.05.31 14:22:11.365 5: SW: 010400610399
2015.05.31 14:22:11.747 5: ZWDongle RAW buffer: 06
2015.05.31 14:22:11.747 5: ZWDongle_0: ACK received
2015.05.31 14:22:11.747 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:11.836 5: ZWDongle RAW buffer: 01
2015.05.31 14:22:11.837 5: ZWDongle RAW buffer: 0104
2015.05.31 14:22:11.840 5: ZWDongle RAW buffer: 010401
2015.05.31 14:22:11.841 5: ZWDongle RAW buffer: 01040161
2015.05.31 14:22:11.842 5: ZWDongle RAW buffer: 0104016108
2015.05.31 14:22:11.844 5: ZWDongle RAW buffer: 010401610893
2015.05.31 14:22:11.845 5: ZWDongle_Read -> sending ACK
2015.05.31 14:22:11.845 5: SW: 06
2015.05.31 14:22:11.846 5: ZWDongle_Read ZWDongle_0: processing 016108
2015.05.31 14:22:11.846 5: ZWDongle_0 dispatch 016108
2015.05.31 14:22:11.846 4: ZWDongle_0 unhandled ANSWER: ZW_REMOVE_FAILED_NODE_ID 08
2015.05.31 14:22:11.846 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
Das kommt eine 08 als Antwort auf das Exclude, das ist (bisher) nicht definiert und unbekannt. Habe das auch im OpenZWave Code bisher nicht gefunden...
Gruß,
Andreas.
@Andreas:
Kennst Du den Beitrag: http://forum.fhem.de/index.php/topic,32823.msg292626.html#msg292626
->Du kannst nur löschen, wenn der Node in der failedNodeList steht. Bei wakeup-Geräten enstprechend markieren bzw bei netzbetriebenen ein Befehl hinschicken. Dann sollten die Geräte in der failedNodeList stehen und Du kannst löschen.
Wenn es Dein Test- und Spielcontroller ist, dann kannst du den Controller auch mit ZW_SetDefault reseten; aber Folgen beachten (siehe INS11095-2).
Zitat von: det. am 31 Mai 2015, 13:59:52
Werde mal die neue Version aus dem SVN testen.
getan, alles prima - keinerlei Fehlermeldungen mehr! Danke!
Hallo Christian,
Zitat von: krikan am 31 Mai 2015, 14:46:18
@Andreas:
Kennst Du den Beitrag: http://forum.fhem.de/index.php/topic,32823.msg292626.html#msg292626
->Du kannst nur löschen, wenn der Node in der failedNodeList steht. Bei wakeup-Geräten enstprechend markieren bzw bei netzbetriebenen ein Befehl hinschicken. Dann sollten die Geräte in der failedNodeList stehen und Du kannst löschen.
hat funktioniert, danke für den Hinweis. Nach der Prozedur liess sich dann auch die zweite Node entfernen.
Zitat von: krikan am 31 Mai 2015, 14:46:18
Wenn es Dein Test- und Spielcontroller ist, dann kannst du den Controller auch mit ZW_SetDefault reseten; aber Folgen beachten (siehe INS11095-2).
Auch hier Danke für den Hinweis auf das Dokument, kannst Du evtl. kurz erläutern was das für Folgen hätte, ich habe das zwar nicht vor und das Dokument hat immerhin >300 Seiten, das wollte ich jetzt erst mal noch nicht lesen ,-)
Danke,
Andreas.
Zitat von: A.Harrenberg am 31 Mai 2015, 15:35:44
>300 Seiten, das wollte ich jetzt erst mal noch nicht lesen ,-)
Brauchst nicht alles lesen, sondern nur die Seite zu ZW_SetDefault. Kurz: Werksreset des Controllers mit dem "Verlust" von allen Nodes, HomeId, Routen, usw. Inkludierte Geräte müssen ebenfalls resetet werden. Für Testzwecke meiner Meinung nach ganz praktisch.
Hi,
ok, Danke,
da an meinem Testsytem (nachdem die zwei unbekannten Einträge ja nun weg sind) nur die Sirene dran hängt sollte es hoffentlich auch ohne den Reset gehen.
Gruß,
Andreas.
@Rudi,
hier noch wie versprochen die Antwort auf die noch offene Frage:
Zitat von: rudolfkoenig am 31 Mai 2015, 12:04:44
- warum pruefst du unter "application messages are removed" nicht auf 01....13 sondern auf ......13?
Natürlich ist die Überprüfung auf 01....13 auch okay, da auf dem sendStack nur Nachrichten mit einem gültigen SOF liegen.
Was mir noch aufgefallen ist:
Das Umsortieren des sendStacks könnte (sollte) noch etwas verbessert werden. Du hast die Überprüfung auf die nodeId entfernt.
Falls jetzt zwei batteriebetriebene Devices gleichzeitig aufwachen, entfernst du alle wakeupNoMoreInformation Messages vom sendStack, fügst aber nur die letzte wieder hinzu.
Zusätzlich sollte die wNMI Nachricht nicht umsortiert werden, wenn sie an erster Stelle im sendStack steht, da sie evtl. schon versendet wurde (der Fehler ist in meinem Patch auch vorhanden).
Das Auftreten dieser Probleme ist zwar sehr unwahrscheinlich, aber sollten meiner Meinung nach trotzdem gefixt werden.
Gruß,
Gero
Die nodeId Pruefung ist mAn ueberfluessig, da $hash->{SendStack} nodeId spezifisch ist.
Mit der ersten Stelle hast du Recht, hab was eingebaut, aber nicht getestet. Koenntest du es bitte pruefen?
Überprüft, getestet und für gut befunden.
Danke!