I’m trying so include a Sensative Strip in Openhab 2 (Downloaded just 2 days ago).
The “thing” is detected but not recognized – But its in the zwave database!
What can be wrong?? And who can I debug this topic.
Is Openhab 2 querying the database online ?
Is there eventually even a way to have a “local product xml file” for a thing?
My zwave adapter is a AEON Z-Stick Gen5.
Other things are deteted and recogniced.
So the infrastructure is working fine.
Thanks for any help,
Michael
Have you confirmed this? Please can you provide the device information as I’d like to check.
No - the database is compiled into the JAR.
No - for many reasons, it is compiled into the JAR.
Please provide the device information and I will check if the device is in the database, and if not it can be added.
Cheers
Chris
It’s a sensative strip-11-01-011
. I got that from the title of the thread, but the database doesn’t know the device name, it uses device IDs that should be printed in HABmin - we need to know these numbers to add it to the database.
1.) I verified successful “sensative_1101011_0_0.xml” is inside “openhab.binging.zwave”.
2.) I’m not able to find a device id in HABmin 2/ openhab 2…
3.) But I found the problem scanning the log file:
NODE 5: Device could not be resolved to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
I looks to me, as if there is a problem in the ZWave Stick - z strip communication.
I will email to the support of sensative.
However, it would be very helpful to be able to assign a product to a node manually,
just for strange situation like this one…
Yes, it’s in the database, but that doesn’t mean that YOUR version is in the database.
No - you probably need to wake the device up at least a few times so that all the initialisation can be completed. It might take a couple of wakeups, and when you wake it up the device will need to be reasonably close to the controller (5 or 10 meters absolute max - less if the device is installed in a ‘bad’ position - eg around brick walls etc).
In this situation, it wouldn’t help since you don’t know the product information anyway…
For this device there is no way to wake it up explicit. Implicit it wakes up if I force an event. But this doesn’t help at all.
But even if, at the moment I’m just testing one device and OH2.
In reality I have to connect 10 to 20 of this device (one per windows).
It’s just impossible to wait for what time and wakeups even to include all these things. The work has to be finished in let’s say half an hour, or the device (or more likely OH2 in this case) is not usable in production.
To choose a device type/profile manually in such a case is no rocket science, even for “non it professionals”. If he hits the wrong profile, he will notice some problem in operation and has to change it.
At least it’s a lot of times better as not using the device or OH2, or manually typing binding in OH1 (with is more or less successful listening to events of the thing).
Really - that is very strange for a zwave device. How do you include it into the network?
Maybe this device is different, but for every other zwave device, forcing an event does not wake the device up. Forcing an event means the device SENDS data, but it is not available to RECEIVE data so the binding can not talk to the device to configure it.
This is why there is normally a wakeup button on the device! ZWave battery devices sleep most of the time, so they can not receive commands except a few seconds every hour or every day. Even this must be configured first before it will work.
Sorry - I don’t understand 
.
I found this in the manual -:
Maybe this will help you?
Regarding your comment about manually choosing a profile - this will not help at all until the device has been woken up and is configured, and once you do this, the binding should automatically select the profile.
Let me know how it goes 
.
I have one of those strips , I can confirm that it works with both OH1 and OH2.
it takes a few wake-ups before it’s get fully initialised .
I agree that the process of adding the device to OH could be more user friendly, but i don’t think we are there yet. 
Pls check also this thread, maybe you’ll get some needed information there:
Hi @MichaelWeller, did you ever manage to get these to work? I’ve got one now and I’m having a nightmare with it! I’ve woken it many, many, many times and Habmin consistently shows it as an ‘Unknown Device’
I’ve a log here (I grepped ‘NODE 38’ so hopefully I didn’t strip anything important, but it was pretty huge otherwise).
I’m not Michael Weller, but I got one to work! 
With OH1 and also with OH2.
Reading your log, I’m a little confused about the unknown device. There is one entry:
2016-10-19 13:22:25.973 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 38: Device discovery resolved to thingType zwave:sensative_1101011_00_000
So the binding seems to have successfully discovered the device. Do you have excluded and re-included the device multiple times?
Futhermore, do you use the latest snapshot version of the zwave-binding? Or: Which version do you use?
I agree, it’s a little bit tricky to do a wake up. You have to make sure that when you put the small magnet onto the bottom of the strip, that the green light flashes. And this has to happen three times within 10 seconds!! For me, it happened quite often that I got two flashes with the first two tries, but the third time I didn’t got a third flash.
Hiya @jaydee73, thanks for the reply!
Yes I excluded and re-included multiple times, because it never seemed to complete the initialisation.
I’m currently using 2.0.0.201610152054 of the binding, and yes, it’s tricky to wake it up but I definitely managed several times (see the log). Did you have to be by the controller to do it? I tried using habmin to put the controller (aeotec zwave stick) in discovery mode and then waking it up in the area where it would eventually be installed (so that it would find the correct neighbours) but it would always flash 5 times quickly (i.e. it couldn’t communicate with the controller). So then I went into my (very very cold!) garage and tried to do it there. I don’t remember exactly, but I guess it was then that you see wakeups in the log. It’s a bit puzzling to me that I could include the device remotely, but initialization didn’t work, but if there’s one thing that I’ve learnt with Z-wave it’s that battery powered devices are horrible to use.
During weekend, I had some time to re-initialize the device with OH2. It took me about a dozen wake up’s for the device to get fully initialized. At first I thought I had the same problem as you but then suddenly it got initialized (I didn’t exclude/re-include the device, only deleted the thing and the xml file).
As the device itself is in the same room as the controller (living room), I haven’t had any problems with communication, but no, the device isn’t near the controller, they are about 5m from each other. But again: it already was included (since the days of my OH1 installation) with my aeon stick.
Yes, battery devices are sometimes tricky. But this little baby seems to be even more special.
Actually, I just looked again and it’s fully initialised now! I didn’t do anything in the meantime, so perhaps you sometimes just need to wait?
Yes, because the device wakes up regularly and this also leads to an automatic initialization.
I’m just a bit surprised because I manually woke it up several times (magnet on the end three times) and this didn’t work. I guess there’s an automated wake up which does something different?
I hate dealing with battery powered devices!u
Maybe…
I know on some devices that they send a NIF, and then a WAKEUP_NOTIFICATION. Since the binding sees the NIF the same as the WAKEUP_NOTIFICATION, it starts to send data even though the device isn’t awake.
So, this “treat NIF as WAKEUP” doesn’t work well on some devices - maybe this is one of them.
I tried removing this recently, and that caused problems with other devices. I intend to implement a delay that will solve this problem, so it that’s the cause, it might fix this…
I have just received one of these. You have to wake it up with the round magnet a couple of times (well maybe 10 or so), before it fully initializes. It is then recognized in OH1 at least. The timing of the wake up passes with the magnet is important - wait for the green flash! - when you get the third green flash, it is awake.
You have to change parameter 1 to 0 (this changes it from producing an ALARM to a SENSOR_BINARY report). I’m using OH2, with the 1.9 zwave binding, and Habmin2 doesn’t seem to work with that (no zwave controls in it anyway). So I fired up my (still good) OH1 installation, and used Habmin1 to set parameter 1 to 0 (default is 1). The rest I left alone. This of course means that I had to wake it up many times to register with OH1, change the parameter with Habmin, shutdown, start OH2, wake it up 10 times again, and presto! it works!
Nice sensor, bit fiddly to align properly, and we’ll see how the adhesive works out. I used my own magnet, as the flat one that comes with it didn’t look like it would attach to the door well. I’ll be impressed if the battery lasts 10 years as well…