Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Official 5.3 Beta Discussion Thread
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
It's something to look at. I don't know if they improved anything or just added an IP interface. The UPB interface, it looked to me from what I've seen looking at the driver, isn't great. If they also improved that in the process, it might be worth taking on a new driver and taking advantage of those improvements.

Anyhoo, in the meantime, for some reason today the lock is responding to my messages. I just locked and unlocked the lock via the driver. I'm not sure what changed, which is sort of not optimal. But at least it's working now. I also made a big improvement in how the XML info files pass in handler specific info to get rid of what would have ultimately become a lot of busy work.

Oh, so I just restarted the driver and now it's not reponding again. The driver had been up a while after the new replication pass but I could still talk to the lock. Clearly the lock hadn't just stayed awake all that time, just because it had been woken up by the master during replication. So there may be something going on with the management of the encryption key or something and I'm not getting it loaded back up correctly when the driver loads next time.
Well, actually it just worked that one time, perfectly, then hadn't worked again all this time. And now it just worked again, after a replication. I've let it sit there for some time, longer than it would have stayed awake just due to the replication pass I think, and it is responding perfectly. I restarted the driver, and now it won't respond.

That's seriously weird.
Well, I've spent days and I cannot figure out the above issue. I can only talk to the lock securely after a replication has been done. Once the driver stops and restarts, it can't talk to it. I can do the replication process again after the driver starts back up and it starts working again. But I can't automatically do a replication when the driver starts, because it requires the master controller to start that process.

It makes no sense to me at all why this is the case. I guess the master is sending the Z-Stick something during replication that it loses when the driver stops, though that makes no sense to me. It wouldn't even know if the driver is there or not. The only difference is that the driver will sometimes send it commands when its running. The driver isn't directly connected to the Z-Stick, it's just talking to it via a virtual serial port. And the only thing really related to secure comms is the network key, which I have stored away load up again when the driver starts.

If the driver was not running for a while then I could see maybe the master deciding it's not responding and putting it on some sort of dead node list, but even I stop and restart the driver as quickly as possible, way too quickly for such a thing to happen, I can't talk to the lock securely again.

If it didn't respond at all, I'd think maybe it was just something to do with the whole beaming thing, which is something I wasted a LOT of time on earlier thinking that was the case. But it wakes up and responds just fine to non-secure messages. And it even responds to the request for a security nonce that is needed to send it back a secure message. So it's responding, it just ignores secure messages as though my network key is wrong, but it's exactly what I was given during the replication phase.

I dunno, this just keeps happening and I'm sucking up time and more time on this thing. It's depressing and infuriating at the same time, which is always a nice combination. I'm not sure if it's wise to continue down this path any further or not.
Well I woke up this morning to my neighbor's house burning down. That was exciting. In the three years I've been here, that's the third time I've had a yard full of emergency vehicles blaring away (two ODs and now a fire.) But, at least that means he's not my neighbor anymore since the house is gutted. My place smells like a chimney, though it's starting to go away. Luckily it was a cool, drizzly morning, so everything was already soaked. So it was contained inside the house and didn't threaten my place. Still a bit of a heart rush moment to wake up to. I was standing ready to grab the computer and make a run for it.

I just had the yearly wake up in a fire panic thing last week, which happens every year when the heater does its first defrost cycle of the year and burns the dust off. So at first I didn't think anything, then it got really strong fast. I jumped to look around and nothing was going on. I stuck my head out the door and it was just a wall of smoke.
What lock are you testing? Some of the firmware for those devices are buggy.  Does it work with another model of zwave lock?
Assume you did a firmware reset of lock?

Seems lots of issues with locks. Any use in testing with the OZW driver?
If it were just no working generally, I'd think maybe something with the lock. But the fact that it always works now after a replication, and will do so for as long as you want, but then stops working when I cycle the driver (which the lock couldn't possibly know about), that tells me it's almost certainly me somehow. And of course the fact that it will always respond to anything non-encrypted.

The gotcha with OZW is that it's a master controller. It doesn't even have an option to work as a secondary, so it doesn't do any of the same things that I need to do. It's on the other side of all of that.

I could try to make this driver a master, but it wouldn't be optimal. You really want a portable master for inclusion purposes. A driver like ours is definitely best done as a secondary.

I spent most of the day yesterday just trying to come up with things to even try. I didn't come up with many and none of them worked. I proved it wasn't me messing up the key. I can do a replication, and it starts working, and then while the driver is still running I can set the key again just as I would when the driver comes up, and it continues to work. So obviously I'm doing the right thing with the security key.

It's got to be something I'm not doing when starting up, or something I'm not telling others about or something like that. Or something else I'm supposed to store away and reset on the Z-Stick. But it clearly knows it's still in the network, since it maintains the home id and controller id, and it can communicate with the other modules non-securely. The Z-Stick doesn't know anything about the network keys. It's always somewhat confusing about what the Z-Stick does at a low level as a Z-Wave node, and what I have to do, but I know it doesn't know or care about the key so I shouldn't have to tell it anything about that when I start up.

So I'm at a loss as to what I'm failing to do or say.
I tried various things today, and made things much worse and ended up reverting back to yesterday's code. I looked through a lot of example code and didn't find anything that jumped out at me as useful.
Ugh... I finally dug into OZW enough to get their little test program built and enough to make a few changes to it to get the lock added. And it also doesn't get a response from the lock. So all these days and it may be the lock is bad or something. I guess I should have bitten the bullet and gotten another secure unit. But the only ones are locks I think and they are pricey so I didn't want to buy two just to have two.
I realized that OZW needs to have a key set on it before it will act as a secure master controller, so of course it couldn't talk to the lock because it was talking to everything insecurely. So I set a key on it and now it acts just like what I'm seeing. Non-secure messages work, including asking for a security nonce to send a secure msg, but it won't respond to secure msgs. So OZW gives up on it as a secure device and just adds it non-securely and nothing else after that works (at least nothing that involves getting or setting the lock state and such.)

That's exactly what I'm seeing, so I guess this lock is legitimately not happy.
I ordered another lock, different model. If that guy acts the same, then obviously that points to me or my system or maybe the Z-Stick. If it works fine, then I'll assume the first lock is screwed. In the meantime I'll move forward on other parts of the driver that don't involve locks or security.