search

intel / iotivity-node

Node.js bindings for IoTivity
https://www.iotivity.org/
42 stars 44 forks source link

iotivity-node on Yocto #99

Closed sanbeam closed 7 years ago

sanbeam commented 7 years ago

Can you please explain the steps to run iotivity-node (specific version) on Yocto based platforms. Do we need to build iotivity bindings natively on the platform. This seems like an issue for most deployment units.

poussa commented 7 years ago

@nagineni Can you take this one?

rzr commented 7 years ago

I will share some notes at: https://wiki.iotivity.org/yocto

Any plans to align meta-iot-web to use 1.2.0 from meta-oic (upstreaming in progress) ?

Regards

nagineni commented 7 years ago

@rzr I will update iotivity-node recipe to 1.2.0 as soon as we have iotivity 1.2.0 recipe in meta-oic master http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic.

rzr commented 7 years ago

hi @nagineni, thank you for feeback

I just sent iotivity_1.2.0 recipe (v2) to @kmaloor https://lists.iotivity.org/pipermail/iotivity-dev/2016-December/006373.html

But you can start working with this layer: https://github.com/tizenteam/meta-oic/tree/sandbox/pcoval/on/master/patch

Thanks again

nagineni commented 7 years ago

@iamsanjeev We have recipes for both iotivity and iotivity-node in the following repos.

meta-oic: http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic/ meta-iot-web: https://github.com/ostroproject/meta-iot-web

You need to clone the repos first and then add the layers to your bitbake configuration in conf/bblayers.conf

Here are some instructions for building a custom Yocto image with iotivity and iotivity-node:

  1. Pull the meta-oic and meta-iot-web layers.
  2. Append layers to the list of layers in your conf/bblayers.conf
  3. Include binary packages in the image by adding the following line in your conf/local.conf IMAGE_INSTALL_append += " iotivity iotivity-resource iotivity-node”
  4. Run bitbake <image-name> to build the image.
rzr commented 7 years ago

yes @iamsanjeev wanted to build on device or crossbuild using yocto sdk, but I still believe it will be faster if using bitbake.

Beside updating iotivity-node.bb do you see any wall with 1.2.0 ?

BTW don't hesitate to contact me for 1.2.1, it's on my plan too (maybe on jan 2017).

@nagineni, please also review my configuration flags in:

https://github.com/TizenTeam/meta-oic/blob/sandbox/pcoval/on/master/patch/recipes-core/iotivity/iotivity_1.2.0.bb

there are some changes since 1.1.1:

https://github.com/TizenTeam/meta-oic/commit/c3ee4dbf4ed82edc7c6d48a9b507e50c4a86169e

Compared to earlier recipe, configuration changes are:

nagineni commented 7 years ago

@rzr Good to hear that you already sent the updated recipe for review.

I already made a custom build with iotivity and iotivity-node v1.2.0 and they both seems to be working fine on Edison.

rzr commented 7 years ago

ok cool, I am doing this on qemu at the moment, I will double check as well and document at:

https://wiki.iotivity.org/yocto

I will update doc, once layers are validated, but it will be enough to move forward.

Thanks again for your check on edison.

nagineni commented 7 years ago

@rzr Any reason why we are not building iotivity with SECURED = 1? I think we should enable this flag by default in the recipe.

rzr commented 7 years ago

good question, I preferred to align to upstream's default parameters but I have tested w/ SECURED=1 it works too. (so I put it into comment, to be overloaded by .bbappend file)

Note that in upstream iotivity we're are about to switch secured to 1 for 1.3 or 2.0 upcoming branches...

I not sure you can rebuild current recipe without patches for tinycbor headers , I will try again with 1.2.1 and backport what is needed

rzr commented 7 years ago

Hi I confirm I managed to make it run in unsecure mode,

but versions should be updated in high level mode, just like in:

https://github.com/TizenTeam/iotivity-node/blob/sandbox/pcoval/wip/js/switch-server-hilevel.js

I can make the change and check again, should PR be done in master branch?

More to come at:

https://wiki.iotivity.org/yocto

I can even share an image with everything in (based on GENIVI)

https://wiki.iotivity.org/automotive#work_in_progress_120

Regards

rzr commented 7 years ago

iotivity 1.2.0 landed in meta-oic http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic/log/?h=1.2.0

Now to check, which branch of iotivity-node should I rebase on ?

Mine is: https://github.com/TizenTeam/iotivity-node/commits/maintenance

Then I can try to build an image for pi3 as requested in: https://github.com/otcshare/iotivity-node/issues/97

sanbeam commented 7 years ago

@rzr, maintenance is what we are using for testing against 1.2.0. You need to check for security. My request is let's make SECURE=0 as default for yocto. Let this be something user can enable. It simplifies development and later we can flip it ON.

nagineni commented 7 years ago

@rzr Glad to hear that the patch landed in meta-oic. I will create a PR for updating iotivity-node recipe to 1.2.0 once the local build is okay. For testing purposes, you can use maintenance branch of iotivity-node, but there are still some issues which needs to be addressed before we merge that branch to master.

rzr commented 7 years ago

@iamsanjeev . as said before I plan to follow upstream SECURITY policy, currently it's disabled, but it will change for 2.0-rel probably.

@nagineni what kind of issues ? version should be upgraded in examples, I will PR that if not done your side

nagineni commented 7 years ago

@rzr, the issues are related to periodic discovery of the resources/devices/platforms and also the missing delete event. Discovery works once, but we see multiple entries of the same resources if we do the discovery again. Maintenance branch is supposed to fix the issue, but it is still reproducible.

gabrielschulhof commented 7 years ago

@nagineni Lemme get this straight about the duplicates you're getting. With each round of discovery, are you getting one resource per interface, resulting in multiple instances of the same resource, because the device has multiple interfaces?

If so, then IIRC we agreed that this is something the end-user's application must fix.

nagineni commented 7 years ago

@gabrielschulhof Checking this on my host and it has only one interface. I am getting duplicates on rediscover even if the device has only one interface.

gabrielschulhof commented 7 years ago

@nagineni gotcha. I'll re-do the test to make sure the number of copies stays the sane across discovery rounds.

rzr commented 7 years ago

FYI I just sent a revision of meta-oic for ostroos and AGL , but it should not affect you, if you're curious it's at: https://github.com/TizenTeam/meta-oic/commits/sandbox/pcoval/on/master/review

gabrielschulhof commented 7 years ago

@nagineni Awesome catch! Thank you!

mythi commented 7 years ago

On Fri, Dec 23, 2016 at 2:24 AM, rzr wrote:

FYI I just sent a revision of meta-oic for ostroos and AGL , but it should not affect you, if you're curious it's at: https://github.com/TizenTeam/meta-oic/commits/sandbox/ pcoval/on/master/review

Did you send these to meta-oic maintainer as well?

-- Mikko

rzr commented 7 years ago

Yes I did send a few patches to @kmaloor, i will contact him again if no feedback

rzr commented 7 years ago

@mythi is everything fine with https://github.com/ostroproject/meta-iot-web/pull/25 ?

rzr commented 7 years ago

I think this bug can be closed, unless we want latest iotivity version 1.2.1 in meta-oit-web

As suggested at: https://github.com/ostroproject/meta-iot-web/pull/25

rzr commented 7 years ago

I checked 1.2.1 so it can land in master: https://github.com/otcshare/iotivity-node/pull/136