Hi,
I know this thread is a bit old, but I just wanted to remind that
"brightness" is required and has a specific definition in the case of
HSV/HSB, when using the Hue-Saturation colour model.
There are several variants of the Hue-Saturation model (HSL, HSV/HSB),
and you need 3 variables for those models: Hue, Saturation, and
Brightness (HSV/HSB model) or "Lightness" (HSL model).
Since we do not appear to have lightness, I believe we only support HSV?
So even if the difference can appear dim (pun intended) between the 2,
brightness is definitely needed for a specific role (defining the colour
in HSV), and adding dimming probably makes sense outside of that context
(for basically dimming the light without altering the color).
I had to deal with this case a few minutes ago (and the fact that
brightness is a separate resource from hs makes some "interesting"
colour transitions...).
Just my 2 cents.
Best regards,
Herve
On 06-Dec-17 05:07, Clarke Stevens wrote:
I agree with Michael. I think it was probably a mistake in this case
to provide both dimming and brightness different resources. There may
be cases where two interfaces are justified, but in those cases I
prefer a single resource that must be 100% synchronized with any
alternative resource (e.g. if you change the brightness resource, the
dimming resource is automatically updated so that a client is only
required to support the dimming resource). Ideally, there is only one
canonical resource published in oneIoTa and any additional interfaces
are either kept as private resources or as public resources that are
not required in any OCF published devices models. I would generally
discourage use of the second option to help ensure interoperability.
In fact, maybe we can include text in those resources that explicitly
states that they will never be required and shall only be used in
conjunction with the required resource that modulates the same property.
Thanks,
-Clarke
On Dec 4, 2017, at 5:52 PM, Michael Koster
<[email protected]
<mailto:[email protected]>> wrote:
+1 and lol
Input for the lighting model design...
We really only need one way to express brightness setting of a light,
and it should allow the control of real products with their diverse
scales (though many seem to be 0-255). There will need to be some
adaptation somewhere, but not in multiple resource types (IMO).
If there is a default scale, perhaps it should be 0-255 so as to
match up with a lot of existing commerciial products.
Best regards,
Michael
On Dec 4, 2017, at 3:09 PM, Gregg Reynolds <[email protected]
<mailto:[email protected]>> wrote:
On Dec 4, 2017 3:07 PM, "Mark Trayer" <[email protected]
<mailto:[email protected]>> wrote:
Greetings,
To go to your original question it really depends on what you
want to expose with respect to your particular light device.
The only resource a light must expose is oic.r.switch.binary
(i.e. you can turn it off and on), everything else is an
implementation choice and comes down to how you are representing
things and maybe the semantics of what you want to convey (i.e.
some devices talk about setting brightness, some talk about
ability to dim).
Dimming is a value defined by the range Property (if present)
... etc.
...
Brightness is a quantized representation (0..100)
Count me confused. Isn't OCF about standardization? Aren't
"brightness" and "dimness" just different words for the same thing?
Really, the model should be based on physics, not marketing fluff,
which is what "brightness" and "dimness" are. What happens when a
manufacturer offers "globulosity" or "mezmerosity" for their
lightbulb products?
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
