Charmed Quark Systems, Ltd. - Support Forums and Community

This thread is not for discussion, so please don't post here. It is for official 5.3 beta release information. There is a separate sticky thread for discussion.

-------------------

Latest Version: 5.2.923
Confidence Level: 99
Download Link: http://www.charmedquark.com/Web2/Downloa..._2_923.exe

The subsequent posts list changes in each beta version...

Version 5.2.900 is posted. This is the first beta heading towards 5.3. I think that the beta cycle will be fairly short this time, since the primary new feature is a driver, though there will be various smaller improvements of course.

This being a first beta, obviously be sure to let the installer do a backup for you, in case you need to back it out. You should always do that of course, but just a reminder.

So this is primarily to get a first look at the new Z-Wave driver out there for folks to evaluate. This is fresh bits, so it's always possible that it may just utterly not work for some folks due to some silly unforeseen reason that we'll have to figure out. And it doesn't have a lot of built in unit support yet. The big purpose of getting it out there initially is to get folks to gather data for us so that we can add more support. A big advantage of this driver over previous Z-Wave drivers is that, if we have support for it built in, we can auto-identify the device and configure it for you. So there will be a lot less fiddling about than before for those units.

There are also generic handlers as well, which you can use in the meantime to deal with various common types of units. Here is a little preview video (the one that was posted in the support section a week ago or so) to give you an idea of how it works:

https://www.youtube.com/watch?v=S5sDybb5ZrY

Let's keep speculative discussion of the driver here, and I'll just update that driver when new versions are released that have reached some new level of usefulness and such. I don't want that other thread to get full of stuff that is immediately invalidated by the next drop.

Some basic things to know:

1. It uses an Aeon Z-Stick (Gen-5) and it works as a secondary controller.
2. So you have to have a primary controller still. A good choice would be the Lutron Vizia RF software with their own Vizia USB stick. It's a good choice because it only does anything when you are running the software and only does anything then when you tell it to. It's not like, say, Smartthings which some folks have used for a master, which probably assumes it owns the Z-Wave network and may interfere with our driver.
3. To add our driver to the network you just include it just like any other Z-Wave device. If you add or remove units on the master, run the inclusion process again on our driver to pick up the changes.
4. Each unit that the driver knows about will be in some particular state at any given time. The goal is to get them to Ready state where they are up and going. Some discussion of the states is provided below.
5. There is a main options menu button, for things applicable to the whole driver, and each unit in the list has a drop down (the down arrow on the left column) for unit specific operations.
6. The driver, for those units it has knowledge of and auto-ids, will send out configuration info automatically. For those you use with a generic handler you have to at least add the driver to the appropriate association group in the unit so that the driver will get notifications of state changes, and possibly set up the config parameters. The driver has dialog boxes to do these things.
7. This driver, like the previous one, does not poll. It only supports two way for devices that support associations. Others will only be able to be supported one way (outgoing commands.)
8. Battery powered units are always a special case (except for locks which support beaming and don't really act like battery powered units.) Any time the driver needs to do any interaction with a battery powered unit you must wake it up. That doesn't mean wave your hand for a motion detector. It means waking it up, which either means pushing some button or taking the batteries out and putting them back in. There are lots of informational popups in the driver to help you do the right thing, so read them. The driver will queue up outgoing msgs to battery powered units and send them when it wakes up.
9. Once a unit has been auto-identified or you manually id it for us, the only way to change that type is to use the 'force rescan' option on that unit. That will force it to go back to scratch and try to auto-id its unit hardware, or go back to waiting for you to select another type.
10. Don't randomly select unit types, since you can make a mess of things and really slow down the response of the driver. If you aren't sure, ask.
11. There's no thermostat support yet in the driver. I'll get to that here soon.
12. As with all things done in AI tabs, you have to save changes to make them take effect, so you are always just making local configuration changes. Of course some commands are talking directly to the units themselves but those are not configuration changes. So manually setting associations and config params, or forcing a rescan of a unit isn't configuration stuff.


Unit States

Each unit is in some state. Here is a brief discussion of them. Obviously this will be in the formal docs when we get to that point.

• Failed. The information the driver got for the unit last time it checked is in conflict with what it got now. So it is offline until you force it to rescan and get it back happy.
  
• Disable. You can disable units so that the driver will not use them. It may be causing problems or something.
  
• WaitDevInfo. We cannot auto-id the unit, or it is battery powered so we've not yet been able to try. If it is battery powered, then make it wake up and the driver will attempt to id it.
  
• WaitApprove. Once units have been auto-id'd, they will be in wait approve state. There is a 'Approve New Units' option to approve them. They will then continue forward.
  
• GetNodeInfo, GetClasses, GetWhatever... These are all states where the driver is trying to get information from the unit to figure out what it is. Or, at least to gather the information required to help us add support for it.
  
• GetInitVals. It has been correctly setup and is now trying to get initial values for its fields.
  
• Ready. It has gotten initial values and is ready for use.
  

The only ones you have to react to are WaitDevInfo, where you have to either wake up a battery powered unit so we can id it, or tell us what it is. Or WaitApprove, where you need to approve those units. Or Failed, where you probably need to rescan it. Or perhaps it did not respond to the initial query for node info and is assumed dead until you force it to rescan. The other states are moved forward through by the driver.


Gathering Info

To get information for us to use to add support, don't select a unit type yet. First use the drop down for that unit and select the Show Unit Info option. That gets us information about the unit (only useful if it has gotten past the GetXXX states though.) It has an option to save to a file. You can send us that file.

The other thing is the trace file. In the main Options menu are options to manage the trace file. You can turn it off (the default when the driver is installed) or set it to various levels. We'll tell you what to do if we need information. You can flush it out, so that you can see the output so far without actually closing it. And you can reset it so that it will start capturing info again from that point, which is useful to gather targeted info. You can set it back to Off to close it and leave it intact so that you can send us the file. It will be in:

[cqc]\CQCData\Server\Data\ZWaveUSB3S\

There will be a trace.txt file there if you have enabled it. It's just plain text, so you can open it in a text editor if you want to see it. It will probably be mostly gibberish to you. But it provides lots of information that lets us know what information is passing back and forth. So we can tell what msgs units are sending out, how they are responding to stuff we send, etc... Once enabled it will generally show zero size until you close it. But if you use the flush command you can still see what has been written so far. The text editor has to open it such that it doesn't request exclusive access if the file is still open for use.

That's also where the Z-Wave configuration file is stored. BTW, the client interface provides you with a 'save config' option so that you can save it somewhere if you want, without having to go to the server to find it.


Anyhoo, there it is. Those folks with modules that we don't support yet (which is basically everyone) let's start gathering data. There's a small set of stuff already supported, which represent a reasonably diverse collection of types of units. Once you've gotten us some info, you can select a generic handler for some of the stuff that we have them for so far and start getting some good use out of the driver.

Be prepared to throw away everything you do with this first version (and probably the next few), since we might find something that requires a significant change of some sort and can't afford to write code to bring forward beta installations of it. Hopefully not, but it could happen. Of course, once we get a lot more units supported, doing that won't be nearly so hard.

5.2.900

• There's no good way to adjust widget z-order for overlapping interface widgets. We were supposed to implement page up/down as a means to move the currently selected widget up and down in the z-order, but that didn't happen. So you can only affect the top-most one if you have some that are completely overlapped. That isn't very useful. So implement page up/down.
  
• The 'move forward in z-order' command in the interface editor, whether invoked via popup menu or the new hot key pageup from the change above, will allow you to take it one too far and cause an error. It has a one-off error when checking to see if the selected widget it already at the top or not
  
• Expand the Monoprice Blackbird driver out to support 8x8 boxes. It uses a driver prompt to select the model, but so far only has the 4x4. Ultimately the one I was going to test against wasn't available, but it should be fine. The 4x4 version was re-tested and it seems to be working fine. It was actually updated to just use an input and output count, so it should be able to support other varitions in the future.
  
• Our last remaining user of the OmniII (non-Pro, pre-3.0 firmware) driver doesn't need that anymore, having upgraded his Omni, so drop that driver since he should be able to use the new driver now.
  
• There's a goober in the file export option of the popup menu in the tree browser. If you do a single file, it still treats that like a scope and appends a slash to the end and tries to read an empty file name from that non-existant scope. Exporting scopes works fine, it's just single file exports that fail.
  
• If the installer sees that the previously stored configuration is to install the MS on the current machine, then compare the previously stored host name and update it if it is different from the actual host name. Otherwise there's no way to change that.
  
• On the docs page that discusses the CreateVariable and CreateSafeVariable action commands, provide a link to the field definition page and indicate that, when creating variables with limits, that they use the same limits format as fields.
  
• Create a lock state semantic field type, which we don't have for some reason. Update the lock device class to indicate this type for lock status fields. I believe the only existing drivers that do V2 compliant locks are the Z-Wave drivers, which have been updated to reflect this change. If there are any others they will fail V2 validation in the IDEs until they are updated.
  
• The link in the template scaling help that links to the discussion of relative paths is broken.
  
• The Admin Intf can't download client driver files into the Program Files area, so it downloads them into the ProgramData area. But that's not optimal because that's not managed and protected in the same way. So, let it use the client service, which is there on all CQC enabled machines, to do the download. Once in place the AI just reads the files so there aren't any problems. Though this adds another moving part to the process, it's ultimately a much better solution.
  
• It turns out that we are doing a good bit more network work than necessary when clients are connecting with server side drivers. We can strip this down to a single exchange, which should speed things up a bit.
  
• Make some fairly substantial improvements in how client and server side drivers are managed and connected to each other, so that we can create a new, much nicer C++ driver test harness. Currently we just have a very simple command line one, and client side drivers have to be tested in the AI against the actually loaded driver. This is very burdensome.
  
• Though it's just for internal use, as per the previous item, create a vastly improved C++ driver test harness that lets us test client and server side together in the same program. This has already had enormous benefits, starting with the new Z-Wave driver.
  
• Create a new, native Z-Wave driver that is orders of magnitude better than what we have. This is very fresh bits of course so it may well be a complete bust for some folks for some silly, simple to fix but unforeseen reason. Mostly we get it out there so that folks can start collecting module info so that we can add built in support for them. The new driver, if provided the right info, can auto-identify and configure units, which makes it much more convenient to use than the old one. And the new C++ test harness as allowed the client side driver to be far better than any have been so far, due to vastly reduced testing cycle times.
  

5.2.901

• Make some changes wrt to nonce management to hopefully make the driver happy replicating from a SmartThings master controller.
  
• There were some issues with how locks were handling reporting states which would make the driver do inconsistent things with lock state triggers and the current lock state field.
  
• There was an issue with how it was doing regularly scheduled auto-configuration (which each unit will try to do once a day) that would make it get into a never ending cycling of sending out the auto-config info.
  

5.2.902

• It looks like SmartThings (as a ZW master controller) starts the secure inclusion process faster than Vizia. This appears to be causing us problems because we haven't gotten through our basic gathering of info from our local controller yet. So, just remember that he sent the invitation to join, but then continue with our basic init. When done with that, if we haven't see the invite yet, then wait for it, else just continue on since we already got it. Hopefully this will let us successful be included.
  
• Clean up an issue that occurred when we moved to using the client service to download client drivers (so that we can get them into Program Files area without dealing with the admin prompt.) We changed the client driver paths back from ProgramData to Program Files, but the admin interface was trying to clean out the client driver path (which it can't do anymore directly.) So change it to do that via the client driver as well.
  

5.2.903

• Fix issues with the main options menu in the new Z-Wave driver client interface. It was misusing the selected item id and getting menu item not found errors.
  
• Add more logging around the include/exclude process to get a better feel for what is going wrong when being included into a Smart Things master controller.
  

5.2.904

• It looks like the thing we call to decide if we are in the network or not is not necessarily correct. So change it to use another calls which looks like it provides the more accurate stuff. The problems we've been having so far are that the Z-Stick was telling the driver it was not in the network after the inclusion completed so the driver never tried to do any of the secure inclusion stuff
  
• The driver was filtering out naming CC msgs before they got to the units. So no units that supported naming would ever get past the GetName state.
  
• Get some new device info files in for Leviton DZ15S, DZ6HD, and DZPD3 units. These are just by eye, so they may not be exactly right but they should auto-id now and we can get some msg trace info if needed.
  
• If we are being included and there is no SUC in the network, set ourselves as the SUC since that's an appropriate role for a static controller and the master would probably later try to make us do it anyway. Hopefully this will make the HC2 master controller happy and have no affect one way or another on the STs scenario (I think STs sets itself as the SUC, so we would see one already in place.)
  
• Put a UTF8 text converter on the output stream that is used to format out the Z-Wave unit info to files, to insure it's in a readable format after the save.
  
• By default, make multi-line editors dialog friendly by not letting them see tabs (so that the tab doesn't get eaten by them it moves to the next control.) In those rare cases where we might need tabs, we can turn it on specific for that editor, but I can't think of any place currently we need that.
  
• Get deice info files done for any remaining units I've gotten files for so far.
  

5.2.905

• When you resize the template itself in the intf edit, it does a set size on the edit window, to keep it a certain amount larger than the actual template. But it's passing the 'copy bits' flag. If the template isn't resized enough, then it stays within the window area and doesn't get redrawn because that part of the window's bits were just copied. So you don't see the template actually resize.
  
• There's an error in the OmniTCP2 driver where, if a zone is bypassed, it knocks the driver offline.
  
• The OmniTCP2 client side driver isn't putting borders around its list boxes, so it looks really weird.
  
• Get more Z-Wave unit support in place. We still need to get some verification on a lot of them, and to gather a little message tracing. But the support is there and they should get identified.
  

5.2.906

• Implement the RIVACmd in the WebRIVA client, using the extentions mechanism. For now we haven't provided any built in commands, this just gets the mechanism in place so that users can provide their own RIVACmd handlers.
  
• A couple more Z-Wave device info files
  

5.2.907

• More Z-Wave unit support.
  
• Get the Z-Wave thermostat support roughed in, though not completed yet and no thermostats yet to test with. This is one of the most annoying ones because of how many new CCs are involved, and the possible variations there can be.
  
• Get support in the new Z-Wave driver for a slow poll cylce, just for 'is it still alive' purposes, not for actual polling of non-reporting units. In a few places where there's something not reported async, but it only rarely changes and being totally up to date isn't important, we can use it to poll such things on a long cycle (like 10 or 15 or 30 minute types cycles.)
  

B Revision

• Failed to reaquire a lock of the device info cache after downloading a device info file, which may have allowed for the wrong device type index to be returned in some cases, which could have assigned the wrong type to a unit perhaps when being auto-identified.
  
• More unit support added: Aeon ZW100-A, Evolve LRM, Linear WADWAZ, Linear WADWSZ, Linear WAPIRZ-1, Monoprice 4-in-1, Wayne Dalton HA-06WD, Yale 220YRD.
  

C Revision

• Add a new 'WaitWakeUp' state to the Z-Wave driver. Before units not having woken up since we knew about them were set to the WaitDevInfo class, along with those that have gotten ids but we don't know those are. That was kind of confusing. This will make it clearer that these need to be woken up.
  
• Add line of text in the Z-Wave driver client, below the list, that gives some guiding text based on the state of the unit, to help folks know what to do for those states.
  
• When non-listening units are about to be put into WaitApprove state, go ahead and queue up the auto-config msgs. In order to have gotten to that point, the unit has to have woken up, so we can get those messages sent out then. Otherwise, we need one wake up to get the unit info and id it, then another after appropral (which is when we used to queue the auto-config cmds.) That required two wakes up to get the unit going, which can be painful for those that only wake up if you take the batteries out and put them back in.
  
• We never implemented the SetCfgParam command for the InvokeCmd field in this new driver. It's now available in the form "SetCfgParam unitname parm# value valbytes [awake]". There's a trailing optioal 'awake' value that lets you tell the driver that you know the unit is awake now (if it's a battery powered one) so that it can send the messages immediately. If the devices doesn't have an option to stay awake for a while, then just set the commands without the awakw parameter and let them queue up, then wake the device up to let them all be sent while it's awake.
  
• Implement a Publish/Subscribe framework (intra-program, not an MTQQ type one) which there are various potential uses for inside CQC and the underlying CIDLib layer.
  
• Add potential support for Pub/Sub to our C++ collections
  
• Enable support for Pub/Sub for the collection (ref vector) that we use in the interface system to hold the widgets. This will subsequently be used by the Intf. Editor to implement a 'widget palette', which was dropped in the move to 5.x, awaiting the above Pub/Sub support (which makes it vastly more reliable and simple to do.) The palette will come in the next drop.