Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Semantic Field Types
[Split this list because I hit the character limit on the first post]


These fields MUST be Boolean. They represent the state of an LED, usually in lighting systems. They MAY be read, write, or read/write depending on the capabilities of the device

This type has the same restrictions as the more basic BoolSwitch type. It just provides more specific semantics in that it implies that the thing to be switched is a light, as opposed to something else.

These types of fields MUST be of type Int and have a range limit that indicates the available range of set point values. It must be at least writeable, and where possible readable.




This type provides information about the playback state of a media stream (audio or video.) It lets the clients of the driver know what the current playback state is. This MUST be a read-only, enumerated string field. The enumerated values are listed below and what they mean:
  • Undefined - The state is not one of the standard ones, and can't be reported.
  • Buffering - The device is buffering data from the source, often indicating insufficient data rate
  • Loading - The device is doing the initial location of the media and starting the loading process
  • Playing - Media is currently actively playing back, i.e. not paused.
  • Paused - Media is loaded, but currently paused
  • Stopped - No media is currently loaded. When commanded to stop, the driver should not just pause, but stop and unload media. This allows for moving to the next item in the playlist if applicable.

This type provides transport control over media streams. It must be an enumerated string field, and write only. It MUST provide the following enumerated values: Pause, Play, Stop, Next, Previous, FF, and Rewind. If a given driver cannot handle one of these values, it MUST just ignore the command.

The type of these fields ultimately is not very important. Motion sensor fields are assumed to exist purely to represent the motion sensor within the driver and to provide a source field name for motion triggers that get sent out. But they are not expected to hold any useful information. But, for the sake of consistency, the MUST be Boolean fields, and readable since they have to have some sort of access.

This type has the same restrictions as the more basic BoolSwitch type. It just provides more specific semantics in that it implies that it controls some audio muting attribute of the owning device.

In pre-V2 drivers this type of field is used to both get and set the power state of a device, or sub-unit of the device. It must be Boolean and MUST be at least writeable, and hopefully readable though that is not required.

In the V2 world this type of field is used to request a power state change. It doesn't reflect the current power state. It is Boolean and write-only. When written to, the device must begin the transition to the requested power state if not there already. It MAY complete the transition before returning if that happens quickly, but it is not necessary. See the PowerState type below.

This type is primarily used by the Power device class, and provides a standard means of indicating power status (which can be more complex than just Off and On.) It MUST be a read only, enumerated string field, with the following values:
  • Off - The device is fully off.
  • Starting - The device has been powered on but is not yet ready.
  • Ready - The device is powered up and ready.
  • Stopping - The device is still powered on but is stopping.
  • Failed - The device is powered on, but has failed to start for some reason and likely will not change without manual intervention of some sort.
The Power device class uses it conjunction with the Power field, see the Power type above.

This field must be of Boolean type and at least writable. Typically it will be readable as well, but that is not required.


This field MUST be a read only string field, with an enumerated limit that indicates the possible zone statuses. It is REQUIRED that these match the standard zone trigger states of Secure, Not Ready, Violated, and Bypassed, with an extra value of Unknown to deal with states outside of the V2 understanding of zone states. If further state information is required, then a separate, driver specific, field must be provided for each zone. This is somewhat limiting but required in order to generate portable security oriented logic and interfaces. The values means:
  • Secure - The zone is secure, without concern for whether the containing area is armed or disarmed, i.e. the window is closed, the door is closed, etc...
  • Not Ready - The zone is not secure, but its owning area is not in alarm, so it currently doesn't technically constitute a security problem.
  • Violated - The zone is not ready, and the owning area is in alarm.
  • Bypassed - The zone is bypassed and will not report the above changes. This may not be used by any given device. If not you will just never see it. This was added as of 5.3.926.
  • Unknown - The state of the zone is not provably one of the above standard states.

This field MUST be either a String field that contains the name of a source input, or a Card field that indicates an input number. In a given device class these fields may be readable or writeable, or both, depending on device capabilities, but will typically be read/write. If writeable, then it MUST have an Enum or Range limit that indicates the available settable inputs (or input modes.)

This field MUST be Int or Float and represents the value of a temperature sensor. If possible it SHOULD have an appropriate Range limit so that it can be used in various display widgets. It MUST be read only. These are separate for CurTemp and CurExtTemp in that these are not implying atmospheric temps that the user would experience, but other temp sensors for things like water temperature and the like


These fields MUST either be a String with a pre-formatted tuner frequency in it, or a floating point value that contains the integral and fractional kilo/megahertz of the frequency. Though it MAY be writeable to set the frequency, no assumptions are made about that wrt to this type. It's assumed it's just for display.

These fields MUST be percentage ranges, Card fields with a Range limit of 0 to 100. Any other scale is not allowed. We have to standardized on a percentage based scale for portability reasons. It can be read, write, or read/write depending on the capabilities of the device.

These fields MUST be Boolean, where writing False to them reduces volume and writing True increases volume. It MUST be write only, so that multiple writes of the same value will be forward to the driver.
Dean Roddey
Explorans limites defectum

Messages In This Thread
Semantic Field Types - by Dean Roddey - 05-01-2013, 03:43 PM
Semantic Field Types - by Dean Roddey - 05-01-2013, 03:47 PM
Semantic Field Types - by Dean Roddey - 08-31-2013, 06:34 PM

Possibly Related Threads…
Thread Author Replies Views Last Post
  Semantic Field Type Discussion Dean Roddey 18 18,342 06-23-2014, 08:29 AM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)