+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: General Discussion (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=3)
+--- Forum: Beta Discussions (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=12)
+--- Thread: Official 5.3 Beta Discussion Thread (/showthread.php?tid=10397)
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-04-2017
So I did it again, reset everything back to ground zero, added the stick first, added the lock, updated the stick to see the lock. I did the node info query and was shocked when it worked. So I tested the lock/unlock commands and they worked as well.... for about 3 or 4 minutes, and then I couldn't get it work again, and it hasn't since.
So another completely random data point that points in no particular direction.
RE: Official 5.3 Beta Discussion Thread - jkmonroe - 12-04-2017
Dean, how are you using the z-stick?
I haven't followed along in the details, but are you using your Leviton USB stick as a master and replicating to the z-stick?
Two things - and you probably have more insight than I -
(1) don't you need to go into the lock and manually set the association if youre using the stick as a 'secondary'? Back when I was going through all of the z-wave nonsense, it became apparent that Leviton wraps a lot of what should be typical classes in manufacturer specific wrappers, and it doesn't replicate correctly from the Leviton software. As soon as I got the Leviton VRUSB/software out of the equation, I could make z-wave work in a typical fashion (see the work I did on getting ST as a master to the VRC0P).
(2) why not use the z-stick itself as the master controller and write the driver around the in-built API? wouldnt that just keep the whole shebang on the stick, negating the need to write a complicated driver with the security messages? similar in a way to how the VRC0P would act ... walk around with the stick to add your network, plug it in and load up the driver in API mode.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-04-2017
Associations are only related to getting a module to report state changes to some other node. So this isn't to do with that. In this case I'm talking directly to the lock to get information from it or telling it to change its state.
Making the Z-Stick the master is much more complicated and it raises a lot of issues for folks who want to use something else as the master, or are already using something else. Letting the Z-Stick be a secondary controller means that CQC can just slot into any existing Z-Wave network. And it should work just fine. It does work just fine except for this one issue with locks. And it also lets you keep a separate, portable master for going around and doing inclusion/exclusion as well. So you can unplug the master any time without affecting the network, and CQC/Z-Wave will continue to work just fine. Take it around do make changes, then bring it back and sync CQC/Z-Stick with the changes.
RE: Official 5.3 Beta Discussion Thread - kfly - 12-05-2017
Dean, That Fact it works for 4 mins is a good sign and just missing a small piece  of missing information in order to solve the puzzle.
Reminds me of the time(20 years ago) when I was managing a global network of remote Unix servers. Once a month the server would crash and only in the winter and at random times during the day. I replaced everything:Server,Software,UPS,everything....  And it still happened. I even suspected deliberate sabotage by a disgruntled local branch employee. For us Tech people it drives us crazy when something is happening that makes zero logical sense. 
The key bit of advice I was giving was "When all the logical causes are exhausted look at the illogical causes again". The key to solving an impossible problem is to keep gathering data until you find the missing piece of information that solves the puzzle.
Turns out this deep technical problem I had was solved with the help of a non technical branch secretary. She noticed we had a branch outage on he same day each month that she rotates the backup tapes. I told her that couldn't be it as we have thousands of servers doing this same backup routine every month. But that was the missing information I needed to solve the puzzle.
Bottom line was it was an environmental problem. In the winter she walks from her desk to the server cabinet and builds up static electricity. When she opens the cabinet door and puts the tape(metal bottom in those days) into the drive the server crashes. Easy fix: Grounding strap installed on the cabinet door especially in Minnesota were they have cold dry winters.
So how does this relate? keep gathering data. How about changing the environment(I know it makes no sense). Let a few people do a test in their environment and see if any more information can be gathered to help solve. 99% chance it will not help... but.... 
Kevin
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-05-2017
Well, it may be bogus, but I've to it to the point where, after a replication pass it works. But as soon as I stop the driver and start it back up again, it is back to the same old same old, where it won't reply to secure msgs. That's obviously better than never working, but still useless in any practical terms. There has to be something the master controller is doing during the replication process that is allowing it work, something maybe it's telling the lock I guess. I don't have to remove and re-add it, I just have to do another replication pass, the sort you'd do if you need to get CQC updated with changes you've made on the master.
Actually it still doesn't respond to secure msgs, I have to send it some non-secure msg before any secure msg, or it won't work. There's a 'no-op' type msg that I use for that. It shouldn't be necessary, based on other examples but it clearly won't work for me unless I do that. It's way lower overhead than the node info query I was doing before to get it to wake up. But clearly the fact that it works in that case means that my security stuff is right. The problem, though it only seemed to affect secure messages, must be elsewhere. If the secure msgs were wrong it wouldn't respond to them just because something non-secure was sent just before. For whatever reason the lock just won't wake up for a secure message, which seems stupid. Maybe secure precludes beaming, I dunno. Doesn't seem like the hardware would know or care if it's secure, and I'm fairly certain it doesn't.
One thing that made a difference is that I saw that some other folks were changing the timeouts that are set at the hardware level, to what to me seem pretty ludicrous values. But I tried it and that seems to have helped a lot, which allowed me to start actually seeing other stuff that I guess had been timing out before which let me find issues in those.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-08-2017
I took a couple days off of Z-Wave and worked on some GUI and utility stuff that I needed to get done. One was to move the old command line field extraction tool into the AI. So now you can click on a driver or a driver host and select to export fields to the standard XML format that the variables driver will import. This is used to create simulations of systems for offline work or pre-development before going on-site and such.
And I put some more time into replacing the stupid multi-line list box control. I got a new scroll bar control wrapper class done which it needs, and might have other purposes. And I have the control basically laying out its child windows correctly with the header control I did before, the h/v scroll bars, and the display window.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-08-2017
I have to give a shout out to these guys:
https://www.youtube.com/watch?v=LhCHQPricjo
They do some very good covers. Here they are doing Yes' Starship Trooper, which one of the most epic prog rock songs in the canon, and really do it well. That's not an easy thing. They have a crew of folks who kind of rotate through for various songs to fit the need.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-10-2017
I went back and dug into the OpenZwave stuff again enough to set up a slightly more useful test. It does seem now to be able to control the lock. Of course it's the master controller and I've already seen that the Vizia RF master controller can do that. But, it at least proves that something else can control it. And I can look through the OZW logs and see what it is doing for maybe some clues.
RE: Official 5.3 Beta Discussion Thread - kfly - 12-10-2017
(12-10-2017, 06:02 PM)Dean Roddey Wrote: I went back and dug into the OpenZwave stuff again enough to set up a slightly more useful test. It does seem now to be able to control the lock. Of course it's the master controller and I've already seen that the Vizia RF master controller can do that. But, it at least proves that something else can control it. And I can look through the OZW logs and see what it is doing for maybe some clues.
Can you open a ticket. If they don't respond I bet we can help push them for some info on why the stick/lock acta different as a secondary controller.  
https://aeotec.freshdesk.com/support/tickets/new
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 12-10-2017
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.