Remove the use of NIF as a wakeup notification

[cdjackson]

#127

Signed-off-by: Chris Jackson chris@cd-jackson.com

[mhilbush]

When I try to wake up my Fibaro FGMS001 by pressing the button three times, I get this. In the past, this would wake up the device. Is it because of the change in this PR?

I'm on this version;

184 | Active   |  80 | 2.0.0.201610121647    | org.openhab.binding.zwave

I don't know why, but the online log viewer is not working for me right now. After I select the log file, I get nothing in the viewer.

2016-10-13 07:28:55.439 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:55.440 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-10-13 07:28:55.441 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:55.442 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:55.443 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A 
2016-10-13 07:28:55.443 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 36: Application update request. Node information received.
2016-10-13 07:28:55.443 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=05 01 
2016-10-13 07:28:55.444 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A 
2016-10-13 07:28:55.445 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=0, expected=AddNodeToNetwork, cancelled=false      MISMATCH
2016-10-13 07:28:59.257 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:59.259 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-10-13 07:28:59.260 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:59.261 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 14 00 49 84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A A9 
2016-10-13 07:28:59.262 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A 
2016-10-13 07:28:59.262 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 36: Application update request. Node information received.
2016-10-13 07:28:59.262 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=05 01 
2016-10-13 07:28:59.263 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 24 0E 04 07 01 5E 86 72 59 80 73 56 22 31 98 7A 
2016-10-13 07:28:59.263 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=0, expected=AddNodeToNetwork, cancelled=false      MISMATCH

[IOOOTAlan]

That's what I'm seeing too, even during inclusion mode. I opened this thread on the forum regarding this issue.

[cdjackson]

When I try to wake up my Fibaro FGMS001 by pressing the button three times, I get this. In the past, this would wake up the device. Is it because of the change in this PR?

Probably.

I removed this because it was causing problems with other devices. Some devices send a NIF, but they aren't awake. They then send a wakeup notification shortly after, and then they are awake. It seems there's no standard approach which is disappointing.

I guess I'll need to think of an alternative approach to dealing with the two systems...

even during inclusion mode

@IOOOTAlan What do you mean by this? Inclusion mode is different to wakeup so I'm not sure what you mean?

[cdjackson]

And I should had added that the log viewer should be working. I was messing with it last night to improve some displays for he new transaction code, and there were some points in which it wasn’t working, but it is working ok now (and for the past 16 hours or so). If it doesn’t work, can you send me your log so I can find out why as it’s definitely working ok for me...

[mhilbush]

This is the log that's causing problems. Sorry it's so big.

zwave.txt

[mhilbush]

Some devices send a NIF, but they aren't awake. They then send a wakeup notification shortly after, and then they are awake. It seems there's no standard approach which is disappointing.

That's one heck of a standard, huh?

Seems like it might be difficult to detect on the fly whether or not a device is awake after it emits a NIF.

Maybe a flag in the DB to indicate whether the device is awake after it emits a NIF? Flag is off by default. When we we find devices that are awake after they emit a NIF, it's a simple tweak to the DB entry for those devices?

[cdjackson]

Yeah - I did think about a database setting. I might try a timer - i.e. delay the NIF and only use it if a wakeup isn’t received xx ms after the NIF...

[cdjackson]

Thanks for the log - the viewer should be at your service again ;)

[mhilbush]

Yep. That did it! Thanks! :-)

I thought about a timer, too. But, I thought there might be some unexpected edge cases with the timer. Not knowing if were talking about a lot of devices, or just a handful, it's hard to judge how much effort to put into doing it on the fly.

[mhilbush]

Oh, and thanks for the select all & select none buttons in the filter. It's pretty tedious unchecking 25-30 checkboxes when you want to see just one node. 👍

[cdjackson]

The problem with a database though is you need to know the device (i.e. you need to be able to get the database entry to know if the setting is set). In one case on the forum at the moment, the user can’t wake the device up at all, so they can’t get the device id, so this doesn’t work.

[cdjackson]

Ah, yes, it didn’t take long before that became a ‘must have’ :)

[mhilbush]

Good point.

On Oct 13, 2016 3:11 PM, Chris Jackson notifications@github.com wrote:The problem with a database though is you need to know the device (i.e. you need to be able to get the database entry to know if the setting is set). In one case on the forum at the moment, the user can’t wake the device up at all, so they can’t get the device id, so this doesn’t work.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

[IOOOTAlan]

@IOOOTAlan What do you mean by this? Inclusion mode is different to wakeup so I'm not sure what you mean?

Yep, it's different but after this pull request got merged we discovered that:

• we were not able to include new devices (meaning that they never get fully recognized) because the interview phase never went forward the MANUFACTURER step -- this happened with mains powered devices too (like the Aeon ZW096 smart switch)
• devices already added but being rescanned also never fully completed the scan

[cdjackson]

we were not able to include new devices (meaning that they never get fully recognized) because the interview phase never went forward the MANUFACTURER step -- this happened with mains powered devices too (like the Aeon ZW096 smart switch)

I can't see how this can impact the actual inclusion - that is a totally separate thing. If the device shows up in the list, then it is included - I'm assuming that this is happening (??) since you said it is not "fully" recognised (which I read to mean it WAS recognised?).

If there's an issue, please can you provide a log as I'd like to understand what is happening - it's really hard to work with descriptions like this since it's very subjective as to what is happening, and maybe we are not using the same terminology. I don't want to go looking for a problem with inclusion if the problem is really in the initialisation.

[IOOOTAlan]

You're right Chris, apologies for my poor wording on the issue.
What I wanted to say is that the devices were indeed included in the network (so inclusion did work), but we weren't able to make them go past the first steps of the interview/configuration phase.
If the logs are still relevant as of now, I'll try to put up a "faulty" version of the binding and attach them here...