Hi Kishen,

That does the trick. The client could see the resources now.

Thanks,
Kien

On 2017/04/08 2:38, "Maloor, Kishen" <kishen.maloor at intel.com> wrote:

    Hi Kien,

    You have to also set OC_MAX_APP_RESOURCES to 2 in this case inside
    port/zephyr/src/config.h by modifying the line below and rebuilding the
    image:

    #define OC_MAX_APP_RESOURCES (1)

    Then you will see both resources show up on the client.

    -Kishen.



    -
    Kishen Maloor
    Intel Open Source Technology Center




    On 4/6/17, 11:54 PM, "Dinh, Kien T" <kien.t.dinh at intel.com> wrote:

    >Hi Kishen,
    >
    >I tried some more to follow your advice to separate to two logical
    >resources
    >on the Arduino 101. And I used the client_linux on linux side to detect
    >them.
    >
    >--
    >static void
    >register_resources(void)
    >{
    >  oc_resource_t *res = oc_new_resource("/a/light", 1, 0);
    >  oc_resource_bind_resource_type(res, "oic.r.light");
    >  oc_resource_bind_resource_interface(res, OC_IF_RW);
    >  oc_resource_set_default_interface(res, OC_IF_RW);
    >  oc_resource_set_discoverable(res, true);
    >  oc_resource_set_periodic_observable(res, 1);
    >  oc_resource_set_request_handler(res, OC_GET, get_light, NULL);
    >  oc_resource_set_request_handler(res, OC_POST, post_light, NULL);
    >  oc_resource_set_request_handler(res, OC_PUT, put_light, NULL);
    >  oc_add_resource(res);
    >
    >  oc_resource_t *res2 = oc_new_resource("/a/temperature", 1, 0);
    >  oc_resource_bind_resource_type(res2, "oic.r.temperature");
    >  oc_resource_bind_resource_interface(res2, OC_IF_R);
    >  oc_resource_set_default_interface(res2, OC_IF_R);
    >  oc_resource_set_discoverable(res2, true);
    >  oc_resource_set_periodic_observable(res2, 1);
    >  oc_resource_set_request_handler(res2, OC_GET, get_temp, NULL);
    >  oc_add_resource(res2);
    >}
    >--
    >
    >However, it could only detect the first resource type, ?oic.r.light? in
    >this case.
    >If ?oic.r.temperature? was in the first place, it would be discovered. I
    >tried again
    >and confirmed that it only worked when adding multiple types to a single
    >resource,
    >like the code in the first email. That is, only the following gets
    >discovered:
    >
    >{
    >?
    >  oc_resource_t *res = oc_new_resource("/a/light", 2, 0);
    >  oc_resource_bind_resource_type(res, "oic.r.light");
    >  oc_resource_bind_resource_type(res, "oic.r.temperature");
    >?
    >}
    >
    >Thanks,
    >Kien
    >
    >On 2017/04/07 11:14, "iotivity-dev-bounces at lists.iotivity.org on behalf
    >of Dinh, Kien T" <iotivity-dev-bounces at lists.iotivity.org on behalf of
    >kien.t.dinh at intel.com> wrote:
    >
    >    Hi Kishen,
    >    
    >    Thank you for the reply and advices. You?re right. There seems to be
    >a problem
    >    on the client side. We use a rest-api-server to monitor the
    >OCF-resources.
    >    It discovers the resources and registers itself as a client to
    >observe the
    >    changes. I used the client_linux to test and it could detect the
    >resource types
    >    types on the Arduino 101.
    >    
    >    Thanks,
    >    Kien
    >    
    >    
    >    On 2017/04/07 8:16, "Maloor, Kishen" <kishen.maloor at intel.com> 
wrote:
    >    
    >        Hello Kien,
    >        
    >        > I tweaked the ?apps/server_zephyr.c? as following to
    >        > bind a new temperature type. However, I could only
    >        > see the first one,
    >        
    >        When you say ?you? could see, I assume you?re talking
    >        about a client application :-) You should probably
    >        revisit your client logic (not sure if you?re using
    >        IoTivity or IoTivity-Constrained for that)
    >        because if you bound two resource types to a resource
    >        on the server in the manner you described, they should most
    >        certainly show on your client during discovery.
    >    
    >        By the way, I just quickly tried what you did on my
    >        end (by updating client_linux), and could see the two.
    >    
    >        > would like to map each sensor to a standard type so
    >        > that the device can have multiple resource types at
    >        > the same time
    >        
    >        If you?re exposing two distinct physical resources,
    >        you should probably be creating two separate logical resources
    >        inside the register_resources() callback, one for each physical
    >        resource. This way you could attach separate handlers to each.
    >        
    >        > However, so far it seemed that iotivity-constrained
    >        > only allowed binding to one.
    >        
    >        ?Binding? a logical resource to multiple resource
    >        types (which the stack does support) is generally
    >        different from what you?re trying to do.
    >        You might want to bind multiple resource types when the
    >        two resource types largely overlap in their data
    >        models, or if may be one conveys the other in some way.
    >        
    >        
    >        
    >        
    >        -
    >        Kishen Maloor
    >        Intel Open Source Technology Center
    >        
    >        
    >        
    >        
    >        From:  <iotivity-dev-bounces at lists.iotivity.org> on behalf of
    >"Dinh, Kien
    >        T" <kien.t.dinh at intel.com>
    >        Date:  Wednesday, April 5, 2017 at 6:21 AM
    >        To:  "iotivity-dev at lists.iotivity.org"
    ><iotivity-dev at lists.iotivity.org>
    >        Subject:  [dev] iotivity-constrained: binding multiple types
    >        
    >        
    >        Kien
    >        
    >        
    >    
    >    _______________________________________________
    >    iotivity-dev mailing list
    >    iotivity-dev at lists.iotivity.org
    >    https://lists.iotivity.org/mailman/listinfo/iotivity-dev
    >    
    >



Reply via email to