Greetings, The design intent was not originally two ways to do the same thing; dimming (not 'dimness') represents the actuation of a dimmer function that meets the requirements Michael enunciated already (it's a server defined range that defaults to 0..100 but can be anything within the limits of the definition of an integer).
Brightness was intended to be a sensed representation (i.e. measure) based on requirements a lighting vendor had when the resources were first defined, this has been arguably superseded by illuminance which is an actual measure of sensed luminous flux. Where this went sideways was in allowing brightness to be actuated as well as sensed. Guidance can be added on appropriate usage to avoid future confusion. Note also that the review processes for approval of changes to oneIoTa (www.oneiota.org<http://www.oneiota.org>) and best practice guidance that has been since developed would obviate this happening going forward, so no, you can't have oic.r.mezmerosity unless of course there's a de facto industry standard for what this means and a driving Use Case for inclusion! Best, Mark. From: Michael Koster [mailto:[email protected]] Sent: Monday, December 4, 2017 6:53 PM To: Gregg Reynolds <[email protected]> Cc: Mark Trayer <[email protected]>; Nash, George <[email protected]>; Wouter van der Beek (wovander) <[email protected]>; [email protected]; [email protected] Subject: Re: [OCF smarthome_tg] Re: [dev] Questions about brightness and dimming resource types +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
