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
