@chris - I think that’s the core problem. There isn’t any logging indicative of any issues. It just looks like a timeout. But I can tell you that if I reset my ZWave stick and have 0 devices, secure include works. If I switch out and then try to include after having added other nodes, secure include fails.
My idea was possibly that OTHER ZWave devices happen to be sending messages around the same time and due to this is causing an issue with receiving the correct messages in the right timing order? Or possibly that the controller isn’t able to actually reach the secure device due to some type of a routing issue from other node communications? Not sure I’m kind of throwing out rough ideas as obviously I’m not 100% sure. But I can tell you, my behavior matches exactly with Nolan and that’s honestly the only difference in my setup from starting a fresh include vs include after others have been added.
The device didn’t respond - to my way of thinking, that is a timeout .
Where are they sending all these messages to though? There’s nothing in your logs showing any other messages during this time, so they aren’t being sent to the controller. Unless you have lots of devices sending data directly to another device (ie not to the controller), I can’t see that this is likely.
If that is the case (which I personally don’t think is likely, but I’m happy to be convinced otherwise), then how to stop this. There’s no way to stop other devices sending all these messages that is stopping the controller working. And if these timeouts are causing havoc during the secure inclusion, then why aren’t they causing the same issue all the rest of the time with any other node? A secure inclusion message is no different than any other message, so do you see lots of timeouts to all nodes?
I simply don’t think this is likely. I’m not contesting that it works if you have no nodes - at least it did once - I’m just saying that I don’t subscribe to the explanation.
Hmmm - if you aren’t including the device in direct range of the controller, then this might be the problem? ie routing isn’t relevant here as it’s secure inclusion, so the device needs to be within direct range of the controller.
Maybe ;). Let’s see… Maybe I’m being picky, but I’m just being careful not to jump to conclusions - there’s so many times I hear “I have exactly the same problem” to find it’s something totally different.
I hear you on all fronts. I subscribe to the methodology of show me how it’s working properly or failing to work properly. With evidence of an issue before I can believe the idea. I wish I knew more about the protocol to be able to make more educated guesses to an area of concern.
I can tell you it’s not a distance issue - I always worried about this. I’ve tried putting it on top of the controller, literally, to the side, below, maybe a foot away, etc. None work. If it is an early or first node though, it works and doesn’t even need to be directly next to it. Works a few feet away even. And it’s quick too!
If there is something you can think of that I can test - I’m happy to try and run the consolidated test to output the result we need to see. Like I mentioned, I have a secondary device to test with a controller. The only difference though, is the controller will be different. But outside resetting my network and re-attaching everything to rules scenes renaming etc - I don’t want to go back to total square 1. But I’m happy to test other possible scenarios with the secondary setup.
What do you mean by “I cannot include the Fibaro…” ? If you cannot even include it in the network, the database does not matter at all. Try to exclude and re-include. Observe that the stick actually exclude, and also include. Try different pace on the include (sometimes too fast is not good, and definately too slow is bad). Or use auto include if the devices has this feature.
I don’t have a 222 myself, but i’d be very surprised if it is not in the database, once you get them included.
Regarding your sirens, I have no suggestions (sorry, I have no experience at all with sirens). But every problem resolving thing starts with viewing the debug-log.
I use the newest openhabian and installed the z-wave binding jar files listed above. I am using z-stick s2 and the lock I am trying to pair is schlage be469. when I enter the code and search for the lock, it found the device but it always failed to pair. I got error message when I first time pair the device, it will have SECURITY STATE=FAILED. I found the device in the inbox afterward, and I added, it recognized my device and know that is be469, but when I add a swith item to its lock, I got error for COMMAND_CLASS_DOOR_LOCK not found
Absolutely - this is why I don’t like to jump to conclusions, and like to look at the logs as they only tell the facts (not all of them of course, but what they do say is factual)
How many times have you tried this? I’m not, not believing you, but something I see a lot is “if I do X, it works” - and often it’s nothing to do with “X” - it just happened to work that once so the conclusion is drawn.
On this problem, from looking at the logs from your failed inclusion, there’s nothing in there that’s showing any external problem. Maybe there is something going on that’s not in the logs, but I think it’s unlikely that these external influences only appear during secure inclusion. Honestly, I’d be much happier if there was a bug in the binding as we can fix that - if we’re saying “it’s ghosts and goblins at work” then, well, that’s just not engineering :).
Let’s sit on this for now. If you have the opportunity to try a fresh install with a device, then it might be interesting. Otherwise, hopefully I’ll get this BE469 in the coming days and maybe the issues there will shed some light on the problem. Of course, if there really is an issue with the number of devices, then the BE469 isn’t going to help since it’s (nearly) the only US device I’ll have so I won’t be able to build a network
Regarding zipato RGBW lightbulb not making warm white.
Blockquote
It looks like there’s an error in the database. Sorry it’s taken so long to look at this.
There’s an error in the database exporter. This is now fixed and I’ll do an update later that will hopefully solve this.
Did you manage to fix it and if so, do you need to compile a new JAR or will it work with the one on top of this thread?
Cheers!
I usually subscribe to that idea too that I’m missing something else, but in this instance it’s the only variable changed, and it did validly apply multiple times. I’ll look into testing it out for you when I get back and supplying some logs for you to compare. Perhaps you’re BE469 will have come and been able to test, and I can provide some alternatives to look at. Since it will be the same lock, hopefully that can help too correlate between your logs, my solo device log, and my prod setup with multiple nodes. Thanks for considering this something to note though. I’ll wait till I have some log proof to share any difference seen.
PS - If anyone will be at BLACKHAT or DEFCON in VEGAS next week, send a message and we can meet up!
I’ve been having a devil of a time trying to get my Kwikset 914 to securely include and I can’t figure it out. When I include through habmin, it gets through the normal include part and appears to succeed but the debug log says “SECURITY_INCLUSION_FAILED Failed at step SECURITY_NETWORK_KEY_SET: 10000ms passed since last request was sent, secure inclusion failed.” I’m not sure which end is failing though. Looking at the attributes of the controller, everything has a yellow question mark though. Is that normal? I can include the lock securely just fine with other software like Home Assistant, but trying to then start openhab it complains about not being in secure inclusion mode even though the same key was used in both systems. I thought that once the device was securely included into the zwave dongle no matter what the means, as long as the software has the same network key it should work fine. Is that not true? I’m definitely missing something here and I just can’t seem to figure it out
Z-Wave binding version info (just fyi, and data based on the date of this post):
a) “Mainstream” stable: 2.1.0 (without date/time info) (included in openHAB 2.1.0 Stable Release)
b) “Mainstream” Snapshot: 2.2.0.201707122217 (included in openHAB 2.2.0 Snapshot Build #986)
c) Refactored/Development/Security Snapshot: 2.1.0.201707062012 (the one under discussion in this thread)
To find out which version you are currently running
Enter in the openHAB console using ssh openhab@localhost -p 8101 with password: habopen
Issue the following console command: bundle:list -s |grep -i zwave
It should display something like (note: the result below is for the “Mainstream” Snapshot, not the development)
I’m pretty sure that this error message doesn’t come from this version of the binding. Are you sure you are running the development version? If you’re not running the right version of the software then this simply isn’t going to work (no matter how you included the device).
I thought I was, I installed quite a few different versions of things over the weeks trying to get everything to work but I guess I must have grabbed the wrong branch for this one. I uninstalled the existing binding and dropped in the one posted at the top of this thread and no more issues with security after deleting/re-adding all my Things. Thanks for the quick reply, I guess I just got myself confused with all the info here
In HABmin/development binding it is now listed as 0064:3001:0000:1.0 and unknown device.
In the old binding xml it is described as 0x3001
So so far it is correct.
But in database it is now changed to be 3002.
It should be changed back to 3001 or added as separate device?
I’m not sure when this changed, but I would be surprised if the latest development binding doesn’t show it at 3002 as I did a full resync of the database…
In any case, that doesn’t matter - I suspect that we probably should have both 3001 and 3002 in the database.
.
I subscribe to the methodology of show me how it’s working properly or failing to work properly. With evidence of an issue before I can believe the idea. I wish I knew more about the protocol to be able to make more educated guesses to an area of concern.
But I’m happy to test other possible scenarios with the secondary setup.
)