search

openhab / org.openhab.ui.habmin

HABmin - a graphical user interface for openHAB 2
231 stars 91 forks source link

delete failed node fails #74

Closed xsnrg closed 9 years ago

xsnrg commented 9 years ago

The variable is not getting enumerated. See attached image. deletefailed

cdjackson commented 9 years ago

Unfortunately there’s no way to pass this information into the localisation routines that I’m using… It’s something I need to sort out, but it’s not high on the todo list...

xsnrg commented 9 years ago

I should have mentioned that the node is also not removed though. This should force the removal of the node from the controller? In this case the S2 zstick

cdjackson commented 9 years ago

This should force the removal of the node from the controller? In this case the S2 zstick

Unfortunately, that’s not necessarily true. It can only remove nodes if they are on the controllers ‘failed nodes’ list. If the controller doesn’t think the node has failed, then you can’t delete it (as far as I know) and sending this command will fail. This is often the case for battery devices, but normally dead mains devices will be removed ok…

Can you provide the log so I can see what’s happening?

xsnrg commented 9 years ago

One entry:

osgi> 2015-08-03 14:05:42.602 [ERROR] [s.RemoveFailedNodeMessageClass] - NODE 13: Remove failed node failed as node not found!

Some record of it is there though. node13

xsnrg commented 9 years ago

With debug:

2015-08-03 14:12:12 [DEBUG] [.z.i.config.ZWaveConfiguration:975 ] - NODE 13: Delete node 2015-08-03 14:12:12 [DEBUG] [s.RemoveFailedNodeMessageClass:42 ] - NODE 13: Marking node as having failed. 2015-08-03 14:12:12 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = RemoveFailedNodeID (0x61), type = Request (0x00) 2015-08-03 14:12:12 [DEBUG] [b.z.i.protocol.ZWaveController:667 ] - Enqueueing message. Queue length = 1 2015-08-03 14:12:12 [DEBUG] [WaveController$ZWaveSendThread:1258 ] - Took message from queue for sending. Queue length = 0 2015-08-03 14:12:12 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 05 00 61 0D FE 68 2015-08-03 14:12:12 [DEBUG] [WaveController$ZWaveSendThread:1315 ] - NODE 255: Sending REQUEST Message = 01 05 00 61 0D FE 68 2015-08-03 14:12:12 [DEBUG] [eController$ZWaveReceiveThread:1528 ] - Receive Message = 01 04 01 61 08 93 2015-08-03 14:12:12 [DEBUG] [eController$ZWaveReceiveThread:1452 ] - Receive queue ADD: Length=1 2015-08-03 14:12:12 [DEBUG] [b.z.i.protocol.ZWaveController:1210 ] - Receive queue TAKE: Length=0 2015-08-03 14:12:12 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 04 01 61 08 93 2015-08-03 14:12:12 [DEBUG] [b.z.i.protocol.ZWaveController:1211 ] - Process Message = 01 04 01 61 08 93 2015-08-03 14:12:12 [DEBUG] [b.z.i.protocol.ZWaveController:190 ] - Message: class = RemoveFailedNodeID (0x61), type = Response (0x01), payload = 08 2015-08-03 14:12:12 [DEBUG] [s.RemoveFailedNodeMessageClass:53 ] - Got RemoveFailedNode response. 2015-08-03 14:12:12 [ERROR] [s.RemoveFailedNodeMessageClass:69 ] - NODE 13: Remove failed node failed as node not found! 2015-08-03 14:12:12 [DEBUG] [b.z.i.protocol.ZWaveController:682 ] - Notifying event listeners: ZWaveTransactionCompletedEvent 2015-08-03 14:12:12 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ] - ZwaveIncomingEvent 2015-08-03 14:12:12 [DEBUG] [WaveController$ZWaveSendThread:1374 ] - NODE 255: Response processed after 3ms/2465ms.

cdjackson commented 9 years ago

Strange that is says the node isn't found! Can you provide the log when the binding starts - there are some checks there to see if nodes are on the failed nodes list and it would be interesting to see if it is or not. If it's not on that list, then the node can't be deleted - maybe that's the case and the error report is just wrong....

xsnrg commented 9 years ago

log attached, sorry for the delay. zwave log zip

cdjackson commented 9 years ago

You can't attach files on Github (yes, I know that's ridiculous!). You need to paste it into a Gist, or a pastebin or something, and then put the link here... (or email it to me direct)

xsnrg commented 9 years ago

I thought I had seen adding an image tag, then download and rename work

On Sat, Aug 8, 2015, 04:08 Chris Jackson notifications@github.com wrote:

You can't attach files on Github (yes, I know that's ridiculous!). You need to paste it into a Gist, or a pastebin or something, and then put the link here... (or email it to me direct)

— Reply to this email directly or view it on GitHub https://github.com/cdjackson/HABmin2/issues/74#issuecomment-128942742.

cdjackson commented 9 years ago

Hmmm :) I hadn’t come across that before, but you’re right - it works :)

cdjackson commented 9 years ago

So, it’s as I thought. The controller says the node is healthy, so I can’t remove it - we’ll, to be precise, the controller won’t remove it when I ask for it to be removed. Until the device is on the controllers ‘failed nodes’ list, it can’t be removed. I think this is a battery device, and from what I’ve seen, they pretty much never get onto the failed node list!

I know this is annoying. I’ve tried looking for a fix - I’ve seen mention of a command to force a device onto the failed node list, and then you can delete it, but I’ve not found this elusive command so we’re stuck!

If you have other software that does this, is there any way you can capture the commands it’s sending to the com port and send it to me? I might be able to work it out from that.

Cheers Chris

xsnrg commented 9 years ago

Thanks for digging Chris. I don't have any other software, but this state is easy to reproduce, just get one of the un-programable Z-SMOKE alarms and bind it to the stick. The only way I have been able to remove them is to reset the controller, which is not fun when you have a bunch of devices on it.

Would it be possible to prompt the user with information that the device selected is not in the failed node list? Or maybe the link not active if a device is not in the failed list?

cdjackson commented 9 years ago

Hi Jim - yes, I appreciate it's easy to reproduce. I thought you'd mentioned earlier that there was some other software that deleted the node and I was thinking we might have been able to find a secret command that I didn't know about by sniffing the data it sent to the stick...

Originally, I had this option greyed out if the node was node in the failed list, but I ungreyed it as it caused confusion... Either way, I can't win here...

I'll close this then - feel free to reopen if you think there's something else we can do...