Hallo zusammen,
ist es möglich ein ZWave-Node manuell zu löschen , d.h. nicht über die "Ablern"-Funktion (Exclusion)?
Hintergrund: Durch versehentliches Resetten eines Devices wurde die Inclusion desselben gelöscht und das Devcie lässt sich nicht mehr am Stick austragen :(
Gruß Lars
Hallo Lars,
ich beschäftige mich auch erst seit kurzem mit dem ZWave Thema. Hier bin ich noch in der Testphase, um zu verstehen wie das ganze funktioniert. In diesem Zusammenhang habe ich mir auch andere SW angesehen.
Zusammengefasst habe ich auch bei anderen SW-Lösungen keine derartige Funktion gesehen. Entweder Du hast die devices sauber abgelernt oder Dir bleibt nur der Weg des factory resets. Dazu benötigst Du aber eben eine solche Alternativ-SW, da das Serial API eine derartige Funktion nicht liefert.
Seitens AEON Labs wird entsprechend darauf referenziert:
ZitatFactory reset on the Z-Stick: This must be done
through the host software which takes control
of the Z-Stick USB adapter while the Z-Stick is in
SerialAPI-Mode. Please consult the instruction
manual of the host software to perform a
network reset (i.e. factory reset on the Z-Stick).
This function can only be preformed via the
host software.
ciao walter
Hat jemand diese sagenumwobene SerialApi und kann nachsehen ob es dort eine Funktion zum (manuellen) entfernen eines Nodes gibt?
Ich habe eigentlich herzlich wenig Lust durchs ganze Haus zu rennen um alle Nodes wieder anzulernen :(
Hallo
Mit der freeware Z-Tool von Homeseer kannst du Nodes aus den Stick entfernen.
Hab ich selber schon getestet.Die Software ist sehr simpel.
vg
Florian
Hallo Florian,
eben bei HomeSeer http://store.homeseer.com/store/HomeSeer-Z-Tool-Z-Wave-Setup-Software-P483.aspx (http://store.homeseer.com/store/HomeSeer-Z-Tool-Z-Wave-Setup-Software-P483.aspx) gekuckt - kostet $29.95.
Oder ist das die falsche SW?
ciao walter
Versuch mal folgendes in FHEM/00_ZWDongle/%sets unter createNode einzufuegen:
"removeFailedNodeId" => { cmd => "61%02x" }, #ZW_REMOVE_FAILED_NODE_ID
und dann melden, ob es tut.
Findet man aber auch kostenfrei.
http://ztool.software.informer.com/1.0/
Vg Florian
Zitat von: rudolfkoenig am 26 Januar 2015, 17:33:14
Versuch mal folgendes in FHEM/00_ZWDongle/%sets unter createNode einzufuegen:
"removeFailedNodeId" => { cmd => "61%02x" }, #ZW_REMOVE_FAILED_NODE_ID
und dann melden, ob es tut.
Ich tu' einfach 'mal. :)
Leider kein Erfolg (zumindest bei meinem ZME_UZB1:
- Zeile eingefügt, 00_ZWDongle.pm gespeichert
- reload 00_ZWDongle.pm
- set ZW_Dongle removeFailedNodeId 2 (aus UI, also 00_ZWDongle.pm richtig geladen)
- get ZW_Dongle nodelist ergibt:
ZW_Dongle nodeList => 1,2,4,5,8 Einträge im Logfile (verbose 5):
2015.01.26 18:00:02 5: SW: 010400610298
2015.01.26 18:00:02 5: ZWDongle/RAW: /06010401610893
2015.01.26 18:00:02 5: SW: 06
2015.01.26 18:00:02 5: ZWDongle_Read ZW_Dongle: 016108
2015.01.26 18:00:02 5: ZW_Dongle dispatch 016108
2015.01.26 18:00:02 4: ZW_Dongle: unhandled ANSWER: ZW_REMOVE_FAILED_NODE_ID 08Viele Grüße,
Andreas
PS:
List des ZW_Dongle (wobei ich gerne die Nodes 2,4,5 entfernt haben würde):
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 52
NAME ZW_Dongle
NR 372
PARTIAL
RAWMSG 016108
ReadTime 1422291983.08744
STATE Initialized
TYPE ZWDongle
ZW_Dongle_MSGCNT 10
ZW_Dongle_TIME 2015-01-26 18:06:09
homeId d79c8805
nrNAck 0
Matchlist:
1:ZWave .*
Readings:
2015-01-26 14:34:18 homeId HomeId:d79c8805 CtrlNodeId:01
2015-01-24 00:33:52 neighborList_1 2,8
2015-01-23 23:41:46 nodeInfo_1 STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
2015-01-23 23:41:05 nodeInfo_2 SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:3 Security:0
2015-01-23 23:41:15 nodeInfo_4 ROUTING_SLAVE THERMOSTAT sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-01-23 23:41:23 nodeInfo_5 ROUTING_SLAVE THERMOSTAT sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-01-24 00:34:07 nodeInfo_8 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-01-26 18:06:23 nodeList 1,2,4,5,8
2015-01-26 14:34:17 state opened
2015-01-23 23:30:04 version Z-Wave 3.99 STATIC_CONTROLLER
SendStack:
Attributes:
group IO_Devs
icon cul_usb
room Global,ZWave
scooty war schneller :o
Kann aber sein Ergebnis bestätigen.
Soll laut Doku erst auf eine failedList gesetzt werden, und erst wenn das Geraet nicht antwortet, geloescht werden.
Was auch immer das im Detail wieder heisst.
Zitat von: rudolfkoenig am 26 Januar 2015, 18:36:28
Soll laut Doku erst auf eine failedList gesetzt werden, und erst wenn das Geraet nicht antwortet, geloescht werden.
Was auch immer das im Detail wieder heisst.
Theoretisch laut Openzwave:
- Dauernd empfangsbereite Geräte können nicht eigenständig in die failedList verschoben werden. Sie werden ausschließlich automatisch in die failedList verschoben, wenn die Kommunikation mehrfach (?) fehlschlägt und können dann manuell gelöscht werden. Achtung jedes empfangene Funktelegramm des Gerätes verschiebt es sofort wieder aus der failedList weg.
- Batteriebetriebene Geräte können eigenständig in die failedList verschoben und manuell gelöscht werden. (bei openzwave nach meinem User-Verständnis in driver.cpp/driver.h umgesetzt->ControllerCommand_RemoveFailedNode )
Mit meinem Aeon Labs Z-Wave Node konnte ich mein Device löschen, das war allerdings auch ein batteriebetriebenes Device. Von daher schonmal vielen Dank für den Tipp. Leider unterstützt das Tool in der kostenlosen Version nur 5 Devices.
Hallo,
folgend ein Tool das ich gefunden habe. Lt Lizenztext frei benutzbar.
http://www.ip-symcon.de/forum/attachment.php?attachmentid=21753&d=1373548171 (http://www.ip-symcon.de/forum/attachment.php?attachmentid=21753&d=1373548171)
Edit: Man kann sich da die gesendeten und empfangenen Pakete ansehen. Evtl hilft das beim Programmieren.
ciao walter
Hallo Rudolf,
arbeiten wir hier weiter? Zumindest die Umsetzung der Funktionen
'61' => 'ZW_REMOVE_FAILED_NODE_ID',
'62' => 'ZW_IS_FAILED_NODE',
'63' => 'ZW_REPLACE_FAILED_NODE',
fände ich sinnvoll.
Danke und ciao
walter
Hab die Befehle hinzugefuegt, aber nicht getestet. Ihr koennt sowas gerne selbst vorher testen, und mir fertige Patches schicken, wie man sieht, ist die Erweiterung kein Hexenwerk.
@wkarl
Hast Du einen Link, wo ich die Bedeutung Deiner vorgeschlagenen und von Rudi eingebauten Ergänzungen nachschauen kann. Die Rückgabe vom isFailedNode verstehe ich nicht. Mir fehlen aber auch die Testobjekte. Danke.
@krikan: den code habe ich aus 00_ZWDongle.pm. Habe auch gegoogelt, ob ich dazu Spezifikas finde, aber ohne konkreten Erfolg.
@rudi: habe die zitierten Funktionen schon letzte Woche mal eingebaut und getestet. Leider hatte ich wenig Erfolg. Sehe eben Du hast es eingepflegt, werde es gleich mal testen.
ciao walter
@rudi: habe die Aktoren auf isFailedNode getestet
Das Ergebnis:
isFailedNode_2 016200
isFailedNode_3 016201
Node-ID 2 ist die aktive Stechdose und Node-ID 3 der inaktiver Schalter. Das wird dann in den Readings eingetragen, finde ich etwas unschön. Mir genügt die Information, wenn ich ein Gerät abfrage, den entsprechenden Status zu bekommen.
Was aus meiner Sicht evtl sinnvoll wäre, die Abfrage periodisch gegen alle Geräte laufen zu lassen und dann ähnlich wie nodeList die inaktiven Geräte zu zeigen.
removeFailedNode funktioniert auch.
ciao walter
habe es gestern mal mit den neuen Befehlen probiert, leider erfolglos... bestimmt gibt es eine Sequenz, die man einhalten muss.
Mit dem ZTool ging es dann aber problemlos.
Ich hatte bei meinem ZME_UZB1 Dongle im Auslieferungszustand schon drei mir unbekannte Knoten in der nodeList, die ich natürlich loswerden wollte.
Diese habe ich erfolgreich über folgende Prozedur entfernen können (hier am Beispiel von Knoten 2):
get ZWDongle isFailedNode 2
danach gibt es unter den Readings des ZWDongles folgenden Eintrag:
isFailedNode_2 016200
erst nach einem
set ZWDongle sendNIF 2
wechselt das Reading auf
isFailedNode_2 016201
Erst danach kann der Knoten
set ZWDongle removeFaildNode 2
entfernt werden.
Gruß,
Gero
Ich bin mir nicht sicher ob das einen neuen Thread wert ist...
Ich habe auch einen ZME_UZB1 neu erstanden. Dieser hatte allerdings bereits zwei Nodes included (Binary Switch nach meiner Erinnerung).
Ich bin nach der Anleitung #18 vorgegangen. Habe dann erst einen Devolo Zwischenstecker hinzugefügt, der dann als ID 4 bekommen hat. Ich hatte die Prozedur dann noch mal durchgeführt, ohne Erfolg.
Ich bezeichne mich jetzt mal "Anfänger". Ich werde die beiden blockierten IDs überleben, bin mir aber nicht sicher ob das irgendwelche Seiteneffekte hat (z.B. erhöhte Funklast)?
Da es die gewünschten Befehle im Z-Wave Wiki nicht gibt zwei get Befehle mit Verbose 5:
2015.09.15 21:04:21 5: zw.dongle dispatch 000400040e320221340000034b000000000000
2015.09.15 21:04:21 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0e320221340000034b000000000000
2015.09.15 21:04:38 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400040e320221340000028b000000000000
2015.09.15 21:04:38 5: SW: 06
2015.09.15 21:04:38 5: zw.dongle dispatch 000400040e320221340000028b000000000000
2015.09.15 21:04:38 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0e320221340000028b000000000000
2015.09.15 21:04:41 4: ZWDongle get zw.dongle nodeList
2015.09.15 21:04:41 5: ZWDongle_Write 00 02
2015.09.15 21:04:41 5: SW: 01030002fe
2015.09.15 21:04:41 4: ZWDongle_ReadAnswer arg:nodeList regexp:^0102
2015.09.15 21:04:41 5: ACK received, removing 01030002fe from dongle sendstack
2015.09.15 21:04:41 4: ZWDongle_Read zw.dongle: sending ACK, processing 010205001d09000000000000000000000000000000000000000000000000000000000500
2015.09.15 21:04:41 5: SW: 06
2015.09.15 21:04:41 4: ZWDongle_ReadAnswer for nodeList: 010205001d09000000000000000000000000000000000000000000000000000000000500
2015.09.15 21:04:41 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400040e3202213400000415000000000000
2015.09.15 21:04:41 5: SW: 06
2015.09.15 21:04:41 5: zw.dongle dispatch 000400040e3202213400000415000000000000
2015.09.15 21:04:41 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0e3202213400000415000000000000
2015.09.15 21:04:41 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400040e3202213400000415000000000000
2015.09.15 21:04:41 5: SW: 06
2015.09.15 21:04:41 5: zw.dongle dispatch 000400040e3202213400000415000000000000
2015.09.15 21:04:41 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0e3202213400000415000000000000
2015.09.15 21:06:35 4: ZWDongle get zw.dongle nodeInfo 2
2015.09.15 21:06:35 5: ZWDongle_Write 00 4102
2015.09.15 21:06:35 5: SW: 0104004102b8
2015.09.15 21:06:35 4: ZWDongle_ReadAnswer arg:nodeInfo regexp:^0141
2015.09.15 21:06:35 5: ACK received, removing 0104004102b8 from dongle sendstack
2015.09.15 21:06:35 4: ZWDongle_Read zw.dongle: sending ACK, processing 0141000000030000
2015.09.15 21:06:35 5: SW: 06
2015.09.15 21:06:35 4: ZWDongle_ReadAnswer for nodeInfo: 0141000000030000
2015.09.15 21:06:41 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400040e3202213400000405000000000000
2015.09.15 21:06:41 5: SW: 06
2015.09.15 21:06:41 5: zw.dongle dispatch 000400040e3202213400000405000000000000
2015.09.15 21:06:41 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0e3202213400000405000000000000
Ein list <device> ergibt:
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/ttyACM0@115200
DeviceName /dev/ttyACM0@115200
FD 20
MaxSendRetries 3
NAME zw.dongle
NR 58
PARTIAL
RAWMSG 000400040e32022134000003a1000000000000
ReadTime 1442344074.15793
STATE Initialized
SendRetries 0
SendTime 1442343995.80541
TYPE ZWDongle
WaitForAck 0
homeId d45fed61
nrNAck 0
zw.dongle_MSGCNT 578
zw.dongle_TIME 2015-09-15 21:07:54
Matchlist:
1:ZWave .*
Readings:
2015-09-15 21:06:00 caps Vers:5 Rev:1 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
2015-09-02 22:22:09 ctrlCaps PRIMARY
2015-09-15 19:36:43 homeId HomeId:d45fed61 CtrlNodeId:01
2015-09-07 22:26:54 isFailedNode_2 016201
2015-09-07 22:32:12 isFailedNode_3 016201
2015-09-05 17:30:19 neighborList_1 4
2015-09-05 17:30:04 neighborList_4 0
2015-09-06 17:04:12 nodeInfo_1 STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
2015-09-15 21:06:35 nodeInfo_2 node 2 is not present
2015-09-02 22:45:10 nodeInfo_3 node 3 is not present
2015-09-05 17:29:11 nodeInfo_4 ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
2015-09-15 21:04:41 nodeList 1,4
2015-09-15 19:36:43 random 5b02c4f24c905f3e0de04d015bd7bb7e5c406eb5846fd1a31986e514f9bdef0a
2015-09-15 19:36:43 state Initialized
2015-09-15 19:45:47 timeouts 0106640f
SendStack:
Attributes:
alias Z-Wave Controller
group Controllers
icon it_wireless_dcf77
room Infrastruktur
verbose 5
Zitat von: Buwe am 15 September 2015, 21:31:09
Ich werde die beiden blockierten IDs überleben, bin mir aber nicht sicher ob das irgendwelche Seiteneffekte hat (z.B. erhöhte Funklast)?
Das NodeIDs weiter hochgezählt werden, auch wenn Nodes ordnungsgemäß exkludiert bzw. mit removeFailedNode entfernt wurden, ist normaler ZWave-Standard. Nebeneffekte dürfte es nicht geben. Neues Hochzählen der NodeIDs ab 1 bzw. 2 kann man mMn nur durch einen nicht notwenidgen Controllerreset erreichen.
ZitatDa es die gewünschten Befehle im Z-Wave Wiki nicht gibt zwei get Befehle mit Verbose 5:
Danke fürs Lesen der heutigen Wiki-Änderung :). Die dort angegeben Befehle sind hier aber grds. nicht notwendig, da zwave-endgerätespezifisch.
Hallo,
ich habe jetzt seit gestern 3 verschiedene devices nach folgenden Schema ohne Probleme gelöscht.
1. set ZWDongle_Raz removeNode nwOn
2. get ZWDongle_Raz isFailedNode <defekt Nr> hier 33
- Ausgabe:ZWDongle_Raz isFailedNode_33 => 016200
3. get ZWDongle_Raz nodeList
4. set ZWDongle_Raz removeFailedNode <defekt Nr>
5. get ZWDongle_Raz nodeList
6. deletereading ZWDongle_Raz isFailedNode_33 und eventuell noch andere readings dieses device löschen und zum Schluss
7. set ZWDongle_Raz removeNode off
Bei einem device stand das reading dann auf 016201. ?
Ich glaube dass das "get ZWDongle_Raz nodeList" nicht unwichtig ist oder auch wie schon erwähnt ein sendNIF zu dem nicht mehr existierenden device abzusetzen. Vielleicht mus man den ZWDongle mit irgendeinem Befehl wachrütteln?
Und falls bis jetzt noch nicht getan das device aus fhem mit "delete <devicename>" löschen.
Vielleicht gehts auch einfacher. Aber das waren wirkliche Leichen und ich konnte sie so alle sauber entfernen.
Und hier meine schöne saubere Nodelist:
ZWDongle_Raz nodeList => 1,7,8,9,24,28,30,31,34,35,36,38,40,41,42,43,44,45
Eine AEOTEC Siren ist gerade dazugekommen.
Grüße,
Josef
Anliegend Patch für isFailedNode und removeFailedNode mit Klartextevents, so dass evtl. eine bessere Verständlichkeit gegeben ist.
@all
removeFailedNode sollte nur genutzt werden, wenn eine normale Exklusion nicht möglich ist. removeFailedNode funktioniert nur, wenn der Node auf der failedNodeList steht. Dorthin gelangt der Node vereinfacht nur, wenn er zuletzt nicht erreicht wurde. Prüfung, ob der Node auf der failedNodeList steht, erfolgt durch isFailedNode (besser wäre mMn isFailedNodeList).
@Rudi:
Habe zwar keine Probleme mit dem Patch festgestellt, aber bitte kontrolliere -> hoffe habe keine Folgewirkung übersehen. Eine Mini-Dokukorrektur zu CC Color Control habe ich noch mit eingebaut.
Habs unveraendert eingecheckt.
Hallo zusammen,
die Anleitung funktioniert bei mir nicht. Ich habe ebenso einen ZME_UZB1, allerdings heißen die fehlerhaften Knoten Unknown_X.
isFailedNode_UNKNOWN_2 yes
isFailedNode__UNKNOWN_2 yes
nodeList
ZWDongle UNKNOWN_2 UNKNOWN_3 RM_WZ RM_SZ RM_FL
Wenn ich das nach den oben genannten Schritten durchspiele erhalte ich im LOG folgende Meldung.
PERL WARNING: Argument "UNKNOWN_2" isn't numeric in sprintf at ./FHEM/00_ZWDongle.pm line 316.
Hat jemand ne Idee wie ich die Knoten wieder los werde?
Wie man aktuell vorgehen muss, steht hier: http://www.fhemwiki.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F
@MaDDin78: Als Argument für "removeFailedNode" musst Du die NodeID nehmen; d.h. Zahl ohne UNKOWN_ davor.
Die Anleitung hatte ich auch schon getestet, tut sich nix, :-(
Zitat von: MaDDin78 am 21 November 2015, 21:39:16
Die Anleitung hatte ich auch schon getestet, tut sich nix, :-(
Hast Du denn immer nur die NodeID genommen? Auch bei isFailedNode (hiernach nicht: isFailedNode_UNKNOWN_2)?
Was sagt das Log?
Ja, selbst mit 2 / 3 tut sich da nix, Im Event Log habe ich beim Abschicken folgende Meldung.
2015-11-21 21:54:09 ZWDongle ZWDongle replaceFailedNode 3
2015-11-21 21:54:09 ZWDongle ZWDongle ZW_REPLACE_FAILED_NODE failedNodeRemoveProcessBusy
OK, Prozeß hängt. Bitte ZWDongle kurz stromlos machen und dann von vorne.
Bitte immer erst neue removeFailedNode-Befehle absetzen, wenn der vorherige removeFailedNode-Befehl abgeschlossen ist.
oh yes, hab den Raspi vorher zig mal neu gestartet aber scheinbar ohne Erfolg.
Dank Dir, jetzt ist dieser Schönheitsfehler auch weg!
Zitat von: rudolfkoenig am 26 Januar 2015, 17:33:14
Versuch mal folgendes in FHEM/00_ZWDongle/%sets unter createNode einzufuegen:
"removeFailedNodeId" => { cmd => "61%02x" }, #ZW_REMOVE_FAILED_NODE_ID
und dann melden, ob es tut.
Sind diese Befehle nicht mittlerweile in FHEM eingebaut? Ich finde sie, aber sie tun leider nicht.
Zitat von: tom44 am 03 Dezember 2015, 21:46:19
Sind diese Befehle nicht mittlerweile in FHEM eingebaut? Ich finde sie, aber sie tun leider nicht.
Ja, sind sie. Du solltest so vorgehen: http://www.fhemwiki.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F
Wenn das nicht funktioniert, müsstest Du bitte genauer darlegen, was es nicht tut.
Gruß, Christian
Danke für die schnelle Antwort. Die Befehle zum löschen der nodes haben einfach keine Wirkung.
Ich habe alle Nodes abgefragt, ob sie failed sind oder nicht und wollte diese dann löschen, alles ohne Wirkung.
In den Readings werden mir auch alle Nodes angezeigt, wie
isFailedNode_2 yes
In der Node-List habe ich auch alte, die ich ebenfalls nicht löschen kann.
UNKNOWN_2 stecker UNKNOWN_4 dimmer sensor
Was steht denn im Log beim Aufruf von "removeFailedNode"?
Nichts! Das ist es ja.
Um zu testen, ob der Befehl überhaupt versucht wird auszuführen, habe ich statt der Node Nummer (in meinem Fall ist das die Nr. 2) qqqq eingegeben. Da bekomme ich dann - zurecht - folgende Warnung:
2015.12.04 07:16:27 1: PERL WARNING: Argument "qqqq" isn't numeric in sprintf at ./FHEM/00_ZWDongle.pm line 317.
Gebe ich aber 2 ein, passiert nichts.
ZitatNichts! Das ist es ja.
Verstehe ich leider nicht. Wenn Du bitte mal verbose 5 beim ZWDongle setzt und dann den Befehl ausführst, muss irgendetwas im FHEM-Logfile stehen. Das wäre evtl. hilfreich.
Beacht auch, dass keine Rückmeldung über die Benutzeroberfläche oder Readings erfolgt. Es werden ausschließlich Events generiert, die man in einem (gleichzeitig geöffneten) EventMonitor verfolgen kann oder eben nachträglich im Log sieht.
Hast Du das ZWDongle zur Sicherheit mal kurz stromlos gemacht?
2015.12.04 07:30:48 4: ZWDongle set ZWAVE1 removeFailedNode 2
2015.12.04 07:30:48 5: ZWDongle_Write 00 610207
2015.12.04 07:30:48 5: SW: 0105006102079e
2015.12.04 07:30:48 5: ACK received, removing 0105006102079e from dongle sendstack
2015.12.04 07:30:48 4: ZWDongle_Read ZWAVE1: sending ACK, processing 016100
2015.12.04 07:30:48 5: SW: 06
2015.12.04 07:30:48 5: ZWAVE1 dispatch 016100
2015.12.04 07:30:48 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00610701
2015.12.04 07:30:48 5: SW: 06
2015.12.04 07:30:48 5: ZWAVE1 dispatch 00610701
2015.12.04 07:30:48 4: ZWAVE1 CMD:ZW_REMOVE_FAILED_NODE_ID ID:01 ARG:
2015.12.04 07:30:48 4: ZWAVE1 ZW_REMOVE_FAILED_NODE_ID failedNodeRemoved
Den ZW Dongle habe ich auch stromlos gemacht. Hier ein bildschirmprint. ich bekomme ich alten reste (UNKNOWN_2 und _3) auch nicht weg.
Zitat2015.12.04 07:30:48 4: ZWAVE1 ZW_REMOVE_FAILED_NODE_ID failedNodeRemoved
Das zeigt eigentlich an, das es entfernt wurde.
Hast Du die nodeList mal neu abgerufen? Und es ist wirklich dann noch drin? *ratlos*
Die überflüssigen Readings kannst Du übrigens mit http://fhem.de/commandref.html#deletereading entfernen.
Zitat von: krikan am 04 Dezember 2015, 07:55:48
Das zeigt eigentlich an, das es entfernt wurde.
Hast Du die nodeList mal neu abgerufen? Und es ist wirklich dann noch drin? *ratlos*
Die überflüssigen Readings kannst Du übrigens mit http://fhem.de/commandref.html#deletereading entfernen.
Ja, habe ich (gefühlte 50 Mal... ), razberry war auch stromlos. Ist die Konfig-Datei evtl. gegen Änderungen geschützt? Alle Suchergebnisse im Forum (und auch außerhalb) beschreiben, wie die alten Nodereste (UNKNOWN_XX) entfernt werden können.
nachdem bei mir als newbi so viele einstellungen verkorkst sind und ich diese nicht mehr wegbekomme, überlege ich mein system komplett neu aufzusetzen... dazu habe ich nun eine menge recherchiert, zB. dass man unbedingt seine sensoren und aktoren exkludieren sollte. gibt es dazu noch weitere dinge zu berücksichtigen? gibt es dazu im forum evtl. auch eine anleitung dazu?
Zitatgibt es dazu noch weitere dinge zu berücksichtigen?
Gehe davon aus, dass Du nur von ZWave schreibst:
1. Geräte exkludieren
2. Geräte eventuell zur Vorsicht zusätzlich reseten
3. ZWDongle-Reset (SET_DEFAULT)
4. Alle FHEM-Devices löschen
5. save bei FHEM, shutdown restart und Neustart
Zitatgibt es dazu im forum evtl. auch eine anleitung dazu?
Zu SET_DEFAULT gibt es passende Diskussionen (2?). Danach ist nämlich alles weg.....
Mehr kenne ich nicht.
Gruß, Christian
PS: Dein eigentliches Problem mit removeFailedNode kann ich leider weiterhin nicht nachvollziehen
Zitat von: krikan am 05 Dezember 2015, 09:15:21
PS: Dein eigentliches Problem mit removeFailedNode kann ich leider weiterhin nicht nachvollziehen
Vielen Dank für deine umfangreichen und schnellen Antworten - wow !!
Ich werde weiter als skript oldie die fhem und perl befehle pauken und ausprobieren.
Wie bei allem, was man beginnt zu lernen folgt nach einer Euphoriephase die Frustrationsphase. Ich hoffe, ich komme da unbeschadet und weiterhin motiviert durch ;-)
Ich weiss, der Thread ist schon älter...
Zitat von: krikan am 21 November 2015, 21:15:26
Wie man aktuell vorgehen muss, steht hier: http://www.fhemwiki.de/wiki/Z-Wave#Wie_kann_man_ohne_Exklusion_Nodes_des_Controllers_l.C3.B6schen.3F
@MaDDin78: Als Argument für "removeFailedNode" musst Du die NodeID nehmen; d.h. Zahl ohne UNKOWN_ davor.
Ich finde nur, das man batteriebetriebene Geräte zuerst manuell auf die FailedNodeList setzen muss, allerdings nichts darüber wie man das tut.
Vielleicht ist das ja auch völlig trivial, aber ich stehe irgendwie auf dem Schlauch...
Liebe Grüße
Mike
set <ZWDongle> sendNIF <NodeId>