Herve, Thank you this really adds to the discussion in my opinion. Since you are actually doing an implementation I have a few questions.
In the case of HSV/HSB does the limits 0-100% make since? I am not an expert but from what I understand it should work for HSV/HSB because the brightness is a 0-1 scale (i.e. 0 to 100%). Also does it make since to use a type of "integer" in the HSV/HSB model? Using type of integer means it only has 100 distinct steps. Would a value of 33.3 ever be desired? As an extra note. You can use the Multi-value "rt" resource to combine the Hue-saturation resource and the brightness resource into a single resource that is a union of both resources properties, see section 7.4.4 of the core specification. From what I understand this one of the reasons the Multi-value "rt" was added to the specification. If you want them to be separate resources (you are not using Multi-value "rt") you can use the batch interface to interact with a collection of resources. Making it to change two separate resources at the same time. Unfortunately I don't know of any examples showing how to use the batch interface properly so I personally don't know how to do this. I am still learning. George Nash From: Herve Jourdain [mailto:[email protected]] Sent: Friday, December 22, 2017 5:37 AM To: Clarke Stevens <[email protected]>; Michael Koster <[email protected]> Cc: Gregg Reynolds <[email protected]>; Mark Trayer <[email protected]>; Nash, George <[email protected]>; Wouter van der Beek <[email protected]>; [email protected]; [email protected] Subject: Re: [OCF smarthome_tg] Re: [dev] Questions about brightness and dimming resource types 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
