(04-17-2018, 06:10 AM)kfly Wrote: [ -> ]Please add Zwave support for a Schlage BE469 Front door lock.(battery power)
(Save on Unit Information didn't save a text file. just popped up a save dialog) Here is a copy and paste of Unit Info and a trace.
thanks
Kevin
Not sure why but the lock seems to be communicating now with the Z-stick. If I Set Unit Type to "Kwikset 910" it comes to a ready state in Driver client but does not seem get data from the lock.
Unit id is "30"  Unit_1E.
if I re-scan unit, make goes blank and  it stops at "GetSecureCi's" state.
Log attached.
I'm assuming on the unit names that you aren't saving the changes. Make all the changes you want then save (Ctrl-S as with any other tab.) Then you should see them show up in the actual driver itself.
(04-24-2018, 06:13 AM)kfly Wrote: [ -> ]Not sure why but the lock seems to be communicating now with the Z-stick. If I Set Unit Type to "Kwikset 910" it comes to a ready state in Driver client but does not seem get data from the lock.
Unit id is "30"  Unit_1E.
if I re-scan unit, make goes blank and  it stops at "GetSecureCi's" state.
Log attached.
Same as before. It just doesn't respond to secure messages at all. The driver waits for 15 seconds or so for a response which never shows up, then it will retry again in a while. The lock response to security nonce queries, but that itself is not a secure message. That does prove that it's there and has been beamed awake. But, given that there's no error, just a lack of response, it's very hard to tell what the problem is.
I'll try some things for the next drop to see if they help. Can you control the lock state from your master controller?
Nodes 14 and 16 are also continually failing.
(04-24-2018, 08:43 AM)Dean Roddey Wrote: [ -> ]I'm assuming on the unit names that you aren't saving the changes. Make all the changes you want then save (Ctrl-S as with any other tab.) Then you should see them show up in the actual driver itself.
Bingo... User error.
I guess since there is only one field on the page(right side of page) to save it didn't occur to me I needed to do a "file/save"
Would probably rather have a pop-up after you edit that one field and automatically save. my 2 cents since it can break all your templates very quickly
.
At least I only renamed one device.....
Thanks again
Kevin
You really don't want to do save on every change, because each one will require the driver to recreate and re-register its fields which will cause all clients to resync (the IVs will do a blinky recycle.) And it's a consistent thing, in all tabs, that you make changes then you save. Just making a change doesn't automatically save something.
Now it's a little bit trickier in the Z-Wave driver since some things do something immediately. But only in the sense that they talk to the units, they don't change any driver configuration. Some things can affect the unit states, but the unit state is not user configuration, it's a reflection of the state of the units. All configuration changes have to be saved, and it's way better to make a batch of changes and save once, and get one driver field re-register.
Of course all of this will be laid out in the driver docs once I get that done.
(04-24-2018, 08:49 AM)Dean Roddey Wrote: [ -> ] (04-24-2018, 06:13 AM)kfly Wrote: [ -> ]Not sure why but the lock seems to be communicating now with the Z-stick. If I Set Unit Type to "Kwikset 910" it comes to a ready state in Driver client but does not seem get data from the lock.
Unit id is "30"  Unit_1E.
if I re-scan unit, make goes blank and  it stops at "GetSecureCi's" state.
Log attached.
Can you control the lock state from your master controller?
I can lock/unlock from the VCROP_V2 driver on CQC if that is what you mean..
Why would it come "ready" when I set it to Kwikset 910. Assume it is communicating with the lock.
I have 9 different z-wave switches/outlets that are in WaitDevinfo.  I assume we need to do something to add these models to CQC. What is easiest way to get you what you need to add them.
Thanks
When you manually select a type for a unit you are telling it, this is what it is. It accepts that and just goes to ready state and starts trying to talk to the lock. That may not work because it's the wrong type, and the fields may end up in error. But the unit itself is ready, it's been told what it is and it's ready to do that. When you reset it, it has to try to figure out what it is on its own and that's failing because it can't get there due to the lock not responding.
On the others, you need to drop the menu down beside them, and select the show device info option. That will show the info it has gathered. If it has non-zero manufacturer ids, it's got useful info. Hit save and save that under a name like:
myname_unitid_make_model.CQCZWUDump
Send those to me. The make/model has to be exact, don't guess. Once I have that info, I can cross reference those ids with the make/model you provided. IF they match up I know I'm good and I can do a device info file for them, or add support for them in the driver itself if that is needed.
Wow, the widget palette has turned out to be almost as hard this time despite all the work done on the publish/subscribe stuff. It was way easier to basically get it going, but the details are just as nasty.
One thing that messed me up is that Windows doesn't send notifications if you change something programmatically in a list window. This is very different from what my old custom system did, and I did a lot of work to change that. BUT, turns out it does send notifications for programmatic mark/unmark operations in a multi-selection list. I of course wrote the whole thing assuming that wouldn't happen, but it does which caused a weird ping-pong effect back and forth between the editor and widget palette, that was hard to figure out at first, since I just assumed it had to be my fault.
And there's a lot of weirdness in that published messages are asynchronously delivered, so the thing it's reporting a change on will have already been changed by the time the subscriber gets it. That makes for some confusion that had to be figured out. And there was some gotchas related to undo as well.
And I found some bugs in the existing IV editor stuff along the way that had not been caught before, since I was digging so deeply into it. I also found a couple things that were never implemented post-5.x which I need to get to here at some point.
But I think I finally have it. In the widget palette you can make selections, delete the selected widgets, and move single widgets up and down in the Z-Order, and those things are reflected in the editor. And of course the widget palette reflects changes in the editor as well. The selecting stuff makes it possible to get to fully covered widgets without having to do the drill down thing (which you can do and it works fine, but the widget palette lets you go straight to a particular one.)
You have to a little careful since it also allows you to select locked widgets which you can't do in the editor. But that can be useful as well of course. The locked widgets won't accidentally get moved during swipe selection of widgets that lie on top of them, but you can still select and modify them if you want to, by selecting them in the widget palette.
5.2.908 is posted. It has four more Z-Wave unit device info files plus some tweaks to maybe see if some locks that don't want to play will get happy.
Also includes the first cut at getting the old 'widget palette' window back into the IV editor. This makes it easier to see and manipulate the Z-Order of widgets and to get to fully covered widgets. A nice new underlying Publish/Subscribe framework was put into place for this (and to be used in various other things moving forward.) That makes it 'easier' than the old one, but still quite tricky. So let me know if you see it get out of sync.
You can change widget selection by marking widgets in the palette window. And you can delete the selected ones, and you can move single ones up and down in the Z-order through it as well. And of course it updates to reflect selections and new and removed widgets via the editor.
Some of the lights that were working lats night are not this morning.
in the Driver screen when I set to "True" I get this pop up:
"The value couldn't be written to the field. See the logs for more info..."
From the log: (Driver Verbosity is on High)
04/26 08:02:17-CQC-PC, CQCServer, CQCDrv_Z-StickThread23
{
    CQCKit, CQCDriver_DriverBase.cpp.8540, Failed/Unknown
    An unknown exception occurred while processing the command
    Z-Stick
      <CQCServer> CIDOrb_ThisFacility.cpp - 536
      <CQCAdmin> CQCKit_CQCSrvAdminClientProxy.cpp - 1945
      <CQCAdmin> CQCAdmin_DrvMonTab.cpp - 1321
}