I have always problems with battery-driven zwave-devices as switches and sensors.
As far as I understand zwave, the controller (tried zwave-me and Aeon Gen 5 stick) pairs with the devices.
This pairing starts with inclusion - and has nothing to do with openhab.
You can use every tool/pc to create your zwave-network.
Then, if I connect the stick with openhab and add it as controller, the paired devices are found by OH2 thing-detection.
My wall-plugs (Fibaro, Coqon) were always identified correct in OH2 and I can add them as things and control.
But battery-driven devices in most cases were detected as “Node 4” or “Z-Wave Node 4”.
I understand, that battery-devices need to send an ?information packet? to identify themself.
And only if OH receives this ID, it can set the proper thing-configuration from chris’ database.
I tried with Popp Wall-C Switch, Fibaro Button and Philio 4in1 sensor - all of them were recognized as “Z-Wave Node x”.
If I delete them from inbox, redetect them again, remove them and redetect them - sometimes they were identified correct - and if I add them in this moment, I can use them.
But I can not reproduce the working step. Its just endless trial and error for me…
Is this a generally problem of battery-devices in zwave-network or what do I wrong?
And is it possible in OH2 to create the things by hand?
I know the device - it should work to find the corresponding settings and manually create a thing?!?
This can be a long lasting thing to get them recognized correctly.
I had to push the button about 20 times to get my stella-z thermostats not to be unknown devices any more.
So for me it is a normal behaviour like you tell.
And yes to your first two points with pairing and OH2-thing
glad to hear this - kind of
But to fully understand:
Is it OK to pair once - and try 20x to redetect the device?
Or do I have to pair/unpair 20x ?
Do the device has to send the correct information while pairing or in paired state?
This is true of every device - not just battery devices.
Yes - there are a number of stages involved with the interrogation process. The manufacturer information is one of the first, but there are a lot of other stages…
No - the binding needs to interrogate the device. This will normally take a couple of wakeups, but depending on the device, it could take more. If it doesn’t complete, then maybe there is a problem with the device, or with the database, or with the binding.
Often there are device problems where a device doesn’t conform to the ZWave standard - I’ve found a few where ZWave have confirmed that the device is not compliant, even though they have approved it! When this happens we can normally work around the problem by adding a configuration to the database, but again, this needs the interrogation / initialisation of the device to complete.
Battery devices are not so simple in ZWave as they only wake up every hour or so. You can speed this up by waking up the device manually…
Yes - you shouldn’t need to exclude/include again.
It’s after pairing that the interrogation is done.
NOTE: The above does not cover secure devices - that’s a whole different world and many of the points above would have a different answer…
I did in paired state … Every time i pressed the button there was a CAN-Entry in logfile… Suddenly after a few times it was discovered