Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 4.0 Beta Discussion Thread
This is the old discussion thread for the 4.0 beta development process. It is now closed and just left around for future reference if needed. A new thread will be started for the 4.1 beta process.
Dean Roddey
Explorans limites defectum
So, I'll just start off by saying that the biggest thing by far in the 3.5 release will be ease of use, and hopefully to get to the point where anyone can set up a CQC system fairly easily. After going around and around in my brain about a thousand times, I think I've settled on a strategy to take, though of course once I dig in I can't promise I won't change it again based on what I find.

My high level scheme is something along these lines:

Driver Standardization

This just has to happen. It'll be a little painful, but no way out of it. Obviously this cannot involve just tossing all the existing drivers, so there will have to be a co-existence of old and new type drivers for a while until they all can be updated. The old ones just won't be able to participate in the new super-magical stuff.

This will involve coming up with standard sets of field names, and strict definitions of what those fields mean, what values they can have, and how the drivers should react to them. This won't be on a driver basis but a 'device class' basis, and some drivers will implement more than one of them. The manifest file will indicate what classes the driver implements and what versions of those classes. The driver IDE, knowing all these device classes, will be able to verify that any given driver meets at least the syntatical requirements of the classes claimed.

Since we'll have to have coexistence, I think it'll be common to add a driver prompt that indicates whether a driver can run in old or new mode. Since most drivers just create, register, and then look up their fields, the impact of this will be somewhat less than it would otherwise be. The fact that the field is called this instead of that will only impact the driver at the point of creating the fields.

In some cases, maybe just a new driver is started, but this could get even messier and inevitably fixes may need to end being made in two places, etc... So it may be better where it's not going to introduce undue complexity to try to go the dual mode route. Or, in other cases, the driver may choose to just maintain both sets of fields if they have little in common, but that should be rare. Any given device class is going to expose the obvious stuff that any driver of that class is likely to support. So it's mostly generally going to be a renaming of fields, and some stuff like 0 to 100% for volumes and dimmers and such instead of a device specific value.

Anyway, obviously there'll be a period there where it will inevitably be a bit more complicated, but we will eventually just say, look we are going to split off the drivers at this point, and the old ones will receive nothing but bug fixes from here on out, and eventually we'll just deprecate them completely. For drivers that are really stable and not likely to change at all, maybe just creating a new one for the new world is the better thing to do. But it'll be kind of case by case.

It may be that case that the commands that a driver can react to in this new scheme are moved more to a standard backdoor command instead of being so much field based, so that they can be standardized. And, since they are standardized, full prompted configuration of them will be possible, even more so than the field based stuff today.


A new method will be added to the driver interface, called something like TestProbe(), which will basically do a quick check on the passed serial port or IP end point (or other type of connection if that's what they use) to see if the device they support is on the other side. So they'll open the port, do some basic testing, then close it back down again and return a result.

This will be used in a new configuration tool to assist the user in finding devices. So it'll be able to ask them, do you have a light system? Can you pick it from this list, can you tell me what serial port it's on? No, ok, I'll test them. Same with IP ports, of which of course there can only be 256 on a class C address of the type that will be used in a home network.

This will vastly reduce the complexity of setting up a system, even for more advanced users really.


The installer will be vastly improved and made far less technical, so that it asks functionality based questions instead of process based questions. It'll be things like, do you want to be able to manage your CQC system from this machine? Do you want to be able to control devices attached to this machine? Do you want to be able to run touch screen interfaces from this machine? Stuff like that, which don't depend on knowlege of how CQC is internally divided into functional units.

Super Configurator

Using all of the above stuff, a super configurator, or maybe system builder is the better term will be provided that will ask you some questions about how your home is laid out in terms of rooms, ask you what devices are in what rooms, and some other stuff like would you like to turn any things on or off at sunrise or sunset, etc... If you have audio or video switchers it'll ask you what outputs go to what rooms and what devices are connected to what inputs.

Then it will just generate a complete system for you, probably allowing you to pick between a few styles (though the layout will likely be the same with just the colors and graphics changing.) At that point, you can make modifications directly, but they will be overwritten if you run the builder thingie again. So you either stick with making changes in the builder and regenerating, or you generate it and then modify.

Either would be a viable scenario depending on what you want to achieve. For the non-technical users, just generating a system and using it will be fine. For the technical DIYer, it's a good way to get a head start, and then modify from there. For the integrator it's a way to generate new customer systems based on standard configurations (since the info you provide to the configurator can be stored and recalled.) They may then make customizations, but it'll vastly simplify their work to support a number of system variations, and to spit out new ad hoc variations as well.

There may be some capability to customize stuff in the configurator itself to some degree. But this will never become a substitute for a talented interface designer doing something completely customized. It can never match that. The point of it is to be able to create good systems quick, not to create ultimate systems. So it's only going to support the core stuff, lighting, multi-zone audio, security, HVAC, and weather, at least initially until enough feedback is gotten from users as to how we can take it further. And hence mostly only these drivers would need to initially make the transition to the new driver scheme mentioned above, with others doing so over time (though there will be other advantages to even advanced uses working through these new style drivers as well, for reasons of easy swapping of devices, so it would be good to have others moved forward as well, even if not needed by this builder thingie.)

One way it might offer customization is to generate some of the commands such that they really just invoke global actions, into which some standard functionality will be automatically generated. But then you can modify them to do other things. So they'd be stuff like LightsOnOff or something like that, and would receive the room indentifier and the on/off indicator. So you could choose to do other things when the user turns the lights off or on in the room. These I guess could remain unchanged during a regeneration of the system, with only new ones being created if needed.

One advantage is that, since they are just generated, there's no need to be super-fancy with them. So they don't need huge amounts of flexibility internally as a highly dynamically reusable type system would need. The generated stuff can be just straight to the point, and fairly easy to understand.

Another reason for doing it this way, instead of the specialized client we initially considered, is that it both offers benefits for everyone, and it means that these generated interfaces are prime targets for integrators to upsell the customer on customizations. They will be built using all the existing stuff, i.e. they'll be real IV interfaces, real scheduled events, and so forth. So it would just be a matter of picking up where the configuration tool left off and taking manual advantage of all of the power available, which the auto generator really can't.
Dean Roddey
Explorans limites defectum
General Tools Changes (too many characters for one post)

Assuming my brain is not fried by the above, and there's time left, some much desired general tool changes will also be implemented. Some of these can come towards the end while the big stuff above is being digested by everyone. Not all of these will get done. Even just getting the above done will be somewhat ambitious. But, where these can be done, they'll be done, else they'll be pushed to the next release.
  • Drag and drop of images into the image repository
  • Possibly converting to an Expression Blend style attribute bar interface in the interface editor, so that the tabs are all stacked up on the right instead of in a dialog box.
  • Beginning to get some context smarts in the CML editor, maybe starting with some assisted parameter prompting stuff and whatnot.
  • Logging tools improvements
  • I'd love to, as a first step towards tools integration, consolidate the remote data browsing interfaces to create a single hierarchy of macros, images, global actions, and interfaces, so that they can all be browsed from the Admin Interface and then the correct editor invoked from there (with the longer term goal of moving those editors into the Admin Intf as well.) Also, the abiltiy to create a new package creator where you just drag stuff from the hierchical view into a packager window to create them.
  • A simple but effective one would be to get rid of stuff like System::Equals in the action editor. They'd still actuall be there, but would be hidden and the actual display would be (x == y) and so forth. It would purely be a visual change, not a painful change in the actual action system. But it would make a lot of difference in terms of usability of the editor probably.

To Summarize

So anyway, there it is. It's pretty ambitious, but I'm going to once and for all get past this 'only geeks can understand it' thing, and do so without sacrificing any of the power that's available. If we can get it to the point where a reasonably intelligent person can answer some questions and get a system up with a pretty graphical interface first time out, in half a day or something, then I think that will be a massive step towards actually getting some sales. And not just in the DIY world. This is heavily required for integrators as well.

In subsequent releases we'll have to then drop down to the more detailed issues of usability. And I know some of you will be unhappy that all this time is being spent on something other than that. But this is really necessary to be successful. And I think that there will be so many benefits in terms of being able to swap out devices without change, and the huge benefits for being able to reuse your own or other people's interfaces.
Dean Roddey
Explorans limites defectum
If you can get half of what you've mentioned so far, I'm already loving it.
All of those things sound great!
If you can't get microsoft tts working in windows 7, support for a third party tts api
I can't wait ,Ive almost given up on making CQC work for me.I have always got part to work but could never get the whole system figured out.Hopefully this will be so easy a caveman could do it.:-)
Sounds wonderful dean!

With the simplefldclient, is there no way to test that a driver is online? Do you just have to catch the exception and assume that means its offline?
If you are going to be reading fields anyway, then just catching the exception is best. If you explicitly just want to test one, yo could do a WaitDriverReady() call with a short timeout. Though that's not something to do for a really fast test, since it may wait a little longer than you indicate.
Dean Roddey
Explorans limites defectum
This would be great, and I agree, TTS in Windows 7 needs to be done. If it has to be done in a foreground app., then that would be fine, and could even be considered a great feature.

And while you are doing this :-D a way to start and pause the TTS queue would be fantastic. I use an audio switcher so I can change which speakers a message comes out of. If I could pause, switch, then speak, pause, switch, and speak and keep it all in-sync, I'd be so happy.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 40,418 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 7,299 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,111 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,898 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 87,586 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,797 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 196,384 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,444 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 488,965 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,266 11-01-2016, 10:32 AM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)