Date   

Re: Iotivity Client

elizabethnathaniaw93@...
 

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.


Re: Iotivity Client

Clarke Stevens
 

Elizabeth,

This presentation may help. In order to implement any arbitrary IoT device you only need to create the appropriate input file with OCF resources. You can see a few examples that work with Raspberry Pi and various Pi Hat boards under the Sample-Rapberry-Pi-Code directory. This presentation explains a little more about any arbitrary IoT device. If you are using a different OS or a microcontroller, you will need to compile for that platform, but essentially the same source code should work. I think you already built for a Due microcontroller, so you can see what the differences are there.

In either case, just create the input file and run DeviceBuilder then compile the code for the target platform.

Hopefully, that helps.

Thanks,
-Clarke



On Jan 2, 2020, at 4:24 AM, elizabethnathaniaw93@... wrote:

Hi,
I'm Elizabeth.
I've tried to implement Iotivity on Raspberry Pi 3 Model B + Enviro Phat. And I used OTGC for Linux as Iotivity Client.
Now, I want to build my own customize Iotivity client + interfaces. Is there any references to do that?
Thanks.


Re: Iotivity Client

김정진
 

Hi.

You can see the sample client app below apps directory. https://github.com/openconnectivity/IOTivity-Lite-setup /apps

Good luck.

2020년 1월 2일 (목) 오후 8:24, <elizabethnathaniaw93@...>님이 작성:

Hi,
I'm Elizabeth.
I've tried to implement Iotivity on Raspberry Pi 3 Model B + Enviro Phat. And I used OTGC for Linux as Iotivity Client.
Now, I want to build my own customize Iotivity client + interfaces. Is there any references to do that?
Thanks.



--

김정진 책임연구원 (Jeongjin Kim) Mobile. 010-4223-8152  j.jin@vinetech.com

㈜바인테크 Vinetech Co., Ltd. | IoT Platform Lab | New Technology BU (신기술사업부)

Dir Tel: 82-2-2182-8392  | Tel: 82-2-2182-8300 | Fax: 82-2-2182-8399

(05836) 서울시 송파구 법원로11길 7, C동 1207호 (문정동, 현대지식산업센터)

#1207~1210, 7, Beobwon-ro 11-gil, Songpa-gu, Seoul, 05836, Rep. of KOREA

 


Re: EnOcean OCF CES Demo

Prof. Dr.-Ing. Diethelm Bienhaus <diethelm.bienhaus@...>
 

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


EnOcean OCF CES Demo

Prof. Dr.-Ing. Diethelm Bienhaus <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


Iotivity Client

elizabethnathaniaw93@...
 

Hi,
I'm Elizabeth.
I've tried to implement Iotivity on Raspberry Pi 3 Model B + Enviro Phat. And I used OTGC for Linux as Iotivity Client.
Now, I want to build my own customize Iotivity client + interfaces. Is there any references to do that?
Thanks.


OCF draft CRs for IoTivity review

Open Connectivity Foundation
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs for Open Connectivity Foundation’s next Core specification release. These draft documents provide a current snapshot of the specification development and are subject to change. Additional CRs will follow upon approval from the relevant OCF WGs. 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: Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

Khaled Elsayed
 

Here is information about the new forum/working group


On Thu, Dec 19, 2019 at 10:38 AM Khaled Elsayed via Lists.Iotivity.Org <khaledieee=gmail.com@...> wrote:
Yes Clarke, I agree that OCF has this today but for some reason those big 3 have been trying to each get its own system to be the de-facto standard.
What I am sensing is that they will define some layers that can provide application level gateways between their systems without using a single standard. 

On Wed, Dec 18, 2019 at 11:17 PM Clarke Stevens <cstevens63@...> wrote:
OCF/IoTivity has virtually identical goals and already enables this. It would be nice if Amazon, Apple & Google would work with OCF rather than start from scratch.

-Clarke

On Dec 18, 2019, at 2:06 PM, Khaled Elsayed <khaledieee@...> wrote:

So, how many times have we heard this over the past 5 or 6 years from different consortium, forums or standardization bodies :-)?

“customers can be confident that their device of choice will work in their home and that they will be able to setup and control it with their preferred system,” the companies write


Best,

Khaled
 



Re: Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

Khaled Elsayed
 

Yes Clarke, I agree that OCF has this today but for some reason those big 3 have been trying to each get its own system to be the de-facto standard.
What I am sensing is that they will define some layers that can provide application level gateways between their systems without using a single standard. 

On Wed, Dec 18, 2019 at 11:17 PM Clarke Stevens <cstevens63@...> wrote:
OCF/IoTivity has virtually identical goals and already enables this. It would be nice if Amazon, Apple & Google would work with OCF rather than start from scratch.

-Clarke

On Dec 18, 2019, at 2:06 PM, Khaled Elsayed <khaledieee@...> wrote:

So, how many times have we heard this over the past 5 or 6 years from different consortium, forums or standardization bodies :-)?

“customers can be confident that their device of choice will work in their home and that they will be able to setup and control it with their preferred system,” the companies write


Best,

Khaled
 



Re: Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

Morten Nielsen
 

You mean like how AllJoyn had at least some traction and then OCF/IoTivity came along, killed AllJoyn and started from scratch?

Just Sayin' 😁

/Morten


From: "Clarke Stevens via Lists.Iotivity.Org" <cstevens63=gmail.com@...>
Sent: Wednesday, December 18, 2019 13:17
To: khaledieee@...
Cc: iotivity-dev@...
Subject: Re: [dev] Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

OCF/IoTivity has virtually identical goals and already enables this. It would be nice if Amazon, Apple & Google would work with OCF rather than start from scratch.

-Clarke

On Dec 18, 2019, at 2:06 PM, Khaled Elsayed <khaledieee@...> wrote:

So, how many times have we heard this over the past 5 or 6 years from different consortium, forums or standardization bodies :-)?

“customers can be confident that their device of choice will work in their home and that they will be able to setup and control it with their preferred system,” the companies write


Best,

Khaled
 



Re: Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

Clarke Stevens
 

OCF/IoTivity has virtually identical goals and already enables this. It would be nice if Amazon, Apple & Google would work with OCF rather than start from scratch.

-Clarke

On Dec 18, 2019, at 2:06 PM, Khaled Elsayed <khaledieee@...> wrote:

So, how many times have we heard this over the past 5 or 6 years from different consortium, forums or standardization bodies :-)?

“customers can be confident that their device of choice will work in their home and that they will be able to setup and control it with their preferred system,” the companies write


Best,

Khaled
 



Apple, Google, and Amazon are teaming up to develop an open-source smart home standard

Khaled Elsayed
 

So, how many times have we heard this over the past 5 or 6 years from different consortium, forums or standardization bodies :-)?

“customers can be confident that their device of choice will work in their home and that they will be able to setup and control it with their preferred system,” the companies write


Best,

Khaled
 


IMPORTANT: migration of IoTivity git repos scheduled for Dec 20th 2019

Nathan Heldt-Sheller
 

Hello again IoTivity Devs,

 

The final clone of existing git repos - from the current tLinux Foundation to the new GitLab repos – will take place this Friday, Dec 20th. We will be making backups of gerrit and the repos, etc., so data will not be lost, but:

 

*** if you would like your patch to be included in the GitLab repo, please merge no later than 5pm PST Thursday Dec 19th ***

 

Otherwise, it will have to be pushed to GitLab, reviewed, etc after the migration is done.

 

Thank you!
Nathan

 

From: Heldt-Sheller, Nathan
Sent: Monday, December 9, 2019 10:39 AM
To: iotivity-dev@...
Subject: IMPORTANT: IoTivity migrating to GitLab

 

Hello IoTivity Devs,

 

IoTivity will be transitioning to GitLab starting in 2020. More information will follow soon, but in the near term this means two things:

 

  1. PLEASE DO NOT submit new patches to Gerrit (IoTivity Classic or Lite repos) between now and EOY
  2. PLEASE MERGE any outstanding patches already pushed the Gerrit by EOY, or plan to manually migrate those patches to GitLab

 

We’re beta-testing the new GitLab services now, and will roll them out in the coming weeks. Keep an eye out for an OCF-sponsored GitLab training in Jan 2020!

Thanks,
Nathan Heldt-Sheller, Intel Corp.

OCF Open Source Work Group Chair


Re: Iotivity Arduino Build AVR issue

elizabethnathaniaw93@...
 

Doesn't matter. I've succeeded implement Iotivity-Linux(client) and Iotivity-Raspberry Pi(server) like in your examples. But, I changed it to Enviro PHat.
Thanks!


Re: Jenkens CI build does not appear to be running [fix ticket submitted]

George Nash
 

The build issue has been resolved.

 

From: iotivity-dev@... <iotivity-dev@...> On Behalf Of George Nash
Sent: Wednesday, December 11, 2019 2:11 PM
To: iotivity-dev@...
Subject: [dev] Jenkens CI build does not appear to be running [fix ticket submitted]

 

I saw today that no Jenkens CI builds have run since December 6th this is most likely a result of the software update done on Monday the 9th.

 

I just sent a ticket in for the issue for anyone that wants to track that ticket here is the link.

 

https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-18488

 

George Nash

 


Jenkens CI build does not appear to be running [fix ticket submitted]

George Nash
 

I saw today that no Jenkens CI builds have run since December 6th this is most likely a result of the software update done on Monday the 9th.

 

I just sent a ticket in for the issue for anyone that wants to track that ticket here is the link.

 

https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-18488

 

George Nash

 


Re: Iotivity Arduino Build AVR issue

elizabethnathaniaw93@...
 

Thanks! I will wait to know how to try in Arduino.

Also, I've tried some steps from your powerpoint until slide 13.
I have a question: In slide 14, where is the location of that files? Because slide before that is mention that the location in workspace/myexample/. I couldn't found the 4 files that mentioned in slide 14 in that folder. But, I found that 4 files in Project-Scripts folder. Are that the files that you mean in the ppt?


Re: Iotivity Arduino Build AVR issue

Clarke Stevens
 

Sorry, forgot the PowerPoint.



On Dec 10, 2019, at 3:50 PM, Clarke Stevens via Lists.Iotivity.Org <cstevens63=gmail.com@...> wrote:

We are only supporting IoTivity-lite now. It’s much faster, smaller and solid. It is slightly different, though. It’s in C rather than C++. The APIs are slightly different. However, we have a DeviceBuilder script that will completely write the working device code for you. All you have to do is fill in the code stubs with interfaces to your particular board. I’ve included a powerpoint, but feel free to ask questions if anything isn’t clear. The instructions in the power point will build for linux. I’ve got to run to a meeting, but I’ll tell you how to do the Arduino stuff a little later today.

-Clarke

On Dec 9, 2019, at 11:59 PM, elizabethnathaniaw93@... wrote:

Mats and Clarke,
Thank you for your quick reply.

Oh, I've read about iotivity-lite. But where I can find the documentation for how to use iotivity-lite? Because the iotivity wiki is not up-to-date.

Wow, that's great. I can't wait for the Arduino example.

What can I help with that? Actually, I'm worried with my skill now I can't help much.

How about iotivity for the Intel Edison board? Is it need to use the iotivity-lite too?



Re: Iotivity Arduino Build AVR issue

Clarke Stevens
 

We are only supporting IoTivity-lite now. It’s much faster, smaller and solid. It is slightly different, though. It’s in C rather than C++. The APIs are slightly different. However, we have a DeviceBuilder script that will completely write the working device code for you. All you have to do is fill in the code stubs with interfaces to your particular board. I’ve included a powerpoint, but feel free to ask questions if anything isn’t clear. The instructions in the power point will build for linux. I’ve got to run to a meeting, but I’ll tell you how to do the Arduino stuff a little later today.

-Clarke

On Dec 9, 2019, at 11:59 PM, elizabethnathaniaw93@... wrote:

Mats and Clarke,
Thank you for your quick reply.

Oh, I've read about iotivity-lite. But where I can find the documentation for how to use iotivity-lite? Because the iotivity wiki is not up-to-date.

Wow, that's great. I can't wait for the Arduino example.

What can I help with that? Actually, I'm worried with my skill now I can't help much.

How about iotivity for the Intel Edison board? Is it need to use the iotivity-lite too?


Bridging specification

Sören Fink <soeren.fink@...>
 

Dear all,

we would like to use the OCF bridging specification with IoTivity lite in an application and provide several virtual devices. Is there a working example for this scenario? Or just a code snippet that initializes the bridge with devices?

Thanks in advance.

Kind regards,
Soeren