+- 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 - 11-10-2017
In my case though it's a two device system, just the stick and the lock, so it would have to be a direct, route. And they are a few feet apart.
RE: Official 5.3 Beta Discussion Thread - kfly - 11-10-2017
(11-10-2017, 09:21 AM)Dean Roddey Wrote: In my case though it's a two device system, just the stick and the lock, so it would have to be a direct, route. And they are a few feet apart.
Hope you just have a bad Z-stick and can move forward.
RE: Official 5.3 Beta Discussion Thread - batwater - 11-10-2017
Dean any chance that the 2 piece scenario is the issue? I would think not but for my install I have several other devices in the mesh that relay the security protocol. From day 1 with the Yale locks I had a light switch in the mix that forwarded the messages. Thinking outside the box.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-10-2017
Oh, yeh, I originally had other modules in the mix so that I could test them. But when I started having issues with the lock I paired it down to just that. So I've done lots of tests both ways.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-10-2017
I didn't make it to Wally World today. I'll go tomorrow. If you're going to go to Wally World, you should always go on a weekend day to make it as annoying and uncomfortable an experience as possible.
So I just worked on the RA2/Caseta client driver today, and I think I have the code basically written. I'll test it out tomorrow and finish it up. It's crazy how much I was able to condense the amount of code involved compared to the old one. It'll be nice to start getting more of the old client side drivers converted over, though it's time consuming enough that I'd only do one once every now and then.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-11-2017
Well I powered hub didn't make OZW any happier. It acts exactly as before. I'll try it with my driver. If it's still the same I guess I'll order another Z-Stick.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-11-2017
Well, I've made a little progress. This new lock has one good sanity check. It has a light that lights up when it wakes up. So I know it's nothing to do with the beaming stuff. Clearly it's waking up when I talk to it. And, as long as I don't stop the driver it seems like I can talk to the lock reliably most of the time, which is back to where I was a while back. I'm able to do my little probe thing and get all of the info, including the secure stuff. Of course that could change at any time for no apparent reason.
But, once I stop and restart the driver, it doesn't respond to secure messages anymore.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-12-2017
So, as I'd sort of figured out randomly before, the lock will wake up if I send it a node information query. If I just send it a lock command, it never even seems to wake up, and I get no response. Sometimes it sends back a nonce, but that seems to be only after a replication, and even then sometimes it doesn't respond to the subsequent commands.
The Vizia RF software can always control the lock. It never fails. The light comes on and stays on for the whole operation, which takes three or four seconds, and actually stays on for a second or two after the lock changes its state. When I do my probe stuff, I send it a node info query which wakes it up, but the light goes right back off again most of the time and the subsequent msgs fail.
So clearly it knows something that neither I nor OZW knows, because neither of us can control it or get it to respond to any secure messages except once in a while I get it to respond after a replication, but that's because during the replication I send it a node info query as part of getting info on what is out there.
RE: Official 5.3 Beta Discussion Thread - znelbok - 11-12-2017
Hey Dean - I have been doing a bit lately with the HTTP trigger driver and a thought hit me this morning. At times I need to set variables in the variables driver as indicators that something has happened - so, would it be possible to add fields to the trigger driver to "internalize" it all. The trigger may be as simple as setting a field for the same driver on and off, or writing the value of the parameters to (ActionParm2).
Would this be an easy upgrade to the driver - I think it wold make it more versatile and for those watching driver counts it may be a way to reduce the driver count marginally.
This could apply equally to all trigger drivers really as I assume they re built on the same back end code.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 11-12-2017
You can already do that. All of the trigger driver instances on a given machine will share a global variables space. You do need to be a little careful if you have multiple instances of trigger drivers on the same machine that they don't step on each other's toes.
Maybe, ultimately, it would be better to just give each driver instance its own global variable space. But most folks probably never run more than one so as a practical matter it won't be an issue.
Anyhoo, in the meantime, just use global variables to store that sort of state.