Date   

OCF Fargo draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Fargo”). These draft documents provide a current snapshot of the specification development and are subject to change. Additional early draft CRs will follow as OCF technical WGs complete work on the next version of the specifications. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: microcontrollers

Viktor Ariel (SURE) <viktor.ariel@...>
 

Hi Nathan, Thanks for the suggestion. We are currently in the process of compiling Iotivity with security on ESP32.

Next step is connecting to an air conditioner board.

Regards


Viktor


On July 17, 2019 12:38:57 AM GMT+08:00, "Heldt-Sheller, Nathan" <nathan.heldt-sheller@...> wrote:

This is great stuff thanks for sharing; is it okay if I (or you preferably!) re-send and cc: the IoTivity Dev reflector for these kinds of discussions? 

The address is iotivity-dev@...

 

Thanks,
Nathan

 

From: Viktor Ariel (SURE) [mailto:viktor.ariel@...]
Sent: Tuesday, June 18, 2019 2:15 PM
To: Yann Stephen <mandza.y.s@...>
Cc: Clarke Stevens <cstevens63@...>; Wouter van der Beek <wovander@...>; Maloor, Kishen <kishen.maloor@...>; Stefano Toppan <stefano.toppan@...>; Max Kholmyansky <max@...>; Sungdong Kim <sd9.kim@...>; Heldt-Sheller, Nathan <nathan.heldt-sheller@...>; ran@ >> ran@sureuniversal. com <ran@...>; Maria Berezansky <maria@...>; vadim >> "vadim@..." <vadim@...>; Avishai Bar-Magen
马一伟 <avishai@...>; baraa <baraa@...>
Subject: Re: microcontrollers

 

Hi Yann,

It looks like you did some really good work here. Wonder how you managed to get Iotivity-light into 8266.

We are starting a project to get ESP32 working with Iotivity-light and with some WiFi and BLE bridging to OCF.

Adding some more people from SURE.

Cheers

Viktor

-- 
Viktor Ariel, PhD.
CEO
SURE Universal Ltd.
 
Web: www.sureuniversal.com
Mobile: +972-544-348-362

On 14/06/2019 17:39, Yann Stephen wrote:

Hello All! 

 

i did scramble around  the ESP32 and ESP8266 and got them working with the the latest iotivity-constrained form Kirshen Github ( last test was about 3/4 months ago tough). 

 

However, i am not sure but WIFI presented significant lags in resources observation in both devices. The espressif SDK package comes with its own mbedtls. Which cause another issue has to get security with iotivity patches working. adjustment will need to be done there i believe. However this should not  be a big deal. but the response time under observe was really bad on my side.


There is an initial port from espressif here:  ESP32 iotivity over Espressif SDK(FreeRTOS) 
One need to update the underlying drivers code based on the new releases of their SDK and iotivity lite if that is a viable direction to take.

 

Regards

 

On Fri, Jun 14, 2019 at 7:43 AM Viktor Ariel (SURE) <viktor.ariel@...> wrote:

Hi Clarke,

Ran Barkai from SURE will lead the effort of integrating Iotivity light with ESP32.

Regards

Viktor

On June 13, 2019 8:26:51 AM MDT, Clarke Stevens <cstevens63@...> wrote:

All,
 
I’m trying to identify people working on IoTivity-lite for microcontrollers. I’m at the intro event this week at CableLabs and learned that Sure Universal is very interested in getting OpenRTOS running on ESP32 boards.
 
Yann has IoTivity-lite with security running on the Arduino Due with an ethernet shield. That’s exciting, but he’s having memory issues getting it on smaller boards. Sure believes that issue can be addressed with the ESP32. They would prefer to use OpenRTOS rather than the Arduino IDE. I believe the OpenRTOS that is on the IoTivity-lite repo has not been maintained, so there’s a bit of work to do. However, I’m excited that Sure wants to take it on.
 
My basic goal with this message is to put the people interested in microcontrollers in touch with one another.  We might want to set up a group on IoTivity or something as I think these targets will likely be increasingly important for OCF and IoTivity.
 
Thanks,
-Clarke


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


OCF Fargo draft version 0.3 CR for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find an early draft (v0.3) of a CR against the Open Connectivity Foundation’s next specification (codenamed “Fargo”). This draft document provides a current snapshot of the specification development and are subject to change. Additional early draft CRs will follow as OCF technical WGs complete work on the next version of the specifications. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: Upgrade Jira on Tuesday 16th 10 AM EDT

Suresh Channamallu <schannamallu@...>
 





On Jul 15, 2019, at 2:30 PM, Suresh Channamallu <schannamallu@...> wrote:


We'll be upgrading Jira at Tuesday 16th 10 AM EDT (14:00 UTC) to new stable version released.

Downtime should be 30 Minutes.

If you think this update needs to be postponed or have any comments or questions, please send an email to helpdesk@....


Upgrade Jira on Tuesday 16th AM EDT

Suresh Channamallu <schannamallu@...>
 


Hi All

We'll be upgrading Jira at Tuesday 16th 9 AM EDT (14:00 UTC) to new stable version released.

Downtime should be 30 Minutes.

If you think this update needs to be postponed or have any comments or questions, please send an email to helpdesk@....

--
Thanks & Regards,
Suresh.channamallu


Re: Payload issue after upgrading to IoTivity 2.0

Max <max001@...>
 


Hi,
An update...

I still don't know the "root cause", and cannot explain the "random" behavior of the library.

However, made some progress with limiting the scope...

There were some changes in the IoTivity 2.0 source code re: building CBOR encoding, comparing to the 1.3 code base.
You can see them here:

Once I rolled back the 2 latest changes, the problematic "random" behavior stopped to reproduce.
So I still don't understand the "root cause", but I am quite confident the issue is with the changes I mentioned.

If I got it right,  the changes are related to "batch / collection" we don't use in our product, so I have kind of patch / workaround for now.
Unfortunately, I have no time to debug the code modifications in depth, for now.

Best regards.
Max.







On Fri, Jul 5, 2019 at 9:37 AM <chiayu.wu@...> wrote:

Hi Max,

 

I met a similar issue of the data size difference after doing “Post request”.

 

But the problem of mine is the size of received pdu of “Get response” will be larger than regular after a “Post request” been performed.

 

Client: Android(2.0.1)

Server: OCSample/OCServer(2.0.1)

 

Step1. Discovery [OK]

Step2. Get [OK]…Get [OK]…Get [OK]…

Step3. Post [OK]

Step4. Get [NG], Android client crashed.

 

The received pdu data of both cases are list below.

The main difference appeared just after token bytes.

received pdu data [OK]:

68 45 EF 0E 57 66 4D B2 3C 91 8A EC 82 01 00 31

61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08 00 E1

F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C 69 67

68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E 62 61

73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E 72 77

65 70 6F 77 65 72 18 32 FF

 

Msgid: EF 0E

Token: 57 66 4D B2 3C 91 8A EC

Difference: 82 01

 

received pdu data [NG]:

68 45 7A EC 4F CA 0D 98 6A 23 A1 C4 84 E8 3B 01

00 31 61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08

00 E1 F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C

69 67 68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E

62 61 73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E

72 77 65 70 6F 77 65 72 18 32 FF

 

Msgid: 7A EC

Token: 4F CA 0D 98 6A 23 A1 C4

Difference: 84 E8 3B 01

 

Android log

A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xa8

 

--

However, if I use Android Client(2.0.1) + Android Server (2.0.1),  “Discovery”, “Get”, “Post” are all OK.

 

Best Regards,

ChiaYu

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of Max
Sent: Wednesday, July 03, 2019 5:01 AM
To: iotivity
Subject: [dev] Payload issue after upgrading to IoTivity 2.0

 

Hi,

 

I am in process of upgrading my Android server device from IoTivity 1.3.1 to 2.0 (using the latest 'master'). 

 

I face a weird issue that I never saw with the previous version.

 

"Randomly", the response to POST request to one of my resources - is wrapped as an array.

Normally, the response looks like: 

 {"value":false,"x.com.sure.a.b":"abc"}

 

In the buggy scenarios, appearing randomly, the data is reported by the client as:

 [{"value":false,"x.com.sure.a.b":"abc"}]

So the data inside the array is right, but the array [] should not be there!

 

Unfortunately, the only way I was able to reproduce the issue (from time to time) is via running a specific test of the Certification Test Tool. I failed to reproduce the bug "manually".

 

I wonder what can be the cause of such a behavior, and how to debug it further.

 

I tried to look into the logs, and indeed I saw that in the "buggy" responses, same code generates 60 bytes, instead of 59 bytes.

 

The proper response (59 bytes) looks in the logs like:

 

07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0000:  44 44 3d a7 32 dc 99 23 b9 73 74 62 53 77 69 74  DD=.2..#.stbSwit
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff bf  ch.'............
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0020:  65 76 61 6c 75 65 f4 6e 78 2e 63 6f 6d 2e 73 75  evalue.nx.com.su
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0030:  72 65 2e 61 2e 62 63 61 62 63 ff                 re.a.bcabc.

 

The buggy response (60 bytes) looks in the logs like::

 

07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0000:  54 44 b8 1b 3b ca b1 13 b9 73 74 62 53 77 69 74  TD..;....stbSwit
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff 81  ch.'............
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0020:  bf 65 76 61 6c 75 65 f5 6e 78 2e 63 6f 6d 2e 73  .evalue.nx.com.s
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0030:  75 72 65 2e 61 2e 62 63 61 62 63 ff              ure.a.bcabc.

 

Is there any method to analyze the payload? I tried to "paste" to cbor.me site - no success. 

 

Any hint on how to analyze the data and identify the "root cause" is highly appreciated.

 

 

Thanks in advance

Max

 

 

Max Kholmyansky

CTO - SURE Universal Ltd.

 

 

 

 

 


Re: Payload issue after upgrading to IoTivity 2.0

ChiaYu
 

Hi Max,

 

I met a similar issue of the data size difference after doing “Post request”.

 

But the problem of mine is the size of received pdu of “Get response” will be larger than regular after a “Post request” been performed.

 

Client: Android(2.0.1)

Server: OCSample/OCServer(2.0.1)

 

Step1. Discovery [OK]

Step2. Get [OK]…Get [OK]…Get [OK]…

Step3. Post [OK]

Step4. Get [NG], Android client crashed.

 

The received pdu data of both cases are list below.

The main difference appeared just after token bytes.

received pdu data [OK]:

68 45 EF 0E 57 66 4D B2 3C 91 8A EC 82 01 00 31

61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08 00 E1

F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C 69 67

68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E 62 61

73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E 72 77

65 70 6F 77 65 72 18 32 FF

 

Msgid: EF 0E

Token: 57 66 4D B2 3C 91 8A EC

Difference: 82 01

 

received pdu data [NG]:

68 45 7A EC 4F CA 0D 98 6A 23 A1 C4 84 E8 3B 01

00 31 61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08

00 E1 F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C

69 67 68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E

62 61 73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E

72 77 65 70 6F 77 65 72 18 32 FF

 

Msgid: 7A EC

Token: 4F CA 0D 98 6A 23 A1 C4

Difference: 84 E8 3B 01

 

Android log

A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xa8

 

--

However, if I use Android Client(2.0.1) + Android Server (2.0.1),  “Discovery”, “Get”, “Post” are all OK.

 

Best Regards,

ChiaYu

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of Max
Sent: Wednesday, July 03, 2019 5:01 AM
To: iotivity
Subject: [dev] Payload issue after upgrading to IoTivity 2.0

 

Hi,

 

I am in process of upgrading my Android server device from IoTivity 1.3.1 to 2.0 (using the latest 'master'). 

 

I face a weird issue that I never saw with the previous version.

 

"Randomly", the response to POST request to one of my resources - is wrapped as an array.

Normally, the response looks like: 

 {"value":false,"x.com.sure.a.b":"abc"}

 

In the buggy scenarios, appearing randomly, the data is reported by the client as:

 [{"value":false,"x.com.sure.a.b":"abc"}]

So the data inside the array is right, but the array [] should not be there!

 

Unfortunately, the only way I was able to reproduce the issue (from time to time) is via running a specific test of the Certification Test Tool. I failed to reproduce the bug "manually".

 

I wonder what can be the cause of such a behavior, and how to debug it further.

 

I tried to look into the logs, and indeed I saw that in the "buggy" responses, same code generates 60 bytes, instead of 59 bytes.

 

The proper response (59 bytes) looks in the logs like:

 

07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0000:  44 44 3d a7 32 dc 99 23 b9 73 74 62 53 77 69 74  DD=.2..#.stbSwit
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff bf  ch.'............
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0020:  65 76 61 6c 75 65 f4 6e 78 2e 63 6f 6d 2e 73 75  evalue.nx.com.su
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0030:  72 65 2e 61 2e 62 63 61 62 63 ff                 re.a.bcabc.

 

The buggy response (60 bytes) looks in the logs like::

 

07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0000:  54 44 b8 1b 3b ca b1 13 b9 73 74 62 53 77 69 74  TD..;....stbSwit
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff 81  ch.'............
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0020:  bf 65 76 61 6c 75 65 f5 6e 78 2e 63 6f 6d 2e 73  .evalue.nx.com.s
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0030:  75 72 65 2e 61 2e 62 63 61 62 63 ff              ure.a.bcabc.

 

Is there any method to analyze the payload? I tried to "paste" to cbor.me site - no success. 

 

Any hint on how to analyze the data and identify the "root cause" is highly appreciated.

 

 

Thanks in advance

Max

 

 

Max Kholmyansky

CTO - SURE Universal Ltd.

 

 

 

 

 


Payload issue after upgrading to IoTivity 2.0

Max <max001@...>
 

Hi,

I am in process of upgrading my Android server device from IoTivity 1.3.1 to 2.0 (using the latest 'master'). 

I face a weird issue that I never saw with the previous version.

"Randomly", the response to POST request to one of my resources - is wrapped as an array.
Normally, the response looks like: 
 {"value":false,"x.com.sure.a.b":"abc"}

In the buggy scenarios, appearing randomly, the data is reported by the client as:
 [{"value":false,"x.com.sure.a.b":"abc"}]
So the data inside the array is right, but the array [] should not be there!

Unfortunately, the only way I was able to reproduce the issue (from time to time) is via running a specific test of the Certification Test Tool. I failed to reproduce the bug "manually".

I wonder what can be the cause of such a behavior, and how to debug it further.

I tried to look into the logs, and indeed I saw that in the "buggy" responses, same code generates 60 bytes, instead of 59 bytes.

The proper response (59 bytes) looks in the logs like:

07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0000:  44 44 3d a7 32 dc 99 23 b9 73 74 62 53 77 69 74  DD=.2..#.stbSwit
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff bf  ch.'............
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0020:  65 76 61 6c 75 65 f4 6e 78 2e 63 6f 6d 2e 73 75  evalue.nx.com.su
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0030:  72 65 2e 61 2e 62 63 61 62 63 ff                 re.a.bcabc.

The buggy response (60 bytes) looks in the logs like::

07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0000:  54 44 b8 1b 3b ca b1 13 b9 73 74 62 53 77 69 74  TD..;....stbSwit
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 e1 f6 e2 c0 ff 81  ch.'............
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0020:  bf 65 76 61 6c 75 65 f5 6e 78 2e 63 6f 6d 2e 73  .evalue.nx.com.s
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0030:  75 72 65 2e 61 2e 62 63 61 62 63 ff              ure.a.bcabc.

Is there any method to analyze the payload? I tried to "paste" to cbor.me site - no success. 

Any hint on how to analyze the data and identify the "root cause" is highly appreciated.


Thanks in advance
Max


Max Kholmyansky
CTO - SURE Universal Ltd.






Re: Easy Setup with OTGC Android

Clarke Stevens
 

Fernando,

There is a current problem with OTGC (based on IoTivity-classic) that prevents it from working with servers based on IoTivity-lite.

If you build a server with IoTivity-classic. It should work fine. Also, when we release the new version of OTGC based on IoTivity-lite (probably towards the end of August), it should work fine with servers built on IoTivity-lite or IoTivity-classic.

Thanks,
-Clarke

On Jun 25, 2019, at 3:39 PM, Fernando Campaña via Lists.Iotivity.Org <fernando.campana=cti.espol.edu.ec@...> wrote:

Hello developers,

Does anybody knows how to easy-setup a server with the Android OTGC? Any specific branch or commit for iotivity? and OTGC android? Any specific code?

I have been trying with branch 1.3-rel (iotivity):
  • mediator: otgc-android (master branch, before migration to iotivity-lite)
  • enrollee: ./enrollee in service/easy-setup/sampleapp/enrollee/linux
But I don't get it to work, I got INVALID_QUERY in OTGC logs.

I have also been trying with branch 1.3-rel (iotivity):
  • mediator:  ./mediator in service/easy-setup/sampleapp/mediator/linux/richsdk_sample
  • enrollee: ./enrollee in service/easy-setup/sampleapp/enrollee/linux
But I got provisionSecurity is Failed.

Regards


Easy Setup with OTGC Android

Fernando Campaña
 

Hello developers,

Does anybody knows how to easy-setup a server with the Android OTGC? Any specific branch or commit for iotivity? and OTGC android? Any specific code?

I have been trying with branch 1.3-rel (iotivity):
  • mediator: otgc-android (master branch, before migration to iotivity-lite)
  • enrollee: ./enrollee in service/easy-setup/sampleapp/enrollee/linux
But I don't get it to work, I got INVALID_QUERY in OTGC logs.

I have also been trying with branch 1.3-rel (iotivity):
  • mediator:  ./mediator in service/easy-setup/sampleapp/mediator/linux/richsdk_sample
  • enrollee: ./enrollee in service/easy-setup/sampleapp/enrollee/linux
But I got provisionSecurity is Failed.

Regards


Re: How to build iotiviyt-constrained swig

Rick Bell
 

Yes – That is deprecated…

This is the working link - https://github.com/iotivity/iotivity-lite/tree/swig

 

Thanks,

-Rick Bell

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of yonggu ha
Sent: Tuesday, June 18, 2019 4:31 AM
To: iotivity-dev@...
Subject: [dev] How to build iotiviyt-constrained swig

 

Is there anybody iotivity-constrained swig sucees, To build for android.
https://github.com/iotivity/iotivity-constrained/tree/swig

I just tried that.
But There are lot of build error.

like :

padapter.c:468:40: error: 'IFA_FLAGS' undeclared (first use in this function)

           } else if (attr->rta_type == IFA_FLAGS) {



I just wondering. It's git address source is right?


How to build iotiviyt-constrained swig

yonggu ha
 

Is there anybody iotivity-constrained swig sucees, To build for android.
https://github.com/iotivity/iotivity-constrained/tree/swig

I just tried that.
But There are lot of build error.

like :
padapter.c:468:40: error: 'IFA_FLAGS' undeclared (first use in this function)
           } else if (attr->rta_type == IFA_FLAGS) {


I just wondering. It's git address source is right?


OCF Essen draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Essen”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: Debug mode cause the issue .fill-up the logserver

Nathan Heldt-Sheller
 

Hi Suresh,

It would be great if you could update the job scripts to clear previous logs... we don't need more than one build of debug logs.

Thanks,
Nathan

On Jun 14, 2019, at 7:01 AM, Suresh Channamallu <schannamallu@...> wrote:

Hi Nathan,

I have seen the App build with Debug mode in the jenkins.  
i assume the job is not wiping the workspace. like debug folders /example folders . This will create problem to log server
The debug logs occupied most of the storage  hence we disable the job for time-being.
if this effect your work ,please let us know.

 The URL-below will direct you the jenkins


Debug mode cause the issue .fill-up the logserver

Suresh Channamallu <schannamallu@...>
 

Hi Nathan,

I have seen the App build with Debug mode in the jenkins.  
i assume the job is not wiping the workspace. like debug folders /example folders . This will create problem to log server
The debug logs occupied most of the storage  hence we disable the job for time-being.
if this effect your work ,please let us know.

 The URL-below will direct you the jenkins


Re: OCF Essen draft version 0.3 CRs for IoTivity review

George Nash
 

Question regarding CR 1970 – Semantic Tags

 

The Relative Position Semantic Tag “tag-pos-rel”

 

Table CC states the contents of the tag is:

<quote>

 

Three element array of

numbers defining the position

relative to a known [0,0,0]

point within the context of an

abstract box [-1,-1,-1],[1,1,1]

 

</quote>

 

Then it gives an example “tag-pos-rel”: [0.5,0.5,0.5]

 

Is the position bound by the abstract box or can it exceed the [1,1,1] unit measurement?

 

It is unclear according to the text if “tag-pos-rel”: [2.0,2.0,0.0]  is a valid position. (i.e. two units away from the [0.0,0.0,0.0] position in x,y )

 

In Table CC shouldn’t [0,0,0]  be [0.0,0.0,0.0] and [-1,-1,-1],[1,1,1]  be [-1.0,-1.0,-1.0],[1.0,1.0,1.0] respectively, since the array will an array of floats?

 

 

George Nash

 

From: iotivity-dev@... [mailto:iotivity-dev@...] On Behalf Of OCF Staff
Sent: Friday, June 7, 2019 12:35 PM
To: iotivity-dev@...
Cc: OCF Staff <staff@...>
Subject: [dev] OCF Essen draft version 0.3 CRs for IoTivity review

 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Essen”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Essen draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Essen”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Essen draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Essen”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Upgrade to Gerrit on Tuesday 21st 9 AM EDT

Suresh Channamallu <schannamallu@...>
 

Hi All


We'll be upgrading Gerrit at Tuesday 21st 9 AM EDT (14:00 UTC) to new stable version released.

Downtime should be 2 hour.

Notices will be sent out prior to and after the upgrade.

If you think this update needs to be postponed or have any comments or questions, please send an email to helpdesk@.... 

Thanks,
Suresh.-- 
Thanks & Regards,
Suresh.channamallu


OCF Essen draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Essen”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...