06-01-2014, 04:27 PM
(This post was last modified: 08-07-2014, 08:29 AM by Dean Roddey.)
So, I'm wrapping up the very last bits of 4.5 functionality, and we are about to go into the 'cool down' phase, where we'll only fix bugs, and we'll be doing some work on converting more drivers to V2 during that period as well, and docs of course.
The last thing done was the new auto-generation system, which also of course includes the room configuration stuff. That's been improved a lot as well, in terms of how you do the actual configuration. I would have gotten this out sooner so folks could start using it. It just ended up being the last thing done, so I couldn't do the XML GW stuff until it was ready.
Generally speaking the data is about the same. We decided that, because there are already so many improvements that we would just limit the new auto-gen system to basically the same functionality it had before, so that we can get 4.5 out the door. We'll pick up on the other side of 4.5 with more extensions to it.
Since the functionality is about the same, the data is more or less the same. However, it now all works purely in terms of V2 drivers, so things are more consistent, and it does mean some changes to the XML data that the XML GW server provides to room config based applications. This thread provides some documentation on what it's like now, so that room config based amps can 'catch up' to the new scheme.
V2 drivers work in terms of very strictly defined 'device classes' so it means that all drivers that implement a device class will implement the same field interface, syntax and semantics, so that client code and logic can work with them interchangeably. This makes it far easier to create programs like a generic room configuration based system. The new auto-gen (and hence room config) take full advantage of that.
So, here is an example of the configuration for a room. I'll provide following commentary on each chunk and how to interpret it. It's pretty straightforward.
The main element provides the name of the room, just for human consumption, and indicates Yes or No for the major functional areas. This lets the app know up front what to expect.
Next are a set of room variables. Each room has four values that can be defined on a per-room basis. On the auto-gen side, these are set as global variables that can be used within the user's custom overlays. In a room config app, they can be used however you want. They are also used in the global actions, discussed below, though that may be of less interest to a room based app. All four values are present whether they have a value or not. An empty value is assumed to be potentially meaningful as well.
After that we have sections pretty much like the previous data, though slightly different.
For Movies/Music, they are the same and they provide the renderer and repo driver monikers as before, and they are separated out unlike before, where they were both under Media. However, now in the V2 land, there is an Audio device class, and any driver that implements Audio should be able to be used as the volume and mute control for a room. So there is now Audio and AudioSub values. The Audio value is the moniker of the device to use. The Sub value is only set if the driver implements multiple sub-units of audio control, such as a multi-zone audio system.
The V2 architecture defines strictly how these values can be used to create the fields of interest. In the Music example above, the Audio is AG_MZAudio, which is a driver I installed for Auto-Generation testing. It's a multi-zone audio driver, so it has multiple zones. The AudioSub is Z2.
So the fields will be:
AG_MZAudio.AUD#Z2~Volume and AG_MZAudio.AUD#Z2~Mute. So you can easily build up all of the relevant fields based on that info. There's also AG_MZAudio.AUD#Z2~AdjustVolume as well, according to the Audio device class.
For Movies, the renderer driver is also provided as the Audio device and there is no sub value, since it is not multi-zone. So, according to the V2 world, the fields for that one would be AG_MovieRend.AUD#Volume and AG_MovieRend.AUD#Mute and so forth for any fields defined by the Audio class.
So this allows us to let the user use something besides the renderer itself to control volume and mute, which is very important for a lot of folk's setup.
For security it's basically like before, but again making use of the V2 scheme that defines what the form of all of the fields are that are implemented by a driver that implements the Security device class. So you get the security panel driver's moniker, and a security area name. From that you can build up all of the fields required. AG_Security.SEC#Area_House_InAlarm or AG_Security.SEC#Area_House_ArmMode and so on.
As before, in the body of the security element are a comma separated list of zones the user selected for this room, which are zones reported by the driver to be within the indicated security area. There again, given the moniker and the zone names, you can create all of the zone field names you need, just look at the Security device class for the details.
Weather is pretty self-explanatory, except that I added a Scale value to let the user tell you what temp scale indicators to provide for visual display. Otherwise it's like before, just a weather driver moniker. They are the V2 Weather device class forms of the fields, which are basically the old ones with the correct (WEATH#) prefix before them, see the Weather device class docs.
For lighting loads, like before, you get a list of loads. For each one you will get at least one of Switch, Dimmer or Color, and possibly any combination of two or all three. The Dimmer and Switch fields are from the Lighting device class and the Color field is from the ClrLighting device class. Dimmers always now have a standard 0 to 100 range. The color lighting is for devices like the Hue that support color settings/getting of lights.
There is a DefLoad value on the main Loads element, that tells you which of the loads is the one to be considered the main one for this room. It will be the name of the one of the loads in the list of loads received, so just find it in the list by name. There can be an arbitrary number of loads now, not just four, since they can let each room control all lights if they want to.
The global actions are pretty much like before as well, You get the name and a path to the global action and a set of parameters to pass to it. The only real difference is that they can now put %(1), %(2), %(3), %(4), and %(N) tokens in the parameters. The first four should be replaced with the values of the four room variables. The N one should be replaced with the current room name.
That's it basically. It's pretty similar, just with a lot more consistency and standardization.
The last thing done was the new auto-generation system, which also of course includes the room configuration stuff. That's been improved a lot as well, in terms of how you do the actual configuration. I would have gotten this out sooner so folks could start using it. It just ended up being the last thing done, so I couldn't do the XML GW stuff until it was ready.
Generally speaking the data is about the same. We decided that, because there are already so many improvements that we would just limit the new auto-gen system to basically the same functionality it had before, so that we can get 4.5 out the door. We'll pick up on the other side of 4.5 with more extensions to it.
Since the functionality is about the same, the data is more or less the same. However, it now all works purely in terms of V2 drivers, so things are more consistent, and it does mean some changes to the XML data that the XML GW server provides to room config based applications. This thread provides some documentation on what it's like now, so that room config based amps can 'catch up' to the new scheme.
V2 drivers work in terms of very strictly defined 'device classes' so it means that all drivers that implement a device class will implement the same field interface, syntax and semantics, so that client code and logic can work with them interchangeably. This makes it far easier to create programs like a generic room configuration based system. The new auto-gen (and hence room config) take full advantage of that.
So, here is an example of the configuration for a room. I'll provide following commentary on each chunk and how to interpret it. It's pretty straightforward.
Code:
<CQCSysCfg:Room CQCSysCfg:Name="Living Room"
CQCSysCfg:Loads="Yes"
CQCSysCfg:Music="Yes"
CQCSysCfg:Movies="Yes"
CQCSysCfg:Security="Yes"
CQCSysCfg:Weather="Yes">
<CQCSysCfg:RoomVars>
<CQCSysCfg:RoomVar>Value 1</CQCSysCfg:RoomVar>
<CQCSysCfg:RoomVar>Value 2</CQCSysCfg:RoomVar>
<CQCSysCfg:RoomVar>Value 3</CQCSysCfg:RoomVar>
<CQCSysCfg:RoomVar>Value 4</CQCSysCfg:RoomVar>
</CQCSysCfg:RoomVars>
<CQCSysCfg:Music CQCSysCfg:Player="AG_MusicRend"
CQCSysCfg:Repo="AG_MusicRepo"
CQCSysCfg:Audio="AG_MZAudio"
CQCSysCfg:AudioSub="Z2"/>
<CQCSysCfg:Movies CQCSysCfg:Player="AG_MovieRend"
CQCSysCfg:Repo="AG_MovieRepo"
CQCSysCfg:Audio="AG_MovieRend"
CQCSysCfg:AudioSub=""/>
<CQCSysCfg:Security CQCSysCfg:Panel="AG_Security"
CQCSysCfg:SecArea="House"
CQCSysCfg:ZoneCnt="2">
LRDoor, LRPatio
</CQCSysCfg:Security>
<CQCSysCfg:Weather CQCSysCfg:Drv="Weather" CQCSysCfg:Scale="F"/>
<CQCSysCfg:Loads CQCSysCfg:DefLoad="MBR Table">
<CQCSysCfg:Load CQCSysCfg:Name="MBR Table"
CQCSysCfg:Dimmer="LGHT#Dim_MBRTable"
CQCSysCfg:Switch="LGHT#Sw_MBRTable"/>
<CQCSysCfg:Load CQCSysCfg:Name="Front Porch"
CQCSysCfg:Switch="LGHT#Sw_ExtFrPorch"/>
<CQCSysCfg:Load CQCSysCfg:Name="L.Room TV"
CQCSysCfg:Dimmer="LGHT#Dim_LivRmTV"
CQCSysCfg:Switch="LGHT#Sw_LivRmTV"
CQCSysCfg:Color="CLGHT#LivRmTV"/>
</CQCSysCfg:Loads>
<CQCSysCfg:GlobActs>
<CQCSysCfg:GlobAct CQCSysCfg:Name="Room Loaded"
CQCSysCfg:ActPath="\User\GenTest\AutoGen\Setup">
<CQCGW:ActParm>%(1)</CQCGW:ActParm>
<CQCGW:ActParm>%(2)</CQCGW:ActParm>
<CQCGW:ActParm>%(3)</CQCGW:ActParm>
<CQCGW:ActParm>%(4)</CQCGW:ActParm>
</CQCSysCfg:GlobAct>
<CQCSysCfg:GlobAct CQCSysCfg:Name="IV Exiting"
CQCSysCfg:ActPath="\User\GenTest\AutoGen\Setup">
<CQCGW:ActParm>IV is exiting</CQCGW:ActParm>
<CQCGW:ActParm></CQCGW:ActParm>
<CQCGW:ActParm></CQCGW:ActParm>
<CQCGW:ActParm></CQCGW:ActParm>
</CQCSysCfg:GlobAct>
</CQCSysCfg:GlobActs>
</CQCSysCfg:Room>The main element provides the name of the room, just for human consumption, and indicates Yes or No for the major functional areas. This lets the app know up front what to expect.
Next are a set of room variables. Each room has four values that can be defined on a per-room basis. On the auto-gen side, these are set as global variables that can be used within the user's custom overlays. In a room config app, they can be used however you want. They are also used in the global actions, discussed below, though that may be of less interest to a room based app. All four values are present whether they have a value or not. An empty value is assumed to be potentially meaningful as well.
After that we have sections pretty much like the previous data, though slightly different.
For Movies/Music, they are the same and they provide the renderer and repo driver monikers as before, and they are separated out unlike before, where they were both under Media. However, now in the V2 land, there is an Audio device class, and any driver that implements Audio should be able to be used as the volume and mute control for a room. So there is now Audio and AudioSub values. The Audio value is the moniker of the device to use. The Sub value is only set if the driver implements multiple sub-units of audio control, such as a multi-zone audio system.
The V2 architecture defines strictly how these values can be used to create the fields of interest. In the Music example above, the Audio is AG_MZAudio, which is a driver I installed for Auto-Generation testing. It's a multi-zone audio driver, so it has multiple zones. The AudioSub is Z2.
So the fields will be:
AG_MZAudio.AUD#Z2~Volume and AG_MZAudio.AUD#Z2~Mute. So you can easily build up all of the relevant fields based on that info. There's also AG_MZAudio.AUD#Z2~AdjustVolume as well, according to the Audio device class.
For Movies, the renderer driver is also provided as the Audio device and there is no sub value, since it is not multi-zone. So, according to the V2 world, the fields for that one would be AG_MovieRend.AUD#Volume and AG_MovieRend.AUD#Mute and so forth for any fields defined by the Audio class.
So this allows us to let the user use something besides the renderer itself to control volume and mute, which is very important for a lot of folk's setup.
For security it's basically like before, but again making use of the V2 scheme that defines what the form of all of the fields are that are implemented by a driver that implements the Security device class. So you get the security panel driver's moniker, and a security area name. From that you can build up all of the fields required. AG_Security.SEC#Area_House_InAlarm or AG_Security.SEC#Area_House_ArmMode and so on.
As before, in the body of the security element are a comma separated list of zones the user selected for this room, which are zones reported by the driver to be within the indicated security area. There again, given the moniker and the zone names, you can create all of the zone field names you need, just look at the Security device class for the details.
Weather is pretty self-explanatory, except that I added a Scale value to let the user tell you what temp scale indicators to provide for visual display. Otherwise it's like before, just a weather driver moniker. They are the V2 Weather device class forms of the fields, which are basically the old ones with the correct (WEATH#) prefix before them, see the Weather device class docs.
For lighting loads, like before, you get a list of loads. For each one you will get at least one of Switch, Dimmer or Color, and possibly any combination of two or all three. The Dimmer and Switch fields are from the Lighting device class and the Color field is from the ClrLighting device class. Dimmers always now have a standard 0 to 100 range. The color lighting is for devices like the Hue that support color settings/getting of lights.
There is a DefLoad value on the main Loads element, that tells you which of the loads is the one to be considered the main one for this room. It will be the name of the one of the loads in the list of loads received, so just find it in the list by name. There can be an arbitrary number of loads now, not just four, since they can let each room control all lights if they want to.
The global actions are pretty much like before as well, You get the name and a path to the global action and a set of parameters to pass to it. The only real difference is that they can now put %(1), %(2), %(3), %(4), and %(N) tokens in the parameters. The first four should be replaced with the values of the four room variables. The N one should be replaced with the current room name.
That's it basically. It's pretty similar, just with a lot more consistency and standardization.
Dean Roddey
Explorans limites defectum
Explorans limites defectum