+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]> 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
