Date   

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?


Re: Iotivity Client

elizabethnathaniaw93@...
 

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?


Re: Iotivity Client

George Nash
 

Elizabeth,

 

As Clark said the client server will not communicate unless they have been onboarded.  This can be done using the OTGC tool developed by OCF. Sorry I don’t know the link to the tool.  Or you can use the onboarding_tool that is part of iotivity-lite.  The onboarding_tool is a used by the development team to test and verify the onboarding and provisioning features. It is not the most user friendly.  The README.rst document has a set-by-setp guide for using the onboarding tool to onboard and provision a server and client. (search for the “Simple Step-by-Step guide for onboarding and provisioning” section) The steps in that document is what I use almost every day when testing servers and clients.

 

George

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of Clarke Stevens
Sent: Sunday, February 23, 2020 10:54 PM
To: elizabethnathaniaw93@...
Cc: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client

 

Elizabeth,

 

Yes, you will need to onboard the server before the client and server will communicate. You probably know more than I do about the update specification. I haven’t built an example with it yet. Wouter is the expert on the update specification. Kishen is the expert on simpleserver and simpleclient, but I think George has also built those many times.

 

Thanks,

-Clarke



On Feb 23, 2020, at 10:43 PM, elizabethnathaniaw93@... wrote:

 

Hi George and Clarke,
Thanks for the response!
Also thanks to Clarke, Yes, I've tried your examples to build an iotivity server as you gave me that before. I've built Iotivity server on my Raspberry Pi with enviro phat as the sensor.

Now, I'm looking for a client example for communicate with smart_home_server_with_mock_swupdate, because my research is try to implement OCF firmware update protocol. I've read both smart_home_server_with_mock_swupdate code and OCF FU protocol documentation (OCF 2.0.3 core and security specifications), it needs a client to trigger the firmware update process (according to OCF FU protocol documentation). That's why I want to learn the other client and server example first before I can make the client for trigger the FU process.

I've tried the simpleclient and simpleserver, but they didn't communicate. In simpleclient code, the client should do observe then get the light state from simpleserver. But, it stopped after send and received coap messages.
Do I need to run onboarding_tool first and onboard the server and client before it can communicate each other (for example: client get the resource from the server)?

And for gcc, what version that compatible?

 


Re: Iotivity Client

Clarke Stevens
 

Elizabeth,

Yes, you will need to onboard the server before the client and server will communicate. You probably know more than I do about the update specification. I haven’t built an example with it yet. Wouter is the expert on the update specification. Kishen is the expert on simpleserver and simpleclient, but I think George has also built those many times.

Thanks,
-Clarke

On Feb 23, 2020, at 10:43 PM, elizabethnathaniaw93@... wrote:

Hi George and Clarke,
Thanks for the response!
Also thanks to Clarke, Yes, I've tried your examples to build an iotivity server as you gave me that before. I've built Iotivity server on my Raspberry Pi with enviro phat as the sensor.

Now, I'm looking for a client example for communicate with smart_home_server_with_mock_swupdate, because my research is try to implement OCF firmware update protocol. I've read both smart_home_server_with_mock_swupdate code and OCF FU protocol documentation (OCF 2.0.3 core and security specifications), it needs a client to trigger the firmware update process (according to OCF FU protocol documentation). That's why I want to learn the other client and server example first before I can make the client for trigger the FU process.

I've tried the simpleclient and simpleserver, but they didn't communicate. In simpleclient code, the client should do observe then get the light state from simpleserver. But, it stopped after send and received coap messages.
Do I need to run onboarding_tool first and onboard the server and client before it can communicate each other (for example: client get the resource from the server)?

And for gcc, what version that compatible?


Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi George and Clarke,
Thanks for the response!
Also thanks to Clarke, Yes, I've tried your examples to build an iotivity server as you gave me that before. I've built Iotivity server on my Raspberry Pi with enviro phat as the sensor.

Now, I'm looking for a client example for communicate with smart_home_server_with_mock_swupdate, because my research is try to implement OCF firmware update protocol. I've read both smart_home_server_with_mock_swupdate code and OCF FU protocol documentation (OCF 2.0.3 core and security specifications), it needs a client to trigger the firmware update process (according to OCF FU protocol documentation). That's why I want to learn the other client and server example first before I can make the client for trigger the FU process.

I've tried the simpleclient and simpleserver, but they didn't communicate. In simpleclient code, the client should do observe then get the light state from simpleserver. But, it stopped after send and received coap messages.
Do I need to run onboarding_tool first and onboard the server and client before it can communicate each other (for example: client get the resource from the server)?

And for gcc, what version that compatible?


Re: Iotivity Client

Clarke Stevens
 

George,

I think she’s looking to build a server. Besides the example George mentions that is distributed in the IoTivity-lite repo, There are many samples available. There are several for Raspberry Pi with various Pimoroni cards. There are Linux examples for a dimmable light using GTK to implement a GUI. I also just put one up to implement (unfortunately without any GUI). I’ve listed the repos below and included a deck that shows how to build them from a JSON input file. You can use DeviceBuilder to automatically build a working C file in about 30 seconds. I’m working on updating all the documentation, but I’m not through yet.

Also, as George knows, the OTGC you downloaded is an excellent and up-to-date client. It sounds like you may already have that working.  So here are a bunch of links you can try.


For the following examples, you will the the ProjectScripts in this repo:


There is a bug, so you may need to run it twice. I’ve tried for a long time to debug this, but so far unsuccessfully. Then, you need to follow the instructions in this PowerPoint:


Here are the examples:

Also, you may have found these already, but these are the two up-to-date versions of the OTGC client. These are in IoTivity-lite (i.e. C):

I apologize if any of this is not accurate. I’m hoping to have it all cleaned up by mid March, but I’m happy to help you if you get stuck.

Thanks,
-Clarke



On Feb 19, 2020, at 1:17 PM, George Nash <george.nash@...> wrote:

Are you looking for example code of a client or a server?
 
If you are looking for a sample server the smart_home_server_linux sample is the most up to date and complete sample for the server. Unfortunately we don’t have a client sample to interact with this server it is typically exercised by the certification and testing tool (CTT).
 
If you are looking for sample clients I would suggest checking out the temp_sensor_client_linux
 
 
The simpleclient will talk to the simpleserver sample.  However these samples are not using standardized resources for that reason I typically don’t recommend them as a samples but they are some of the few samples that we have both a client and server that talk with each other.
 
Hope this helps.
 
George
 
From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of elizabethnathaniaw93@...
Sent: Wednesday, February 19, 2020 8:29 AM
To: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] Iotivity Client
 
Hi Clarke,
Thanks. I've downloaded the OTGC Linux.
Also, is there any example in C for the client?
In iotivity-lite source in github, there are several examples of the client in C, but I couldn't found an example when it runs get or post function (e.g. turn on/off the light, get light state) from the client that is written in C file.



Re: Iotivity Client

George Nash
 

Are you looking for example code of a client or a server?

 

If you are looking for a sample server the smart_home_server_linux sample is the most up to date and complete sample for the server. Unfortunately we don’t have a client sample to interact with this server it is typically exercised by the certification and testing tool (CTT).

 

If you are looking for sample clients I would suggest checking out the temp_sensor_client_linux

 

 

The simpleclient will talk to the simpleserver sample.  However these samples are not using standardized resources for that reason I typically don’t recommend them as a samples but they are some of the few samples that we have both a client and server that talk with each other.

 

Hope this helps.

 

George

 

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

 

Hi Clarke,
Thanks. I've downloaded the OTGC Linux.
Also, is there any example in C for the client?
In iotivity-lite source in github, there are several examples of the client in C, but I couldn't found an example when it runs get or post function (e.g. turn on/off the light, get light state) from the client that is written in C file.


Re: Iotivity Client

elizabethnathaniaw93@...
 

Hi Clarke,
Thanks. I've downloaded the OTGC Linux.
Also, is there any example in C for the client?
In iotivity-lite source in github, there are several examples of the client in C, but I couldn't found an example when it runs get or post function (e.g. turn on/off the light, get light state) from the client that is written in C file.


OCF Cloud #bundled

Jozef Kralik
 

Hi guys

We would like to announce brand new OCF Native Cloud (https://github.com/go-ocf under Apache 2.0 license) which was developed from the scratch in golang.
 
For testing purposes, feel free to use a prepared docker cloud image - OCF Cloud #bundled (https://github.com/go-ocf/cloud), which makes the testing deployment easy and straightforward. It allows you to onboard both secure and unsecure devices.

In the upcoming releases, we plan to extend this bundled version with following features:
Contributions are warmly welcomed!


Stay tuned
Go-OCF contributors


Re: Iotivity 2.0.5 - SWupdate API

elizabethnathaniaw93@...
 

Hi guys,
I really need to implement the firmware update resource through Iotivity for my research. The due date is end of this month. If anyone knows, please help.
So, I've read the example here https://github.com/iotivity/iotivity-lite/blob/master/apps/smart_home_server_with_mock_swupdate.cpp. Then, I copied the code from that example that related to swupdate resources to my main code. My main code is from https://github.com/openconnectivity/Sample-Raspberry-Pi-Code/blob/master/IoTivity-lite/enviro-phat/enviro-phat.c. After that, I run OTGC on Android and successfully onboarding the device. But, I don't know how to trigger the software update resource? Also how to set the URL for download the firmware update?
Thank you.


Re: OCF Native Cloud for IoT gateway?

Ondrej Tomcik
 

Hello guys,

Elizabeth, question is what you want to achieve with your IoT Gateway. The fact is that the OCF Native Cloud - https://github.com/go-ocf/ should be able to run on the Raspi so you can have kind of a home-cloud instance. But I am not sure if this is what you really want.

 

So please describe more what you’re trying to achieve, so we can point you to the right direction.

 

Best,

Ondrej Tomcik :: KISTLER :: measure, analyze, innovate

 


 

 

Confidentiality Notice: This e-mail is privileged and confidential and for the use of the addressee only. Should you have received this e-mail in error please notify us by replying directly to the sender or by sending a message to info@.... Unauthorised dissemination, disclosure or copying of the contents of this e-mail, or any similar action, is prohibited.

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of Harishkm via Groups.Io
Sent: piatok, 7. februára 2020 7:33
To: elizabethnathaniaw93@...; iotivity-dev@iotivity.groups.io
Cc: iotivity-dev@iotivity.groups.io
Subject: Re: [dev] OCF Native Cloud for IoT gateway?

 

Hi,

 

AFAIK OCF native cloud was implementation for cloud only where both client and server communicates to each other through cloud securely. I am not sure how it can play a role of gateway. Probably Ondrej can shed more light on this.

 

 

Regards,

Harish Kumara M

 

 

 

--------- Original Message ---------

Sender : elizabethnathaniaw93@... <elizabethnathaniaw93@...>

Date : 2020-02-06 23:01 (GMT+5:30)

Title : [dev] OCF Native Cloud for IoT gateway?

 

Hello.
I want to make my Raspberry Pi as an IoT gateway. So, in my case: the Iotivity client will send a request to this gateway instead of direct to the Iotivity server, vice versa.
Then I found about OCF Native Cloud. Regarding this documentation https://wiki.iotivity.org/doku.php?id=coapnativecloud and this https://openconnectivity.org/specs/OCF_2.1.0_Specification_Overview.pdf (page 60-76), this cloud can act as a gateway? So can I make my Raspberry Pi as an IoT gateway with this API/function? Please correct me if I misunderstood the concept.
And I found the implementation in Iotivity API for the cloud on Iotivity GitHub (https://github.com/iotivity/iotivity). But can't find in Iotivity lite 2.0.5. Is it because not applied yet or remove it to make it lightweight for a constrained device?
Thanks.


Re: OCF Native Cloud for IoT gateway?

Clarke Stevens
 

We have gateway specifications for ZigBee, Z-Wave, BlueTooth, Haier/U+, AllJoyn, oneM2M and EnOcean. I’m thinking any of those specifications might be good reference (or maybe even directly applicable depending on what is on the other side of the gateway).

-Clarke

On Feb 6, 2020, at 11:33 PM, Harishkm via Groups.Io <h.marappa@...> wrote:


Hi,

 

AFAIK OCF native cloud was implementation for cloud only where both client and server communicates to each other through cloud securely. I am not sure how it can play a role of gateway. Probably Ondrej can shed more light on this.

 
 

Regards,

Harish Kumara M

 

 
 

--------- Original Message ---------

Sender : elizabethnathaniaw93@... <elizabethnathaniaw93@...>

Date : 2020-02-06 23:01 (GMT+5:30)

Title : [dev] OCF Native Cloud for IoT gateway?

 
Hello.
I want to make my Raspberry Pi as an IoT gateway. So, in my case: the Iotivity client will send a request to this gateway instead of direct to the Iotivity server, vice versa.
Then I found about OCF Native Cloud. Regarding this documentation https://wiki.iotivity.org/doku.php?id=coapnativecloud and this https://openconnectivity.org/specs/OCF_2.1.0_Specification_Overview.pdf (page 60-76), this cloud can act as a gateway? So can I make my Raspberry Pi as an IoT gateway with this API/function? Please correct me if I misunderstood the concept.
And I found the implementation in Iotivity API for the cloud on Iotivity GitHub (https://github.com/iotivity/iotivity). But can't find in Iotivity lite 2.0.5. Is it because not applied yet or remove it to make it lightweight for a constrained device?
Thanks. 

<201602111742151_N3WZA6X7.png>



Re: OCF Native Cloud for IoT gateway?

Harishkm
 

Hi,

 

AFAIK OCF native cloud was implementation for cloud only where both client and server communicates to each other through cloud securely. I am not sure how it can play a role of gateway. Probably Ondrej can shed more light on this.

 

 

Regards,

Harish Kumara M

 

 

 

--------- Original Message ---------

Sender : elizabethnathaniaw93@... <elizabethnathaniaw93@...>

Date : 2020-02-06 23:01 (GMT+5:30)

Title : [dev] OCF Native Cloud for IoT gateway?

 

Hello.
I want to make my Raspberry Pi as an IoT gateway. So, in my case: the Iotivity client will send a request to this gateway instead of direct to the Iotivity server, vice versa.
Then I found about OCF Native Cloud. Regarding this documentation https://wiki.iotivity.org/doku.php?id=coapnativecloud and this https://openconnectivity.org/specs/OCF_2.1.0_Specification_Overview.pdf (page 60-76), this cloud can act as a gateway? So can I make my Raspberry Pi as an IoT gateway with this API/function? Please correct me if I misunderstood the concept.
And I found the implementation in Iotivity API for the cloud on Iotivity GitHub (https://github.com/iotivity/iotivity). But can't find in Iotivity lite 2.0.5. Is it because not applied yet or remove it to make it lightweight for a constrained device?
Thanks.


OCF Native Cloud for IoT gateway?

elizabethnathaniaw93@...
 

Hello.
I want to make my Raspberry Pi as an IoT gateway. So, in my case: the Iotivity client will send a request to this gateway instead of direct to the Iotivity server, vice versa.
Then I found about OCF Native Cloud. Regarding this documentation https://wiki.iotivity.org/doku.php?id=coapnativecloud and this https://openconnectivity.org/specs/OCF_2.1.0_Specification_Overview.pdf (page 60-76), this cloud can act as a gateway? So can I make my Raspberry Pi as an IoT gateway with this API/function? Please correct me if I misunderstood the concept.
And I found the implementation in Iotivity API for the cloud on Iotivity GitHub (https://github.com/iotivity/iotivity). But can't find in Iotivity lite 2.0.5. Is it because not applied yet or remove it to make it lightweight for a constrained device?
Thanks.


Re: Alljoyn iOS SDK

Clarke Stevens
 

Maxence,

I believe you are in the right place for your question. I was waiting for someone to step in who is more qualified than me, but I didn’t want you to think you are being ignored.

We have experts who know the status of AllJoyn. I am not that expert. However, we do have an AllJoyn bridging specification. I believe the basic migration plan is that somebody will build a bridge device if they see a market for one. The alternative may be using the specification to see how AllJoyn maps to OCF and look at converting to a native OCF implementation. Hopefully, others who are better qualified to speak on behalf of AllJoyn can step in and comment.

Thanks,
-Clarke

On Jan 29, 2020, at 8:28 AM, Maxence CORNU <maxence.cornu@...> wrote:

Hello, 

I don't know if it's the right mail address for a technical question but let's try 🙂 .
I integrated allJoyn iOS SDK in a project in 2017, it worked fine, but now as allJoyn was merged in OCF, the SDK is no longer maintained and as I can't activate the bitcode iOS feature with, it will soon be a problem. So I'm seeking a kind of "migration guide" of the SDK to the OCF version.
Have you got any information about that ?

Best regards

Maxence CORNU
Leader IT - Enki


Ce message et toutes les pieces jointes sont etablis a l'attention exclusive de leurs destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. L'internet ne permettant pas d'assurer l'integrite de ce message, le contenu de ce message ne represente en aucun cas un engagement de la part de Leroy Merlin.

 



Alljoyn iOS SDK

Maxence CORNU <maxence.cornu@...>
 

Hello, 

I don't know if it's the right mail address for a technical question but let's try 🙂 .
I integrated allJoyn iOS SDK in a project in 2017, it worked fine, but now as allJoyn was merged in OCF, the SDK is no longer maintained and as I can't activate the bitcode iOS feature with, it will soon be a problem. So I'm seeking a kind of "migration guide" of the SDK to the OCF version.
Have you got any information about that ?

Best regards

Maxence CORNU
Leader IT - Enki


Ce message et toutes les pieces jointes sont etablis a l'attention exclusive de leurs destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. L'internet ne permettant pas d'assurer l'integrite de ce message, le contenu de ce message ne represente en aucun cas un engagement de la part de Leroy Merlin.

 


Iotivity 2.0.5 - SWupdate API

elizabethnathaniaw93@...
 

Hi,
I've read the OCF specification and there is a resource called SWupdate for doing the firmware update process and I want to implement that function since it's available in Iotivity 2.0.5. Is there any example of how to use that new API? Either in a raspberry pi or Arduino?
Thanks.


Re: EnOcean OCF CES Demo

하용구 <ygha@...>
 

Hello Everyone.

I'm not sure yet.

I think I found the cause.


When I get in touch with the BSC developer tonight, I think It'll be confirmed.

I'll let you know, when the results come out.


Thank you.



----- 원본 메시지 -----

제목: Re: EnOcean OCF CES Demo

발신: "Prof. Dr.-Ing. Diethelm Bienhaus" <diethelm.bienhaus@...> (2020-01-03 오전 04:07)

수신: "하용구" <ygha@...>

참조: Maloor Kishen kishen.maloor@...,ralshafi ralshafi@...,iotivity-dev@... iotivity-dev@...,하용구 ygha@...,Thorsten Elle t.elle@...,Jörg Hofmann j.hofmann@...,john.park john.park@...,Agis Ed Ed.Agis@...,Sören Fink soeren.fink@...


Hello 하용구,



now we run out of time. Until now no answer came from OCF.


Soeren has been working the Christmas Evening, Silveseter and New Years day with you and no functional result so far.

Today his grandma died. He is out of the game for the next days.




If at CES Demo no connection between EnOcean sensors and your apps could be shown this would be catastrophic.


Hence here a fall back solution based on MQTT so we can be sure it works:


We will have a mosquitto MQTT broker running on the gateway.

For testing we can use the


test.mosquitto.org


broker with port:


1883



I defined the following topic structure:


ces2020enocean


as the root topic


followed by the sensor, e.g.:


ces2020enocean/singleContact


Message payload is in that case "on" / "off". In case of temperature and humidity it is of type float (string with '.' as separator)



Definitions:


hostname:               // e.g. test.mosquitto.org
port:                   // e.g. 1883
topicBase:              // e.g. ces2020enocean
topicSingleContact:     // singleContact, valuetype: on/off
topicTemperature:       // temperature, valuetype: float
topicHumidity:          // humidity, valuetype: float
topicSmokeAlarm:        // smokeAlarm, valuetype: on/off
topicLiquidDetection:   // liquidDetection, valuetype: on/off



We read the configuration from a XML file. So we are flexible if you have other suggestions.



So from my point of view the last remaining way to make the scenario work is that you add in your app a subscription to those topics. We could use 

test.mosquitto.org

It would be better if we run a MQTT broker on our gateway and you connect to it. It is in the config file - so switching is easy.


You can test your apps very easy e.g. using MQTTlens (a Chrome Browser add-on)




For Android there are several easy to use libraries and  tutorials available (if you are not familiar with MQTT), e.g.:

https://github.com/eclipse/paho.mqtt.android


lots of tutorials e.g.


https://android.jlelse.eu/about-the-mqtt-protocol-for-iot-on-android-efb4973577b

https://wildanmsyah.wordpress.com/2017/05/11/mqtt-android-client-tutorial/ (source code downloadable)



Best regards,

Diethelm




Am 02.01.2020 um 13:28 schrieb Prof. Dr.-Ing. Diethelm Bienhaus:
Dear Kishen, dear Rami, dear IoTivity developers,



there are still problems with the EnOcean -> Commax/LG demo.


We have implemented a variety of variants - but there are still problems. Yg Ha has sent protocols etc. (Email -> Kishen).


Joerg from BSC is flying to Las Vegas tomorrow morning. We only have today 4 hours left to solve the problems.



We have melted all down to a minimal solution for Commax:


- the EnOcean single contact is represented by a single application with one device (oic.d.sensor) with only one resource (oic.r.sensor.contact)

- the EnOcean temperature / humidity sensor is represented by a single application with one device (oic.d.sensor) with two resources (oic.r.humidity and oic.r.temperature)

In addition to these minimal versions, we have also implemented the suggested multi device server and tested it without success.



Another question regarding "reset" from Soeren, who is developing the IoTivity lite part of the gateway:


What is the right way to reset an IoTivity Lite device to RFOTM state? Is it correct and sufficient to call the method oc_reset_device(size_t device)? If this method is used, the device is then displayed in DeviceSpy without a name. Is this behavior correct?




So: PLEASE support us especially Yg Ha in order to make the CES demo a success.



Best regards,


Diethelm Bienhaus and Joerg Hofmann







Am 31.12.2019 um 16:45 schrieb 하용구:

Kishen.


I'll explain it in more detail.
Bsc had used two single device servers in China, not module type.

So, strangely enough, I was able to test a single device without security.

Now, it was done before you gave a patch to devicespy,
It is currently being tested with two single device servers(with security) modified .


Thank you.


BR.

YG HA.

----- 원본 메시지 -----

제목: Re: Re: EnOcean OCF for CES

발신: 하용구 수석연구원/부설연구소 선행개발팀(2020-01-01 오전 12:30)

수신: Maloor Kishen<kishen.maloor@...>

참조: d.bienhausd.bienhaus@...,Thorsten Ellet.elle@...,Jörg Hofmann j.hofmann@...,john.park john.park@...,Agis EdEd.Agis@...,ralshafi ralshafi@...,Sören Fink soeren.fink@...



Hello Kishen.

I think you need an explanation.

I used to think that the version that Bsc used in China was a module type multi server.

The version did not work with my client in China.

So, after the Chinese mvite, I recommended that Bsc use multi device type instead of module method.

However, As you know the multi-device server at Bsc was not on-boarded to devicespy.

So, I thought it strange, so I asked Bsc for a version without security. However, the unsecured version did not work either.

So, I made myself a server sample application for Bsc using a sample from the iotivity-lite and delivered it to Bsc, and they used it to send me a new version.

Now, a server without security works with my client.

It is currently being tested with security.

I think it will be solved by tomorrow.

There is some issue in secure version(in build option), it is currently being modified to receive a new version.

I am going to test again tomorrow. It is 1 a.m. in Korea.

There is a time difference between Korea and Germany, which lacks development time.


If there is a problem tomorrow, I will ask you for help.


and


In mvite #1,2,3 participating member companies used devicespy.

 

we will use devicespy in ces ocf promotion.

 


BR.

YG HA.


----- 원본 메시지 -----

제목: Re: EnOcean OCF for CES

발신: "Maloor, Kishen" <kishen.maloor@...> (2019-12-31 오후 10:56)

수신: "하용구" <ygha@...>

참조: d.bienhaus d.bienhaus@...,Thorsten Elle t.elle@...,Jörg Hofmann j.hofmann@...,john.park john.park@...,Agis, Ed Ed.Agis@...,ralshafi ralshafi@...,Sören Fink soeren.fink@...


Hi YG HA,

 

The fix that I sent you fully addresses the specific onboarding/provisioning issue of Lite multi device servers

with DeviceSpy which you reported. At this point, I believe that things should work for you.

 

What other issues are you seeing? Could you describe?

 

I suspect that DeviceSpy might be making assumptions that also causes things to fail. Have you tried using OTGC for all your onboarding/provisioning

needs during the demos? That should more likely work.

 

If on the other hand your Classic Client itself isn't handling things correctly, then that’s a completely separate matter which should probably engage

IoTivity Classic folks. You could post those queries to the mailing list.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: 하용구 <ygha@...>
Date: Tuesday, December 31, 2019 at 11:14 AM
To: "Maloor, Kishen" <kishen.maloor@...>
Cc: "d.bienhaus" <d.bienhaus@...>, Thorsten Elle <t.elle@...>, Jörg Hofmann <j.hofmann@...>, "john.park" <john.park@...>, "Agis, Ed" <Ed.Agis@...>, ralshafi <ralshafi@...>, Sören Fink <soeren.fink@...>
Subject: Re: Re: EnOcean OCF for CES

 

Hi, Kishen.

As a result of the test so far today, there are other problems besides on-boarding.

I took a none-secure version from BCC yesterday and tested it.
But that doesn't work, either.

I am currently using the 1.3 / 2.0 Classic client.

To date, the results are as follows.
1. bsc iotivity-lite single device server (X)
2. bsc iotivity-lite multi-device server (X)



But, you know, I have a server that passes through a ctt made of iotivity-lite. My classic client is functioning well with the lite server.
So, I made myself an oic.d.sensor (oic.r.sensor.contact) of the bsc and tested it.

The result was all right.

I just delivered the sample I made to Bsc.
I don't have a choice anymore.

 

Attached file is sample source that I delivered to bsc today.

 

Thanks.

 

BR.

YG HA.

 

----- 원본 메시지 -----

제목: Re: EnOcean OCF for CES

발신: "Maloor, Kishen" <kishen.maloor@...> (2019-12-31 오후 01:58)

수신: "하용구" <ygha@...>, "d.bienhaus" <d.bienhaus@...>

참조: Thorsten Elle t.elle@...,Jörg Hofmann j.hofmann@...,john.park@... john.park@...,Agis, Ed Ed.Agis@...,ralshafi@... ralshafi@...,Sören Fink soeren.fink@...

 

Hi YG HA,

 

Sorry, I've been out on holiday and just catching up with my e-mails.

Regarding the specific issue of provisioning multi device servers with DeviceSpy,

I think I've located the problem.

 

Attached is a simple patch that must be applied to the multi device server source

tree following which you perform a full clean and rebuild. The different logical

devices should then be available to be onboarded/provisioned separately by DeviceSpy,

i.e. it should solve the problems you've been seeing.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: 하용구 <ygha@...>
Date: Monday, December 23, 2019 at 6:56 AM
To: "d.bienhaus" <d.bienhaus@...>
Cc: Thorsten Elle <t.elle@...>, Jörg Hofmann <j.hofmann@...>, "john.park@..." <john.park@...>, "Agis, Ed" <Ed.Agis@...>, "ralshafi@..." <ralshafi@...>, "Maloor, Kishen" <kishen.maloor@...>, Sören Fink <soeren.fink@...>
Subject: Rs: Re: Re: WG: Re: Re: EnOcean OCF for CES

 

Hello.

 

The problems I have identified so far are as follows.

1. I see several sensor devices in DeviceSpy. However, only one device is onboarded, and all the others have no secure connection.

2. If DeviceSpy has one device on board, for example, a smoke sensor, it seems to have used your device type as oic.d.sensor,
In other words, there is a comma at the end of the string.

You must remove : , (comma).

Please check with DeviceSpy and device type.

 

Thank you.

 

BR.

YG HA.

----- 원본 메시지 -----

제목: Re: Re: WG: Re: Re: EnOcean OCF for CES

발신: 하용구 수석연구원/부설연구소 선행개발팀(2019-12-23 오전 09:45)

수신: d.bienhaus<d.bienhaus@...>

참조: 하용구ygha@...,Thorsten Ellet.elle@...,Jörg Hofmannj.hofmann@...,john.park@...,Ed.Agis@...,ralshafi@...,kishen.maloor@...,Sören Finksoeren.fink@...

 

Hello BSC.

 

I want to ask one.

 

In the ces, I will DeviceSpy for onboarding.

 

Please check connection between DeviceSpy(latest version 1.2.4) and your device.

 

and reply to me.

 

Thank you.

----- 원본 메시지 -----

제목: Re: WG: Re: Re: EnOcean OCF for CES

발신: "d.bienhaus@..." <d.bienhaus@...> (2019-12-23 오전 04:19)

수신: "하용구" <ygha@...>

참조: Thorsten Elle t.elle@...,Jörg Hofmann j.hofmann@...,john.park@...,Ed.Agis@...,ralshafi@...,kishen.maloor@...,Sören Fink soeren.fink@...

 

Hello 하용구,

 

 

Jörg will bring 12 different sensors in order to show a set of available hardware.

 

 

For the CES show case we will only activate two of them:

 

Single Input Contact

oic.d.sensor

oic.r.sensor.contact

 

and

 

 

Temperature and Humidity Sensor

oic.d.sensor

oic.r.humidity and oic.r.temperature

 

 

Thorsten and Soeren built an EnOcean emulator that only provides these two sensors.

You can download the image containing it here: https://cld.bitstack.de/f/e640209252f84d87a859/?dl=1


 

Best regards,

 

Diethelm

 

 

 

 

 

 

 

 

Am 21.12.2019 um 12:09 schrieb 하용구:

Hello Jorg Hofmann.

 

Will you bring the all sensor device(12 items)?

 

Do you want to connect all sensor device(12 items) to scenario network2 at ces demo?

 

You said in Guangzhou, China, that only a few sensor devices are connected for the scenario.

Is this decision still valid?

in my mind

1. Temperature/humidity sensor
2. Smoke sensor
3. illumination sensor
4. Water sensor
5. ftke sensor
6. Rocker switch, 2 rockcer

I think this is appropriate.
What do you think?

 

If you agree, other sensor devices should not be connected to the gateway at the ces event.

 

It is now Saturday night in Korea.

I will go to work next Monday, test the connection between your sw emulator and commax client,

and share the results.

 

Thank you.

 

BR.

YG HA.

----- 원본 메시지 -----

제목: Re: WG: Re: Re: EnOcean OCF for CES

발신: "Thorsten Elle" <t.elle@...> (2019-12-21 오후 07:32)

수신: ygha@...

참조: Jörg Hofmann j.hofmann@...,d.bienhaus@...,john.park@...,Ed.Agis@...,ralshafi@...,kishen.maloor@...

 

Hello 하용구,

the rocker-switch uses internally always the same module. You see this module in the center from the image with the disassembled switch. The other devices on the images use the same module. All with 2 Button’s (internally) and the same EEP (f6-2-1) in the „EnOcean-world“. So they emit the same datagram. Now it is up to you (the person who administrates the users setup) to configure this especially switch – with it’s own (EnOcean-)ID – to the users needs. For example a rocker-switch, with the red button, hanging around the users neck, which is used to initiate an emergency-call if the user pushes the button. For this case the software in beyond this use-case has to know the it is the “Rocker Button B” within the datagram it has to look for.

(The images are added below.)

with kind regards
Thorsten

 

Am 21.12.2019 um 10:33 schrieb Jörg Hofmann:

Hallo Thorsten,
 
kannst Du es ihm erklären?
 
Gruß,
Jörg
 
Von: 하용구 [mailto:ygha@...]
Gesendet: Samstag, 21. Dezember 2019 02:29
An: Diethelm Bienhaus <d.bienhaus@...>; Jörg Hofmann <j.hofmann@...>
Cc: john.park@...; Ed.Agis@...; Rami Alshafi <ralshafi@...>; Maloor Kishen <kishen.maloor@...>
Betreff: Rs: Re: Re: EnOcean OCF for CES
 
 
Hello.
 
Specially I don't understand about Rocker switch.
 
 
 
Please check this and the last email.
 
 
 
I have to create a new ux/ui for your servers.
 
I need a clear definition of your device and resources.
 
 
 
Thank you.
 
 
 
[]
 
 
 
 
----- 원본 메시지 -----
 
제목: Re: Re: EnOcean OCF for CES
 
발신: 하용구 수석연구원/부설연구소 선행개발팀(2019-12-21 오전 10:17)
 
수신: d.bienhaus<d.bienhaus@...<mailto:d.bienhaus@...>>, Jörg Hofmann<j.hofmann@...<mailto:j.hofmann@...>>
 
참조: john.park@...,Ed.Agis@...,Rami<mailto:john.park@...,Ed.Agis@...,Rami> Alshafiralshafi@...,Maloor<mailto:Alshafiralshafi@...,Maloor> Kishenkishen.maloor@...<mailto:Kishenkishen.maloor@...>
 
 
Hello.
 
I received the sw emulator yesterday.
But I can't test it because it's a holiday here.
I'll test it next Monday and let you know the results.
 
However, after running the emulator, there are all sensors shown in China.
 
You have to decide. Are you going to show all these sensors to the event?
 
1. Duplicate temperature and temperature/humidity sensors.
 
- will you bring two device to ces show?
 
- each resource has sensor interface(not actuator)
 
2. The occupation sensor is not suitable for show in the showroom. This was what you said in China.
 
- do you want this device show on the client?
 
- you need to decide?
 
3. Light sensor has an illumination resource. Are you going to bring lightbulb with you to the event?
How will you show changes to the illuminance value?
 
 
 
4. There are two rocker switches. What is this device doing?
 
- How many oic.r.button resources do you have on each device?
* Button resource has Boolean value
 
- What does each action mean?
- How do you want it to appear in the ui of the client?
 
 
 
- will you bring two rocker switch device?
 
 
 
Thank you.
 
BR.
 
YG HA
 
 
----- 원본 메시지 -----
 
제목: Re: EnOcean OCF for CES
 
발신: "d.bienhaus@...<mailto:d.bienhaus@...>" <d.bienhaus@...<mailto:d.bienhaus@...>> (2019-12-20 오후 11:19)
 
수신: "하용구" <ygha@...<mailto:ygha@...>>
 
참조: john.park@...,Ed.Agis@...,Rami<mailto:john.park@...,Ed.Agis@...,Rami> Alshafi ralshafi@...,Maloor<mailto:ralshafi@...,Maloor> Kishen kishen.maloor@...,Jörg<mailto:kishen.maloor@...,Jörg> Hofmann j.hofmann@...<mailto:j.hofmann@...>
 
 
Hello YG HA,
 
 
 
 
 
Am 20.12.2019 um 01:25 schrieb 하용구:
 
Hello EnOcean.
 
 
 
I'd like to ask you a few things in advance for a smooth ces demo.
 
1.
 
 
 
Please clarify the device name for each server.
For example, in Gwangjeongwoo, the device name of all devices is displayed this way, DX9034934893_SAD8I.
I recommend that your servers use device names such as Smoke, Contact, and Temperature.
 
The CTT shows that devices appear with a clear name.  (screen shot beneath)
 
You can download the image with the simulator tool:
 
Link:
 
https://cloud.bscgmbh.de/index.php/s/s2JBcwF2Qey3EnC
 
PWD: oCFCES2019
 
BR
Diethelm
 
 
 
[]
 
 
 
 
 
 
2.
 
 
 
I heard in Guangzhou that all devices will be registered when your sensors are near a gateway.
What I'm asking you is that some sensors overlap, or that have events too often, are not suitable for demonstration at a crowded exhibition.
This is what the BSC representative in Guangzhou agreed to.
In the current demosinario, the BSC sensors are used for demonstrations, such as temperature/humidity sensors and window sensors.
So, I want you to clarify which devices will appear on the network through the gateway.
 
 
 
Thank you.
 
 
 
BR.
 
YG HA.
 
----- 원본 메시지 -----
 
제목: EnOcean OCF for CES
 
발신: "d.bienhaus@..."<mailto:d.bienhaus@...> <d.bienhaus@...><mailto:d.bienhaus@...> (2019-12-18 오전 01:18)
 
수신: ygha@...<mailto:ygha@...>
 
참조: john.park@...,Ed.Agis@...,Rami<mailto:john.park@...,Ed.Agis@...,Rami> Alshafi ralshafi@...,Maloor<mailto:ralshafi@...,Maloor>, Kishen kishen.maloor@...,J<mailto:kishen.maloor@...,J>örg Hofmann j.hofmann@...<mailto:j.hofmann@...>
 
 
Dear all,
 
 
 
EnOcean is a well established standard in the domain of home automation. At CES 2018 we already demonstrated successfully how EnOcean sensors were integrated in the OCF based systems.
 
 
 
Where are we now?
 
 
 
The EnOcean OCF Bridging Specification has been submitted. The Bridging Task Group continues to work closely with us on the OCF-EnOcean Bridge adoption planned for the Gaborone release.
 
For the certification of OCF devices, servers and bridges the passing of the tests performed by means of the official Conformance Test Tool (CTT) is essential.
 
OCF supported us with an example code for multiple devices (thanks to George Nash). Haier used this code base for the implementation of a multi-device-server application. It was tested and integrated by COMMAX.
 
 
 
We now provide two variants of our gateway solution both based on the OCF sources:
 
a) multi-device-server application with EnOcean sensors as devices
 
b) bridge server with EnOcean sensors as virtual devices
 
 
 
b) is the the implementation conform to the Bridging Spec.
 
a) is a multi device server and compatible with the Haier implementation which is based on the same source.
 
 
 
The problem with b) is that the actual development support app does not support a bridge with resources exposed as virtual devices. Kishen will support us in January going on with the project (@Kishen: thanks in advance!).
 
 
 
In order to show a functional setting at CES the version a) is the most promising approach. Not to waste time a VirtualBox image file containing the gateway application and a GUI tool which simulates physical sensors will be available for download within the next two days. So companies like COMMAX can use this for their app development. At CES the physical sensors will be used and the gateway software behaves in the same way like the simulator variant used for development and testing.
 
 
 
We are sure you will agree that using variant a) is the appropriate solution for the CES.
 
 
 
Best regards,
 
 
 
Diethelm
 
 
 
 
 

 

 


-- 
---------------------------------------------------------- 
Prof. Dr.-Ing. Dipl.-Wirt. Ing. Diethelm Bienhaus

Fachgebiet Informatik mit Schwerpunkt Ingenieur-lnformatik
Fachbereich Mathematik, Naturwissenschaften und Informatik

Technische Hochschule Mittelhessen
Wiesenstr. 14 - D-35390 Gießen

-- 
---------------------------------------------------------- 
Prof. Dr.-Ing. Dipl.-Wirt. Ing. Diethelm Bienhaus

Fachgebiet Informatik mit Schwerpunkt Ingenieur-lnformatik
Fachbereich Mathematik, Naturwissenschaften und Informatik

Technische Hochschule Mittelhessen
Wiesenstr. 14 - D-35390 Gießen


Re: Iotivity Client

Clarke Stevens
 

Elizabeth,

Yes. That is why it was created. All the source code is available (I’ll have to look up the reference for you, but I think it is under the developer section on the OCF web site). You can take the source code and add any features you want for your particular use, knowing that it already works and passes certification with all security features, onboarding, etc.

OTGC is available in Linux and Android that is up to date. This year, I plan to make OTGC into a real open source project and plan to bring in the iOS and Windows versions (that are currently unmaintained). Hopefully, we will get volunteers to bring those versions up to date.

Thanks,
-Clarke

On Jan 6, 2020, at 5:57 PM, elizabethnathaniaw93@... wrote:

Thanks, Jeongjin and Clarke!
I've tried that example before. I'm wondering is it possible to customize OTGC? Because I try to create my user interface.