4.6 Official Beta Release Thread

[Dean Roddey]

Version 4.5.12 is now posted. It is basically just more fixes to get things stabilized moving towards a 4.6 release, and some small improvements.

• Ugh... at the last minute before the .11 drop I ungrouped the security tile in the auto-gen home screen, in order to change something, and forgot to re-group it, so the auto-gen failed. Sorry, so many details... The auto-gen was looking for the security group and not finding it, so it couldn't process the widgets of that group.
  
  
• The Brultech GEM driver isn't dividing the raw voltage value by 10 before storing it to the field.
  
  
• Drivers don't throw an exception when there is a duplicate field name. The first one just wins and the rest lose. It shouldn't do this. It should complain so that the driver writer knows there is an issue.
  
  
• CML drivers don't catch CML level exceptions during the initialization phase, so C++ exceptions can leak out. Those get displayed instead of the CML level exception info when debugging the driver in the IDE.
  
  
• When drivers are paused, remove their binding from the name server. That way, no one will think they are there and try to talk to them, and fail. In particular a paused repo will cause the client service on every host to continually attempt to connect, then fail and log a message or two. The driver has to stay in the list, so it'll show up for removal or resuming and so forth. But the Admin Intf doesn't use the name server to find the drivers, so it'll still see it. But almost everyone else gets to drivers via the name server, and won't see them as available when they are paused.
  

[MS/Edit - Changed 4.5.8 to 4.5.12]

[Dean Roddey]

Version 4.5.13 is posted. Mostly it's adding support to the auto-gen system for thermostats. So, for those thermostat supporting drivers currently V2'd, you'll be able to control your thermos as well now via the auto-generated interfaces. You'll have to update your room config and regenerate to get that stuff.

Otherwise, it's mostly just small bug fixes, and a couple small improvements to make certain things easier.

• Somewhere along the line, the undo for arrow key driven movement in the Intf Designer got broken.
  
  
• Fixed various errors in the V2 Omni driver. Also updated it to use the extended current mode info for the 'operating mode' field. This way we can see what the actual mode is instead of just replicating the currently set mode.
  
  
• The Omni V2 driver's flag fields should just be booleans, since flags can only be off or on, and they need to be set using the unit off/on commands, not by setting them like a dimmer to levels 0 or 1.
  
  
• Create a new command on the variables targets, CreateVarFromField(varname, fieldname). It will create a new variable with the indicated name, giving it the same data type, limits, and current value as the referenced field.
  
  
• Update the variables target command AdjustEnumVal() so that it will actuall work with int or card fields as well as enumeraed ones. This will be useful for generically adjusting values, particularly in conjunction with the new CreateVarFromField() above.
  
  
• Unlike all of the other values the Brultech driver extracts from the data packet, the voltage is in the other byte order, so it's pulling the bytes out the wrong way, usually creating way too high a value.
  
  
• Fix a bunch of issues in the new V2 Omni driver.
  
  
• Implement a thermostat simulator driver, for use in developing the auto-gen thermo support.
  
  
• In the auto-gen templates, add the current room name to the right of the room select button.
  
  
• The progress bar is not checking the writeable attribute when clicked on. So it will attempt to change the value when you click, even if the field is not writeable or the widget is configured to be non-writeable.
  
  
• Add support for thermostats to the auto-gen system. We need to rearrange the main tiles screen. Heat/AC, if used, would probably be more important than music and movies, so move them over and put the new one closer to the top so it's on the first page. And this now puts us over a single page with all of the pre-defined tiles enabled.
  
  
• To make things easier in the thermo support, and to provide a good example for folks looking for a replacement for adjust buttons, implement an 'adjust bar' in the auto-gen stuff. It provides a very compact way to adjust multiple values. Not trivial to do but very useful, and other folks can just steal my example and adjust it. It sort of takes its inspiration from things like car computer interfaces and such. There may be other places to use it in the auto-gen interfaces. It will make use of some the improvements made above.
  

[Dean Roddey]

And 4.5.14 is posted...

Oops, I messed up a bit, so this quick follow-up just fixes an issue where I left references to some thermo stuff even if thermos were not enabled, so the tile was removed but references to widgets within that tile were still there and would cause the template to fail to load. Sorry about that. It should be good now.

[Dean Roddey]

Version 4.5.15 is posted. It's basically all just smallish fixes and improvements, plus some stuff that was done for the V2 Z-Wave driver (which won't show up until the .16 drop.)

• Another fix for the Elk V2 driver. The high/low thermo set points are ints now, but the field writes were still being handled over in the card field write callback, because originally they were card fields. So writes to set points did nothing.
  
  
• The above brought up the issue that fields writes to a driver that go a field write callback that the driver doesn't implement, were not being handled at all. The base C++ driver has a default handler that just returns a rejection. But the CML driver wasn't propogating those methods. It was just expecting the calls to propogate without taking any action. So the field write would nothing but also return no error. It will now appropriately return an 'unhandled' rejection. Another one of those things that remained uncaught for over a decade somehow.
  
  
• The room config's thermo editing dialog doesn't correct display any previously selected Thermo sub-unit name.
  
  
• The room config's media editing dialog isn't displaying any selected Audio sub-unit name.
  
  
• Let the split in the CML IDE between the source editor window and the file list window be dynamically adjustable.
  
  
• Have the CML IDE's value display window show up to the first 128 values of collections, so that you can see what is going into the collections, not just information about the collection itself.
  
  
• Remove the clip children attribute from the list box window. Sometimes this prevents it from visually getting rid of the scroll bar and it shouldn't be required.
  
  
• Go through the security, lighting, and multi-zone audio, and thermo simulator drivers and get them all in sync in terms of reflecting a 'virtual house'. They were mostly so before but not really completely formalized. Get them all fully set up to reflect that virtual house (with garage) setup so that they can be used very conveniently for auto-gen testing and system demostrations. And also to use in a future video on the auto-gen system, and to replace the old simulator thingie in any new videos created post-4.6 to replace the current video set.
  
  
• Come up with an XML description of Z-Wave devices for use with the new V2 Z-Wave driver. This will make the driver vastly more intelligent, and vastly easier to set up correctly. It'll tell the driver what command classes the device supports, what groups it supports, what technologies (beaming, security, etc...) and what groups are required to have the device send all the required info to the VRCOP. It can even, where required, indicate non-standard functionality for the driver to be aware of. The user just has to select from a list to indicate the type of the device, and that'll tell the driver all it needs to know. It'll be able to set up the device on its own.
  
  
• The xml files that define device classes and (now for the V2 ZW driver) Z-Wave devices can just be installed by the installer on each machine. It's not much stuff and it avoids having to put even more burden on the master server. Those files are read only for any given CQC installation, so they can just be copied into the CQCData area and referenced locally by anything that needs them. Update the IDEs to get them from that new local machine directory, and update the installer to copy them there. Since they are read only they can be referenced by clients from the server side CQCData directory, so there's no need to store them twice.
  
  
• Do the same as above with the V2 device class validation files as well. They can just be local, read only files, for faster access and less burden on the server. Update the installer appropriately to copy them to their new location.
  
  
• Write a little utility that will go through all of the ZWave device info files, parse them, and create an index file that can be used by the client side driver for letting the user browse for device types. This will be copied along with the device info files (see the previous entry above) so that it's available on whatever machine the client interface might be
  
  
• The PDL engine isn't really working right for IP based connections, since the recent changes with how sockets are opened/bound and so forth. Just noticed that as I was trying a little dummy driver test and it wasn't working.
  
  
• Actually it turns out that the Flag units in the Omni are not just boolean but 0 to 255 values. So the previous change in the V2 driver to make them boolean was incorrect. Undo that and put it back the way it was. The problem appears to have been that the driver was using the wrong command to set the flags.
  
  
• The Denon X-4000 driver was incorrectly mapping the incoming source input values in the string field change callback, and so only TV or CD would be accepted (since they were the same on both sides of the mapping enum.)
  
  
• The SNMP driver still has some issues wrt to the recent changes for socket binding, so give it another try and see if this does better.
  
  
• The V1 version of the CQSL audio player is trying to access the power state fields, which only get created in V2 mode, which causes an error.
  
  
• The auto-gen is not using the V2 compliant forecast field on the weather tile, it's using one of the driver specific fields. Change it to use the V2 field.
  
  
• The high/low set points are on different sides in the main tiles screen and the detail screen. Make them the same with high on the left and low on the right.
  

[Dean Roddey]

Version 4.5.16 is posted. It has some small fixes and improvements, but mostly is just to get the first rough cut of a V2 Z-Wave driver out for folks to play with. See the notes at the bottom for details on the new driver.

• One more fix to the SNMP driver wrt to socket open/binding changes recently introduced. Currently it's sort of just defensive programming and needs to more solidly insure salubrious socket setup, but it works for now.
  
  
• The Elk V2 driver has possibly a wee logic error wrt to updating the status of non-secure zones when the area alarm state changes. It's possible it could get out of sync, because it was just flipping between NotReady/Violated instead of actually looking at the new alarm state and explicitly setting the values. If the driver ever called that method when the alarm state hadn't actually changed, it could cause the zones to go to the wrong state.
  
  
• Do a completely new, V2 compliant version of the Leviton Z-Wave driver. It's almost a rewrite from scratch because it's so fundamentally different. It should be vastly better than the old one. See below for comments on this new driver. Also note that I've not been able to test against thermos or locks yet, so they may not work. If they do, it's only by accident.
  
  
• The V2 Omni driver has a goober in temp/humidity zones where an error occurs as it's try to store incoming temp/SP values, so they never get stored.
  
  
• Allow a comparison value for the IsLoadChange (and the For/From variations) event filter, so that it can be used to only trigger for a load on or load off. That will allow for more efficiency.
  
  
• The template pre-scaling dialog shouldn't let you enter \User\ as the target scope, since it cleans out the target scope first, and this could accidentally toast everything. So make them enter at least a sub-scope under \User. It was checking that the target has to start with \User\, but of course \User\ starts with \User\, so you could accidentally toast your whole \User area.
  
  
• Add a new command to the RadioRA2 driver's InvokeCmd field. It is "RunTCEvent : tcid, eventid", so it will run a timeclock event. You pass the integration id of the time clock and the id of the event to run.
  

The new V2 Leviton Z-Wave driver is available now in an early version. There's been no testing yet against locks or thermos, so those bits may not work, or may not be fully V2 compliant yet.

* One known gotcha I just noticed... The buttons on the client driver that allow you to manually set config params or associations, or to do auto-config, shouldn't be enabled if you have made changes that need to be stored. They send unit names to the server, so the server has to have the same config as the client in order to be sure it can find the referenced units. So save your changes before using those buttons. I'll make sure in the next drop they are correct disabled if changes have not been stored.


Some other things to consider:

• It's a completely different driver, so it doesn't make use of the V1 driver's configuration.
  
• In order to avoid a lot of confusion, it now supports 'device info' files. For every unit you want the driver to make use of, you have to have one. For a while, we'll be sort of struggling to get them done, because sometimes it's awfully hard to find the required technical information. Some manufacturers seem to not bother publishing it. But, once the device info file is there, it becomes trivially easy to set up a z-wave device such that the driver can know how to interact with it.
  
• The devices often have fairly extensive options, but the device info files can usually default almost all of them, so the user only has to deal with the stuff that can actually vary, and doesn't have to worry about changing something that shouldn't vary.
  
• This new guy supports more ancillary functionality, such as battery reports or energy usage, which are generally separate from the core function of the device. As long as the device info is set up correctly, it will pick this stuff up, though in cases like the battery it's often going to be an option as to whether to enable it or not.
  
• This driver DOES NOT POLL. It's intended for use with modern Z-Wave devices that send out reports when status changes. It will do a (very sparse) active ping if it doesn't hear anything for quite a while, but that's it. This also though means that the Z-Wave network will be much 'quieter', and therefore more likely to be quicker to respond and more reliable.
  
• This one correctly deals with battery powered devices that don't say awake all the time (some do, most don't.) It will watch for wakeup notifications and will get any info it needs. It will also queue up outgoing commands and send them when the device wakes up. The queue is fairly small, so it can overflow. But it makes it practical to send setup commands to the device, since you don't have to sit there with a trigger finger waiting for it to wake up. It also now correctly sends 'no more info' commands to the device when it's done, so that it can go back to sleep as quickly as possible.
  
• It supports auto-configuration of devices, where that info is known and has been set into the device info file. It can set out commands to set up wake up interval, configuration parameters, and associations, to make sure that the device is set up properly for what the driver expects. This is a huge improvement over the previous driver.
  
• In theory it handles 'multi-instance' devices, i.e. devices that have more than one instance of a particular feature, such as a multi-contact closure device and whatnot. This functionality hasn't yet been implemented though since no hardware has been available to do so. We though the Aeon multi-sensor was, but it's in fact non-compliant and we had to add a special hack to support it.
  

Anyhoo, if you use it and you have a device that's not in the list, just post here and let's work out the device info required and you can then copy those files in (temporarily, they'll be in the real release the next time after that) and that will make the device info available for you to configure the device. Also, some of them have no auto-config info set, since I don't know what is required, or haven't had time yet to look that up. So if you think a device should have some auto-configuration, but the driver says none is available, let me know and we can work on getting that into the device info file as well.

Though I don't think it will happen, don't be totally surprised if you have to just remove the driver, trash the config, and start over. It is early code, and that sort of thing sometimes happens.

[Dean Roddey]

Version 4.5.18 is posted (.17 was for some one to test against only, so it was skipped.) This one is new V2 drivers and improvements in existing V2 drivers. A new driver for the Myro:Air device is now available, though the artwork support isn't tested yet. Support for Yale Real Living locks was added to the V2 Z-Wave driver. And there's a new V2 Aprilaire driver.

• More fixes for the V2 Omni driver. 1-Temp/humidity zones still need a status field. 2-Zones weren't counting assigned area as part of their equality testing, so the client wouldn't see changing the assigned area as a change. 3- There was a glitch in the initial querying of temp/humidity zone status, which could cause it to fail to poll a block of zones in some cases because of a one-off index issue. 4- The client side driver, when deciding when to show the changes indicator, was comparing the edited item to the pre-edit contents of that item, but it should have been comparing to the previous configuration version of the item. The pre-edit contents may also have been different from the original content, and could show a change even if you went back to the original state.
  
  
• Do a V2 enabled Aprilaire driver. Unlike the previous one, this one supports a configuration file, where you can name each thermo and provide per thermo low/high temp range, so that the current temp field can have limits, and therefore be useable with things like program bars (and it's required for V2 compliance as well.) See below for comments on the file format. Haven't been able to test it yet with external sensors connected, so those might not work. If you have such a system, and can let me have access for a bit, I can work on that
  
  
• Add another CommResult value, "Access", which can be used to indicate access denied type rejections of field writes. It's a fairly obvious one so might as well get it in there.
  
  
• Add support to the V2 Z-Wave driver for Yale Real Living locks, and fix some more goobers found along the way. This should mean other locks will work (given the right device info file) but given the level of inconsistency, it might require some sort of driver tweaking to support other locks, we'll see. The Yale ones are sort of different in that they are not wakeup type devices. They are always available, so the driver can treat them as mains powered effectively.
  
  
• Update the V2 Z-Wave driver so that the device info file can tell the driver about what async report will be sent when the driver does a field write on it to change the state. The driver can then use that generated async report effectively as a confirmation response, which is a big advantage over the previous driver. The fact that the message is sent doesn't really mean that it worked. This is effectively almost like doing a read back of the value, but without the overhead of that. So far it's only used on the door locks class, but could be used on others where it's advantageous.
  
  
• In the V2 Omni driver, when an area is armed/disarmed, the Omni doesn't send out zone status changes for the zones associated with that area. So the zone's Arming field doesn't change between armed/disarmed as the area is armed or disarmed. So, we need to do that manually. When the area arming state changes, go through all zones associated with that area and, for any that are not in a bypassed mode, update them to reflect the armed/disarmed state of the area. Oh, and it also needs to be done on driver startup, for any areas that are already armed, to get the zones into sync. Just figured that out before I was about to upload the release. Oy!
  
  
• Add the NowPlaying device class to the shipped list of device classes, since we need it for a Myro:Air driver. It can't be a formal renderer but needs to expose metadata in a standard way, so it's the first device of that type to be V2'd and we need to get Now Playing all worked out and implemented. Add a new GetNowplayingFlds(fieldlist, subunitname) method to the V2Helpers class to make it easier to build up the V2 compliant field defs for this class.
  
  
• Do a driver for the Myro Air device. It will implement the Media Transport and Now Playing device classes (and faux Power for V2 compliance purposes.) It will provide cover art via the standard backdoor command supported by the 'Driver Image' widget. As per the Now Playing device class the driver will expose an ImgSerialNum field that will change any time the artwork changes. This is what the image widget is associated with. And, as per, it will expose two named image types, CoverArt and PosterArt. This device doesn't support poster art, so it will return nothing for that. For cover art, if the device has provided it, it will be returned. * I couldn't test the artwork yet, so it might not work. I'll have to RDP into the user's system once he upgrades to this drop, and work on it that way, since the driver has to access a web server in the box (local network) to get the art.
  

The V2 Aprilaire configuration file is simple, it's in this form:

Code:

Version=1

// A comment
1=Kitchen,20,110
2=LivingRoom,-20,120

The first line must be the version. After that you can have comments and empty lines. Each non-empty/comment line must define a thermo. Starts with the thermo number, equals sign, the name (no spaces, alphanum plus underscore and hyphen), then comma separated low/high temp ranges to use for the current temp field limits.

Put it in:

[cqc]\CQCData\MacroFileRoot\Drivers\AprilaireV2\[moniker].Cfg

where [moniker] is the driver moniker, so that you can have more than one if you need to.

[Dean Roddey]

Version 4.5.19 is posted. This one is some small'ish fixes plus some expansion of the auto-generation system, to allow you to create a custom layout type template (assumed probably to be a floor plan type deal with lights and/or security zone indicators on it) which will be used as the detail template for the security tile, and optionally for the lighting tile (replacing the standard one.)

• One of the very few places where we use third party code is the JPEG support library, where we use the core files of the standard open JPEG library to handle the basic encode/decode functionality. If there is any data at the end of the file, after the image block, it will try to read them. If there's anything there that's not a valid block, it fails. The Myro device is returning some bogus data at the end apparently, but they get it from some Apple supplied library and probably can't do anything about it. So, for now at least, comment that trailing code reading out. That trailing data won't get into the actual image, so it should be correct even if saved back out. And this will make us more tolerant of other such munged files, though that's really the wrong thing to do.
  
  
• Add cover art image support to the Myro:Air driver.
  
  
• Since the client side V2 Z-Wave driver stuff for config, parms, and associations, now only work in terms of named units, those buttons shouldn't be available when changes have been made, since the local config may not be in sync with the server config wrt to names of units. So the client could send a unit name the server doesn't yet know about. Also make some other improvements to the client side interface while in there.
  
  
• Added some more device support to the Z-Wave V2 driver, though I'm not completely sure they are 100% correct. Some more Leviton devices.
  
  
• The V2 Omni driver was changed in the previous drop to update the armed/disarmed state of non-bypassed zones when the area arm state changes. To really make it work right, it shouldn't do this until the final arm state is reached, i.e. after the countdown timers are finished and we get the final arm status indicator.
  
  
• Update the auto-gen/system config stuff so that you can provide a 'custom layout' template. This is assumed typically to be a floor plan type template in which you place lights and/or security zone info. If set, it will be used as the detail template for the security tile (which otherwise doesn't have one), and can be optionally used in place of the standard lighting tile detail template. It (and any images it references) will be scaled and updated like any of the standard ones.
  

[Dean Roddey]

Version 4.5.20 is now posted. It's got a few small fixes slash updates, but by far the biggest thing in this one is support for Websockets. I did a preview slash overview post on this subject here, if you want some more info for now since the docs aren't updated to cover this yet:

http://www.charmedquark.com/vb_forum/sho...hp?t=11722

The list of changes are:

• The standard V2 helper method that sets up the fields for the Media Transport device class failed to put the L prefix before the limits string (which makes it a wide character string.) The silly compiler will, if there is a variation of the method that takes a boolean at that place, convert a non-wide string to a boolean parameter, silently. So it ended up calling another version of the field definition setup method, and didn't get the limits set correctly.
  
  
• The blanker window does a final explicit turn on of the monitor power when it is dismissed, just in case. But that extra one was put in after the destruction of the blanker window. The power command references the window after it's destroyed, and that causes problems.
  
  
• The Denon X4000 driver isn't handling writes to the set audio mode field, so it just gets rejected.
  
  
• The images from Driver Backdoor Image widgets haven't been working with RIVA clients, so get that fixed.
  
  
• Add a (non-V2 related) backdoor command to the standard media renderer engine, to allow clients to get the playlist id of the current playlist item.
  
  
• Add raw elapsed/total time fields to the Myro Air driver. These are non-V2 fields.
  
  
• Add support for Websockets to the web server. This is a fairly big addition, though nothing that would affect you if you aren't using it. But it will allow for much nicer browser based clients. The primary purpose for it is to support our own HTML5 based client in the 5.0 time frame. But, since it was there, it made sense to expose it to users as well. So you can create CML based server side handlers and effectively create your own web server protocol to serve whatever needs your client has. They should be effectively OS independent, as long as appropriate care is taken on the HTML side of things. The docs aren't done for this yet, but a preview post was done on it in the Support section of the forum.
  
  
• When the blanker is dismissed remotely, be sure to reset the 'last activity' time stamp. Otherwise, it may just go back to sleep because the inactivity interval has just been getting longer while it was blanked. If it's done remotely via the IV control protocol, then that needs to do it because no user input occurred. Also, when the blanker dismisses itself when clicked on, that click doesn't get to the IV to be seen as activity, so it needs to be updated there as well.
  

[Dean Roddey]

Version 4.5.21 is posted. Just some small fixes and a additions.

• Add action commands to the Devices target to call the driver backdoor commands that query a card or int value from the driver. We currently allow for text and boolean value queries, but not int or card values.
  
  
• The driver backdoor image widget wasn't protecting itself against an exception if the image data is bad, and causes an exception while decoding. This would leave the last good image displayed until the next good one was received. It should clear the image if this occurs, instead of leaving a potentially out of date image displayed.
  
  
• Another round with the V2 Z-Wave driver. A lot of improvements were implemented, and things learned. Added support for the Schlage BE469 lock, which seems to work well enough. Haven't figure out yet what it's sending though for async notifications. It's some variant on the alarm msg. Took an empirical shot at it, but it could be wrong. Kristian is going to get me some traces to look at from various lock/unlock activities.
  
  
• Add a NotSupported value to the CommResults enumeration, since that's another obvious reason for field write rejections that could be reported back to clients.
  
  
• The blanker window, when it dismisses and turns the power back on, tries to force itself to be the foreground window before doing it, because it used to it in such a way that could only be done when it was the foreground. This may be causing problems now and it's not required anymore given the way we do it, so remove that and see if the problems some folks are having go away.
  

[Dean Roddey]

Version 4.5.22 is posted. It's just improvements to the V2 Z-Wave driver, mainly to let some one do some testing, but also for anyone else who is interested in working with me to get some more module type support in place.

• More improvements to the Z-Wave driver. Got some more testing on some Leviton switches and realized I'd not re-wired the handling of scene reports back in, and a lot of scene capable lights use a scene report (for scene 0) as their way of reporting local changes. And, if there's no configured report response to a write to a dimmer, then do a read of the dimmer after an driver invoked Off/On operation, so that the dimmer level stays in sync. If the unit sends out a report in response to the driver doing Off/On, then we will get the dimmer level in that. Add support for removing all associations from a group. Internally, simplify things by converting basic reports to general reports, so that all reports are now general reports. This get's rid of a bunch of special casing. Have the driver, upon loading the first time before any user config is set, try to figure out which one is the VRCOP and go ahead and set it up for the user.
  
• More tweaks to the Schlage Z-Wave E369 lock support. It should in theory now correctly track physical lock/unlock operations at the door.
  
• Another tweak to the blanker stuff to see if it gets rid of some issues some folks are having.