The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Topic 1: Base Level Status Schema


  • Subject: RE: Topic 1: Base Level Status Schema
  • From: Kevin Hawkins
  • Date: Wed, 27 Aug 2003 01:53:00 +0000

A possible workaround if people prefer single body sections....see end

> -----Original Message-----
> From: Kevin Hawkins
> Sent: 26 August 2003 21:34



>
> SINGLE BODY - the second scenario
>
> xap-header <<< The response
> {
> ...
> UID=FF222200 <<< note the UID is the '00' one
> class=status.reponse
> source=ACME.Exampledevice.Test
> }
> interface <<<
> {
> switch=ON
> relay=OFF
> volume=ON
> volume=30%
> }
>
> The awkward thing here with a single body section is reporting NA
> and Unknown for devices and the fact that the same name pair gets used
> twice
> for state and level. Currently this is allowed in the spec but
requests
> have
> been made to disallow it. Also it is not possible to match UID's to
> names
> easily. Although it seems shorter and more readable it is problematic.
> Anyone a workaround for this ??
>

Thinking on the last comment above.... we could do away with say

State=

And just use one name value pair say ..

Level = 0 - 100% ONOFFERRORNAUNKNOWN

.. then we wouldn't create duplicate names in a body section

0% would have to be translated to OFF for binary status display and all
other values to ON.

level=OFF or level=ON indicates that the device does not support level
setting and has only a binary state.

note that a device may have to set to the closest level eg a device that
supports 0%, 50% and 100% that was set to 30% should set itself to 50% -
and
I guess report 50% in a status.report

Kevin








xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.