But have you tried sending the ReplaceFailedNode?
No, but Iāll try that tonight.
I tried doing Replace Failed several times in the Zensys tool. In all cases, it didnāt remove the node. After selecting Replace Failed, it just sits there waiting for me to put the āreplacement deviceā into inclusion mode. This obviously is different than what @5iver stated above, and I have no explanation for why it works for him and not for me.
This is what I did.
- Send NOP
- Is Failed
- Replace Failed
I find that the NOP, IS Failed, Removed Failed procedure works far more reliably.
Just to clarify - when you send the ReplaceFailed, it just sits there?
What is done in the binding is simply ReplaceFailed(node ID), then RemoveFailed(node ID).
Yes, when you select Replace Failed, it pops up a dialog box asking you to put the āreplacement deviceā into inclusion mode. That dialog box has one button ā āAbort Actionā.
I know I got screwed up with this terminology before. They seem to have designed the terminology purposely to confuse people like me. LOL
So, letās skip the terminologyā¦ When I do Is Failed and Remove Failed in the Zensys tool it sends:
- 0x62 (Is Failed)
- 0x61 (Replace Failed)
What does the binding send?
Do you really need the IsFailed? I doubt it, but can you confirm?
It sends the Replace Failed, and the Remove Failed - separately as per the two configuration parameters.
One other thing I notice in the Zensys toolā¦
After I do the Is Failed, the node turns red in the UI. I assume this is because itās now considered failed?
Yes, but thatās likely just the UI and nothing to do with the controller.
I assume so based on what I just posted above, but Iāll try it now without the Is Failed. Just the NOP followed by Replace Failed.
Hmm - stranger still . This should just be a status call - I donāt really see why this is neededā¦
Youāre right. NOP followed by Remove Failed works.
Just doing Remove Failed doesnāt work.
That is the same as what I experienced. It waits for a device to be put into inclusion mode and then gets included with the old node ID. Replace Failed reuses the same node ID from a failed device with a new device (youāre replacing the device and keeping the node ID. Remove Failed wipes out the node ID.
In both cases, I would alwaysā¦
- disable the queuing so that commands were sent immediately and not waiting for the device to wakeup,
- select the node,
- send the NOP by adding the node ID to the little box, \
- send isFailed,
- Remve Failed or Replace Failed
Without all the steps, the behavior was not consistent.
Ok, so then weāre on the same page. You use Replace Failed when you want to replace the ghost node with another device. Otherwise, you use Remove Failed. Correct?
In my testing so far, Is Failed doesnāt appear to be necessary other than to cause the Zensys UI to update the node list to show the node as failed (i.e. in red).
Correct. As for IsFailed, Iām pretty sure that I read somewhere a long time ago that it was necessary, and it had been inconsistent with out, so I just always used it. It was a long time ago!
Folklore. LOL
Iām reading through some dusty PDFsā¦
As far as I understand UserGuide (Page 52, chapter 4.2.8) correct, you can only replace a failed node with an existing node from the node list.
See here:
What does āNOPā stand for?
NOP = āNo Operationā ā to send a frame not carrying any functional info to a node.
It is like a ping.
See here: