Dean Roddey
Senior Member
So I'm now in the 'end game' for the next release, and it's been a real brain fryer since it's making some really fundamental changes. I just wanted to describe some of this new stuff and get some feedback before it's too late to make changes 'easily', particularly since some of these changes are driven by comments from folks here.
Not for Programmers
One common complaint we've had is that there were two levels of configuring logic in CQC. To cause things to happen in CQC you create an 'action', which currently is just a flat list of steps, no logic. Any of those steps can be an invocation of one of our CML macros, but that's a programming language and more than many folks want to bite off. To deal with this, we've introduced logic at the action level. The action level is also the level at which are you working via a prompted dialog box, as apposed to CML which is a free form text language. So now you can go do logic via a prompted dialog.
It won't allow you to match a powerful language like CML, but it goes a long way towards preventing a need for CML. In the example above an action is shown that is the action for a triggered event that speaks the day of the week and the current weather conditions (from the weather channel) when motion is detected in the Kitchen, as long as it's not suppressed by setting a global variable value. It also is using a count down timer in the timers driver so that it will only speak again after 15 minutes of no motion.
You can see that it provides If/Else type logic decisions, comments, local and global variables for storing values and manipulating them. The other big difference over the existing system is that it provides lots of helpers for entering values. There was some of this before but it's much expanded now, so that you actually don't have do much typing. If you are writing to an IR device, you can select from a list of all the available IR commands. The parameter fields at the bottom are where you enter the values for the selected command, and the litttle button beside them allows you to do a prompted set of the value and the popup menu on the entry fields allow you to insert various types of info.
Popup Templates
Another big thing in this release is the ability to do 'modal popup interfaces', basically similar to dialog boxes in Windows, but with all the full graphical power of our interface system. This can be used in many ways from popping up a confirmation ("Are you sure you want to turn on the fireplace with your head in it?") to popping up a radar weather image or a CD selection window.
It's a very flexible system in that the popup can set global variables that the calling (underlying, invoking) interface can see and react to. That's how you can do a confirmation popup, by just having it set a particular global variable to Yes or No and reacting to it (using the conditional logic we introduced in the previous section) to do something or not. Or a CD selection poup and store the selected title info (a title cookie in our parlance) which can be used when it's closed to play that title.
You can see from the example above that you have access to all the graphical power of our interface system to do slick popup looks. And you can combine it with the new action system in nice ways. In the 'Are you sure' popup above, that is a generic template in that the title text and the question text are passed into ot, so it can be used in many situations. Here's an example of invoking it:
It's setting up two global variables to indicate the title and question text (all interfaces in a given viewer window share gobal variables) and then invoking the popup. On return, it cleans up the two globals, then checks the value of the variable that the popup stored either Yes or No in and if it was Yes it does an exit command to exit the current template.
A template can have an 'OnLoad' action and there's one set on this popup template that looks for those two variables and loads them into the title and question text 'widgets'. Anyway, lot's of flexibility, and the interface is really quite programmable, allowing you to create very different looks and flows of control.
Triggered Events
Triggered events are what you configure in CQC to react to changes in the system state by running an action. It's composed of two parts, one being the filters that decide whether the action should be run or not and then the action to run. We previously had a 'filter language' that again was a little more obscure than some folks would have liked. So that's now been replaced by a set of four graphically configured filters. In the vast bulk of cases that's more than enough to effectively guarantee that the event will only run when appropriate, though of course the new action logic can be used to further make decisions as to what to do.
This is the filter set for the first example given above for the event that speaks the weather conditions on motion. I'm using our little device simulator for these examples (which simulates a small house's worth of faux devices) so that's what the DevSim you see is referring to. It's see if the incoming event is a change in in the KitchenMotion field, and that the current hour is between 8 and 9, and that the countdown timer channel 1 has zeroed out. Those are combined with All True logic (AND) so it's run if all of them are true.
There are other big goodies as well, in the media area, but I'll touch on them in a subsequent post. I figure these are the ones that most address previously mentioned shortcomings in CQC from folks here. Does any of that make sense above, or address issues that you might have had with CQC so far? If it doesn't make sense, just ask or if you have any comments let me know what you think.
Not for Programmers
One common complaint we've had is that there were two levels of configuring logic in CQC. To cause things to happen in CQC you create an 'action', which currently is just a flat list of steps, no logic. Any of those steps can be an invocation of one of our CML macros, but that's a programming language and more than many folks want to bite off. To deal with this, we've introduced logic at the action level. The action level is also the level at which are you working via a prompted dialog box, as apposed to CML which is a free form text language. So now you can go do logic via a prompted dialog.

It won't allow you to match a powerful language like CML, but it goes a long way towards preventing a need for CML. In the example above an action is shown that is the action for a triggered event that speaks the day of the week and the current weather conditions (from the weather channel) when motion is detected in the Kitchen, as long as it's not suppressed by setting a global variable value. It also is using a count down timer in the timers driver so that it will only speak again after 15 minutes of no motion.
You can see that it provides If/Else type logic decisions, comments, local and global variables for storing values and manipulating them. The other big difference over the existing system is that it provides lots of helpers for entering values. There was some of this before but it's much expanded now, so that you actually don't have do much typing. If you are writing to an IR device, you can select from a list of all the available IR commands. The parameter fields at the bottom are where you enter the values for the selected command, and the litttle button beside them allows you to do a prompted set of the value and the popup menu on the entry fields allow you to insert various types of info.
Popup Templates
Another big thing in this release is the ability to do 'modal popup interfaces', basically similar to dialog boxes in Windows, but with all the full graphical power of our interface system. This can be used in many ways from popping up a confirmation ("Are you sure you want to turn on the fireplace with your head in it?") to popping up a radar weather image or a CD selection window.

It's a very flexible system in that the popup can set global variables that the calling (underlying, invoking) interface can see and react to. That's how you can do a confirmation popup, by just having it set a particular global variable to Yes or No and reacting to it (using the conditional logic we introduced in the previous section) to do something or not. Or a CD selection poup and store the selected title info (a title cookie in our parlance) which can be used when it's closed to play that title.

You can see from the example above that you have access to all the graphical power of our interface system to do slick popup looks. And you can combine it with the new action system in nice ways. In the 'Are you sure' popup above, that is a generic template in that the title text and the question text are passed into ot, so it can be used in many situations. Here's an example of invoking it:

It's setting up two global variables to indicate the title and question text (all interfaces in a given viewer window share gobal variables) and then invoking the popup. On return, it cleans up the two globals, then checks the value of the variable that the popup stored either Yes or No in and if it was Yes it does an exit command to exit the current template.
A template can have an 'OnLoad' action and there's one set on this popup template that looks for those two variables and loads them into the title and question text 'widgets'. Anyway, lot's of flexibility, and the interface is really quite programmable, allowing you to create very different looks and flows of control.
Triggered Events
Triggered events are what you configure in CQC to react to changes in the system state by running an action. It's composed of two parts, one being the filters that decide whether the action should be run or not and then the action to run. We previously had a 'filter language' that again was a little more obscure than some folks would have liked. So that's now been replaced by a set of four graphically configured filters. In the vast bulk of cases that's more than enough to effectively guarantee that the event will only run when appropriate, though of course the new action logic can be used to further make decisions as to what to do.

This is the filter set for the first example given above for the event that speaks the weather conditions on motion. I'm using our little device simulator for these examples (which simulates a small house's worth of faux devices) so that's what the DevSim you see is referring to. It's see if the incoming event is a change in in the KitchenMotion field, and that the current hour is between 8 and 9, and that the countdown timer channel 1 has zeroed out. Those are combined with All True logic (AND) so it's run if all of them are true.
There are other big goodies as well, in the media area, but I'll touch on them in a subsequent post. I figure these are the ones that most address previously mentioned shortcomings in CQC from folks here. Does any of that make sense above, or address issues that you might have had with CQC so far? If it doesn't make sense, just ask or if you have any comments let me know what you think.