Charmed Quark Systems, Ltd. - Support Forums and Community

Any chance in adding some kind of functionality to the "Query unit Info" screen next to the Save button for missing models.  "request missing model" button? 
That would do do a save and do some kind of mailto: to you..   ie to "z-model-request@charmedquark.com"
Could just prompt to enter text of the file name(make/model,etc) before mailto.

Some way to make it super easy to add models as they change over the years. (even if people don't run mail client on server it is easy to cut/past to one like gmail).

thx

Yeh, I could do that probably. Actually, if you have any e-mail accounts configured for CQC, I could offer to use one of those and send it myself, else invoke your e-mail client.

(06-01-2018, 09:36 AM)Dean Roddey Wrote: [ -> ]Yeh, I could do that probably. Actually, if you have any e-mail accounts configured for CQC, I could offer to use one of those and send it myself, else invoke your e-mail client.

Thanks. I think the more models that the new Z-wave stick controller knows about out of the box the more plug and play CQC is. This will reduce at least one pain point for new customers to deal with when migrating to CQC or moving from UPB,etc or another lighting control protocol.

So I was thinking early this morning about the battery device issue (hard to do when there is blood in one's coffee stream) and had a palm slapping head moment, I went back to the documentation I had written up to get the VRC0P working with SmartThings and re-learned that I need to manually associate each battery device with the secondary controller as the SmartThings hub won't do it for you.

The instructions walk you through how to do a manual association via the SmartThings web platform. I'm thinking that if I can get a device awake and recognized basically to CQC I can then go back, wake it up again and force add the Zstick association to the battery operated device. It's the only thing I can find that makes any sense for the behavior/result I am seeing. The other option if the mechanism is not there in the CQC driver is to force the association through the SmartThings web interface.

Dean does this logic sound reasonable to you?

I won't be in a position to do this test potentially until Sunday afternoon.

So, I was thinking about this, and just to make it clear to everyone, while it's clear in my head (and I'll add this to the driver docs) is that there are a few scenarios of how the driver can get set up with a battery powered unit.

1. You swap the batteries or take off/on the cover, and it sends out a node info frame. I thought this was universal but apparently not. This is broadcast, so no prior associations are required. Everyone will see it and it announces to the network, hey, I'm back and I'm more stupidier than ever. The driver treats this as a wakeup for any battery powered device it's not been able to id yet, and starts the process of setting it up. Most devices, upon sending that broadcast, will stay awake a little while to let other things talk to it now that it is available.

2. Or we see a wakeup. But wakeups are command class msgs. They could be broadcast, but they may not be. If not broadcast, then requires a prior association be in place so that we can see the wakeup. But this is a catch-22. The association command cannot be sent until the unit wakes up. But no controller will know the device wakes up until it has an association in place on that unit.

* The exception is that some of the newer units will automatically associate to the master when they are added to the network. That gives the master a special advantage. HOWEVER keep in mind that the master STILL cannot send anything until the device wakes up. So just telling the master to set up an association for our driver has no effect until you force the unit to wake up (or it does so eventually itself) and the association command can be sent. Once you get the association really in place, then make the device wake up and the driver should see that, go through the usual process and take it to WaitApprove, but only if the comms are good enough that it can get through the process. If it gets stuck on some other step along the way, you may have to wake it up again.

* If the unit is smart enough to find any other controllers and associate with them automatically on joining the network, that would be a very good thing, but I don't know if that happens, and even less likely if you add the secondary controller after the network is already set up.

3. Another option is to force the unit awake (swapping batteries unless you know it only requires a case open/close), and hopefully it stays awake for a minute or so, then go to our driver and force a rescan on that unit. Upon rescan, the driver will make one attempt to talk to the unit in case it is awake. If the unit responds, then the driver will go through the usual process of setting it up. As long as comms are good it will get the device set up and associated and move to WaitApprove state (if it can id the unit.) Again, if it gets stuck on some intermediate step, you would have to try it again. auto-config (which includes setting up associations) is the very last thing it does because it has to id the unit and load the device info in order to know what config/association commands to send.


* Actually, reading the docs, it's a little squishy. It says a unit MAY broadcast the wakeup if it has no configured units to notify. Otherwise, I guess it can only send to those units that it is associated with. So, there again, that would give the master a special privilege because there would be no previously configured targets when the unit is first added, and it would broadcast the wakeup. But, for any unit already in the network and set up, it gets into the catch-22 problem where it can't send wakeups to a unit because it's not set up to, and the unit cannot send it setup commands because it doesn't know when the unit is awake.

The whole wakeup thing should have been handled better.

Anyhoo, I'd say that the best bet is make it wake up, by swapping batteries, which should make it stay awake for a little while. Then force a rescan on the unit. That should give the driver the opportunity to get through the process. If it is able to id the unit, it will send setup msgs to it which should get the association set up.

But if comms aren't reliable, all bets are off. If a msg cannot be sent, then driver will retry a couple times, but by then the unit will have gone back to sleep again because it thinks no one is talking to it. Then all the subsequent commands will time out, and slow down everything else.

Anyway, that's probably still confusing, but that's the silliness of Z-Wave. And this is supposed to be a simple consumer level system.

OK, so the Schlage lock is responding, if directly asked, but it's returning an unknown lock state. So presumably not having the bolt in there means it's not happy. And presumably that's why it never sends out any notifications, so I can't be sure what it actually sends out when it changes state.

Do you have another one of this model still there? The device info (as best I can guess it) is there in the latest drop. You could give it a try and see how it does, and maybe get me a trace of what it sends out if you lock/unlock it from the pad.

(06-01-2018, 01:20 PM)Dean Roddey Wrote: [ -> ]OK, so the Schlage lock is responding, if directly asked, but it's returning an unknown lock state. So presumably not having the bolt in there means it's not happy. And presumably that's why it never sends out any notifications, so I can't be sure what it actually sends out when it changes state.

Do you have another one of this model still there? The device info (as best I can guess it) is there in the latest drop. You could give it a try and see how it does, and maybe get me a trace of what it sends out if you lock/unlock it from the pad.

OK status after the last drop :
Still have to disable both locks to get driver online.(I can deal with this since it is only when I clear out config file)
The driver does not seem to recognize the Schlage lock automatically.
If I manual set the model to Schlage lock it works and comes online in the Z-stick driver
I can unlock/lock via CQC (Yea!)

If I use the master controler(vizia+ stick) to lock unlock the status changes in the Z-stick cqc driver.
If I lock/unlock via the lock itself the status does not make it to the driver(odd). Association looks good.

progress at least.
I checked the box. the only thing in the box is the door deadbolt. so it should not affect your testing. maybe just hold the mechanism to add some resistance when it is locking/unlocking???

Reset the trace, lock the door from the lock itself. Wait 15 seconds, unlock it (or vice versa), then stop the trace and post the output. I was never able to see what it sends, so it may send something different if done from the lock itself.

(06-02-2018, 09:44 AM)Dean Roddey Wrote: [ -> ]Reset the trace, lock the door from the lock itself. Wait 15 seconds, unlock it (or vice versa), then stop the trace and post the output. I was never able to see what it sends, so it may send something different if done from the lock itself.

ok, Here is unlock wait 15 seconds then lock wait 15 seconds
Unit id: 25   or  0x19   
------------------
Z-Wave USB3 Trace
,  Time: 3:23:37 PM
----------------------------------------------------

15:23:55 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 15:23:55) 
{
    Flags:
    Type: Single
    SrcId: 19
    Class: Security
     Cmd: Nonce Get
    Bytes: 00 19 02 98 40 
}
15:23:55 - [TRACE]- SEC: Idle, sending nonce 1 to node 19 immediately
15:23:55 - [TRACE]- Sending msg, AckId=4746, Attempt #1
15:23:55 - [TRACE]- Transitioned from Idle to WaitAck state
15:23:55 - [ZW->DR] - ACK
15:23:55 - [TRACE]- Transitioned from WaitAck to WaitCallback state
15:23:55 - [ZW->DR] - RES,Msg:SendData/0x13,Recvd: 15:23:55) 7MSs
{
    Bytes: 01 
}
15:23:55 - [ZW->DR] - TRANSACK,Msg:SendData/0x13,Recvd: 15:23:55) 99MSs
{
   Callback Id: 61
        Status: Success
    Bytes: 3D 00 00 0A 
}
15:23:55 - [TRACE]- Transitioned from WaitCallback to Idle state
15:23:55 - [TRACE]- Using stored in nonce for unit 25. 0 in nonces left in list
15:23:55 - [TRACE]- Decrypting with nonce 1/1
15:23:55 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Secure,Recvd: 15:23:55) 59MSs
{
    Encrypted Data:
    {
        SrcId: 19
        Bytes: 00 19 1D 98 81 82 BD 38 E1 DA 14 1D B5 FE D2 3F A9 0B 4A 47 F9 86 14 01 17 03 7A 25 34 10 E9 D1 
    }

    Flags:
    Type: Single
    SrcId: 19
    Class: Notification
     Cmd: 5
    Bytes: 00 19 09 71 05 16 01 00 FF 06 02 00 
}
15:23:55 - [TRACE]- Processing app cmd. Src=19, Class=71, Cmd=5
15:23:56 - [MSG] - No nonce available for incoming msg

{
    [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 15:23:56) 350MSs
    {
        Flags:
        Type: Single
        SrcId: 19
        Class: Security
         Cmd: Msg Encap
        Bytes: 00 19 1D 98 81 82 BD 38 E1 DA 14 1D B5 FE D2 3F A9 0B 4A 47 F9 86 14 01 17 03 7A 25 34 10 E9 D1 
    }
}
15:23:56 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 15:23:56) 0MSs
{
    Flags:
    Type: Single
    SrcId: 19
    Class: Security
     Cmd: Msg Encap
    Bytes: 00 19 1D 98 81 82 BD 38 E1 DA 14 1D B5 FE D2 3F A9 0B 4A 47 F9 86 14 01 17 03 7A 25 34 10 E9 D1 
}
15:23:56 - [TRACE]- Processing app cmd. Src=19, Class=98, Cmd=81
15:24:15 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 15:24:15) 19837MSs
{
    Flags:
    Type: Single
    SrcId: 19
    Class: Security
     Cmd: Nonce Get
    Bytes: 00 19 02 98 40 
}
15:24:15 - [TRACE]- SEC: Idle, sending nonce 2 to node 19 immediately
15:24:15 - [TRACE]- Sending msg, AckId=4747, Attempt #1
15:24:15 - [TRACE]- Transitioned from Idle to WaitAck state
15:24:15 - [ZW->DR] - ACK
15:24:15 - [TRACE]- Transitioned from WaitAck to WaitCallback state
15:24:15 - [ZW->DR] - RES,Msg:SendData/0x13,Recvd: 15:24:15) 5MSs
{
    Bytes: 01 
}
15:24:15 - [ZW->DR] - TRANSACK,Msg:SendData/0x13,Recvd: 15:24:15) 19MSs
{
   Callback Id: 62
        Status: Success
    Bytes: 3E 00 00 02 
}
15:24:15 - [TRACE]- Transitioned from WaitCallback to Idle state
15:24:15 - [TRACE]- Using stored in nonce for unit 25. 0 in nonces left in list
15:24:15 - [TRACE]- Decrypting with nonce 2/2
15:24:15 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Secure,Recvd: 15:24:15) 54MSs
{
    Encrypted Data:
    {
        SrcId: 19
        Bytes: 00 19 1D 98 81 4D 8E C2 E0 28 C5 68 B0 95 99 6D 46 DF 7E 9F D3 A6 3C 02 66 45 28 13 F5 97 2F 58 
    }

    Flags:
    Type: Single
    SrcId: 19
    Class: Notification
     Cmd: 5
    Bytes: 00 19 09 71 05 15 01 00 FF 06 01 00 
}
15:24:15 - [TRACE]- Processing app cmd. Src=19, Class=71, Cmd=5

I just put up a 5.2.917 release, which has some small tweaks. This one has the first built in RIVACmd command, which are commands that are passed through to WebRIVA. This one is:

Cmd: /CQSL/RIVACmd/LoadURLTab
P1: [urltoload]
p2: [tabname]

That will open the passed url into a new tab and give it the indicated name. It may be a new window. We have no control over this. Sometimes they will refuse to open a new tab unless the command comes from a button click by the user. Yet still more lovely limitations caused by security.

If you use the same tab name again, it will reload that same tab (or window.) If you always want a new tab/window, just pass _blank as the tab name.