Open GoogleCodeExporter opened 9 years ago
Also seems like the device is not added on the device database
Here goes some details:
Z-Wave information about the Danalock
Manufacturer Info
Zensys manufacturer ID(270) // Poly-Control
Device Info
GENERIC_TYPE_ENTRY_CONTROL
SPECIFIC_TYPE_ADVANCED_DOOR_LOCK
Supported commands
Non encrypted combo and lock
COMMAND_CLASS_MANUFACTURER_SPECIFIC,
COMMAND_CLASS_BATTERY,
COMMAND_CLASS_VERSION,
COMMAND_CLASS_SECURITY,
Crypted combo (Z-Wave and bluetooth units, prepared for a future keypad)
COMMAND_CLASS_DOOR_LOCK,
COMMAND_CLASS_USER_CODE,
COMMAND_CLASS_SCHEDULE_ENTRY_LOCK,
COMMAND_CLASS_CONFIGURATION,
COMMAND_CLASS_TIME,
COMMAND_CLASS_MANUFACTURER_SPECIFIC,
COMMAND_CLASS_BATTERY,
COMMAND_CLASS_VERSION
Crypted lock (Z-Wave units)
COMMAND_CLASS_DOOR_LOCK,
COMMAND_CLASS_CONFIGURATION,
COMMAND_CLASS_TIME,
COMMAND_CLASS_MANUFACTURER_SPECIFIC,
COMMAND_CLASS_BATTERY,
COMMAND_CLASS_VERSION
Original comment by santal.m...@gmail.com
on 10 Aug 2014 at 10:19
Oh... and this should be important aswell
http://guide.danalock.com/index.php/ZwConfigVariablesTable
Original comment by santal.m...@gmail.com
on 10 Aug 2014 at 10:20
Please upgrade to the latest version and send complete logs. There is a issue
with rPI boards at the moment.
Original comment by jus...@dynam.ac
on 11 Aug 2014 at 4:27
Hi here goes the complete log.
Original comment by santal.m...@gmail.com
on 11 Aug 2014 at 8:53
Attachments:
the device doesn't appear to be reset correctly. Is there a factory reset
option or something on it? Its not even responding to simple Network Key
functions in the log you sent.
(I gather you had previously tried to pair it with something?)
Original comment by jus...@dynam.ac
on 11 Aug 2014 at 10:29
That's weird.
I excluded the device from the controller, then I made reset on the zstick
controller and to the doorlock.
After that I cleaned the xml file to have a clean environment.
Restarted my program and included the lock successfully. Then I sent some
commands and nothing happens
Original comment by santal.m...@gmail.com
on 11 Aug 2014 at 10:44
I don't understand why you say that:
2014-08-10 22:42:03.643 Info, Node004, Response RTT 1197 Average Response RTT
1192
2014-08-10 22:42:03.643 Info, Node004, Received SecurityCmd_NonceReport from
node 4
2014-08-10 22:42:03.644 Info, Input Packet: Packet: 0x00, 0x98, 0x06, 0x01,
0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e,
0x0f, 0x10
2014-08-10 22:42:03.644 Detail, Node004, Queuing (Security)
SecurityCmd_MessageEncap (SecurityCmd_NetworkKeySet) (Node=4): 0x01, 0x2d,
0x00, 0x13, 0x04, 0x26, 0x98, 0x81, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
0xaa, 0x0e, 0x0f, 0x10, 0xc6, 0x52, 0xd4, 0xa1, 0xd6, 0xb1, 0xb5, 0x51, 0xc3,
0xc1, 0x59, 0x8a, 0x6b, 0x40, 0xd3, 0x91, 0x24, 0xa1, 0x75, 0x16, 0xf2, 0xcf,
0x36, 0xe8, 0xfe, 0x25, 0x07, 0xe8
2014-08-10 22:42:03.644 Info, Node004, Reseting Network Key after Inclusion
2014-08-10 22:42:03.644 Info, Node004, Using Configured Network Key
(AddingNode: true KeySet: true)
2014-08-10 22:42:03.644 Detail, Node004, Expected reply and command class was
received
2014-08-10 22:42:03.644 Detail, Node004, Message transaction complete
This seems like they are communicating. Or am I wrong?
Original comment by santal.m...@gmail.com
on 11 Aug 2014 at 10:49
After we send a SecurityCmd_NetworkKeySet we should get a
SecurityCmd_NetworkVerify - thats why I say its not responding correctly.
We are talking to the Lock Unencrypted fine - But most of the command classes
require encryption - so things are not working correctly.
When you say you reset the lock - its more than just "excluding" it from the
Network right? I imagine there is some "factory reset" button or code or
soemthing?
Can you test pairing hte lock with HomeSeer? (then copy the Network Key from
the zwave.ini file in HomeSeer to the options.xml file and fire up OZW and see
if it works)
Original comment by jus...@dynam.ac
on 12 Aug 2014 at 4:27
Yes, I've done a factory reset.
I will try homeseer.
Original comment by santal.m...@gmail.com
on 12 Aug 2014 at 8:32
It worked.
But that is not a solution? I want to be able to include and work with it.
And it seems to be to slow to a 1 device only network. I tell it to lock and it
take about a 1 minute or two to assume the command.
What can be wrong :(
Original comment by santal.m...@gmail.com
on 12 Aug 2014 at 9:24
You didn't state if it's working with 1) OZW or 2)Homeseer, or 3)it worked with
Homeseer, you copied the network key to OZW and now you can control the lock.
If 3, then it is a solution! Albeit not a OZW one!
As for the slow response, I assume your referring to OZW. In that case, make
sure that your testing that after OZW is fully started. If your testing
immediately after starting your app, OZW is going through its probe stages, and
your commands will be at the end of the queue.
Original comment by jus...@dynam.ac
on 12 Aug 2014 at 4:37
It worked with homeseer and I copied the networkkey and it was working fine on
ozw too. Although on Ozw it was extremelly slow taking about a minute to reply.
Yes that is not the solution I want. I want to be able to include the device
and use it with my ozw application.
Why didn't it work. Do you have any clue?
And thanks for the hint
Original comment by santal.m...@gmail.com
on 12 Aug 2014 at 4:45
So, is there any solution for including this device correcly on ozw?
Original comment by santal.m...@gmail.com
on 18 Aug 2014 at 2:54
right now - I need to do some more testing with a rpi and other Locks. Thats
going to take a while, as I neither own a rPi, nor any other locks.
but I believe the rPi isn't fast enough for it to complete the Network Key Set
within ~10 Seconds of inclusion (yours is right on the limit - So that might be
the issue).
Original comment by jus...@dynam.ac
on 20 Aug 2014 at 3:36
And as you can include via HomeSeer and then it works correctly - Then I don't
consider this "broken" right now... If you do the inclusion with homeseer, copy
the network key to OZW Options.xml and fire up OZW, then its the same as doing
the inclusion with OZW.
Original comment by jus...@dynam.ac
on 20 Aug 2014 at 3:37
This latest tests I done was on a desktop... So it's not rpi related... I
am running a Intel i7 at 2.8Ghz with debian 7
Still it fails so I believe something is wrong.
2014-08-20 16:37 GMT+01:00 <open-zwave@googlecode.com>:
Original comment by santal.m...@gmail.com
on 20 Aug 2014 at 4:16
Its taking just over 10 seconds. I believe the time-out is less than 10
seconds. without physical access to the lock, not much more I can do at the
moment.
Original comment by jus...@dynam.ac
on 20 Aug 2014 at 4:24
I can help, what would you want me to do with the lock to test or do?
I have programming skills so maybe I can help, I'm just a little bit
unaware of the security process
2014-08-20 17:24 GMT+01:00 <open-zwave@googlecode.com>:
Original comment by santal.m...@gmail.com
on 20 Aug 2014 at 4:26
Definitly something is wrong on this lock...
Here goes another log
I'm pretty sure that I have a fast machine, the device is on high_power
inclusion, I have the lock right on the side of the zwave stick... still it
takes too long and nothing has been done. What can be wrong here?
What can I do to help you debugging this?
2014-08-20 17:26 GMT+01:00 Diogo Alves <santal.maluko@gmail.com>:
Original comment by santal.m...@gmail.com
on 20 Aug 2014 at 9:06
Essentially, you need to figure out why it doesn't respond to the
NetworkKey_Set command.
There is no Log attached, so nothing I can look it.
Original comment by jus...@dynam.ac
on 21 Aug 2014 at 5:33
Sorry forgot to attach:
Original comment by santal.m...@gmail.com
on 21 Aug 2014 at 8:50
Attachments:
In the log it's 11 seconds between discovery and the networkkey_set command.
That's inline with the 10 second timeout I suspect.
Can you capture the serial port traffic with Homeseer and send to me? (With the
network key Homeseer is using)
Original comment by jus...@dynam.ac
on 21 Aug 2014 at 9:43
I can do it later tonight.
I will then post here the logs.
Thanks for the suggestion!
2014-08-21 10:43 GMT+01:00 <open-zwave@googlecode.com>:
Original comment by santal.m...@gmail.com
on 21 Aug 2014 at 11:05
Please try revision 885 - I've tried to reduce the discovery time during a
AddNode Command.
If it doesn't work, please:
"make clean"
"BUILD=debug make"
and then link with your application, and send me the full logs.
Original comment by jus...@dynam.ac
on 21 Aug 2014 at 2:37
Hello
Here is the result on the homeseer
I will try those changes you posted now
This log is all the inclusion process
The network key is
Key=A1-FF-13-14-14-2B-F8-B7-3C-40-31-7-C7-5F-CA-32
Original comment by santal.m...@gmail.com
on 21 Aug 2014 at 11:14
Attachments:
Just tried the update.
it took about 7 seconds but it still doesn't secure the device.
Has the exact same behaviour but it's faster
I hope that the raw dump from home seer can you :(
Original comment by santal.m...@gmail.com
on 21 Aug 2014 at 11:32
Can you do the debug log like I asked please?
Original comment by jus...@dynam.ac
on 22 Aug 2014 at 1:31
hey, I found out that I did not linked the library... and have marked the
timming in a wrong way
Now I paired the lock, unfortunatly I can't lock or unlock (I could do it
before with the homeseer inclusion)
I will post here the config file I've created for it (maybe I have something
wrong)
The inclusion log and the lock command log
PS1: That was a great work you've done
PS2: Beware version 887 is not initializing properly and throws and
segmentation fault
Original comment by santal.m...@gmail.com
on 22 Aug 2014 at 10:40
Attachments:
this time it does set the NetworkKey Correctly - So it seems timeouts might
have been a issue:
2014-08-22 11:30:40.051 Info, Node020, Received SecurityCmd_NetworkKeyVerify
from node 20
But Getting the Associations Failed. (in all the examples).... It just doesn't
respond. this is critical in OZW, so no reply means that OZW essentially hangs
on that stage for that node. hence why it wont lock. (cause its stuck in that
stage)
In the Lock-Unlock file, it almost appears if the device has gone to sleep -
Its not even responding to NONCE_Get messages, and thus the entire security
queue hangs up.
(if it doesn't respond to NONCE_GET we can't even send a Encrypted message. Its
fundamental to the device.)
the 'config' you posted is not really a config file. Its from zwcfg_*.xml.
Which despite its name, is NOT a config file. whenever you are testing, its
much better if you can remove the zwcfg_*.xml file between runs. Its not
critical and will get recreated.
If you putting that danalock.xml file into the config/danalock/ etc directory,
its will mess things up. you don't need any config file as of know, but as we
move along, we might end up creating one.
can you do a "inclusion" with homeseer, remove any zwcfg_*.xml file, and
startup OZW with the right network key... lets see what is different... if any.
Finally, 887 is working fine for me. Can you get a backtrace of your crash?
Original comment by jus...@dynam.ac
on 22 Aug 2014 at 2:50
Great! I will do that.
I would really like to learn more about openzwave internals. I seems to
have a loooooot of features but some are still unknow to me, plus I'm using
the py-ozw so I'm not handling with the openzwave code too much
2014-08-22 15:50 GMT+01:00 <open-zwave@googlecode.com>:
Original comment by santal.m...@gmail.com
on 22 Aug 2014 at 3:03
Hey Justin,
With 884, 885 and 886 my Kwikset locks no longer work which seems similar to
what has been posted in this thread.
As worked for me in previous builds, I tried playing the the MAX_TRIES and
RETRY_TIMEOUT but thats not helping either this time.
Attached is my log.
Can you tell me what might be going on?
I will try to remove and re-add the locks to the network to see if that makes
any difference.
Anything else I can do to help you find the problem?
Thanks,
TJ
Original comment by TJTrolin...@gmail.com
on 22 Aug 2014 at 3:37
Attachments:
TJ: Readd as I posted in the other forum. Its failing the Decryption when we
receive messages back, which indicate the Keys got out of whack.
Original comment by jus...@dynam.ac
on 22 Aug 2014 at 4:06
Hello,
after removing the config the lock is wrong fine.... it just hangs for
sometime because it is not accepting the BasicCmd and it retries 3 times...
since each retry takes 20 seconds it takes a minute sometimes
2014-08-22 17:06 GMT+01:00 <open-zwave@googlecode.com>:
Original comment by santal.m...@gmail.com
on 22 Aug 2014 at 6:51
I removed the two locks.
Did a factory reset on both.
Added the first one with no problems and was able to lock/unlock.
Then tried to add the second one about 10 times with no success.
Then after a restart couldn't communicate with the first one again.
It seems to be always the same issue waiting for a reply to "Security message".
I am at a loss what to do next.
2014-08-23 15:26:55.785 Info, Node028, Sending (Security) message (Callback
ID=0x17, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association Set)
(Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa, 0xaa,
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41, 0x6f,
0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x17, 0xea
2014-08-23 15:26:55.785 Detail, Node028, Received: 0x01, 0x04, 0x01, 0x13,
0x01, 0xe8
2014-08-23 15:26:55.785 Detail, Node028, ZW_SEND_DATA delivered to Z-Wave
stack
2014-08-23 15:26:57.018 Detail, Node028, Received: 0x01, 0x05, 0x00, 0x13,
0x17, 0x00, 0xfe
2014-08-23 15:26:57.018 Detail, Node028, ZW_SEND_DATA Request with callback
ID 0x17 received (expected 0x17)
2014-08-23 15:26:57.018 Info, Node028, Request RTT 1232 Average Request RTT 1224
2014-08-23 15:27:06.424 Detail, Node028, Received: 0x01, 0x0c, 0x00, 0x49,
0x84, 0x1c, 0x06, 0x04, 0x40, 0x03, 0x72, 0x86, 0x98, 0x0f
2014-08-23 15:27:06.424 Detail,
2014-08-23 15:27:06.424 Info, Node028, UPDATE_STATE_NODE_INFO_RECEIVED from
node 28
2014-08-23 15:27:06.424 Detail, Node028, AdvanceQueries queryPending=1
queryRetries=0 queryStage=Associations live=1
2014-08-23 15:27:35.799 Detail,
2014-08-23 15:27:35.799 Info, Node028, Sending (Security) message (Attempt 2,
Callback ID=0x18, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association
Set) (Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa,
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41,
0x6f, 0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x18, 0xe5
2014-08-23 15:27:35.830 Detail, Node028, Received: 0x01, 0x04, 0x01, 0x13,
0x01, 0xe8
2014-08-23 15:27:35.830 Detail, Node028, ZW_SEND_DATA delivered to Z-Wave
stack
2014-08-23 15:27:37.032 Detail, Node028, Received: 0x01, 0x05, 0x00, 0x13,
0x18, 0x00, 0xf1
2014-08-23 15:27:37.032 Detail, Node028, ZW_SEND_DATA Request with callback
ID 0x18 received (expected 0x18)
2014-08-23 15:27:37.032 Info, Node028, Request RTT 1232 Average Request RTT 1228
2014-08-23 15:27:48.357 Detail, Node002, Received: 0x01, 0x0b, 0x00, 0x04,
0x00, 0x02, 0x05, 0x31, 0x05, 0x01, 0x09, 0x4d, 0x86
2014-08-23 15:27:48.357 Detail,
2014-08-23 15:27:48.357 Info, Node002, Received SensorMultiLevel report from
node 2, instance 1, Temperature: value=77F
2014-08-23 15:27:48.357 Detail, Node002, Initial read of value
2014-08-23 15:27:48.841 Detail, Node002, Received: 0x01, 0x09, 0x00, 0x04,
0x00, 0x02, 0x03, 0x45, 0x03, 0x00, 0xb5
2014-08-23 15:27:48.841 Detail,
2014-08-23 15:27:48.841 Detail, Node002, Initial read of value
2014-08-23 15:27:48.841 Info, Node002, Received thermostat fan state: Idle
2014-08-23 15:28:15.813 Detail,
2014-08-23 15:28:15.813 Info, Node028, Sending (Security) message (Attempt 3,
Callback ID=0x19, Expected Reply=0x04) - SecurityCmd_MessageEncap (Association
Set) (Node=28): 0x01, 0x1f, 0x00, 0x13, 0x1c, 0x18, 0x98, 0x81, 0xaa, 0xaa,
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x46, 0x7f, 0x0f, 0x61, 0xb3, 0x97, 0x41,
0x6f, 0x46, 0xa4, 0x40, 0xfe, 0xd1, 0xe6, 0x25, 0x19, 0xe4
2014-08-23 15:28:15.845 Detail, Node028, Received: 0x01, 0x04, 0x01, 0x13,
0x01, 0xe8
2014-08-23 15:28:15.845 Detail, Node028, ZW_SEND_DATA delivered to Z-Wave
stack
2014-08-23 15:28:17.046 Detail, Node028, Received: 0x01, 0x05, 0x00, 0x13,
0x19, 0x00, 0xf0
2014-08-23 15:28:17.046 Detail, Node028, ZW_SEND_DATA Request with callback
ID 0x19 received (expected 0x19)
2014-08-23 15:28:17.046 Info, Node028, Request RTT 1232 Average Request RTT 1230
2014-08-23 15:28:55.827 Error, Node028, ERROR: Dropping command, expected
response not received after 3 attempt(s)
2014-08-23 15:28:55.827 Detail, Node028, Removing current message
Original comment by TJTrolin...@gmail.com
on 22 Aug 2014 at 10:28
Yes... I have the same problem with the attempts.... it messes with all my
network... I would like to have something to turn off that message.... so it
would not mess with everything....
Original comment by santal.m...@gmail.com
on 26 Sep 2014 at 10:42
Original issue reported on code.google.com by
santal.m...@gmail.com
on 10 Aug 2014 at 10:11