So, after the inclusion I searched my userdata/zwave directory for the corresponding xml. But to my surprise there wasn’t anything about this device.
I assume the device doesn’t have a xml because it’s not properly initiated (it’s a battery powered device). But despite that fact, that I woke the device up a few times, there’s still no xml.
My question therefor is: Is there another way to get this xml or do I really have to add this device manually to the database?
The XML is a persistence file. It is used to save information about the device between restarts of the binding. If there is not file, then it means the binding doesn’t have any data to save, and this is normally because the device has not initialised.
Normally this is because a battery device has not been woken up - I realise you said you have done this, but I would double check that this is really happening. Try grabbing a debug log and check that this is working, or what is happening…
Anyway, if the device is not initialising, then changing the database will not help at all. The database is only used AFTER the device has initialised, so if initialisation is failing, you really need to resolve this in any case.
I don’t think so. The mentioned device has the name ‘CRC-3100’, but the Octan is named ‘CRC-3-1-0x’.
Then on the other hand I’m not really sure … also the device description is Octon and not Octan but that could be a typo too…
Hm, so the database won’t help, that’s sad. I actually don’t have any problems adding different z-wave devices into my network. Shortly before I tried adding the Octan, I added a Fibaro Roller Shutter without any problems.
I tried to set the binding to debug level and re-include the Octan again, but the log output nearly ‘killed’ my raspi. So no log there…
After Inclusion it’s not a problem to set the log level to debug.
Inclusion itself doesn’t create much logging - only a few entries. It’s what comes next that is interesting - this is the interrogation phase and it’s probably this that isn’t working. If you can’t get a log, it will be very difficult to debug.
Can you provide the actual log from the image you shows above?
Hm, I can provide the new log after the re-inclusion. Now it’s Node 50.
Sadly I can’t append the log here on the board, it’s to big and zip’s are not allowed.
I agree, it’s a shame this isn’t allowed, but you should be able to find somewhere on the net to put it (eg dropbox). Alternatively you can open a ticket on my website and attach it there.
Well, basically I’m already on a snapshot build (the one including the security refactoring).
I never had a thing in habmin, because it’s not recognized and therefore there is not xml to delete. Nevertheless, I excluded the ‘thing’ and performed a factory reset as described in the mentioned post, as well as in the user manual. Still after a reboot of my OH and the re-inclusion, the behavior is the same. A thing not recognized as the given Octan Remote and no useful log information.
Despite the fact, that the battery state of the remote seems fine (green, as far as I can tell), I think I should change the battery (just in case) and retest. If that doesn’t help, a new remote should be in order.
243 │ Active │ 80 │ 2.3.0.201804022210 │ ZWave Binding
I’m most certainly not on the newest snapshot. As far as I understand, your snapshot version doesn’t work any longer with OH 2.2.x and needs OH 2.3-Snapi. And expect for some bindings, I run on the latest stable OH 2.2 version. So that’s a no-go for me, because I fear the change to OH 2.3-Snapi and the newest Z-Wave binding will lead to even more problems and probably a lot of headache. I switched to the z-wave binding snapshot only because of the security refactoring and in order to be able to add my Danalock into the network.
So I will probably have to sit this one out (if it’s really related to my case) and try another remote.
