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.
Are you sure you are doing what is required to wake it up? Maybe it has a button you have to press or something? You don't need to do anything on the CQC side. If you wake it up, it sends a wakeup notification. The driver sees that and immediately starts talking to it. As long as it is talking to the device it should stay awake. Or, actually, if you do the battery thing, it sends out a node info broadcast, so that the driver doesn't have to be already associated with it. Everyone sees the node info broadcast, and the driver reacts to that the same way, since when that gets sent it out means that device has come online and all units basically stay awake for a while at that point as well, so the driver there again starts interrogating it.

It may be not so great comm or something. You can reset the log, do the battery, wait 15 seconds, then close the log and post it. We should see what happened.
There's a 907 B revision posted now. The installer comments will indicate the B revision. This one is one small fix and a number of new units supported. See the release thread for which ones. One of those won't work right yet, since I need some more info, the Linear dual window/door sensor one.
Dean, I installed 907b and the wired units filled in properly, Evolve and the Wayne Dalton light switches. None of the battery units are showing up ready to approve I would have, will they not show up until they next wake up?
They have to wake up. We can only get very basic node info on them until they wake up. You'll have to make them wake up. The issue is that wakeups are CC msgs, so they may only get sent to associated nodes. But we don't even know if we can configure associations until we get the list of classes they support. But we can't do that until they wake up. But if they do, we won't see that if they chose to only send to associated nodes (as apposed to broadcasting.) It's a sort of catch-22.

So, generally you will need to go do the battery thing (or press the button if they have one.) That will cause them to send a node info frame, which is always broadcast. That insures the driver sees it, even though it's not already associated.

And, usually, the devices will stay on for a short while after you do that, so you have time to get back and do the approval. If it goes back to sleep before you approve, then the auto-config msgs we send when you approve them just get queued up until the unit wakes up again. And, again, that auto-config is what sets the associations (among other things.)

So, if you aren't sure the unit stays awake, you need to wake them up again after approval, to insure any auto-config msgs get sent. It's sort of a real pain, but that's just the weird bootstrapping issues of battery powered units.

We could possibly try to do something help shortcut some of that, but it's tricky. We could skip the approval stage and as soon as we get the manufacturer ids and id the unit (and see we have support) we could send out auto-config right then while it is still awake. Then, in theory, you'd only need to wake it up once, and it would send out the auto-config right then as soon as it knows what the unit is.

But the reason for the auto-config is that, in order to add new units, we have to re-register fields. That makes all the IVs and such re-update as well. So I didn't want the driver re-registering fields in a sort of random way as units wake up. Saving them up and then doing an approval means you can control when that happens and it happens all at once.

I guess we could still do the above, then put it into approval state. So all approval state does is say you can create fields for this guy now, but we'd have already auto-configured him and all that.

Did any of that make sense?
BTW, I'm assuming here that units already recognized stayed that way and only the ones support was just added for are the ones you are talking about, right?
(04-14-2018, 03:39 PM)Dean Roddey Wrote: [ -> ]BTW, I'm assuming here that units already recognized stayed that way and only the ones support was just added for are the ones you are talking about, right?

I had to shut down for a while there. There was a little wind and I went out to trim the verge as they say, since some of the bushes were rubbing against the wall and bothering me. It was a little overcast as I did that and heard some thunder to the west. I figured it was coming this way so I shut down the computer when I came in, and within 30 seconds it was full on. I don't know if I've ever experienced that fast and violent a storm onset. It only lasted a few minutes so it was moving fast, but it was crazy.
So I've been working on the side on a publish/subscribe framework. Not an MTQQ (or however it's spelled) distributed type one but intra-process. The immediate use for it to enable my collections to optionally publish changes if asked to. Then the immediate use for that is to get a widget list back into the interface editor, without having to have lots of ad hoc code all over the editor to try to catch every place I make a change to the list.

I got the framework in place and I'm doing some unit tests to make sure it's working. Then I'll do the one collection I immediately need for the IE, and then do the widget list. The new editor, though vastly better than the old one, really does miss having that.
I think I have the publish/subscribe stuff worked out. Testing sort of pointed me towards redoing some of it. So I'll move on to implementing it in the one collection immediately needed.

Anybody had any time to play around some more with the Z-Wave driver? How is it doing? I'll address the issue discussed above of getting the auto-config msgs out up front. It's sort of not optimal, since if you aren't going to approve a unit (marking it disabled probably), it's probably best not to mess with it. But, the realities of battery powered units is what it is, and having to wake up each unit twice really sucks. So if we could get it down to one time, to get information, and if we id it then go ahead and send auto-config info.
Agreed on the 2x really is a major pain. I have 3 of the GoControl door devices that are sealed in weather proof housing monitoring my fence gates. I really don't want to have to unseal them to get CQC to recognize them. Can there be a way where we could choose what the unit is from a menu and assign it manually then once it wakes up it just happens? I believe this is how the SmartThings master hub works.