The problem isn’t detection of NIF - NIF is treated as wakeup anyway. The problem is that the binding doesn’t add the WAKEUP class to the node, and therefore data is not queued - it’s sent immediately just as if the device is a battery device. We can force the wakeup class to be added, which I think is what we did in OH1 - I’d suggest to discuss this on the forum though. <
So at the moment there is no way to let OH2 perform the configuration of this device: the device can only produce NIF and (correctly) does not announce the wakeup class as it doesn´t support this class.
The old work around was to force the binding to include the wakeup class, and at least I assume that this is true (@chris is this correct ?) to handle NIF equal to wake-ups.
So would it be an option, as it seems to be impossible to code this in the device database, to force the wakeup class if e.g. 3 NIF are received in sequence and after this handle NIFs (from this device) as wakeups ?
Just to be fail-save with other devices, this special handling of NIF could be removed in case a real wake-up is received from this device, as this would mean it is just not necessary.
NIFs are always handled as wakeups (where the wakeup class exists of course ;)).
It’s not impossible to fix this in the database - we can do the same thing we did in OH1 which is to add the WAKEUP class into the device. There is no need (I think) for special handling of the NIF…
But as far as I understand, the Information from database can not be used, as at the moment it is not possible to configure the device and it is marked as ‘Unknown Device’
So would it be an option, if a unknown Device gets 3 NIF that the binding is forced to add wakeup class ? Or what could be a negative effekt of this ?
The negative affect is that devices might end up with the wakeup when they don’t need it, and that would stop them working almost completely if they are a mains device.
We could add WAKEUP if it’s not a LISTENING device, but I think we might have tried this when we looked at this issue on OH1 and there might be a downside of this too…
Maybe the best thing to do is raise an issue on the OH2 tracker - add this information and a link here so we don’t forget what this is about and I’ll take a look shortly.
So, a possible approach could then be to add the WAKEUP class (forced by the 3 NIF or something else what can be produced with that hardware ) at least until the configuration has been completed. Then the database can be used to make sure that it is an battery operated device. If it is mains operated, then the WAKEUP class could be deleted again.
I’m not so sure. It would be very messy to add and remove command classes, and would likely break things. As soon as the WAKEUP class is added, then nothing will be sent to the device unless there is a wakeup, so this could cause problems. Better to try and use the LISTENING flag that I mentioned earlier.
I have some Merten battery operated push buttons that simply wont be initialised correctly/completely. I have spent days trying to wake up the device. Tripple clicking for hours…
When I go in inclusion mode the light on the pushbutton changes from blinking red to a steady green light, which goes out after about 20-30 seconds. The node is shown as node3, but there is no node3.xml and inside HABmin there is no Manufacturer, Type / ID, Firmware, etc set. All is empty except. It is shown as online.
as far as I see at the moment it is not possible to perform the required initialization for those devices with openhab2 and the version 2 of the zwave binding, sorry.
It worked with openhab1 after chris has moved a lot of bits just to make this item work (thanks again ) but those work arounds have led to other problems so those were removed later on.
) but those work arounds have led to other problems so those were removed later on.