Inheritance?

[nowox]

I am looking for exactly what Web Thing API offers, but I am missing an essential feature which is inheritance.

For example an onOffLight is a onOffSwitch. A dimmableLight is a onOffLight and a dimmableColorLight is a dimmableLight. With inheritance, I can build a component that is able to turn on and off a light, thus a component that understands how to interact with a onOffSwitch. Therefore it will able to control all the inherited Web Thing Types.

With this approach, the onOffColorLight would have different properties. Having a color string property that take hexadecimal RGB is a bad idea for multiple reasons:

1. Devices with limited resources would not be able to compose a hex string easily
2. color is not compatible with a dimmableLight.

Instead it would be better to have a HSL with:

• on
• luminosity, integer
• hue, integer
• saturation, integer

Then a dimmableLight has:

• on
• luminosity, integer

and a onOffLight has

• on

I would also add some read only properties with as lumens and type to a light. With this, it is possible to say how powerful is the light I am controlling and what type of light is it: omnidirectional, spot...

Currently with JSON schema draft 7 it is not possible to have inheritence. But this is something I think mandatory for a Web of Things.

What do you guys think?

[benfrancis]

A schema based capabilities system (#57) could probably help with a lot of this, because a device could expose multiple capabilities (e.g. Lamp, OnOffSwitch, DimmerSwitch, Color) rather than a single web thing type so that a client that knows how to turn an OnOffSwitch on and off can do that for any thing which exposes that capability, without necessarily knowing how to control all of its other capabilities.

There are many ways of representing colour (and colour temperature). The idea of a hexadecimal RGB string was to provide a web-style high level abstraction which could be mapped onto all of them. Resource constrained devices don't necessarily have to parse the hex strings themselves if they use the gateway integration pattern. If they use the direct integration pattern and expose a web server themselves, they're definitely capable of parsing a hex string. With a schema based system you could also define an HSLColor capability if you wanted to.

[nowox]

You are right about the hex colors, but how do you solve a light which is on with the color #000000 or even worse a dimmable color light with a luminance set to 50% and a color set to #ff0000. The web guy is expecting a full red color whereas he gets #800000...

My goal is to write something very similar to Web Things, but compatible with MQTT and low power devices. The ultimate goal is to get an interoperable standard to communicate with ZigBee, Z-Wave, EnOcean, Lora, KNX, Lonworks devices.

[benfrancis]

You are right about the hex colors, but how do you solve a light which is on with the color #000000 or even worse a dimmable color light with a luminance set to 50% and a color set to #ff0000. The web guy is expecting a full red color whereas he gets #800000.

Smart bulbs use all kinds of different methods for defining colour, colour temperature and brightness. Often setting a bulb to black doesn't actually completely turn it off. Some bulbs have both colour and colour temperature properties with separate RGB LED arrays. Mapping between colour and brightness and between colour and colour temperature is certainly challenging!

I think we're probably eventually going to move the web thing types (and capabilities) out of the Web Thing API specification, into an external schema repository like iotschema.org where all of these kinds of domain specific issues can be debated.

My goal is to write something very similar to Web Things, but compatible with MQTT and low power devices. The ultimate goal is to get an interoperable standard to communicate with ZigBee, Z-Wave, EnOcean, Lora, KNX, Lonworks devices.

Great, that's our goal too! That's what the Things Gateway is for, to bridge all of those underlying protocols to a standard Web of Things abstraction layer.

[kgiori]

Brief comment and questions on colored sourced of light. Background reference: I have hooked Philip's Hue to my Mozilla Things Gateway, and I have programmed RGB LEDs using microcontrollers.

Should we keep two different APIs, to better map to the way these existing products are programmed? That is:

1. Commercial colored bulbs -- color, temp, luminosity, hue, warm/cool, intensity... would be great if colored bulb industry experts gave us a common, standardized API.
2. RGB LEDs -- for these I have used a library to program hex or numeric values for R, G, and B. Is this enough or do we need more for a standard API that covers the different of types of RGB LEDs out there? (Some are 3-wire, some are 4-wire. Maybe more types too. But perhaps these wiring diffs don't matter to the API.)

Do these come together using an "inheritance" or "capabilities" approach? I am interested in understanding how these approaches would work for these two types of colored light. If we don't adopt a capabilities model and/or inheritance model we will end up with oodles of different APIs for only slightly different types of "things".

[benfrancis]

We could define an RGBColor capability and an HSLColor capability for example, although it's pretty trivial to just convert between the two at the API level and present whatever UI controls you want. It might make sense to have separate Color and ColorTemperature properties though, because it's easy to convert in one direction but not the other. The way that a Level/Brightness property and a Color property interact with each other may be implementation specific because of the variation in how the hardware works.

Currently iotschema is proposing a CurrentColour property with RColourData, GColourData and BColourData values. OneIoTA has a whole mess of different ways of specifying a colour.