New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Pkg] IoTivity Pkg for RIOT OS #6096

Merged
merged 1 commit into from Dec 5, 2016

Conversation

Projects
None yet
6 participants
@mattiantonini
Contributor

mattiantonini commented Nov 9, 2016

This PR adds the IoTivity-Constrained library on top of RIOT-OS. This version of IoTivity is designed for constrained nodes and it contains also the glue code for RIOT. The pkg can be included like other pkgs (e.g. microcoap, etc).

It is available here.

In particular under:

  • /pkg/iotivity : there are makefiles of the pkg
  • /examples/iotivity-examples : there are some working examples (with a brief tutorial)

Any feedback will be appreciated.

P.S. I have problem with labels... I can't add them. Anyway, they are PKG, new feature

Show outdated Hide outdated examples/iotivity_examples/br_fw/config.h
// Copyright (c) 2016 Intel Corporation
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 9, 2016

Member

to remain clean, Apache licensed files should not be PRed directly to be located in the RIOT/example/
Instead, can't you pull them (+ whatever you need) along with your pkg?

@emmanuelsearch

emmanuelsearch Nov 9, 2016

Member

to remain clean, Apache licensed files should not be PRed directly to be located in the RIOT/example/
Instead, can't you pull them (+ whatever you need) along with your pkg?

@OlegHahm

This comment has been minimized.

Show comment
Hide comment
@OlegHahm

OlegHahm Nov 9, 2016

Member

For clarification: Using Apache License (or whatever license you want) for an application on top of RIOT is okay (IANAL). However, any code that can be downloaded from this repository should have LGPL or a compatible permissive license (e.g., BSD or MIT) to avoid confusion about RIOT's license.

Member

OlegHahm commented Nov 9, 2016

For clarification: Using Apache License (or whatever license you want) for an application on top of RIOT is okay (IANAL). However, any code that can be downloaded from this repository should have LGPL or a compatible permissive license (e.g., BSD or MIT) to avoid confusion about RIOT's license.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 10, 2016

Contributor

@emmanuelsearch I have just updated the example. That file is not necessary.
@OlegHahm Thanks for the clarification!

Contributor

mattiantonini commented Nov 10, 2016

@emmanuelsearch I have just updated the example. That file is not necessary.
@OlegHahm Thanks for the clarification!

@OlegHahm OlegHahm added this to the Release 2017.01 milestone Nov 10, 2016

@rzr

This comment has been minimized.

Show comment
Hide comment
@rzr

rzr Nov 11, 2016

Contributor

As an iotivity developer, I'd like to test it along w5100 driver can you share some hints ?

Contributor

rzr commented Nov 11, 2016

As an iotivity developer, I'd like to test it along w5100 driver can you share some hints ?

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 11, 2016

Contributor

@rzr Which is your target? Arduino-DUE?

Contributor

mattiantonini commented Nov 11, 2016

@rzr Which is your target? Arduino-DUE?

@rzr

This comment has been minimized.

Show comment
Hide comment
@rzr

rzr Nov 11, 2016

Contributor

I have MEGA2650 and w5100 and I am already deployed IoTivity CSDK on it but not yet w/ constrained version.

This patch may be also required:
#6075

Regards. I am also on IRC as RzR

Contributor

rzr commented Nov 11, 2016

I have MEGA2650 and w5100 and I am already deployed IoTivity CSDK on it but not yet w/ constrained version.

This patch may be also required:
#6075

Regards. I am also on IRC as RzR

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 14, 2016

Contributor

@rzr I cannot test it on a MEGA2650 because I haven't it. Anyway, you can add the w5100 driver in the makefile by adding the line

USEMODULE += w5100

and removing the following lines

USEMODULE += gnrc_rpl
USEMODULE += auto_init_gnrc_rpl

Let me know if it works.

Regards,
Mattia

P.S. the PKG were tested on Samr21-xPRO and native targets.

Contributor

mattiantonini commented Nov 14, 2016

@rzr I cannot test it on a MEGA2650 because I haven't it. Anyway, you can add the w5100 driver in the makefile by adding the line

USEMODULE += w5100

and removing the following lines

USEMODULE += gnrc_rpl
USEMODULE += auto_init_gnrc_rpl

Let me know if it works.

Regards,
Mattia

P.S. the PKG were tested on Samr21-xPRO and native targets.

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 21, 2016

Member

Successfully tested the node-to-node (periodic PUT) example on native.
We nevertheless have some warnings (see below) at compile time, which should be fixed according to RIOT usual (stringent) policy.

port/riot/abort.c: In function 'abort_impl':
port/riot/abort.c:5:1: warning: old-style function definition [-Wold-style-definition]
 abort_impl()
 ^
messaging/coap/transactions.c: In function 'coap_register_as_transaction_handler':
messaging/coap/transactions.c:59:1: warning: old-style function definition [-Wold-style-definition]
 coap_register_as_transaction_handler()
 ^
messaging/coap/transactions.c: In function 'coap_check_transactions':
messaging/coap/transactions.c:189:1: warning: old-style function definition [-Wold-style-definition]
 coap_check_transactions()
 ^
 messaging/coap/coap.c: In function 'coap_init_connection':
messaging/coap/coap.c:263:1: warning: old-style function definition [-Wold-style-definition]
 coap_init_connection()
 ^
messaging/coap/coap.c: In function 'coap_get_mid':
messaging/coap/coap.c:270:1: warning: old-style function definition [-Wold-style-definition]
 coap_get_mid()
 ^
Member

emmanuelsearch commented Nov 21, 2016

Successfully tested the node-to-node (periodic PUT) example on native.
We nevertheless have some warnings (see below) at compile time, which should be fixed according to RIOT usual (stringent) policy.

port/riot/abort.c: In function 'abort_impl':
port/riot/abort.c:5:1: warning: old-style function definition [-Wold-style-definition]
 abort_impl()
 ^
messaging/coap/transactions.c: In function 'coap_register_as_transaction_handler':
messaging/coap/transactions.c:59:1: warning: old-style function definition [-Wold-style-definition]
 coap_register_as_transaction_handler()
 ^
messaging/coap/transactions.c: In function 'coap_check_transactions':
messaging/coap/transactions.c:189:1: warning: old-style function definition [-Wold-style-definition]
 coap_check_transactions()
 ^
 messaging/coap/coap.c: In function 'coap_init_connection':
messaging/coap/coap.c:263:1: warning: old-style function definition [-Wold-style-definition]
 coap_init_connection()
 ^
messaging/coap/coap.c: In function 'coap_get_mid':
messaging/coap/coap.c:270:1: warning: old-style function definition [-Wold-style-definition]
 coap_get_mid()
 ^
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 21, 2016

Member

Tested the node-to-node scenario on 2 SAMR21 boards (one client, and one server).
It compiles (see warnings mentioned above, though) and runs, but as far as I understand the output, it seems that it does not get passed the discovery phase.
I get the below output on the server, repeatedly:

2016-11-21 17:09:05,954 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:09:06,943 - INFO # ipadapter: got multicast request
2016-11-21 17:09:06,949 - INFO # Incoming message from [fe80:0000:0000:0000:5846:166f:4aaa:bb8e]:56789
2016-11-21 17:09:06,953 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:09:06,956 - INFO # client_oic: continue discovery
2016-11-21 17:09:07,951 - INFO # ipadapter: got multicast request
2016-11-21 17:09:07,963 - INFO # Incoming message from [fe80:0000:0000:0000:5846:166f:4aaa:bb8e]:56789
2016-11-21 17:09:07,965 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:09:07,967 - INFO # client_oic: continue discovery
2016-11-21 17:09:07,971 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683

and on the client I get repeatedly:

2016-11-21 17:08:57,860 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:08:58,862 - INFO # client_oic: continue discovery
2016-11-21 17:08:58,868 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:08:58,906 - INFO # ipadapter: got multicast request
2016-11-21 17:08:58,912 - INFO # Incoming message from [fe80:0000:0000:0000:5855:5c7c:8647:1e2e]:56789
2016-11-21 17:08:58,917 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:08:59,870 - INFO # client_oic: continue discovery
Member

emmanuelsearch commented Nov 21, 2016

Tested the node-to-node scenario on 2 SAMR21 boards (one client, and one server).
It compiles (see warnings mentioned above, though) and runs, but as far as I understand the output, it seems that it does not get passed the discovery phase.
I get the below output on the server, repeatedly:

2016-11-21 17:09:05,954 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:09:06,943 - INFO # ipadapter: got multicast request
2016-11-21 17:09:06,949 - INFO # Incoming message from [fe80:0000:0000:0000:5846:166f:4aaa:bb8e]:56789
2016-11-21 17:09:06,953 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:09:06,956 - INFO # client_oic: continue discovery
2016-11-21 17:09:07,951 - INFO # ipadapter: got multicast request
2016-11-21 17:09:07,963 - INFO # Incoming message from [fe80:0000:0000:0000:5846:166f:4aaa:bb8e]:56789
2016-11-21 17:09:07,965 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:09:07,967 - INFO # client_oic: continue discovery
2016-11-21 17:09:07,971 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683

and on the client I get repeatedly:

2016-11-21 17:08:57,860 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:08:58,862 - INFO # client_oic: continue discovery
2016-11-21 17:08:58,868 - INFO # Outgoing message to [ff03:0000:0000:0000:0000:0000:0000:0158]:5683
2016-11-21 17:08:58,906 - INFO # ipadapter: got multicast request
2016-11-21 17:08:58,912 - INFO # Incoming message from [fe80:0000:0000:0000:5855:5c7c:8647:1e2e]:56789
2016-11-21 17:08:58,917 - INFO # ipadapter: waiting for multicast requests...
2016-11-21 17:08:59,870 - INFO # client_oic: continue discovery
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 21, 2016

Member

In the documentation for the node-to-node scenario, there is no instruction how to specify one wants to operate in "periodic PUT" mode vs operation "Switch" mode. What must be set/unset or which option must be specified? I must confess I did not look in the code yet.

Member

emmanuelsearch commented Nov 21, 2016

In the documentation for the node-to-node scenario, there is no instruction how to specify one wants to operate in "periodic PUT" mode vs operation "Switch" mode. What must be set/unset or which option must be specified? I must confess I did not look in the code yet.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 21, 2016

Contributor

@emmanuelsearch Regarding the Node-to-Node scenario there was a typo. The Switch mode is implemented in the Client_Switch example and the Periodic PUT in the Client example.
Regarding the discovery problem, you have loaded the client example on both nodes. You can see it from the terminal (oic_client).
Finally, thanks for the notice about warnings.

Contributor

mattiantonini commented Nov 21, 2016

@emmanuelsearch Regarding the Node-to-Node scenario there was a typo. The Switch mode is implemented in the Client_Switch example and the Periodic PUT in the Client example.
Regarding the discovery problem, you have loaded the client example on both nodes. You can see it from the terminal (oic_client).
Finally, thanks for the notice about warnings.

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 21, 2016

Member

OK, will test again. It is strange that client code was loaded on both boards since I compiled and flashed separately from /server and from /client respectively, as far as I can tell.

Member

emmanuelsearch commented Nov 21, 2016

OK, will test again. It is strange that client code was loaded on both boards since I compiled and flashed separately from /server and from /client respectively, as far as I can tell.

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Successfully tested node-to-node examples on SAMR21 boards both periodic and switch versions.
Will test the rest later.

Member

emmanuelsearch commented Nov 22, 2016

Successfully tested node-to-node examples on SAMR21 boards both periodic and switch versions.
Will test the rest later.

Show outdated Hide outdated examples/iotivity_examples/README.md
Client performs the discovery phase. Once it is completed, client registers as an Observer of the resource, then it switches on its LED.
Client is now ready to send a PUT request when the User Button is pressed. The server LED will change the status when the button is pressed. Terminal outputs are similar to outputs in previous examples.
##<a name="l2n_comm"></a>Linux-to-Nodes communications
In this scenario, we will deploy an IoTivity server on a RIOT node and the IoTivity client will run on a Linux machine. This architecture requires the "enhanced" version of the Border Router [BR_FW](br_fw_ex). It requires two SAMR21-XPRO nodes or similar.

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here I think you mean in fact br_fw instead of br_fw_ex, right?

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here I think you mean in fact br_fw instead of br_fw_ex, right?

This comment has been minimized.

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Exactly! Anyway, Fixed!

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Exactly! Anyway, Fixed!

Show outdated Hide outdated examples/iotivity_examples/README.md
```
The server starts and it is waiting for incoming requests.
Now, we open a new terminal window, go to `/examples/iotivity-examples/client_switch` and type
```

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here, my .md editor/visualiser (MacDown) needs a new line, else it does not interpret it right (might be MacDown).

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here, my .md editor/visualiser (MacDown) needs a new line, else it does not interpret it right (might be MacDown).

This comment has been minimized.

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Fixed. Check it!

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Fixed. Check it!

The server starts and it is waiting for incoming requests.
Now, open a new terminal window, go to `/examples/iotivity-examples/client` and type
```
$ make flash BOARD=samr21-xpro SERIAL=client_node_serial

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

I noticed that if the client was compiled beforehand this only works with first
make clean all BOARD=samr21-xpro
and then
make flash BOARD=samr21-xpro SERIAL=...
else you end up with client code instead of server code.
(I have not checked yet in details why, or if this is the only scenario where things get mixed up).
Does it ring a bell?

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

I noticed that if the client was compiled beforehand this only works with first
make clean all BOARD=samr21-xpro
and then
make flash BOARD=samr21-xpro SERIAL=...
else you end up with client code instead of server code.
(I have not checked yet in details why, or if this is the only scenario where things get mixed up).
Does it ring a bell?

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

more warnings for the br_fw:

/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'handle_incoming_message':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:75:30: warning: passing argument 2 of 'ipv6_addr_to_str' from incompatible pointer type
   ipv6_addr_to_str(addr_str, addr, addr_len);
                              ^
In file included from /home/vagrant/RIOT/sys/include/net/gnrc/conn.h:27:0,
                 from /home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:29:
/home/vagrant/RIOT/sys/include/net/ipv6/addr.h:713:7: note: expected 'const union ipv6_addr_t *' but argument is of type 'uint8_t *'
 char *ipv6_addr_to_str(char *result, const ipv6_addr_t *addr, uint8_t result_len);
       ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'main':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:153:18: warning: unused variable 'mcast_thread' [-Wunused-variable]
     kernel_pid_t mcast_thread = thread_create(oic_forwarding_thread_stack, sizeof(oic_forwarding_thread_stack),
                  ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: At top level:
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:59:21: warning: 'mcast_thread' defined but not used [-Wunused-variable]
 static kernel_pid_t mcast_thread;
                     ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'handle_incoming_message':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:75:3: warning: 'addr_str' is used uninitialized in this function [-Wuninitialized]
   ipv6_addr_to_str(addr_str, addr, addr_len);
   ^
Member

emmanuelsearch commented Nov 22, 2016

more warnings for the br_fw:

/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'handle_incoming_message':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:75:30: warning: passing argument 2 of 'ipv6_addr_to_str' from incompatible pointer type
   ipv6_addr_to_str(addr_str, addr, addr_len);
                              ^
In file included from /home/vagrant/RIOT/sys/include/net/gnrc/conn.h:27:0,
                 from /home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:29:
/home/vagrant/RIOT/sys/include/net/ipv6/addr.h:713:7: note: expected 'const union ipv6_addr_t *' but argument is of type 'uint8_t *'
 char *ipv6_addr_to_str(char *result, const ipv6_addr_t *addr, uint8_t result_len);
       ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'main':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:153:18: warning: unused variable 'mcast_thread' [-Wunused-variable]
     kernel_pid_t mcast_thread = thread_create(oic_forwarding_thread_stack, sizeof(oic_forwarding_thread_stack),
                  ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: At top level:
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:59:21: warning: 'mcast_thread' defined but not used [-Wunused-variable]
 static kernel_pid_t mcast_thread;
                     ^
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c: In function 'handle_incoming_message':
/home/vagrant/RIOT/examples/iotivity_examples/br_fw/main.c:75:3: warning: 'addr_str' is used uninitialized in this function [-Wuninitialized]
   ipv6_addr_to_str(addr_str, addr, addr_len);
   ^
Show outdated Hide outdated examples/iotivity_examples/README.md
```
The server starts the initialization phase, then it is ready for incoming requests. We can check the reachability of the server by typing in another terminal window
```
$ ping6 <IPv6 server>

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here, if you mean the local (fe80::) IPv6 address of the server, pinged from shell on the border router, I suggest you indicate this explicitly (I could test: this works).
Else, which address are you talking about? And do you obtain it (shell commands are not working on the server)?
I suspect you are rather talking about non-local unicast IPv6 address to ping (and later coap) from multi-hops away (from Linux), right?

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

Here, if you mean the local (fe80::) IPv6 address of the server, pinged from shell on the border router, I suggest you indicate this explicitly (I could test: this works).
Else, which address are you talking about? And do you obtain it (shell commands are not working on the server)?
I suspect you are rather talking about non-local unicast IPv6 address to ping (and later coap) from multi-hops away (from Linux), right?

This comment has been minimized.

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

The server address can be found by typing routers in the br console

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

The server address can be found by typing routers in the br console

Show outdated Hide outdated examples/iotivity_examples/README.md
###<a name="l2n_tst"></a>Testing
There are many different ways to test this scenario.
- Tools: you can use [Copper(Cu)][7] or [coap-cli][8] to perform get request. The second one supports CBOR.

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

is CBOR needed to make this example work? If yes and if Cu does not support CBOR, I propose you do not mention Cu? Else, why mention CBOR at this point?

@emmanuelsearch

emmanuelsearch Nov 22, 2016

Member

is CBOR needed to make this example work? If yes and if Cu does not support CBOR, I propose you do not mention Cu? Else, why mention CBOR at this point?

This comment has been minimized.

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Cu removed.

@mattiantonini

mattiantonini Nov 23, 2016

Contributor

Cu removed.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 23, 2016

Contributor

@emmanuelsearch Removed warnings in BR_FW example

Contributor

mattiantonini commented Nov 23, 2016

@emmanuelsearch Removed warnings in BR_FW example

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

I could get the BR example to work using cli-coap to test GET on the 4 resources, but the output is partly misinterpreted (see below). Can this be fixed?

vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/light/1
(2.05)	�estate��
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
(2.05)	��bdix$0d9f5186-7a60-42df-6e6c-02890136b058elinks��dhreff/oic/pbrt�hoic.wk.p�bif�hoic.if.rooic.if.baseline�ap�bbm���dhreff/oic/dbrt�koic.d.lighthoic.wk.d�bif�hoic.if.rooic.if.baseline�ap�bbm���dhrefh/light/1brt�koic.r.light�bif�ioic.if.rwooic.if.baseline�ap�bbm�����
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/p  
(2.05)	�brt�hoic.wk.pbif�hoic.if.rooic.if.baseline�bpix$f121d360-5a8d-4470-5bce-4d32936c14f5dmnmngRIOT-OS�
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/d
(2.05)	�brt�koic.d.lighthoic.wk.dbif�hoic.if.rooic.if.baseline�bdix$0d9f5186-7a60-42df-6e6c-02890136b058anlRIOT's lightcicvc1.0cdmvc1.0�
Member

emmanuelsearch commented Nov 24, 2016

I could get the BR example to work using cli-coap to test GET on the 4 resources, but the output is partly misinterpreted (see below). Can this be fixed?

vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/light/1
(2.05)	�estate��
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
(2.05)	��bdix$0d9f5186-7a60-42df-6e6c-02890136b058elinks��dhreff/oic/pbrt�hoic.wk.p�bif�hoic.if.rooic.if.baseline�ap�bbm���dhreff/oic/dbrt�koic.d.lighthoic.wk.d�bif�hoic.if.rooic.if.baseline�ap�bbm���dhrefh/light/1brt�koic.r.light�bif�ioic.if.rwooic.if.baseline�ap�bbm�����
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/p  
(2.05)	�brt�hoic.wk.pbif�hoic.if.rooic.if.baseline�bpix$f121d360-5a8d-4470-5bce-4d32936c14f5dmnmngRIOT-OS�
vagrant@vagrant:/dev$ coap get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/d
(2.05)	�brt�koic.d.lighthoic.wk.dbif�hoic.if.rooic.if.baseline�bdix$0d9f5186-7a60-42df-6e6c-02890136b058anlRIOT's lightcicvc1.0cdmvc1.0�
@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 24, 2016

Contributor

@emmanuelsearch you have to put also -c as argument in order to parse payloads CBOR-encoded
e.g.

coap -c get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
Contributor

mattiantonini commented Nov 24, 2016

@emmanuelsearch you have to put also -c as argument in order to parse payloads CBOR-encoded
e.g.

coap -c get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

Also: I've been trying to PUT on the light, but did not succeed. I tried things like:
echo -n '{state: true}' | coap put coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/light/1
but the LED status stays off (and indeed does not turn on in reality)

2016-11-24 15:12:21,701 - INFO # ipadapter: got multicast request
2016-11-24 15:12:21,708 - INFO # Incoming message from [2001:0db8:0000:0000:0000:0000:0000:0001]:59698
2016-11-24 15:12:21,710 - INFO # ipadapter: waiting for multicast requests...
2016-11-24 15:12:21,710 - INFO # server_oic: PUT request
2016-11-24 15:12:21,711 - INFO # server_oic: LED0 is OFF

Is this intended?

Member

emmanuelsearch commented Nov 24, 2016

Also: I've been trying to PUT on the light, but did not succeed. I tried things like:
echo -n '{state: true}' | coap put coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/light/1
but the LED status stays off (and indeed does not turn on in reality)

2016-11-24 15:12:21,701 - INFO # ipadapter: got multicast request
2016-11-24 15:12:21,708 - INFO # Incoming message from [2001:0db8:0000:0000:0000:0000:0000:0001]:59698
2016-11-24 15:12:21,710 - INFO # ipadapter: waiting for multicast requests...
2016-11-24 15:12:21,710 - INFO # server_oic: PUT request
2016-11-24 15:12:21,711 - INFO # server_oic: LED0 is OFF

Is this intended?

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

-c does not help much, here's what I get:

vagrant@vagrant:/dev$ coap -c get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
(2.05)	��bdix$0d9f5186-7a60-42df-6e6c-02890136b058elinks��dhreff/oic/pbrt�hoic.wk.p�bif�hoic.if.rooic.if.baseline�ap�bbm���dhreff/oic/dbrt�koic.d.lighthoic.wk.d�bif�hoic.if.rooic.if.baseline�ap�bbm���dhrefh/light/1brt�koic.r.light�bif�ioic.if.rwooic.if.baseline�ap�bbm�����
Member

emmanuelsearch commented Nov 24, 2016

-c does not help much, here's what I get:

vagrant@vagrant:/dev$ coap -c get coap://[2001:db8::5855:5c7c:8647:1e2e]:5683/oic/res
(2.05)	��bdix$0d9f5186-7a60-42df-6e6c-02890136b058elinks��dhreff/oic/pbrt�hoic.wk.p�bif�hoic.if.rooic.if.baseline�ap�bbm���dhreff/oic/dbrt�koic.d.lighthoic.wk.d�bif�hoic.if.rooic.if.baseline�ap�bbm���dhrefh/light/1brt�koic.r.light�bif�ioic.if.rwooic.if.baseline�ap�bbm�����
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

and according to the doc of cli-coap, coap -c is for non-confirmable?

Member

emmanuelsearch commented Nov 24, 2016

and according to the doc of cli-coap, coap -c is for non-confirmable?

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

maybe we need to use coap-cbor-cli instead to test?

Member

emmanuelsearch commented Nov 24, 2016

maybe we need to use coap-cbor-cli instead to test?

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 24, 2016

Contributor

Use this version https://www.npmjs.com/package/coap-cbor-cli , -c encodes payloads in cbor

Contributor

mattiantonini commented Nov 24, 2016

Use this version https://www.npmjs.com/package/coap-cbor-cli , -c encodes payloads in cbor

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 24, 2016

Member

actually, coap-cbor-cli crashes on my system (unrelated, but problematic to test ;)
did you try it yourself? does it work on your machine?

Member

emmanuelsearch commented Nov 24, 2016

actually, coap-cbor-cli crashes on my system (unrelated, but problematic to test ;)
did you try it yourself? does it work on your machine?

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 24, 2016

Contributor

At my side works (version 0.3.1)

coap -c coap://[aaaa::5859:1c2a:64c7:c48a]:56789/light/1
{ state: true }

but you should use a real IoTivity client for PUT requests

Contributor

mattiantonini commented Nov 24, 2016

At my side works (version 0.3.1)

coap -c coap://[aaaa::5859:1c2a:64c7:c48a]:56789/light/1
{ state: true }

but you should use a real IoTivity client for PUT requests

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

I am not trying on a Pi, but on my laptop (a mac, using a vagrant VM with Ubuntu in it). So far I had problems with the iotivity script (it's nuts all the stuff iotivity needs to install!!) especially with boost. Will share progress asap.

Member

emmanuelsearch commented Nov 25, 2016

I am not trying on a Pi, but on my laptop (a mac, using a vagrant VM with Ubuntu in it). So far I had problems with the iotivity script (it's nuts all the stuff iotivity needs to install!!) especially with boost. Will share progress asap.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 25, 2016

Contributor

Are you trying on a RaspberryPi? Can you share the terminal output?

Contributor

mattiantonini commented Nov 25, 2016

Are you trying on a RaspberryPi? Can you share the terminal output?

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

Latest terminal output running the install iotivity script (using x86_64 instead of arm in IOTIVITY_ARCH):

Compiling out/linux/x86_64/release/resource/csdk/security/src/aclresource.o
resource/csdk/security/src/aclresource.c: In function 'AclToCBORPayload':
resource/csdk/security/src/aclresource.c:628:24: error: 'CborEncoder {aka struct CborEncoder}' has no member named 'ptr'
         *size = encoder.ptr - outPayload;
                        ^
resource/csdk/security/src/aclresource.c:640:27: error: 'CborEncoder {aka struct CborEncoder}' has no member named 'ptr'
         cborLen += encoder.ptr - encoder.end;
                           ^
scons: *** [out/linux/x86_64/release/resource/csdk/security/src/aclresource.o] Error 1
scons: building terminated because of errors.
Member

emmanuelsearch commented Nov 25, 2016

Latest terminal output running the install iotivity script (using x86_64 instead of arm in IOTIVITY_ARCH):

Compiling out/linux/x86_64/release/resource/csdk/security/src/aclresource.o
resource/csdk/security/src/aclresource.c: In function 'AclToCBORPayload':
resource/csdk/security/src/aclresource.c:628:24: error: 'CborEncoder {aka struct CborEncoder}' has no member named 'ptr'
         *size = encoder.ptr - outPayload;
                        ^
resource/csdk/security/src/aclresource.c:640:27: error: 'CborEncoder {aka struct CborEncoder}' has no member named 'ptr'
         cborLen += encoder.ptr - encoder.end;
                           ^
scons: *** [out/linux/x86_64/release/resource/csdk/security/src/aclresource.o] Error 1
scons: building terminated because of errors.
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

Do you have any experience with installing IoTivity elsewhere than on the Pi?

Member

emmanuelsearch commented Nov 25, 2016

Do you have any experience with installing IoTivity elsewhere than on the Pi?

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 25, 2016

Contributor

It is a known problem (https://lists.iotivity.org/pipermail/iotivity-dev/2016-November/006161.html)... I have to fix the script... anyway there is a workaround by going into extlibs\tinycbor\tinycbor and doing a “git fetch && git checkout v0.3.2” to use the previous version of TinyCBOR.

Contributor

mattiantonini commented Nov 25, 2016

It is a known problem (https://lists.iotivity.org/pipermail/iotivity-dev/2016-November/006161.html)... I have to fix the script... anyway there is a workaround by going into extlibs\tinycbor\tinycbor and doing a “git fetch && git checkout v0.3.2” to use the previous version of TinyCBOR.

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

Thanks. So do I wait until you fix the script? Or should I try the workaround?

Member

emmanuelsearch commented Nov 25, 2016

Thanks. So do I wait until you fix the script? Or should I try the workaround?

@rzr

This comment has been minimized.

Show comment
Hide comment
@rzr

rzr Nov 25, 2016

Contributor

you'll find info on dependencies at :
http://wiki.iotivity.org/build

Current version is v0.4 not v0.3.2

If havent checked yet , but there are chances that 1.2.1-RC1 client on supported OS will work with your servers on RIOT.

By the way I am linking your efforts at

http://wiki.iotivity.org/os

feel free to update page

Contributor

rzr commented Nov 25, 2016

you'll find info on dependencies at :
http://wiki.iotivity.org/build

Current version is v0.4 not v0.3.2

If havent checked yet , but there are chances that 1.2.1-RC1 client on supported OS will work with your servers on RIOT.

By the way I am linking your efforts at

http://wiki.iotivity.org/os

feel free to update page

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 25, 2016

Contributor

You can do the workaround and restart the script, or pull the updated version. If you pull, you should remove the iotivity_wdir folder.

Contributor

mattiantonini commented Nov 25, 2016

You can do the workaround and restart the script, or pull the updated version. If you pull, you should remove the iotivity_wdir folder.

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

mmh. this is what I get with the newest commit if the the iotivity install script:

Cloning into 'extlibs/tinycbor/tinycbor'...
fatal: Remote branch 0.3.2 not found in upstream origin

which tinycbor repo is being used?

Member

emmanuelsearch commented Nov 25, 2016

mmh. this is what I get with the newest commit if the the iotivity install script:

Cloning into 'extlibs/tinycbor/tinycbor'...
fatal: Remote branch 0.3.2 not found in upstream origin

which tinycbor repo is being used?

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 25, 2016

Member

seems that the branch name is rather v0.3.2 and not just 0.3.2
(see https://github.com/01org/tinycbor/releases)

Member

emmanuelsearch commented Nov 25, 2016

seems that the branch name is rather v0.3.2 and not just 0.3.2
(see https://github.com/01org/tinycbor/releases)

@rzr

This comment has been minimized.

Show comment
Hide comment
@rzr

rzr Nov 25, 2016

Contributor

yes I confirm , but I would give a try with v0.4

Contributor

rzr commented Nov 25, 2016

yes I confirm , but I would give a try with v0.4

@aabadie

Nice new feature ! I just read the documentation for the moment. See my comments below.
I'll test this soon on IoTLAB

Show outdated Hide outdated examples/iotivity_examples/README.md
IoTivity Examples
===============
These examples implement some simple clients and a server to test the IoTivity package for RIOT-OS. The pkg is based on the [IoTivity-Constrained][1] library.
All examples use the realm-local multicast address **ff03:158** instead the link-local multicast address **ff02::158**. Every payload is [CBOR][2] encoded.

This comment has been minimized.

@aabadie

aabadie Nov 26, 2016

Contributor

missing word: ...instead of the link-local...

@aabadie

aabadie Nov 26, 2016

Contributor

missing word: ...instead of the link-local...

This comment has been minimized.

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

fixed

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

fixed

Show outdated Hide outdated examples/iotivity_examples/README.md
$ make flash BOARD=samr21-xpro SERIAL=client_node_serial
$ make term BOARD=samr21-xpro SERIAL=client_node_serial
```
Client starts the discovery phase. Once it find a resource (with ResourceType **oic.r.light**), it registers as an observer on the resource, then it switches on its LED and it finally starts with periodic PUT requests. The server LED will blink periodically.

This comment has been minimized.

@aabadie

aabadie Nov 26, 2016

Contributor

finds

@aabadie

aabadie Nov 26, 2016

Contributor

finds

This comment has been minimized.

@aabadie

aabadie Nov 26, 2016

Contributor

extra space between LED and and

@aabadie

aabadie Nov 26, 2016

Contributor

extra space between LED and and

This comment has been minimized.

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

fixed

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

fixed

$ make host-tools
$ sudo ./start_network_mcast.sh <serial-port> <tap-device> <IPv6-prefix> <IPv6-mcast>
```
then run the Step 3 with the proper changes.

This comment has been minimized.

@aabadie

aabadie Nov 26, 2016

Contributor

Does this mean that one has to manually configure the routes on the BR ? Could this be done automatically with the start_network_mcast.sh script ?

@aabadie

aabadie Nov 26, 2016

Contributor

Does this mean that one has to manually configure the routes on the BR ? Could this be done automatically with the start_network_mcast.sh script ?

This comment has been minimized.

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

I'm going to try this afternoon

@mattiantonini

mattiantonini Nov 26, 2016

Contributor

I'm going to try this afternoon

This comment has been minimized.

@mattiantonini

mattiantonini Nov 28, 2016

Contributor

I tried but unfortunately it does not work. Looking inside the /dist/tools/ethos/start_network.sh script, routes are configured using link local addresses (fe80::). I'm using global addresses (2001:db8::) to create them. Any suggestion?

@mattiantonini

mattiantonini Nov 28, 2016

Contributor

I tried but unfortunately it does not work. Looking inside the /dist/tools/ethos/start_network.sh script, routes are configured using link local addresses (fe80::). I'm using global addresses (2001:db8::) to create them. Any suggestion?

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

@aabadie I propose we refine later, and merge as is, since it works. Do you agree?

@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

@aabadie I propose we refine later, and merge as is, since it works. Do you agree?

This comment has been minimized.

@aabadie

aabadie Nov 29, 2016

Contributor

yes !

@aabadie

aabadie Nov 29, 2016

Contributor

yes !

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 28, 2016

Member

after hours (literally!) of compilation needed for the IoTivity on Linux, I could get the Simple IoTivity Client to run from my laptop to a SAMR21 via another SAMR21 as border router. I could verify that the Linux-to-node communication is working (see below). However, the runtime is rather slow: it takes around 10s from typing the command to the LED reacting. Any idea where the delay comes from? For example: is a timeout configured to exaggeratedly big value somewhere in a discovery phase at some point?

vagrant@vagrant:~/AGILE/agile-iotivity/IoTivity/Simple-Client-Linux$ bin/simple_client 2001:db8::5855:5c7c:8647:1e2e off
Client is Running!
0: listenCallback(): failed to create resource. clientResponse: 255

Resource Found

Resource Found

Resource Found
Found 3 Resource(s)

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /light/1
Resource Types:
	oic.r.light
Resource Interfaces: 
	oic.if.rw
	oic.if.baseline
Light resource found!

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /oic/d
Resource Types:
	oic.d.light
	oic.wk.d
Resource Interfaces: 
	oic.if.r
	oic.if.baseline

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /oic/p
Resource Types:
	oic.wk.p
Resource Interfaces: 
	oic.if.r
	oic.if.baseline
GET Successful!
State: ON
PUT on Light Resource!
PUT Successful!
GET Successful!
State: OFF
vagrant@vagrant:~/AGILE/agile-iotivity/IoTivity/Simple-Client-Linux$ 
Member

emmanuelsearch commented Nov 28, 2016

after hours (literally!) of compilation needed for the IoTivity on Linux, I could get the Simple IoTivity Client to run from my laptop to a SAMR21 via another SAMR21 as border router. I could verify that the Linux-to-node communication is working (see below). However, the runtime is rather slow: it takes around 10s from typing the command to the LED reacting. Any idea where the delay comes from? For example: is a timeout configured to exaggeratedly big value somewhere in a discovery phase at some point?

vagrant@vagrant:~/AGILE/agile-iotivity/IoTivity/Simple-Client-Linux$ bin/simple_client 2001:db8::5855:5c7c:8647:1e2e off
Client is Running!
0: listenCallback(): failed to create resource. clientResponse: 255

Resource Found

Resource Found

Resource Found
Found 3 Resource(s)

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /light/1
Resource Types:
	oic.r.light
Resource Interfaces: 
	oic.if.rw
	oic.if.baseline
Light resource found!

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /oic/d
Resource Types:
	oic.d.light
	oic.wk.d
Resource Interfaces: 
	oic.if.r
	oic.if.baseline

Host: coap://[2001:db8::5855:5c7c:8647:1e2e]:56789
URI: /oic/p
Resource Types:
	oic.wk.p
Resource Interfaces: 
	oic.if.r
	oic.if.baseline
GET Successful!
State: ON
PUT on Light Resource!
PUT Successful!
GET Successful!
State: OFF
vagrant@vagrant:~/AGILE/agile-iotivity/IoTivity/Simple-Client-Linux$ 
Show outdated Hide outdated examples/iotivity_examples/README.md
We will use Serial Numbers in order to identify the designed node during the compilation phase.
###<a name="l2n_br"></a>Start the Border Router
Step 1) Open a terminal window in `/example/iotivity-examples/br_fw/` and type

This comment has been minimized.

@emmanuelsearch

emmanuelsearch Nov 28, 2016

Member

For now, in my experience, this works only if you indeed start the server first and then the border router.
I propose to state this explicitly as a caveat in this readme, just in case ;)

@emmanuelsearch

emmanuelsearch Nov 28, 2016

Member

For now, in my experience, this works only if you indeed start the server first and then the border router.
I propose to state this explicitly as a caveat in this readme, just in case ;)

This comment has been minimized.

@mattiantonini

mattiantonini Nov 29, 2016

Contributor

Start BR and Start Server swapped

@mattiantonini

mattiantonini Nov 29, 2016

Contributor

Start BR and Start Server swapped

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 28, 2016

Contributor

Delays are set hard-coded in the client code: 10 seconds for discovery, 3 seconds for requests. They can be reduced as you want. The minimum value is 1 or 2 seconds.

Contributor

mattiantonini commented Nov 28, 2016

Delays are set hard-coded in the client code: 10 seconds for discovery, 3 seconds for requests. They can be reduced as you want. The minimum value is 1 or 2 seconds.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 29, 2016

Contributor

Old-Style-Definitions warnings suppressed (master updated)

Contributor

mattiantonini commented Nov 29, 2016

Old-Style-Definitions warnings suppressed (master updated)

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

So for the hardcoded delays, you mean: they are hardcoded in your Simple Client from your AGILE repo?
It makes sense to indicate where these can be tweaked exactly in the doc (10 sec delays sticks out ;)

Member

emmanuelsearch commented Nov 29, 2016

So for the hardcoded delays, you mean: they are hardcoded in your Simple Client from your AGILE repo?
It makes sense to indicate where these can be tweaked exactly in the doc (10 sec delays sticks out ;)

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

(assuming @aabadie agrees, and you answer my last comment)
ACK.
Please squash.
You could also consider running uncrustify (just tiny nits).

Member

emmanuelsearch commented Nov 29, 2016

(assuming @aabadie agrees, and you answer my last comment)
ACK.
Please squash.
You could also consider running uncrustify (just tiny nits).

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 29, 2016

Contributor

@emmanuelsearch exactly, delays are hardcoded in my Simple Client inside the AGILE repo. I will run uncrustify and squasing ;)

Contributor

mattiantonini commented Nov 29, 2016

@emmanuelsearch exactly, delays are hardcoded in my Simple Client inside the AGILE repo. I will run uncrustify and squasing ;)

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

@mattiantonini OK. Can you indicate in the documentation that the (relatively high delay) values are hardcoded in the client?

Member

emmanuelsearch commented Nov 29, 2016

@mattiantonini OK. Can you indicate in the documentation that the (relatively high delay) values are hardcoded in the client?

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Nov 29, 2016

Contributor

@emmanuelsearch Documentation updated on Agile Repo

Contributor

mattiantonini commented Nov 29, 2016

@emmanuelsearch Documentation updated on Agile Repo

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 29, 2016

Member

@mattiantonini great. I suggest mentioning the default delay values in the documentation of the RIOT example, for good measure. You could indicate something like "several seconds", or something like that

Member

emmanuelsearch commented Nov 29, 2016

@mattiantonini great. I suggest mentioning the default delay values in the documentation of the RIOT example, for good measure. You could indicate something like "several seconds", or something like that

@aabadie

ACK

@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
@emmanuelsearch

emmanuelsearch Nov 30, 2016

Member

@mattiantonini please squash/fixup and let's go!

Member

emmanuelsearch commented Nov 30, 2016

@mattiantonini please squash/fixup and let's go!

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
Contributor

mattiantonini commented Nov 30, 2016

@aabadie

This comment has been minimized.

Show comment
Hide comment
@aabadie

aabadie Dec 4, 2016

Contributor

Let's ask Murdock before merging.

Contributor

aabadie commented Dec 4, 2016

Let's ask Murdock before merging.

@aabadie

This comment has been minimized.

Show comment
Hide comment
@aabadie

aabadie Dec 4, 2016

Contributor

@mattiantonini, Murdock reported some errors.

Contributor

aabadie commented Dec 4, 2016

@mattiantonini, Murdock reported some errors.

@mattiantonini

This comment has been minimized.

Show comment
Hide comment
@mattiantonini

mattiantonini Dec 5, 2016

Contributor

Murdock's tests are all green :)

Contributor

mattiantonini commented Dec 5, 2016

Murdock's tests are all green :)

@emmanuelsearch emmanuelsearch merged commit 364874f into RIOT-OS:master Dec 5, 2016

1 check passed

Murdock The build succeeded. runtime: 30m:8s
Details
@emmanuelsearch

This comment has been minimized.

Show comment
Hide comment
Member

emmanuelsearch commented Dec 5, 2016

Go!

@rzr

This comment has been minimized.

Show comment
Hide comment
@rzr

rzr Dec 5, 2016

Contributor

Congratulation this is appreciated

Contributor

rzr commented Dec 5, 2016

Congratulation this is appreciated

@miri64

This comment has been minimized.

Show comment
Hide comment
@miri64

miri64 Dec 5, 2016

Member

Congratulations!

Member

miri64 commented Dec 5, 2016

Congratulations!

@mattiantonini mattiantonini deleted the mattiantonini:pkg/iotivity branch Dec 6, 2016

@mattiantonini mattiantonini restored the mattiantonini:pkg/iotivity branch Jan 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment