Class: Power

[Dean Roddey]

General Description

This thread is for discussion of the device class for the power and power status aspects of devices. After discussion it has become clear that there is enough to power state management and reporting to justify its being made into a separate class in order to support generic access to it.

The underlying reason for this device being created is that many devices, though powered on, are not necessarily ready to be used. So there will be good reasons to generically be able to power on or off a device, and then wait for the device to actually get up and ready or to be fully off. So we need a field to do the powering off and on, and a field to indicate standard power states.

Other device classes will be updated to remove power stuff from them, on the assumption that all V2 device (which have power concerns) will implement this device class.

Fields Provided
[INDENT]The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in the form:

PWR#sub~fieldname

where PWR# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. It will not be uncommon that there will be multi-unit concerns, since many devices that support multiple internal powered units. If the device provides more than one powered source, then the sub~ part will be present and will indicate the specific source instances, see the Multi-Unit section below.

The fields provided by this class are:

• Power. This field supports powering the device off and on. It MUST implement the Power semantic field type and MUST conform to the definition of that type.
  
• Status. This field is an enumerated, read-only field that indicates the power status of the device. It MUST implement the PowerState semantic field type and MUST conform to the definition of that type.
  

[/INDENT]

Multi-Unit Considerations

[INDENT]It is not unlikely that this device class will be used within a device that supports multiple powered units. Where that is the case, apply the same per-unit prefix to these fields that are otherwise being used in that driver. That may be a fixed prefix driven by the type of device (say zones within an A/V receiver), or a user provided name applied to the units. So PWR#Z1~Status, and so forth.

If the device also has an overall power control, it MUST be give the sub-unit name Main, so PWR#Main~Power, etc... That of course means that none of the other sub-units can be called Main, which may require adjustment if the names are queried from the device.
[/INDENT]

Backdoor Commands/Queries

[INDENT]None are required at this time.[/INDENT]

[Dean Roddey]

The 4.4.900 version should now support the Power device class (prefix is PWR#)

[Dean Roddey]

Added requirement that, if a device has both zoned and overall power control that the sub-unit name for the overall power control MUST be 'Main', for consistency.

[Mark Stega]

What would be the harm in allowing status to implement the PowerState semantic type, but allow the enumeration to be determined by the implementation of the driver? It seems this is only a field for displaying status to the end user and the more informative you can get the better off the user would be. I know we had a lot of discussion of the composition of this field, but now that I am implementing some V2 drivers it seems odd that we don't allow the driver to report precisely.

[Dean Roddey]

Actually it's for more than just human consumption. It has to have known values so that client logic can generically understand how to react to power state. So they can do things like see if it's in a final state, and if not wait for it to get there, and to know what that final state is based on current state, to decide if the current state requires a wait, and if it should display some sort of countdown and that sort of thing.

[Mark Stega]

OK, so how about two status fields; one for automation use and one for human consumption? The second status could leave the enumeration up to the driver.

[Dean Roddey]

It's probably too late at this point. Power is one of the most used ones and it's already implemented in quite a number of drivers. And 99% of devices already will see just the standard status as just busy work since they'll never it to anything but Off or Ready. Adding a third one would be a bit of overkill given how little it'll be used, and also considering the fact it's not likely to be necessary for any non-customized setup anyway, i.e. wouldn't hardly ever be needed in any auto-generated content or generic content designed for non-technical end users (for whom the standardized states are more than enough.) I would just leave it as a driver specific field if you want to have it for a specific device.