(12-10-2017, 09:18 PM)Dean Roddey Wrote: [ -> ]I imagine the answer to that is, buy the SDK, that's proprietary information. I'm pretty sure it's nothing to do with them. They are really just a passthrough. And, what makes it even more unlikely they'd say is that it works after a replication perfectly. It's only after stopping the driver and starting it up again that it doesn't work. The answer clearly is in that somehow, but I've not been able to figure out what it is.
Seems like of issues with Aeotec and zwave of secure devices.
https://groups.google.com/forum/#!search...dTk4VNGgAJ
Even though not really related as it is your driver, a general post of what you are seeing with a lock(working then not working)  may jog someones memory about undocumented or mis-documented behaviors with secure zwave devices like locks.
https://groups.google.com/forum/#!forum/...ecommunity
But it does work with OZW now. I didn't do extensive banging on it, but I can start and stop OZW on the Z-Stick and engage and release the lock just fine, and I see it doing plenty of secure transactions against the lock. The only difference is it's a master and I'm a secondary.
I may just do the absolute minimum work to implement enough master controller stuff to add the lock to my own network and see if that makes any difference. If not, then that points in one specific direction. If so, it points in another specific direction.
OMG, I'm going to shoot myself! So, I just kept thinking about how I could cull out various possibilities. So I set up the poll callback, after a certain number of passes, to return a lost comm res to force the driver to recycle. This would let me do a replication, which makes it start working, and verify that I can lock/unlock, then wait for it to cycle.
That would, in any sense that could be explained by physics or myth, be the same as stopping and restarting the driver, from the point of view of the Z-Stick. And, after it came back up, it still worked. So CLEARLY it had nothing to do with the stopping and starting of the driver. And I'd proven to myself repeatedly that I was doing the right thing wrt to the security stuff. That wasn't leaving many possibilities.
So I went back and carefully looked at what I do in the context of a replication and what I do in the context of starting up the driver. There was one difference. In the replication, I discovered by random experiment that I have to broadcast out my product ids (I'm a Bubba's Big Door Knob, those types of ids.) So, I added the same broadcast on driver startup, and the freaking thing works.
I also was doing that broadcast during the driver startup at various times during the past month just to see if it helped, but probably something else was wrong at that point. So I removed it again thinking it wasn't relevant and I didn't want to just do things randomly that I wasn't sure about the effects of.
No where, anywhere, did I see any mention of this as a requirement in general. I tried it at the end of the replication at some point and it got the master accepting the replication. I just assumed that the master needed to get that info during replication in order to know what exactly is joining the network and that it would store that info away. I wouldn't have though it would be needed after that. But, apparently, that does something to nodes to make them come talk to our Z-Stick node and get whatever info is required to make them happy.
The weird thing is, how the heck does the lock know we closed and reopened the serial port on the Z-Stick? That's the only thing that even the Z-Stick could possibly sense, much less the lock. Or maybe something about the process that had the Z-stick open stopping causes something in the faux USB serial port driver to change that the Z-Stick senses and that causes it to change state in some way that makes use look like a dead node and we have to re-introduce ourselves. I dunno.
But, something obviously happens and that broadcast gets us back into the club. I've now been locking and unlocking the lock, and doing node info probes on it, which gets all its information and does lots of secure exchanges. I've stopped and restarted the driver a number of times and it continues to work.
I'm not gonna lie. I may have cried a little bit. Now of course I have to go back and try to get this driver, which now has more jumper wires and patches on it than I can count because of all of the random trial and error stuff I've been doing, back into some rational shape and start moving forward again. I'll have to be careful so as not to make a bunch of changes and suddenly it stops again for some other reason and I can't figure it out again.
I currently have the time outs stupidly high so I need to start moving those down to the point where they stop working and then bump them back up again for something with some safety margin, but so that it doesn't come to a complete stop if there's a bad node.
Sounds like you have found the missing piece to the Zwave/Lock puzzle.  That's great news!
┬á ┬á "ItÔÇÖs not that IÔÇÖm so smart, itÔÇÖs just that I stay with problems longer. -┬á┬áAlbert Einstein"
Congratulations Dean, or should I say Thomas Edison ÔÇ£I have not failed. I've just found 10,000 ways that won't work.ÔÇØ
I'm banging away hard on the Z-Wave driver. Based on the stuff I learned in my descent into the dark side, I'm doing some significant reorganization again, to try to simplify it, which Z-Wave very much needs as much of as possible. Now that I know it's not wasted time I can really dig in and make sure it's as good as I can get it.
There's this tension between wanting to get the driver up as quickly as possible, vs wanting to get as much info as possible on all the units, to make sure nothing has changed while the driver was away. With a larger network, and the amount of info required, it's a lot of overhead to try to really get everything when it comes up. So I'm sort of walking a middle line.
The security stuff requires that much more overhead, because you have to get more info up front to know what stuff you have to get securely and what can be gotten non-securely, since each unit can be different. And security exchanges add a lot of overhead to whatever is already there just to send the actual msgs themselves.
I had some videos sort of running in the background, half watching last night, those types that are the deep canonical background of Star Wars stuff. Do Pinto Beans increase mitoclorian (sp?) counts? Did Darth Vadar's helmet support lossless audio streaming? Those kinds. I had the most bizarre dreams afterwards, even by my standards.
Nice work Dean! This one just didn't want to give it up.
I've done the work, I think, to handle the two big scenarios of how to make sure we are still in sync upon startup and how to deal with newly added/removed units upon an inclusion or re-inclusion (to pick up changes), without having lots of redundant code, and as simply as possible so that it's not a 'fix one thing, break two things' type of deal moving forward. There are lots of nitpicky bootstrapping issues.
I'm just working my way forward through that code now, finding an issue, fixing it, doing it again, until I get this stuff back up to where I was before and test it out well. At that point, I'll feel comfortable moving forward with getting a very basic driver in place (with a working client side interface) that I can put out there for some folks to try. It won't support much in this original configuration. Of course that will also let some of you run my little probe on the stuff you have and get the info required to add support for them.
Just to reconfirm, this new driver will use the Aeotec Gen 5 USB stick as a slave, correct?