Date   

Re: Iotivity lite state

Kishen Maloor
 

Thanks, George. If you could cherry-pick those specific changes to master, that should satisfy the immediate request.

 

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: "Nash, George" <george.nash@...>
Date: Wednesday, April 22, 2020 at 8:06 PM
To: "Maloor, Kishen" <kishen.maloor@...>, "fariouche@..." <fariouche@...>, "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: RE: [dev] Iotivity lite state

 

The API that I added is only concerned with the ownership status e.g. owned vs. unowned. Any other configuration status is not part of the change.  What other configurations were you interested in?

 

It should not be too hard to cherry-pick that specific change to master.

 

Kishen if you would like me to do that I could have it done tomorrow.

 

You could also checkout the `ocfbridging` branch. If you want to use those APIs before they go through the full review process.

 

You will find three new functions and a callback function

Callback `oc_ownership_status_cb_t` (the callback gives the UUID, logical device index and a bool value indicating if the device’s status is owned or unowned)

Function `oc_add_ownership_status_callback`

Function `oc_remove_ownership_status_callback`

Function `oc_is_owned_device`

 

 

I have kept the `ofcbridging` branch up to date with master so you should be able to use the new APIs without making any additional modifications to your code.

 

George

 

 

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 4:43 PM
To: fariouche@...; iotivity-dev@iotivity.groups.io
Cc: Nash, George <george.nash@...>
Subject: Re: [dev] Iotivity lite state

 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Re: Iotivity lite state

George Nash
 

The API that I added is only concerned with the ownership status e.g. owned vs. unowned. Any other configuration status is not part of the change.  What other configurations were you interested in?

 

It should not be too hard to cherry-pick that specific change to master.

 

Kishen if you would like me to do that I could have it done tomorrow.

 

You could also checkout the `ocfbridging` branch. If you want to use those APIs before they go through the full review process.

 

You will find three new functions and a callback function

Callback `oc_ownership_status_cb_t` (the callback gives the UUID, logical device index and a bool value indicating if the device’s status is owned or unowned)

Function `oc_add_ownership_status_callback`

Function `oc_remove_ownership_status_callback`

Function `oc_is_owned_device`

 

 

I have kept the `ofcbridging` branch up to date with master so you should be able to use the new APIs without making any additional modifications to your code.

 

George

 

 

 

From: Maloor, Kishen <kishen.maloor@...>
Sent: Wednesday, April 22, 2020 4:43 PM
To: fariouche@...; iotivity-dev@iotivity.groups.io
Cc: Nash, George <george.nash@...>
Subject: Re: [dev] Iotivity lite state

 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Re: Iotivity lite state

Kishen Maloor
 

Hello,

 

We've recently added such an API, but it exists on a branch along with some other in-progress work.

George, would it be possible to submit this specific change to master?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of "fariouche via groups.io" <fariouche@...>
Reply-To: "fariouche@..." <fariouche@...>
Date: Wednesday, April 22, 2020 at 7:27 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Iotivity lite state

 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


Iotivity lite state

Farid BENAMROUCHE
 

Hello,

I'm currently trying to develop a device using iotivity lite.
I would like to display the state of the device, when it is UNOWNED, owned, configured etc and show he progress to the user using blinking LEDs...

I didn't find any API for that, and seems like not easy to find the information in the code.
Any help or guidance to implement that if I can help is welcomed?
Maybe also some kind of notifications/callback when the state changes

Thank you
Regards


GitHub Stars & Go-OCF Cloud

Jozef Kralik
 

Hello all!

We are trying to join the open collective to receive some sponsorship for the go-ocf/cloud project. As we did some github project reorganization and moved everything under the cloud repository, we have unfortunately 5 starts.

May I please ask you to star this https://github.com/go-ocf/cloud repository, so we can join the open collective? Distribute further please.


Thanks a lot for your support.
Best,
Jozef


Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi George,
So I figure it out in what time my server is. For now, I'm not implement the oic.r.time.stamp yet but I will note it for later use.
Yes, I prefer the 'update now' option. But in the OCF specification, they said that they have the manually triggered software update with change the pstat attribute. But I don't understand how it works. For now, I will use the software update resource.
And I've succeeded to implement the oc_rep_to_json. Now I can continue the next step of my research. Thank you so much. Stay safe and stay healthy.

Regards,
Elizabeth


Re: Project status

Kishen Maloor
 

Hello,

 

> For what I guess, iotivity (now iotivity-clasic) is not maintained in favor of iotivity-

> lite (old iotivity-constrained).

 

Well, they are two independent projects, but yes, iotivity-classic has no active

contributors/maintainers. iotivity-lite is being updated and maintained.

 

> - Device builder have a template to generate code for iotivity-lite. Its currently

> working ?

 

Yes.

 

> - The build system have some patches for mbedtls.

 

Yes, they are required to support some security features of the OCF specifications.

 

> For what I see aplying them makes the mbedtls api incompatible with upstream, not ?

 

I think the impact to upstream APIs is minimal. I beleve those patches larglely add new

stuff to the library internals that did not exist on the upstream.

 

> This patches would be at anypoint integrated into mbebtls original/upstream code?

 

No, there is no such plan at the moment.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of David Suárez <david.sephirot@...>
Date: Wednesday, March 18, 2020 at 5:03 PM
To: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: [dev] Project status

 

Hi,

Whats the current iotivity projects status ? For what I guess, iotivity (now iotivity-clasic) is not maintained in favor of iotivity-lite (old iotivity-constrained).

On other way, Im interested in packaging this library(s) for Debian. Currently im packaging ocf specs and device builder. This makes me ask some questions that probably can be resolved here:

- Device builder have a template to generate code for iotivity-lite. Its currently working ?

- The build system have some patches for mbedtls. For what I see aplying them makes the mbedtls api incompatible with upstream, not ? This patches would be at anypoint integrated into mbebtls original/upstream code?

Thanks !


Project status

David Suárez
 

Hi,

Whats the current iotivity projects status ? For what I guess, iotivity (now iotivity-clasic) is not maintained in favor of iotivity-lite (old iotivity-constrained).

On other way, Im interested in packaging this library(s) for Debian. Currently im packaging ocf specs and device builder. This makes me ask some questions that probably can be resolved here:

- Device builder have a template to generate code for iotivity-lite. Its currently working ?

- The build system have some patches for mbedtls. For what I see aplying them makes the mbedtls api incompatible with upstream, not ? This patches would be at anypoint integrated into mbebtls original/upstream code?

Thanks !


Re: Iotivity Client

George Nash
 

>  For the updatetime, in what timezone the update will start? Because, when I set the updatetime 1 minute after my time it won't work. Then after few hours, when I started again the server and client, the lastupdate was changed but different from the updatetime. Is there any way to set the timezone to my location?

The client is sending the request to the server.  So the client must be able to find out the time stamp from the server. I would suggest implementing the oic.r.time.stamp resource on your server so you can get the time the server is using. Unfortunately for you oic.r.time.stamp is not a resource required by the OCF specification so you will need to implement it yourself.  It has be specified by the smarthome task group here https://oneiota.org/revisions/5505.  Once implemented you can use that resource to find out the time from the server itself.

 

Not sure why the sw update did not have an “update now” option. It seems to me that would be a really useful option. I think the thought was that a developer can provide a now option to the users without complicating the specification. I was not part of the specification for that so I don’t know for sure.

 

> Also, I want to capture my payload, but since I'm not familiar with C, is there any function to print the array without considering the type (int, strint, bool, etc)? Like in PHP, we can directly print the array value or even change to JSON without know the type. For now, I just follow the existing example. Using switch ... case ... , but in pstat property there are some value that is an object value and I can't print the value.

Look at the oc_rep_to_json function found in the rep.h header file.  This will convert an oc_rep_t to a JSON string.  It even has the pretty print option that adds tabs and newlines to make the JSON output more readable.

 

 

 

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Monday, March 9, 2020 8:48 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

Hi George and Kishen!
Thanks a lot for your reply.

George,
I think this is the problem:

  •  The `swupdateaction` must be a string oc_rep_set_text_sring(root, swupdateaction, “<action>”);  where action is one of the following strings [“idle”, “isac”, “isvv”, “upgrade”]

After I changed to strings it works! Thanks! I've succeeded to sent POST request and change that 3 swupdate value (purl, swupdateaction, and updatetime).

Kishen,
I'm glad you replied my email. I heard from Clarke that you're very busy recently. Thanks again.
I've reviewed the new OCF specification that you gave me. So to confirmation, in my understanding, is it the software update process (the change of swupdate and pstat's property value) will change automatically after the client sent the POST request? As in the diagram? And if we, developer, want to give the condition success or failure, we can change the callback function?
Okay, I will note it for the payload from OCF's CTT and compare it later.


And I have other questions guys:

  • For the updatetime, in what timezone the update will start? Because, when I set the updatetime 1 minute after my time it won't work. Then after few hours, when I started again the server and client, the lastupdate was changed but different from the updatetime. Is there any way to set the timezone to my location?
  • Also, I want to capture my payload, but since I'm not familiar with C, is there any function to print the array without considering the type (int, strint, bool, etc)? Like in PHP, we can directly print the array value or even change to JSON without know the type. For now, I just follow the existing example. Using switch ... case ... , but in pstat property there are some value that is an object value and I can't print the value.


Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi George and Kishen!
Thanks a lot for your reply.

George,
I think this is the problem:
  •  The `swupdateaction` must be a string oc_rep_set_text_sring(root, swupdateaction, “<action>”);  where action is one of the following strings [“idle”, “isac”, “isvv”, “upgrade”]
After I changed to strings it works! Thanks! I've succeeded to sent POST request and change that 3 swupdate value (purl, swupdateaction, and updatetime).

Kishen,
I'm glad you replied my email. I heard from Clarke that you're very busy recently. Thanks again.
I've reviewed the new OCF specification that you gave me. So to confirmation, in my understanding, is it the software update process (the change of swupdate and pstat's property value) will change automatically after the client sent the POST request? As in the diagram? And if we, developer, want to give the condition success or failure, we can change the callback function?
Okay, I will note it for the payload from OCF's CTT and compare it later.


And I have other questions guys:
  • For the updatetime, in what timezone the update will start? Because, when I set the updatetime 1 minute after my time it won't work. Then after few hours, when I started again the server and client, the lastupdate was changed but different from the updatetime. Is there any way to set the timezone to my location?
  • Also, I want to capture my payload, but since I'm not familiar with C, is there any function to print the array without considering the type (int, strint, bool, etc)? Like in PHP, we can directly print the array value or even change to JSON without know the type. For now, I just follow the existing example. Using switch ... case ... , but in pstat property there are some value that is an object value and I can't print the value.


Re: Iotivity Client

Kishen Maloor
 

Hello,

 

You may have reviewed Section 5.3.5 of the OCF Specification here: https://openconnectivity.org/specs/OCF_Core_Optional_Specification_v2.1.1.pdf

 

Figure 3 depicts the internal state machine that drives the SW Update process. The IoTivity-Lite stack performs those state transitions internally based on

the progress of the actual update as reported by the application. For that the stack provides callback interfaces to developers to implement all the steps

of the process and return a success/failure status for each.

 

You've probably seen this in apps/smart_home_server_with_mock_swupdate.cpp that mostly returns a success result for each step to be able to test out all the

transitions.

 

On this point in your e-mail:

> Yes, I've followed the step on README, and also I tried to change the option to

> number [1]: All NCRs '*'. But still Unauthorized. Then, today I try to fill the

> href resource with /sw (softwareupdate URI). Turns out it worked!

 

Yes, the SW Update resource (as also /oic/sec/pstat) is from a protected group of resources to which wildcards don't apply in ACEs. In other words, the device

owner needs to explicitly call out such resources in the ACE to provide access to Clients. It seems that you had worked this out.

 

Lastly, there isn't a Client sample that triggers the SW Update process, and I understand that that's what you're trying to build. Making it work requires you to

provide properly formatted requests.

 

Below is the entire SW Update sequence triggered (and captured) by OCF's Certification Test Tool (as Client) on apps/smart_home_server_with_mock_swupdate.cpp. It shows you the

exact payloads sent/received and I thought it might be instructive for you as you build your Client. You will notice that it largely follows all the transitions in

figure 3.

 

Hope this helps.

 

Thanks,

-Kishen.

 

*Idle* (initial state)

 

Observe response from /oic/sec/pstat:

{"rt":["oic.r.pstat"],"if":["oic.if.baseline"],"dos":{"p":false,"s":3},"cm":0,"tm":0,"om":4,"sm":4,"isop":true,"rowneruuid":"11111111-2222-3333-4444-555555555555"}

 

Observe response from /sw:

{"lastupdate":"1970-01-01T00:00:00Z","nv":"","purl":"","signed":"vendor","swupdateaction":"idle","swupdateresult":0,"swupdatestate":"idle","updatetime":"1970-01-01T00:00:00Z"}

...

 

(Client kicks off SW Update process)

 

POST /sw request payload:

{"swupdateaction": "isac", "purl": "coaps://[fd00::1001]:49442", "updatetime": "2020-01-22T11:27:20Z"}

 

..

 

*new_version_check*

 

Observe response from /oic/sec/pstat:

{"rt":["oic.r.pstat"],"if":["oic.if.baseline"],"dos":{"p":false,"s":3},"cm":256,"tm":0,"om":4,"sm":4,"isop":true,"rowneruuid":"11111111-2222-3333-4444-555555555555"}

 

Observe response from /sw:

{"lastupdate":"1970-01-01T00:00:00Z","nv":"","purl":"coaps://[fd00::1001]:49442","signed":"vendor","swupdateaction":"isac","swupdateresult":1,"swupdatestate":"nsa","updatetime":"2020-01-22T11:27:20Z"}

 

...

 

*version_validation*

 

Observe response from /sw:

{"lastupdate":"1970-01-01T00:00:00Z","nv":"","purl":"coaps://[fd00::1001]:49442","signed":"vendor","swupdateaction":"isvv","swupdateresult":1,"swupdatestate":"svv","updatetime":"2020-01-22T11:27:20Z"}

 

...

 

*version_available*

 

Observe response from /oic/sec/pstat:

{"rt":["oic.r.pstat"],"if":["oic.if.baseline"],"dos":{"p":false,"s":3},"cm":320,"tm":0,"om":4,"sm":4,"isop":true,"rowneruuid":"11111111-2222-3333-4444-555555555555"}

 

Observe response from /sw:

{"lastupdate":"1970-01-01T00:00:00Z","nv":"","purl":"coaps://[fd00::1001]:49442","signed":"vendor","swupdateaction":"isvv","swupdateresult":1,"swupdatestate":"sva","updatetime":"2020-01-22T11:27:20Z"}

 

...

 

*upgrading*

 

Observe response from /oic/sec/pstat:

{"rt":["oic.r.pstat"],"if":["oic.if.baseline"],"dos":{"p":false,"s":3},"cm":448,"tm":0,"om":4,"sm":4,"isop":true,"rowneruuid":"11111111-2222-3333-4444-555555555555"}

 

Observe response from /sw:

{"lastupdate":"2020-01-22T11:27:20.002464Z","nv":"","purl":"coaps://[fd00::1001]:49442","signed":"vendor","swupdateaction":"upgrade","swupdateresult":1,"swupdatestate":"upgrading","updatetime":"2020-01-22T11:27:20Z"}

 

...

 

*idle*

 

Observe response from /oic/sec/pstat:

{"rt":["oic.r.pstat"],"if":["oic.if.baseline"],"dos":{"p":false,"s":3},"cm":0,"tm":0,"om":4,"sm":4,"isop":true,"rowneruuid":"11111111-2222-3333-4444-555555555555"}

 

Observe response from /sw:

{"lastupdate":"2020-01-22T11:27:20.002464Z","nv":"","purl":"coaps://[fd00::1001]:49442","signed":"vendor","swupdateaction":"idle","swupdateresult":1,"swupdatestate":"idle","updatetime":"2020-01-22T11:27:20Z"}

 

...

 

 

 

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of George Nash <george.nash@...>
Date: Thursday, March 5, 2020 at 11:08 AM
To: "elizabethnathaniaw93@..." <elizabethnathaniaw93@...>, "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: Re: [dev] Iotivity Client

 

The `swupdateaction` must be a string oc_rep_set_text_sring(root, swupdateaction, “<action>”);  where action is one of the following strings [“idle”, “isac”, “isvv”, “upgrade”];

 

 

It is converted internally to an enum what you must send is a string.

 

The OC_STATUS_NOT_ACCEPTABLE comes from the software updates post handler code.

                Possible sources:

  • you tried to write a read only property. (I don’t see that in your code.)
  • the “purl” is longer than 63 characters. (it only supports short urls smaller than 63 characters.)
  • the “purl” is not a string
  • the “swupdate” is not a string (and smaller than 63 characters)
  • the “updatetime” is not a string
  • the “updatetime” string is larger than 63 charaters
  • the “updatetime” does not conform to the RFC3339 (i.e. the string could not be parsed to a clock time)
  • the “updatetime” is a time in the past.  We only update at a future time past times are ignored.
  • If “purl” is marked as an invalid url by the validate_purl callback
  • (probably some others I have missed.)

 

The response code OC_STATUS_SERVICE_UNAVAILABLE is the equivalent of a “503 Service Unavailable Error that indicates the server is  temporarily unable to handle the request” I have no clue why you would be getting that response code.

 

George Nash

 

 

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Thursday, March 5, 2020 8:16 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

George,
Ups, sorry my bad. Missing separator. I mean R,U,N (Read, Update, Notify).
Yes, I've followed the step on README, and also I tried to change the option to number [1]: All NCRs '*'. But still Unauthorized. Then, today I try to fill the href resource with /sw (softwareupdate URI). Turns out it worked! I can get the oic.r.softwareupdate property values. I put the screenshot of my server's ACE. In the last 2 ACE, I put the href.

Another problem is, after I successfully observe and get the values when I try to oc_do_post, the oc_status code was 11 (OC_STATUS_NOT_ACCEPTABLE) or 17 (OC_STATUS_NOT_AVAILABLE). This is my code for oc_do_post:
1  if (oc_init_post(swupdate_uri, swupdate_server, NULL, &post_swupdate, HIGH_QOS, NULL)) {
2     oc_rep_start_root_object();
3     oc_rep_set_text_string(root, purl, "http://127.0.0.1");
4      //oc_rep_set_int(root, swupdateaction, 0);
5      //oc_rep_set_text_string(root, updatetime, "2020-03-05T20:00:00Z");
6      oc_rep_end_root_object();
7      if (oc_do_post())
8        PRINT("Sent POST request\n");
9      else

10        PRINT("Could not send POST request\n");

11  }


When I comment line 4 and 5, the oc_status code was 11. Then, when I uncomment line 4 and 5, the oc_status code was 17. Any idea why this happens?


Re: Iotivity Client

George Nash
 

The `swupdateaction` must be a string oc_rep_set_text_sring(root, swupdateaction, “<action>”);  where action is one of the following strings [“idle”, “isac”, “isvv”, “upgrade”];

 

 

It is converted internally to an enum what you must send is a string.

 

The OC_STATUS_NOT_ACCEPTABLE comes from the software updates post handler code.

                Possible sources:

  • you tried to write a read only property. (I don’t see that in your code.)
  • the “purl” is longer than 63 characters. (it only supports short urls smaller than 63 characters.)
  • the “purl” is not a string
  • the “swupdate” is not a string (and smaller than 63 characters)
  • the “updatetime” is not a string
  • the “updatetime” string is larger than 63 charaters
  • the “updatetime” does not conform to the RFC3339 (i.e. the string could not be parsed to a clock time)
  • the “updatetime” is a time in the past.  We only update at a future time past times are ignored.
  • If “purl” is marked as an invalid url by the validate_purl callback
  • (probably some others I have missed.)

 

The response code OC_STATUS_SERVICE_UNAVAILABLE is the equivalent of a “503 Service Unavailable Error that indicates the server is  temporarily unable to handle the request” I have no clue why you would be getting that response code.

 

George Nash

 

 

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Thursday, March 5, 2020 8:16 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

George,
Ups, sorry my bad. Missing separator. I mean R,U,N (Read, Update, Notify).
Yes, I've followed the step on README, and also I tried to change the option to number [1]: All NCRs '*'. But still Unauthorized. Then, today I try to fill the href resource with /sw (softwareupdate URI). Turns out it worked! I can get the oic.r.softwareupdate property values. I put the screenshot of my server's ACE. In the last 2 ACE, I put the href.

Another problem is, after I successfully observe and get the values when I try to oc_do_post, the oc_status code was 11 (OC_STATUS_NOT_ACCEPTABLE) or 17 (OC_STATUS_NOT_AVAILABLE). This is my code for oc_do_post:
1  if (oc_init_post(swupdate_uri, swupdate_server, NULL, &post_swupdate, HIGH_QOS, NULL)) {
2     oc_rep_start_root_object();
3     oc_rep_set_text_string(root, purl, "http://127.0.0.1");
4      //oc_rep_set_int(root, swupdateaction, 0);
5      //oc_rep_set_text_string(root, updatetime, "2020-03-05T20:00:00Z");
6      oc_rep_end_root_object();
7      if (oc_do_post())
8        PRINT("Sent POST request\n");
9      else

10        PRINT("Could not send POST request\n");

11  }


When I comment line 4 and 5, the oc_status code was 11. Then, when I uncomment line 4 and 5, the oc_status code was 17. Any idea why this happens?


Re: Iotivity Client

elizabethnathaniaw93@...
 

George,
Ups, sorry my bad. Missing separator. I mean R,U,N (Read, Update, Notify).
Yes, I've followed the step on README, and also I tried to change the option to number [1]: All NCRs '*'. But still Unauthorized. Then, today I try to fill the href resource with /sw (softwareupdate URI). Turns out it worked! I can get the oic.r.softwareupdate property values. I put the screenshot of my server's ACE. In the last 2 ACE, I put the href.

Another problem is, after I successfully observe and get the values when I try to oc_do_post, the oc_status code was 11 (OC_STATUS_NOT_ACCEPTABLE) or 17 (OC_STATUS_NOT_AVAILABLE). This is my code for oc_do_post:
1  if (oc_init_post(swupdate_uri, swupdate_server, NULL, &post_swupdate, HIGH_QOS, NULL)) {
2     oc_rep_start_root_object();
3     oc_rep_set_text_string(root, purl, "http://127.0.0.1");
4      //oc_rep_set_int(root, swupdateaction, 0);
5      //oc_rep_set_text_string(root, updatetime, "2020-03-05T20:00:00Z");
6      oc_rep_end_root_object();
7      if (oc_do_post())
8        PRINT("Sent POST request\n");
9      else
10        PRINT("Could not send POST request\n");
11  }

When I comment line 4 and 5, the oc_status code was 11. Then, when I uncomment line 4 and 5, the oc_status code was 17. Any idea why this happens?


Re: Iotivity Client

George Nash
 

There is no RUN permission so I am a little confused.

 

The permissions are CREATE, READ, UPDATE, DELETE, NOTIFY  (CRUDN)

 

READ will let clients read the resource properties.  (e.g. oc_do_get)

UPDATE will let clients update (write) the resource properties (e.g. oc_do_push)

NOTIFY will let clients receive a notifications.

 

CREATE enable a client to create a new resource on the server

DELETE enable a client to delete an existing resource from the server

 

You are unlikely to need CREATE and DELETE.

 

 

Your error OC_STATUS_UNAUTHORIZED is almost always a permissions error so it seems likely that the ACE2 is not setup correctly or you may have forgotten to pair the server and client.

 

If you use the instructions found in the top level README instead of selecting

[2]: All NCRs with >=1 secured endpoint '+'

Try selecting

[1]: All NCRs '*'

 

Set the READ, UPDATE, and NOTIFY permission.  Using wildcard `*` with this permission opens the server up even to un-trusted clients but its unlikely to be a problem while you are just getting started. Once you have the client/server actually working mess around the ACE2 permissions to make it more secure.

 

George

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Wednesday, March 4, 2020 8:33 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

George,
Yes, Thank you! That really helps me to have a better understanding of the code flow.
So, today I tried to observe oic.r.softwareupdate resource, get the endpoint and port, then oc_do_post the first step (isac) to check it will work or not. But it didn't work. And after I print the result of the oc_status code is 6 which means OC_STATUS_UNAUTHORIZED. Is it because of the permission of softwareupdate resources? Since it is the internal iotivity-lite framework?
I've tried to use onboarding tool, choose option provision ACE2, set the resource href to /sw, give RUN permission. But it didn't work, I think I've done it wrong.
Maybe you can help me how to give authorization to the client to interact with pstat and softwareupdate resource or how to set the permission of the internal Iotivity-lite framework (such as pstat and softwareupdate resource)?.


Re: Iotivity Client

elizabethnathaniaw93@...
 

George,
Yes, Thank you! That really helps me to have a better understanding of the code flow.
So, today I tried to observe oic.r.softwareupdate resource, get the endpoint and port, then oc_do_post the first step (isac) to check it will work or not. But it didn't work. And after I print the result of the oc_status code is 6 which means OC_STATUS_UNAUTHORIZED. Is it because of the permission of softwareupdate resources? Since it is the internal iotivity-lite framework?
I've tried to use onboarding tool, choose option provision ACE2, set the resource href to /sw, give RUN permission. But it didn't work, I think I've done it wrong.
Maybe you can help me how to give authorization to the client to interact with pstat and softwareupdate resource or how to set the permission of the internal Iotivity-lite framework (such as pstat and softwareupdate resource)?.


Re: Iotivity Client

George Nash
 

I think I understand why you are trying to observer the `pstat` resource.  You are trying to track the ‘cm’ property.  I don’t think you need to track that the IoTivity-lite famework should be tracking all of that for you.

 

To add software update to your code you should only require the functions found in the oc_swupdate.h header file.

 

You can reference the smart_home_server_with_mock_swupdate.cpp.  I went to your past email and it seems you don’t know how to do the following

 

  • You don't know how to trigger the software update resource?
  • Also how to set the URL for download the firmware update?

 

I will do my best to answer those two questions. Note, I personally have not done this I am giving my best answer to those questions if I get the answer wrong I hope Cunningham’s Law will kick in and someone will correct me.

 

As best I can tell you trigger the software update resource from a client. Looking at the specification for oic.r.softwareupdate there are 3 properties that you can write to from the client. They are `purl` (package url, the source of the software package, might be an HTTPS or a CoAPs URL), `swupdateaction` (Scheduled action to do a software update) , and `updatetime` (Scheduled time).

 

 

So you would discover the oic.r.softwareupdate resource to find the endpoints for the server.

Then you would call oc_do_post to call filling out the 3 properties listed above.

 

Call POST on the oic.r.softwareupdate (check if a newer software version is avalible)

  • “purl”: https://myvender/newversion, “swupdateaction”: “isac”, “updatetime”: "2020-03-03T14:30:00Z"  (“isac” means initiate software availability check)

 

This will trigger the swupdate_impl.check_new_version callback on the server

 

I am not sure how the client finds out the result of this call.

 

Call POST on the oic.r.softwareupdate (download and verify the software version is valid)

  • “purl”: https://myvender/newversion, “swupdateaction”: “isvv”, “updatetime”: "2020-03-03T14:31:00Z" (“isvv” means initiate software version validation)

 

This will trigger the download_update callback on the server.

 

Once again I am not sure how the client finds out the result of this call.

 

Call POST on the oic.r.softwareupdate (initiate the software update)

 

This will trigger the actual update

 

Other than the upgrade action I am not sure if the “updatetime” is used for any of the other actions.

 

I hope this helps you get started.

 

George

 

 

 

 

 

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Tuesday, March 3, 2020 9:53 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

Hi George!
Okay, I will explain first why I need to know the pstat resource. So, as I said before, I want to create a client that can communicate with the smart_home_server_with_mock_swupdate file in iotivity-lite GitHub. Because I want to implement the OCF firmware update protocol. My reference is in the OCF Security and OCF Core documentation version 2.0.3. In OCF Core docs, they provide a firmware update protocol (I put the picture below). After I read the swupdate.c, oc_swupdate_internal.h in API folder, I try to see the connection between the code and the protocol.
So far, what I understand is: (please if you know or anyone knows more about this correct me. I've created a post about iotivity update in this mailing list, but no one reply yet.)
 - the code has implemented the protocol from 'new firmware available' until the 'upgrade image' part. It means I need to make a client to 'observe device' and 'software upgrade initialization' part.
- In 'observe device', the client needs to observe the softwareupgrade and pstat resource.
That's why I need to observe the pstat.cm state.



Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi George!
Okay, I will explain first why I need to know the pstat resource. So, as I said before, I want to create a client that can communicate with the smart_home_server_with_mock_swupdate file in iotivity-lite GitHub. Because I want to implement the OCF firmware update protocol. My reference is in the OCF Security and OCF Core documentation version 2.0.3. In OCF Core docs, they provide a firmware update protocol (I put the picture below). After I read the swupdate.c, oc_swupdate_internal.h in API folder, I try to see the connection between the code and the protocol.
So far, what I understand is: (please if you know or anyone knows more about this correct me. I've created a post about iotivity update in this mailing list, but no one reply yet.)
 - the code has implemented the protocol from 'new firmware available' until the 'upgrade image' part. It means I need to make a client to 'observe device' and 'software upgrade initialization' part.
- In 'observe device', the client needs to observe the softwareupgrade and pstat resource.
That's why I need to observe the pstat.cm state.



Re: Iotivity Client

George Nash
 

Without a little code I am a little lost why your payload would be null.

 

> Is it okay to have 2 get handler for 1 resource? 1 for get_light and 1 for get_pstat?

 

As far as I know you can put as many get handlers as you would like.  It is quite reasonable to have 1 for light and 1 for pstat.

 

I am a little curious what you are trying to achieve.  The oc_pstat.h header is considered an internal API and should not need to use IoTivity-lite. However, most developers will not even need to know about the pstat resource in their daily use of IoTivity-lite so you may have a reason you are tying to use the internal API that was not considered by us.

 

If you can expand on your question I will see if I can help.

 

George

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Friday, February 28, 2020 9:37 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

George,
Thanks!
What I did was, I use simpleclient and simpleserver example.
I edited the simpleclient --> in do_ip_discovery, I discover the oic.r.pstat. Then, in discover callback function I could get the coaps endpoint and port for /oic/sec/psat/ resource. Inside discover callback function, I put oc_do_observe(...) and call the handler. Here I create new function called observe_pstat that oc_do_observe will call. But, in my function observe_pstat, when I want to get the data payload, it was null. I don't know why? Should I put the get handler in simpleserver for get_pstat? Is it okay to have 2 get handler for 1 resource? 1 for get_light and 1 for get_pstat?

In the other hand, I've read the oc_pstat.h, It has get function to get the pstat attribute (cm, tm, etc). But, I have no idea how to use it.


Re: Iotivity Client

elizabethnathaniaw93@...
 

George,
Thanks!
What I did was, I use simpleclient and simpleserver example.
I edited the simpleclient --> in do_ip_discovery, I discover the oic.r.pstat. Then, in discover callback function I could get the coaps endpoint and port for /oic/sec/psat/ resource. Inside discover callback function, I put oc_do_observe(...) and call the handler. Here I create new function called observe_pstat that oc_do_observe will call. But, in my function observe_pstat, when I want to get the data payload, it was null. I don't know why? Should I put the get handler in simpleserver for get_pstat? Is it okay to have 2 get handler for 1 resource? 1 for get_light and 1 for get_pstat?

In the other hand, I've read the oc_pstat.h, It has get function to get the pstat attribute (cm, tm, etc). But, I have no idea how to use it.


Re: Iotivity Client

George Nash
 

You should be able to observer the pstat resource from the client.

 

Discover the oic.r.pstat resource. From the discovery callback call oc_do_observe(…) using the server information that you got from the discovery callback.

 

Check the permissions for the oic.r.pstat resource to see if it has notify permissions. I am not sure what the default permissions for that resource is. If it does not have the correct permissions you should be able to update the permissions using the onboarding_tool.

 

It really should be as simple as that.

 

George

 

 

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Thursday, February 27, 2020 9:45 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

Hi Clarke and George,
I see. Thank you!
I've tried the onboarding_tool from iotivity-lite github and follow the step in README.md. It works. The simpleserver and simpleclient can communicate.

Do you have any idea if I want to observe the pstat resource from client? Do I need to change the endpoint at discovery function, I mean the rt, to oic.r.pstat?