Sent to the smarthome task group I have cc'ed the iotivity-dev group since a related question was asked by another developer Fabian a few days ago.
As a programming exercise I have been developing a ocf light that is built using only standard interfaces that are defined on oneIoTa.org The brightness resource type has 3 entries on oneIoTa RAML, Swagger, and JSON Schema. oic.r.light.brightness.json<https://oneiota.org/revisions/2399> BrightnessResURI.swagger.json<https://oneiota.org/revisions/2518> brightness.raml<https://oneiota.org/revisions/1746> The dimming resource type also has 3 entries on oneIoTa RAML, Swagger, and JSON Schema. dimming.raml<https://oneiota.org/revisions/1798> DimmingResURI.swagger.json<https://oneiota.org/revisions/2530> oic.r.light.dimming.json<https://oneiota.org/revisions/2398> Which entry should be considered the defacto representation of the resource type? I ask because they don't all match up. In brightness all three list the "brightness" property with a maximum of 100 and minimum of 0. The swagger representation also lists "precision", "range", "step", and "value". These are all properties from oic.r.baseresource. I am confused why these properties are listed in BrightnessResURI.swagger.json? Are we expecting these values to be used in the brightness resource type? My confusion became even greater when I started looking at the dimming resource. In dimming all three list the "dimmingSetting" unlike the brightness there is no min/max value. The dimming.raml representation also shows "step", and "range". The swagger representation lists "dimmingSetting", "precision", "range", "step", and "value". Once again most of the properties are from oic.r.baseresource. What properties are required vs. optional? I could not identify this information from any of the 3 representations. My initial interpretation of this was: - The brightness was always a percentage 0% to 100% brightness. This would make more since if it was a number instead of an integer since in theory you could have 12.5% brightness. Still limiting it to the nearest 1% makes since. - The dimmingSetting was based on the actual values supported by the device. If you have a light with 255 brightness values. Then you would set the "range"=[0, 255]. Or possibly you have a light with 6 brightness settings you could set "range" =[0, 10], "step"=2, this would give you 6 possible values 0,2,4,6,8,10 oic.r.baseresource has led to other questions for me. Is oic.r.baseresource added to all resources by default? Note: I could not find any documentation on the baseresource. The only place it is even mentioned _that I could find_ was in the OCF Resource Type Specification v1.3. Every mention seems to assume that its already known and understood. If it were not for the listing in oneIoTa I don't think I would have known what was in the baseresource. If oic.r.baseresource is include by default how is it handled for Multi-value "rt" resources? (See section 7.4.4 of the OCF Core Specification v1.3) Wouldn't the oic.r.baseresource automatically force using composite resources where each resource is a link since it make a union of properties not possible? Initially I thought that the brightness and dimming resource types could exist in a Multi-value "rt" resource if my initial interpretation was correct one of the properties would have to be given a priority over the other when doing a update since it is possible the update would contain a dimmingSetting that would not work with the brightness on the same device. When I do a find on /oic/res the oic.r.baseresource is not found so it does not appear to be a default resource like many of the security related resources. George Nash
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
