Connecting sensors to Mozilla’s IoT Gateway

Here is a 1st post about Mozilla’s IoT effort, and specifically the gateway project which is illustrating “Web Of Things” concept to create a decentralized Internet of Things, using Web technologies.

Today we will focus on the gateway, as it is the core component of the whole framework. Version 0.4.0 was just released, so you can try it your own on Raspberry Pi 3.  The Raspberry Pi 3 is the reference platform, but it should be possible to port to other single board computers (like ARTIK, etc).

The post will explain how to get started and how to establish basic automation using I2C sensors and actuators on gateway’s device (without any cloud connectivity).

To get started, first install the gateway according to these straightforward instructions:

Prepare SD Card

You need to download the Raspbian based gateway-0.4.0.img.zip (1GB archive) and dump it to SD card (2.6GB min).

lsblk # Identify your sdcard adapter ie:
disk=/dev/disk/by-id/usb-Generic-TODO
url=https://github.com/mozilla-iot/gateway/releases/download/0.4.0/gateway-0.4.0.img.zip
wget -O- $url | funzip | sudo dd of=$disk bs=8M oflag=dsync

If you only want to use the gateway and not hack on it, you can skip this next part which enables a developer shell though SSH.  However, if you do want access to a developer shell, mount the 1st partition called “boot” (you may need to replug your SD card adapter) and add a file to enable SSH:

sudo touch /media/$USER/boot/ssh
sudo umount /media/$USER/*

First boot

Next, install the SD card in your Raspberry PI 3 (Older RPis could work too, particularly if you have a wifi adapter).

When it has completed the first boot, you can check that the Avahi daemon is registering “gateway.local” using mDNS (multicast DNS)

ping gateway.local
ssh pi@gateway.local # Raspbian default password for pi user is "raspberry"

Let’s also track local changes to /etc by installing etckeeper, and change the default password.

sudo apt-get install etckeeper
sudo passwd pi

Logging in

You should now be able to access the web server, which is running on port 8080 (earlier version used 80):

http://gateway.local:8080/

It will redirect you to a page to configure wifi:

URL: http://gateway.local:8080/
Welcome
Connect to a WiFi network?
FreeWifi_secure
FreeWifi
OpenBar
...
(skip)

We can skip it for now:

URL: http://gateway.local:8080/connecting
WiFi setup skipped
The gateway is now being started. Navigate to gateway.local in your web browser while connected to same network as the gateway to continue setup.
Skip

After a short delay, the user should be able to reconnect to the entry page:

http://gateway.local:8080/

The gateway can be registered on mozilla.org for remote management, but we can skip this for now.

Then administrator is now welcome to register new users:

URL: http://gateway.local:8080/signup/
Mozilla IoT
Welcome
Create your first user account:
user: user
email: user@localhost
password: password
password: password
Next

And we’re ready to use it:

URL: http://gateway.local:8080/things
Mozilla IoT
No devices yet. Click + to scan for available devices.
Things
Rules
Floorplan
Settings
Log out

Filling dashboard

You can start filling your dashboard with Virtual Resources,

First hit the “burger menu” icon, go to settings page, and then go to the addons page.

Here you can enable a “Virtual Things” adapter:

URL: http://gateway.local:8080/settings/addons/
virtual-things-adapter 0.1.4
Mozilla IoT Virtual Things Adapter
by Mozilla IoT

Once enabled It should be listed along ThingURLAdapter on the adapters page:

URL: http://gateway.local:8080/settings/adapters
VirtualThingsAdapter
virtual-things
ThingURLAdapter
thing-url-adapter

You can then go back to the 1st Things page (it’s the first entry in the menu):

We can start adding “things” by pressing the bottom menu.

URL: http://gateway.local:8080/things
Virtual On/Off Color Light
Color Light
Save

Then press “Done” at bottom.

From this point, you can decide to control a virtual lamp from the UI, and even establish some basic rules (second entry in menu) with more virtual resources.

Sensing Reality

Because IoT is not about virtual worlds, let’s see how to deal with the physical world using sensors and actuators.

For sensors, there are many way to connect them to computers using analog or digital inputs on different buses.  To make it easier for applications developers, this can be abstracted using W3C’s generic sensors API.

While working on IoT.js‘s modules, I made a “generic-sensors-lite” module that abstracted a couple of I2C drivers from the NPM repository.  To verify the concept, I have made an adapter for Mozilla’s IoT Gateway (which is running Node.js), so I published the generic-sensors-lite NPM module first.

Before using the mozilla-iot-generic-sensors-adapter, you need to enable the I2C bus on the gateway (version 0.4.0, master has I2C enabled by default).

sudo raspi-config
Raspberry Pi Software Configuration Tool (raspi-config)
5 Interfacing Options Configure connections to peripherals
P5 I2C Enable/Disable automatic loading of I2C kernel module
Would you like the ARM I2C interface to be enabled?
Yes
The ARM I2C interface is enabled
ls -l /dev/i2c-1
lsmod | grep i2c
i2c_dev 16384 0
i2c_bcm2835 16384 0

Of course you’ll need at least one real sensor attached to the I2C pin of the board.  Today only 2 modules are supported:

You can double check if addresses are present on I2C the bus:

sudo apt-get install i2c-tools
/usr/sbin/i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- 23 -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

Install mozilla-iot-generic-sensors-adapter

Until sensors adapter is officially supported by the mozilla iot gateway, you’ll need to install it on the device (and rebuild dependencies on the target) using:

url=https://github.com/rzr/mozilla-iot-generic-sensors-adapter
dir=~/.mozilla-iot/addons/generic-sensors-adapter
git clone --depth 1 -b 0.0.1 $url $dir
cd $dir
npm install

Restart gateway (or reboot)
sudo systemctl restart mozilla-iot-gateway.service
tail -F /home/pi/.mozilla-iot/log/run-app.log

Then the sensors addon can be enabled by pressing the “enable” button on the addons page:

URL: http://gateway.local:8080/settings/addons
generic-sensors-adapter 0.0.1
Generic Sensors for Mozilla IoT Gateway

It will appear on the adapters page too:

URL: https://gateway.local/settings/adapters
VirtualThingsAdapter
virtual-things
ThingURLAdapter
thing-url-adapter
GenericSensorsAdapter
generic-sensors-adapter

Now we can add those sensors as new things (Save and done buttons):

URL: http://gateway.local:8080/things
Ambient Light Sensor
Unknown device type
Save
Temperature Sensor
Unknown device type
Save

Then they will appear as:

  • http://gateway.local:8080/things/0 (for Ambient Light Sensor)
  • http://gateway.local:8080/things/1 (for Temperature Sensor)

To get value updated in the UI, they need to turned on first (try again if you find a big, and file tickets I will forward to drivers authors).

A GPIO adapter can be also used for actuators, as shown in this demo video.

If you have other sensors, check if the community has shared a JS driver, and please let me know about integrating new sensors drivers in generic-sensors-lite

How to Prototype Insecure IoTivity Apps with the Secure Library

IoTivity 1.3.1 has been released, and with it comes some important new changes. First, you can rebuild packages from sources, with or without my hotfixes patches, as explained recently in this blog post. For ARM users (of ARTIK7), the fastest option is to download precompiled packages as .RPM for fedora-24 from my personal repository, or check ongoing works for other OS.

Copy and paste this snippet to install latest IoTivity from my personal repo:

distro="fedora-24-armhfp"
repo="bintray--rzr-${distro}"
url="https://bintray.com/rzr/${distro}/rpm"
rm -fv "/etc/yum.repos.d/$repo.repo"
wget -O- $url | sudo tee /etc/yum.repos.d/$repo.repo
grep $repo /etc/yum.repos.d/$repo.repo

dnf clean expire-cache
dnf repository-packages "$repo" check-update
dnf repository-packages "$repo" list --showduplicates # list all published versions
dnf repository-packages "$repo" upgrade # if previously installed
dnf repository-packages "$repo" install iotivity-test iotivity-devel # remaining ones

I also want to thank JFrog for proposing bintray service to free and open source software developers.

Standalone Apps

In a previous blog post, I explained how to run examples that are shipped with the release candidate. You can also try with other existing examples (rpm -ql iotivity-test), but some don’t work properly. In those cases, try the 1.3-rel branch, and if you’re still having problems please report a bug.

At this point, you should know enough to start making your own standalone app and use the library like any other, so feel free to get inspired or even fork demo code I wrote to test integration on various OS (Tizen, Yocto, Debian, Ubuntu, Fedora etc…).

Let’s clone sources from the repo. Meanwhile, if you’re curious read the description of tutorial projects collection.

sudo dnf install screen psmisc git make
git clone http://git.s-osg.org/iotivity-example
# Flatten all subprojects to "src" folders
make -C iotivity-example
# Explore all subprojects
find iotivity-example/src -iname "README*"

 

 

Note that most of the examples were written for prototyping, and security was not enabled at that time (on 1.2-rel security is not enabled by default except on Tizen).

Serve an Unsecured Resource

Let’s go directly to the clock example which supports security mode, this example implements OCF OneIoT Clock model and demonstrates CoAP Observe verb.

cd iotivity-example
cd src/clock/master/
make
screen
./bin/server -v
log: Server:
Press Ctrl-C to quit....
Usage: server -v
(...)
log: { void IoTServer::setup()
log: { OCStackResult IoTServer::createResource(std::__cxx11::string, std::__cxx11::string, OC::EntityHandler, void*&)
log: { FILE* override_fopen(const char*, const char*)
(...)
log: } FILE* override_fopen(const char*, const char*)
log: Successfully created oic.r.clock resource
log: } OCStackResult IoTServer::createResource(std::__cxx11::string, std::__cxx11::string, OC::EntityHandler, void*&)
log: } void IoTServer::setup()
(...)
log: deadline: Fri Jan  1 00:00:00 2038
oic.r.clock: { 2017-12-19T19:05:02Z, 632224498}
(...)
oic.r.clock: { 2017-12-19T19:05:12Z, 632224488}
(...)

Then, start the observer in a different terminal or device (if using GNU screem type : Ctrl+a c and Ctrl+a a to get switch to server screen):

./bin/observer -v
log: { IoTObserver::IoTObserver()
log: { void IoTObserver::init()
log: } void IoTObserver::init()
log: } IoTObserver::IoTObserver()
log: { void IoTObserver::start()
log: { FILE* override_fopen(const char*, const char*)
(...)
log: { void IoTObserver::onFind(std::shared_ptr)
resourceUri=/example/ClockResUri
resourceEndpoint=coap://192.168.0.100:55236
(...)
log: { static void IoTObserver::onObserve(OC::HeaderOptions, const OC::OCRepresentation&, const int&, const int&)
(...)
oic.r.clock: { 2017-12-19T19:05:12Z, 632224488}
(...)

OK, now it should work and the date should be updated, but keep in mind it’s still *NOT* secured at all, as the resource is using a clear channel (coap:// URI).

To learn about the necessary changes, let’s have look at the commit history of the clock sub project. The server’s side persistent storage needed to be added to the configuration; we can see from trace that Secure Resource Manager (SRM) is loading credentials by overriding fopen functions (those are designed to use hardware security features like ARM’s Secure Element/ Secure key storage). The client or observer also needs a persistent storage update.

git diff clock/1.2-rel src/server.cpp

(...)
 
+static FILE *override_fopen(const char *path, const char *mode)
+{
+    LOG();
+    static const char *CRED_FILE_NAME = "oic_svr_db_anon-clear.dat";
+    char const *const filename
+        = (0 == strcmp(path, OC_SECURITY_DB_DAT_FILE_NAME)) ? CRED_FILE_NAME : path;
+    return fopen(filename, mode);
+}
+
+
 void IoTServer::init()
 {
     LOG();
+    static OCPersistentStorage ps {override_fopen, fread, fwrite, fclose, unlink };
     m_platformConfig = make_shared
                        (ServiceType::InProc, // different service ?
                         ModeType::Server, // other is Client or Both
                         "0.0.0.0", // default ip
                         0, // default random port
                         OC::QualityOfService::LowQos, // qos
+                        &ps // Security credentials
                        );
     OCPlatform::Configure(*m_platformConfig);
 }

This example uses generic credential files for the client and server with maximum privileges, just like unsecured mode (or default 1.2-rel configuration).

cat oic_svr_db_anon-clear.json
{
    "acl": {
       "aclist2": [
            {
                "aceid": 0,
                "subject": { "conntype": "anon-clear" },
                "resources": [{ "wc": "*" }],
                "permission": 31
            }
        ],
        "rowneruuid" : "32323232-3232-3232-3232-323232323232"
    }
}

These files will not be loaded directly because they need to be compiled to the CBOR binary format using IoTivity’s json2cbor (which despite the name does more than converting json files to cbor, it also updates some fields).

Usage is straightforward:

/usr/lib/iotivity/resource/csdk/security/tool/json2cbor oic_svr_db_client.json  oic_svr_db_client.dat

To recap, the minimal steps that are needed are:

  1. Configure the resource’s access control list to use new format introduced in 1.3.
  2. Use clear channel (“anon-clear”) for all resources (wildcards wc:*), this is the reason coap:// was shown in log.
  3. Set verbs (CRUD+N) permissions to maximum according to OCF_Security_Specification_v1.3.0.pdf document.

One very important point: don’t do this in a production environment; you don’t want to be held responsible for neglecting security, but this is perfectly fine for getting started with IoTivity and to prototype with the latest version.

 

Still Unsecured, Then What?

With faulty security configurations you’ll face the OC_STACK_UNAUTHORIZED_REQ error (Response error: 46). I tried to sum up the minimal necessary changes, but keep in mind that you shouldn’t stop here. Next, you need to setup ACLs to match the desired policy as specified by Open Connectivity, check the hints linked on IoTivity’s wiki, or use a provisioning tool, >stay tuned for more posts that cover these topics.

 

 

 

Get Started with IoTivity Interactions on the ARTIK10 and Tizen

A curious mind recently asked me to share materials about the OCF SmartHome demo, or perhaps I should call it the “Minimalist Smart Switch” instead. The demo was displayed at the Embedded Linux Conference in Berlin, and featured IoTivity running on an ARTIK10 SoC that connected to a Tizen Gear S2 Smartwatch; both run Tizen OS.

Get Started with IoTivity Interactions on the ARTIK10 and Tizen - ocf

You will find more technical details in the following slide deck.

Install Tizen and IoTivity

If you want to run it this demo, you can download the system image and uncompress the archive directly to the SD card using QEMU tools.

lsblk # will list all your disks
disk=/dev/sdTODO # update with your disk id
file=tizen-common-artik10-20160801rzr.qcow2
sudo qemu-img convert -p "${file}" "${disk}"
sync 

Once this is completed, insert the SD card into the ARTIK10 and turn it on; it will boot Tizen and launch the IoTivity server. For more information about this, check out the previous blog posts about booting tizen on ARTIK and building software for Tizen OS. These will show you how to rebuild the latest version of IoTivity from scratch.

Of course, this can be adapted to other hardware like the ARTIK5 and maybe the ARTIK7 too, it would be a good idea to bookmark this page as a reference for Tizen on ARTIK. If you run into issues, feel free to ask about them in the ARTIK forums.

Note, You can also do it again on Yocto OS using meta-artik too, but using Tizen will save you the time and resources to rebuild everything.

Setup the Tizen Clients

For IoTivity clients on mobile devices, like the Samsung Z1, or smartwatches, such as the Samsung GearS2, the clients need a little preparation. Most of it’s documented in the Tizen page on the IoTivity wiki. I will also be personally available to assist developers at next the Tizen community meeting (2016-11-28 09h@UTC), which has more details on the Wiki’s Meeting page.

What’s Next for Tizen and IoTivity?

Micro-controllers have recently been a focus of some of my work. I shared some hints are shared in the following presentation “From Arduino Microcontrollers to Tizen using IoTivity” which I presented at IoT With the Best 2016.

Others at the Samsung Open Source Group have worked on more constrained devices by bridging different technologies together, including JerryScript, 6LoWPAN, and more. This was demonstrated at the recent Samsung Open Source Conference .

One likely challenge for ARTIK0 owners will be running iotivity-constrained on operating systems Iotivity supports, such as RIOT, Zephyr, and Tizen RT. If you’re one of these people, please keep us updated in the Tizen IRC channel, or the mailing lists!

Get Started with IoTivity Interactions on the ARTIK10 and Tizen - lfelc

Thanks to Luis De Bethencourt for helping me with the pictures of the Gear S2 on my wrist :-)

An Introduction to Tizen Development on ARTIK

This article is a direct follow up of my previous post about booting Tizen on the ARTIK10. Before starting, you should bookmark this wiki page as an entry point for Tizen on ARTIK devices.

At the 2015 Tizen Developer Conference, I had the opportunity to present a tutorial about Tizen platform development; it’s still valid today. This article is very similar but is adapted for ARTIK10 and ARTIK5 configuration.

For some context, check out to the following slide deck along with the recorded video on how to patch Tizen and build with GBS for x86a as well as this page about Tizen:Common on VMware.

 

 

Tools Setup

If you’re familiar with Tizen you probably know about Git Build System (GBS): a very convenient tool to build packages. It’s adapted from Debian’s git-build-package to support zypper repos.

First, gbs and some other Tizen tools need to be installed on the host machine used for development; On a debian based distro this is trivial: add the proper apt source for your specific OS as listed in the tools folder.

For instance, edit and adapt:

# cat /etc/os-release # mine is NAME=Ubuntu VERSION_ID=14.04
# cat /etc/apt/sources.list.d/org_tizen.list # edit and adapt 

deb http://download.tizen.org/tools/latest-release/${NAME}_${VERSION_ID}/ /
deb-src http://download.tizen.org/tools/latest-release/${NAME}_${VERSION_ID}/

# sudo apt-get install gbs mic lthor sdb

Then, the configuration file ~/.gbs.conf must be created, it should contain something like the following:

# cat ~/.gbs.conf

[profile.tizen_common_3.0b_artik_armv7l]
repos=repo.tizen_base_armv7l,repo.tizen_common_3.0b_artik_armv7l
buildroot=~/tmp/gbs/tmp-GBS-tizen_common_3.0b_artik_armv7l/

[repo.tizen_base_armv7l]
url = http://download.tizen.org/snapshots/tizen/base/latest/repos/arm/packages/

[repo.tizen_common_3.0b_artik_armv7l]
url=http://download.tizen.org/snapshots/tizen/common_artik/latest/repos/arm-wayland/packages/

By the way, here is my current .gbs.conf, with more profiles:

wget -O ~/.gbs.conf https://notabug.org/tizen/tizen-helper/raw/master/config/gbs.conf

Hello Tizen Source

Here, is the “helloworld project” and the packaging file needed to create a minimal platform package.

# mkdir -p tizen-example/packaging
# cd tizen-example
# cat main.c

#include "stdio.h"
void main()
{
    printf("Hello Tizen!\n");
}

A trivial makefile is needed to install it, as GNU make will guess how to build it (note, tabs are used not spaces) :

# cat Makefile

prefix?=/usr

install: main
    install -d ${DESTDIR}${prefix}/bin/
    install main ${DESTDIR}${prefix}/bin/

Finally write a minimal RPM spec file, like on any RPM based distribution (Red Hat, SUSE, Mer, etc):

# cat packaging/tizen-example.spec

Name: tizen-example
Version: 0
Release: 0
Summary: example
Source: %{name}-%{version}.tar.gz
License: TODO
BuildRequires: make
%description
Basic hello world example
%prep
%setup -q -n %{name}-%{version}
%build
%install 
%make_install
%clean
%files
%{_bindir}/*

Then commit those files into a newly created git project:

git init
git add .
git commit -sam 'Import'

Build the Software

The next step is to build it with this single command line:

gbs build -P "tizen_common_3.0b_artik_armv7l" --arch armv7l --include-all

It will download dependencies and eventually produce an RPM file; the contents can be listed with this command line:

rpm -qlp ~/tmp/gbs/tmp-GBS-tizen_common_3.0b_artik_armv7l/local/repos\
tizen_common_3.0b_artik_armv7l/armv7l/RPMS/rzr-example-0-0.armv7l.rpm

/usr/bin/main

Deploy to Target Device

At this stage, the package can be uploaded using scp, but let’s use an alternate way: Tizen’s Smart debug bridge (sdb) which was installed earlier.

On the target side, the SDB daemon should be already running:

# systemctl status sdbd    

sdbd.service - sdbd
   Loaded: loaded (/usr/lib/systemd/system/sdbd.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2016-07-25 10:03:00 PDT; 7min ago
  (...)

If not, (re)start it:

# systemctl restart sdbd

# ifconfig -a 

Take note of the target’s IP address. Back on the host, use the sdb client to connect to it.

# sdb connect  192.168.0.42
connecting to 192.168.0.42:26101 ...
connected to 192.168.0.42:26101

# sdb devices
List of devices attached 
192.168.0.42:26101     device          artik

Perfect! Now files can be pushed or pulled just like the Tizen SDK IDE, but this has the benefit of providing shell access with su supported:

# sdb shell

sh-3.2$ pwd
/opt/home/owner

Now, we’re ready to upload our built RPM and install it with rpm running as root:

# sdb push ~/tmp/gbs/tmp-GBS-tizen_common_3.0b_artik_armv7l/local/repos/tizen_common_3.0b_artik_armv7l/armv7l/RPMS /opt/home/owner/RPMS
pushed   tizen-example-0-0.armv7l.rpm   100%          3KB
(...)

# sdb shell
sh-3.2$ su
Password: # tizen
bash-3.2# rpm -i /opt/home/owner/RPMS/tizen-example-*.rpm

bash-3.2# /usr/bin/main
Hello Tizen!

It’s not rocket science, but this is enough to validate the Tizen toolchain.

Setting up a private repo

Note: a quick tip for deploying is to setup an HTTP repo on the host machine and pull packages with zypper.

On the host machine, execute the following:

sudo apt-get install apache2
sudo a2enmode userdir
mkdir -p ~/public_html/tmp/
ln -fs ~/tmp/gbs  ~/public_html/tmp/gbs
ifconfig -a # note host_ip for later ie: 192.168.0.154

Then, some variables need to be adapted on the target side.

# sdb shell # or ssh root@$target_ip
# su # password=tizen
# host_ip=192.168.0.154 # adapt
# user=pcoval # adapt
# profile=tizen_common_3.0b_artik_armv7l
# url="http://${host_ip}/~${user}/tmp/gbs/tmp-GBS-${profile}/local/repos/${profile}/armv7l/"
#
# zypper removerepo ${user}
Repository 'pcoval' not found by alias, number or URI.

# zypper addrepo ${url} ${user} 
Adding repository 'pcoval' ...............................................[done]
Repository 'pcoval' successfully added
Enabled: Yes
Autorefresh: No
GPG check: Yes
URI: http://192.168.0.154/~pcoval/tmp/gbs/tmp-GBS-tizen_common_3.0b_artik_armv7l/local/repos/tizen_common_3.0b_artik_armv7l/armv7l/

# zypper repos
# | Alias                   | Name                                  | Enabled | Refresh
--+-------------------------+---------------------------------------+---------+--------
1 | Tizen_Base              | Bootstrap Project of Tizen  (arm)     | Yes     | No     
2 | Tizen_Common_3.0b_artik | Tizen:Common:3.0b:artik (arm-wayland) | Yes     | No     
3 | pcoval                  | pcoval                                | Yes     | No     

By the way, here are some zypper commands, you will probably use:

# zypper
# zypper refresh -r ${user} 
# zypper repos -r ${user} 
# zypper update -r  ${user} 
# zypper clean -r ${user} 
# zypper install --force -r ${user} ${package}

What’s Next ?

This should have summed up all that is needed to get into Tizen platform development on ARTIK devices. Now there are many new possibilities open for things like IoT development; let us know about your plans or join existing discussions about hardware support related to things like Graphics, Bluetooth/BLE, or maybe try to compare the results of this with Yocto’s meta-artik or other Operating Systems.

Remember, we also plan to have a quick chat about ARTIK at next Tizen Community Online Meeting, I hope to see you there! As a parting gift, here are some extra hints about packaging new software for the Tizen contrib repo.

 

How to Boot Tizen on ARTIK

The fact that Tizen can be run on ARTIK is not the latest breaking news, considering it was previously demonstrated live at the 2015 Tizen Conference. There, the ARTIK project was also explained as an IoT platform of choice. Since then, ARTIK has become a new Tizen reference device, so here are a couple of hints that will help you test upcoming Tizen release on this hardware. First let me point out that Tizen’s wiki has a special ARTIK category, where you’ll find ongoing documentation efforts, you’ll want to bookmark this page.

In this article, I will provide a deeper explanation of how to use the bleeding edge version of Tizen:3.0:Common on ARTIK10, and how to start working on this platform. As explained in my previous Yocto/meta-artik article, I suggest you avoid using the eMMC for development purposes; for this article I will boot the ARTIK from an SDcard. In the long term I think it could be possible for the community to assemble Tizen infrastructure that automatically builds bootable SDcard tizen images to save time, but I’ll detail the whole process here in the meantime.

The Short and Easy Path

For your convenience, you can download an image of the build I’ll be describing here (md5=0d21e2716f67a16086fdd2724e7e11f1). It’s a binary image of the latest Tizen weekly development version (plus the latest IoTivity build too) prepared for the ARTIK10. All you have to do is flash it to the SD card, switch SW2/1 to on and SW2/2 to off, setup USB link to change a couple of U-Boot variables (set rootdev 1 ; set rootpart 3 ; boot ) as explained later in this tutorial.

# lsblk
disk=/dev/sdTODO
file=tizen-common-artik_20160627.3_common-wayland-3parts-armv7l-artik10.qcow2
# time qemu-img convert -p "${file}" "${disk}"

If you want to take the long road, or you want to do this for the ARTIK5, follow the rest of this guide; it will explain how to build Tizen and IoTivity to run on the ARTIK.

Download Tizen

Development for the Tizen project is a continuous process, the latest version can be downloaded here.

In the images/arm-wayland/ sub folder you’ll need to download 2 archives, the first is the boot image, which is different based on whether you’re using the ARTIK5 or ARTIK10. This image includes kernel and modules and the bootloader. The main difference between the ARTIK5 and ARTIK10 images is that U-Boot parameters are written at different media offsets.

I’m using the ARTIK10 for this guide, so I downloaded the tar.gz file found here. If you want to save bandwidth and time, it’s possible to grab a headless image archive tizen-common-artik_YYYYMMDD.*_common-headless-3parts-armv7l-artik.tar.gz.

If you own an ARTIK5, download the image from here; the ARTIK1 is totally different and it’s unlikely the same Tizen 3 codebase will be ever supported.

Prepare the SD Card

To write data to SD card, I’ll use the helpful sdboot script to handle the partitioning, formating and copying tasks that would be done manually using dd.

git clone https://github.com/tizenteam/sdboot -b master 

Insert the SD card into the host computer and identify the device node:

lsblk
disk=/dev/sdX # replace X with matching letter

Next, partition the SD card (8GB is minimal requirement), and format no less than 6 partitions.

sudo bash -x ./mk_sdboot.sh -f "$disk"

In the repo that was cloned earlier there is tizen-sd-bootloader-artik10.tar.gz; this contains early stages of the signed bootloader (bl1.bin, bl2.bin and ARM Trust Zone Software tzsw.bin). Note: don’t be confused by the “tz” in “twsw.bin” it means ARM TrustZone software not Tizen. The general purpose is to establish a chain of trust to ensure software integrity. The general purpose is to establish a chain of trust to ensure software integrity. U-boot.bin and its parameters file params.bin will be overridden later, and uInitrd, while not totally mandatory, will be helpful to setup systemd and mount the modules partition.

Use the mk_sdboot.sh helper script to write these files at the specific offets (Seek by 1231 for artik10’s U-Boot params file):

sudo bash -x ./mk_sdboot.sh -w /dev/sdb  tizen-sd-bootloader-artik10.tar.gz

Now, the SDcard should be able to launch U-Boot’s shell, so the next step is to prepare the operating system. Copy the Linux kernel to the 1st partition and its modules to the 2nd, and override the copied uboot and params just before the 1st partition:

sudo bash -x ./mk_sdboot.sh -w "$disk" tizen-*-boot-armv7l-artik10.tar.gz

Now, you can try to boot the kernel if you want, but let’s also dump Tizen’s rootfs to our SD card’s 3rd partition. Along with this, 2 other partitions are copied too: user and systemd-data.

sudo bash -x ./mk_sdboot.sh -w "$disk" tizen-*-3parts-armv7l-artik.tar.gz 

The device should now be capable of booting into Tizen.

Boot Tizen

For the purpose of this guide, I’m going to assume you’ve already booted your ARTIK with an existing OS (Fedora) or others (Ubuntu, Yocto) and know how to setup your debug link.

 

 

Power up the ARTIK10.

screen /dev/ttyUSB0 115200

U-Boot 2012.07-g801ab1503-TIZEN.org (Jun 20 2016 - 15:27:02) for ARTIK10

CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
APLL = 800MHz, KPLL = 800MHz
MPLL = 532MHz, BPLL = 825MHz

Board: ARTIK10
DRAM:  2 GiB
WARNING: Caches not enabled

TrustZone Enabled BSP
BL1 version: /
VDD_KFC: 0x44
LDO19: 0x28

Checking Boot Mode ... SDMMC
MMC:   S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: 14.6 GiB
MMC Device 2: MMC Device 2 not found
In:    serial
Out:   serial
Err:   serial
rst_stat : 0x100
Net:   No ethernet found.
Hit any key to stop autoboot:  0 

Hit any key to stop and get a shell, if you don’t, U-Boot will try to boot the OS from the eMMC. Once you are in UBoot’s shell, change some variables temporarily:

ARTIK10 # version
U-Boot 2012.07-g801ab1503-TIZEN.org (Jun 20 2016 - 15:27:02) for ARTIK10
gcc (Tizen/Linaro GCC 4.9.2 2015.02) 4.9.2
GNU ld (GNU Binutils) 2.25.0 Linaro 2015_01-2

ARTIK10 # env default -f ;
ARTIK10 # set rootdev 1 ; set rootpart 3 ; boot 

In the next step of the boot process, the kernel, device tree and rootfs are loaded and executed:

reading zImage
5339682 bytes read in 67299 ms (77.1 KiB/s)
reading exynos5422-artik10.dtb
69754 bytes read in 117983 ms (0 Bytes/s)
reading uInitrd
1353683 bytes read in 29687 ms (43.9 KiB/s)
## Loading init Ramdisk from Legacy Image at 43000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    1353619 Bytes = 1.3 MiB
   Load Address: 00000000
   Entry Point:  00000000

Starting kernel ...

[    0.092805] [c0] /cpus/cpu@0 missing clock-frequency property
(...)
[    0.093269] [c0] exynos-snapshot: exynos_ss_init failed
[    0.335618] [c5] Exynos5422 ASV : invalid IDS value
(...)
Welcome to Tizen 3.0.0 (Tizen3/Common)!
(...)

Login to Tizen

The first boot will take a bit longer than usual, but eventually a prompt will appear that will allow you to login as root with “tizen” as the password:

Welcome to Tizen 3.0.0 (Tizen3/Common)!
(...)
localhost login: 
Password: 

# cat /etc/os-release 
NAME=Tizen
VERSION="3.0.0 (Tizen3/Common)"
ID=tizen
VERSION_ID=3.0.0
PRETTY_NAME="Tizen 3.0.0 (Tizen3/Common)"
ANSI_COLOR="0;36"
CPE_NAME="cpe:/o:tizen:tizen:3.0.0"
BUILD_ID=tizen-common-artik_20160627.3_common-wayland-3parts-armv7l-artik

# cat /proc/cmdline 
console=ttySAC3,115200n8 root=/dev/mmcblk1p3 rw rootfstype=ext4 loglevel=4 asix.macaddr=d2:40:??:??:??:?? bd_addr=C0:97:??:??:??:??

# cat /proc/version 
Linux version 3.10.93-3.1-arm-artik10 (abuild@w17) (gcc version 4.9.2 (Tizen/Linaro GCC 4.9.2 2015.02) ) #1 SMP PREEMPT Mon Jun 27 16:54:57 UTC 2016

# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk1p3        2.0G  726M  1.2G  38% /

Hotfix

I noticed a critical bug that can be worked around for now. Some daemons are causing damage to the root filesystem after a short period (less than 5 minutes), I suspect they could generate too much output and fill our low disk space, this is something that needs to be investigated. As a temporary solution, they should be stopped as soon as possible:

# systemctl stop deviced ; systemctl stop resourced ;
# systemctl disable deviced ; systemctl disable resourced

To make sure they won’t be re installed / restarted, they need to also be renamed:

# mv /usr/bin/deviced /usr/bin/deviced.orig
# mv /usr/bin/resourced /usr/bin/resourced.orig
# systemctl status deviced
Active: inactive (dead) since Mon 2016-07-25 10:05:09 PDT; 25s ago

Then, make sure the modules partition is mounted and matches the kernel version:

ls -l  /lib/modules/$(uname -r)/modules.dep
-rw-r--r-- 1 root root 21574 Jun 27 09:56 /lib/modules/3.10.93-3.1-arm-artik10/modules.dep

If not you aren’t using uInitrd, you’ll have to tweak fstab.

Connect to the Network

Check to make sure the network is working and the device has an IP address assigned to it:

ifconfig -a
eth0: flags=-28605  mtu 1500
        inet 192.168.0.42  netmask 255.255.255.0  broadcast 192.168.0.255

If it doesn’t, it can be set it up manually after loading the AX8817X USB NIC’s driver:

# modprobe -v asix

insmod /lib/modules/3.10.93-3.1-arm-artik10/kernel/drivers/net/usb/usbnet.ko 
insmod /lib/modules/3.10.93-3.1-arm-artik10/kernel/drivers/net/usb/asix.ko macaddr=d2:40:??:??:??:??

The LAN’s DHCP server should then assign an IP address to the device.

Install Packages

The headless image should already have zypper installed, it will be used for this section. If for some reason it’s not part of the image, it’s possible to use sdb to install it. This is outside the scope of this article, but if you have questions, feel free to post them to the comment section.

First, add the remote repos:

# zypper lr
Warning: No repositories defined.
Use the 'zypper addrepo' command to add one or more repositories.

# zypper addrepo http://download.tizen.org/live/Tizen:/Base/arm/Tizen:Base.repo
# zypper ar http://download.tizen.org/live/Tizen:/Common:/3.0b:/artik/arm-wayland/Tizen:Common:3.0b:artik.repo

Now it’s possible to install packages and upgrade the distro to latest snapshot.

# zypper in screen openssh
# zypper up

Take IoTivity for a Spin.

What’s next? Many people have expressed interest in using IoTivity on new platforms like Tizen, so let’s take a look at some of the IoTivity apps.

# zypper in iotivity-test iotcon-test 
# downgrade if needed
# rpm -ql iotivity-test

The binary image I shared at the beginning of this article contains the recently-released iotivity-1.1.1. I built it locally from sources using GBS on the 1.1.1 git tag with security enabled. The example apps must be run in the same directory where *.dat files are stored. Here are some instructions to launch a sample app I described in my previous article on IoTivity on ARTIK:

ls /usr/bin/*.dat
/usr/bin/oic_svr_db_client.dat
/usr/bin/oic_svr_db_server.dat
cd /usr/bin/ ; /usr/bin/simpleserver 2 
# in an other terminal :
cd /usr/bin/ ; /usr/bin/simpleclient 1 

What’s Next?

I’m going to continue hacking away at Tizen on my ARTIK10, stay tuned for more articles about developing on these platforms. Also check upcoming Tizen Community Online Meeting, a live chat about ARTIK is planned this fall, see you there.

 

How to Run IoTivity on ARTIK with Yocto

Samsung ARTIK is described by its developers as an end-to-end, integrated IoT platform that transforms the process of building, launching, and managing IoT products. I first saw one a year ago at the Samsung VIPEvent 2015 in Paris, but now there is an ARTIK10 on my desk and I would like to share some of my experiences of it with you.

In this post, I will show how to build a whole GNU/Linux system using Yocto, a project that provides great flexibility in mixing and matching components and customizing an environment to support new hardware or interesting software like IoTivity. If you’re looking for Tizen support, it’s already here (check at bottom of this article), but this post will focus on a generic Linux build.

Many of the board’s features I will be covering in this article are briefly introduced in the following video:

There are 3 ARTIK models on the market: ARTIK 1 is MIPS based system with 1MB of RAM while ARTIK 5 and 10 are powerful ARM systems based on Exynos System on Module. This article covers the ARTIK 10 and it can easily be adapted to the ARTIK 5, but not the ARTIK 1.

According to the specifications, the ARTIK 10 has an 8 Core CPU (4 Cortex-A7 and 4 Cortex-A15), 2GB of RAM, and a GPU (Mali T628) for multimedia needs. Since the ARTIK family is targeted for Internet of Things use cases, there are also a lot of connectivity controllers (Wired Ethernet, Wi-Fi : IEEE802.11a/b/g/n/ac, Bluetooth 4.1 + LE, Zigbee/Thread) as well as security elements (ARM TrustZone, TEE) which are mandatory for a safe IoT.

Unboxing and Booting the ARTIK 10

In the box you’ll find 4 antennas, a micro USB cable, and power supply (5V*5A with center positive plug). Warning: some devices like Intel NUC use the same 5.5 x 2.1mm power supply barrel, but at 12V. It’s a good idea to label power supply connectors if you have a bunch lying around because plugging in 12V+ will probably brick your ARTIK.

Setup the Debug Port

Once you plug the USB cable into the ARTIK, 2 blue lights will turn on and on your host side a serial port device will appear (even if device is powered off):

$ lsusb
Bus 002 Device 012: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

dmesg | tail
usb 2-1.5.2: new full-speed USB device number 12 using ehci-pci
usb 2-1.5.2: New USB device found, idVendor=0403, idProduct=6001
usb 2-1.5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5.2: Product: FT232R USB UART
usb 2-1.5.2: Manufacturer: FTDI
usb 2-1.5.2: SerialNumber: ????????
ftdi_sio 2-1.5.2:1.0: FTDI USB Serial Device converter detected
usb 2-1.5.2: Detected FT232RL
usb 2-1.5.2: FTDI USB Serial Device converter now attached to ttyUSB0

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun  2 15:11 /dev/ttyUSB0

As you can see the device is owned by root and belongs to the dialout group, so check if your user is in this group too (groups | grep dialout), then you can use your favorite serial terminal (minicom, picocom) or GNUscreen.

screen /dev/ttyUSB0 115200

That’s it!. If you’re on Windows, enjoy this Cybercode twins’ video to learn a bit about how to get setup.

Ready For Your First Boot

Turn off the device by pressing on the left side of the “POWER SW” 2 states button. Then, connect the power supply, wait about 10 seconds, and hold the SW3 POWER switch for a couple of seconds. After this, U-Boot’s log should be printed in the terminal.

Mine came loaded with the reference system based on Fedora 22. To use this, you can login as root:root and you’ll have at least 13G free (of 16G) to work. Here is a reference file from the flashed OS on the eMMC:

# cat /etc/artik_release

RELEASE_VERSION=1020GC0F-3AF-01Q0
RELEASE_DATE=20160308.225306
RELEASE_UBOOT=U-Boot 2012.07
RELEASE_KERNEL=3.10.93

Since we’ll be setting up a different operating system, I prefer to avoid touching this supported system and I’ll leave it to use as a reference to compare hardware support. The plan is to work on a removable microSD card and not change the eMMC at all.

Boot From an SD Card

Like many other SoC’s like the ODROID devices, booting from a microSD card is supported, but it requires a bit of manual intervention. You first need to configure it using micro switches “SW2” on the left, located between the debug and USB3 ports.

The switch block may be covered with tiny piece of plastic tape, remove it carefully with a toothpick and move both switches from the left (OFF) position to the right where “ON” is printed.

To try my experimental, compressed image, download demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2 (md5:12c64d6631482f90d45a0d015bea5980) from our file server and copy to your microSD card using qemu-utils:

# lsblk
disk=/dev/sdTODO
file=demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2
# time qemu-img convert -p "${file}" "${disk}"

As you did earlier, power the device off, connect the USB cable, insert the microSD card, switch it on, wait for a few seconds, and finally hold the micro switch for a couple of seconds. U-Boot should run through its configuration and some verbose output should be printed on the serial console:

U-Boot 2012.07 (Jun 06 2016 - 10:42:48) for ARTIK10

CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
APLL = 800MHz, KPLL = 800MHz
MPLL = 532MHz, BPLL = 825MHz

Board: ARTIK10
DRAM:  2 GiB
WARNING: Caches not enabled

TrustZone Enabled BSP
BL1 version: ?/???
VDD_KFC: 0x44
LDO19: 0x28

Checking Boot Mode ... SDMMC
MMC:   S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: 14.6 GiB
MMC Device 2: MMC Device 2 not found
In:    serial   
Out:   serial   
Err:   serial   
rst_stat : 0x100
Net:   No ethernet found.
Hit any key to stop autoboot:  0
[Fusing Image from SD Card.]
(...)
reading zImage
5030144 bytes read in 32570 ms (150.4 KiB/s)
reading exynos5422-artik10.dtb
71014 bytes read in 31067 ms (2 KiB/s)
## Flattened Device Tree blob at 40800000
   Booting using the fdt blob at 0x40800000
   Loading Device Tree to 4ffeb000, end 4ffff565 ... OK

Starting kernel ..
(...)

And in the end you’ll get a login prompt for root without password:

Poky (Yocto Project Reference Distro) 2.0.2 artik10 /dev/ttySAC3

artik10 login: root

root@artik10:~# cat /proc/version 
Linux version 3.10.93 (philippe@WSF-1127) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Jun 6 10:39:42 CEST 2016

root@artik10:~# cat /proc/cmdline 
console=ttySAC3,115200n8 root=/dev/mmcblk1p2 rw rootfstype=ext4 loglevel=4 rootdelay=3

Now you are ready for the section on building your own image, but if you really want to make sure everything is working, Canonical supports ARTIK so you can use an Ubuntu snappy image. For reference, I tested artik10-snappy-20160317.img.tar.xz and it reported the following for its Kernel:

Linux version 3.10.9-00008-gb745981-dirty (u@u-ThinkPad-T450) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #7 SMP PREEMPT Thu Mar 10 10:06:16 CST 2016

Build Your Own Image with meta-artik

First we start with Poky: the Yocto reference distro, because it’s the quickest way to reach today’s goal. As with all Yocto targets, you first need to identify a Board Support Package (BSP) layer that collects all the special software needed for this family of hardware. As far as I know there is no official Yocto layer for ARTIK.

I’ve known about meta-exynos but I also noticed the meta-artik community layer from ResinIo; they spoke about ARTIK BSP at the latest Samsung Developer Conference (SDC2016):

What really matters in this set is the u-boot-artik and linux-exynos recipes to fetch sources. So we’re going to make use of my small contribution to produce standalone bootable sdcard images in meta-artik’s master branch.
The patch adds a new class for SD card output; the black magic is that U-Boot params should be dumped to different places (0x00080e00 (1031*512) for ARTIK5 and 0x00099e00 (1231*512) for ARTIK10), if not done I’ll try to adapt this for Tizen too.

Let’s clone Poky, add the layer to your conf file, and build a regular image.

$ git clone -b jethro http://git.yoctoproject.org/git/poky
$ cd poky
$ git clone -b master https://github.com/resin-os/meta-artik
$ . ./oe-init-build-env

With the recipe in place, you need to tell the environment to look for it. For this, edit the bblayers.conf file from the base setup (this file will be in build/conf/ underneath your top level directory) and add a line to the BBLAYERS stanza (there’s no need to add to BBLAYERS_NON_REMOVABLE, that doesn’t apply to this build). Using the format of the base post, the line would look like this:

$ cat conf/bblayers.conf

RELATIVE_DIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../../..')}"
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  ${RELATIVE_DIR}/poky/meta-yocto-bsp \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  "

BBLAYERS += "${RELATIVE_DIR}/poky/meta-artik"

Then, build the image:

$ MACHINE=artik10 bitbake core-image-minimal

When this finishes, write the image to the SD card:

lsusb # list of disks devices
disk=/dev/sdTODO # update device for sdcard
dd if=tmp/deploy/images/artik10/core-image-minimal-artik10.artik-sdimg bs=32M oflag=sync of=$disk

Adding IoTivity

IoTivity is an open source framework that enables effective device-to-device connectivity for the Internet of Things. It implements the emerging standards from the Open Connectivity Foundation (OCF was formerly known as OIC, and the specified protocols still use the oic name, as does the layer described below).

The layered approach of Yocto makes it easy to add components, as long as descriptions exist for them. Otherwise you need to write your own descriptions, which is not too hard. To add IoTivity, add the meta-oic layer:

$ cd ../../poky
$ git clone -b 1.1.0 http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic

Next, add it to previous file (./build/conf/bblayers.conf)

BBLAYERS += "${RELATIVE_DIR}/poky/meta-oic"

We also want to add some of the IoTivity packages into the built image; edit build/conf/local.conf to add these:

# IoTivity
IMAGE_INSTALL_append = " iotivity iotivity-resource iotivity-service"
# To get the example apps, include these as well:
IMAGE_INSTALL_append = " iotivity-resource-samples iotivity-service-samples"

Finally, build it :

MACHINE=artik10 bitbake core-image-mininal

Like before, copy this image to the SD card and boot it up the normal way.

Trying out IoTivity

Once you have installed the example packages, you can find apps to try things out. This is probably more interesting with two machines running IoTivity, so you can have a distinct client and server device, but it is possible to run both on the same machine.

In /opt/iotivity/examples/resource/cpp/ you will see these files, which make up client/server pairs – the names are descriptive:

ls /opt/iotivity/examples/resource/cpp/

OICMiddle              groupclient            simpleclient
devicediscoveryclient  groupserver            simpleclientHQ
devicediscoveryserver  lightserver            simpleclientserver
fridgeclient           presenceclient         simpleserver
fridgeserver           presenceserver         simpleserverHQ
garageclient           roomclient             threadingsample
garageserver           roomserver

Start the simple server, which will emulate an OCF/OIC device, and in this case, a light:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleserver

Usage : simpleserver 
    Default - Non-secure resource and notify all observers
    1 - Non-secure resource and notify list of observers

    2 - Secure resource and notify all observers
    3 - Secure resource and notify list of observers

    4 - Non-secure resource, GET slow response, notify all observers
Created resource.
Added Interface and Type
Waiting

Now start the simple client in the another shell session:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleclient

---------------------------------------------------------------------
Usage : simpleclient 
   ObserveType : 1 - Observe
   ObserveType : 2 - ObserveAll
---------------------------------------------------------------------



Finding Resource...
Finding Resource for second time...
In foundResource
In foundResource
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774In foundResource
/oic/d for the first time on server with ID: 4126ec5c-16ce-4b9b-84e6-15ad6e268774
DISCOVERED Resource:
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/oic/p for the first time on server with ID:         URI of the resource: /oic/d4126ec5c-16ce-4b9b-84e6-15ad6e268774

DISCOVERED Resource:
        URI of the resource: /oic/p
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/a/light for the first time on server with ID:       Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
        Host address of the resource:           oic.wk.d
        List of resource interfaces:
4126ec5c-16ce-4b9b-84e6-15ad6e268774            oic.if.baseline
                oic.if.r
coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:

                oic.wk.p
        List of resource interfaces:
DISCOVERED Resource:            oic.if.baseline
        URI of the resource: /a/light

                oic.if.r
        Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
                core.light
                core.brightlight
        List of resource interfaces:
                oic.if.baseline
                oic.if.ll
Getting Light Representation...

The OIC specifications describe a RESTful model of communications, where everything is modeled as resources and web-style commands are used to operate on representations of these resources, such as GET, POST, PUT, etc. The communication model is called CRUDN (Create, Retrieve, Update, Delete, Notify). In this example, the IoTivity server sets up resources to describe the (emulated) OIC device. Once the client starts, it tries to discover if there are interesting resources on the network using a multicast GET; the server responds to this with the resources it is hosting. In our example, there is a light resource and a brightlight resource (meaning the light that can have brightness controlled). At this point, the two can speak to each other with the client driving the conversation.

We can see the client getting a representation of the state of the emulated light:

GET request was successful
Resource URI: /a/light
        state: false
        power: 0
        name: John's light

It then creates a state on the server that has a power value of 15.

Putting light representation...
PUT request was successful
        state: true
        power: 15
        name: John's light

Next the client tries to update the light state to a value of 55:

Posting light representation...
POST request was successful
        Uri of the created resource: /a/light1
Posting light representation...
POST request was successful
        state: true
        power: 55
        name: John's light

After this, the client sets up an observe on the server so it will be notified of state changes.

Observe is used.

Observe registration action is successful

The light power is updated in steps of 10, with the client reporting to via prints every time it receives a notification. A typical event looks like:

OBSERVE RESULT:
        SequenceNumber: 0
        state: true
        power: 55
        name: John's light

Meanwhile, we can watch the server report the requests it receives and the actions it takes. Once the light power reaches a certain level and the client sees that the last change has been observed, the connection is shut down.

This is just a basic sample of IoTivity in operation, have fun experimenting with this brand new technology for the Internet of Things! There is more to be done from this state, specifically on the connectivity domain such as adding Bluetooth, BTLE, or LPWAN, since these are what matter the most for IoTivity.

What’s Next?

We can expect that Tizen support will improve soon as it’s becoming one of the reference board.

IoT applications have an incredibly wide range of uses; here is an example of work we’ve done within the automotive context:

Feedback is also welcome if you’d like us to explain anything with more depth, such as Tizen support, Tizen OBS/GBS images, or Tizen Yocto, feel free to keep in touch.

[wp_biographia user="pcoval"]

[wp_biographia user="mats"]

ARTIK is a registered trademark of Samsung.

The Future of Open Source, Ubuntu Joins Open Compute Project & New Leadership for the OSI

Open Source Weekly Wrap Up: May 9 -15 2015

2015 Future of Open Source Study

For the last 15 years, North Bridge and Black Duck Software have joined efforts every year to conduct a survey about the use of open source in modern business. A record 1,300 people responded to the survey this year, up from 822 in 2013. Respondents included software engineers, CIOs, CEOs, educators, analysts, and more. There is little that has changed in open source trends, and this survey demonstrates the continued pervasive expansion of open source.

Here are some notable findings from this year’s survey:

Enterprise Use/Participation

  • 78% of companies run on open source, and less than 3% don’t use FOSS at all.
  • 64% of respondents said their company currently participates in open source projects, up 14% YOY.
  • 88% expect their companies to increase open source contributions, up from 56% last year.
  • 66% consider OSS to be the default option before proprietary.

The Open Source Advantage

  • 50% said open source involvement helps their company recruit top talent.
  • 55% said open source delivers better security
  • 89% said open source greatly impacts the speed of innovation
  • 78% said open source improves margins

What Needs Improvements

  • 55% have no policies or procedures for open source compliance.
  • 27% have a formal policy for employee contributions to OSS.
  • 16% have an automated code approval process.

Read More from North Bridge

Snappy Ubuntu Joins the Open Compute Project

Canonical, the lead company behind the Ubuntu Linux distribution, has announced that Ubuntu Snappy will be coming to Open Compute Project (OCP) network switches. Ubuntu will bring an assortment of benefits to OCP, including the fastest, smallest, and most reliable Ubuntu distribution ever, transactional updates for each app and kernel separately with rollback functionality, a new, simpler packaging system, and an assortment of NOS and NFV applications. Penguin Computing will be the first company to offer switches running Snappy, and their initial offerings will include top of rack 10GE and aggregation 40GE models.

Read more from Ubuntu Insights.

Samsung Launches ARTIK, a New Platform for IoT

Samsung has announced the release of ARTIK, an open source platform designed for building IoT devices. The goal of ARTIK is to reduce the fragmentation of the IoT market by providing an end-to-end solution for making interconnected applications for everything from low-powered wearables to high-end smart homes. The group behind the product worked with the team from Arduino to fully integrated the Arduino IDE into ARTIK, making it easier for developers to get started. Samsung is currently taking applications until May 31st to receive an alpha developer kit, so if you are interested in building IoT devices, be sure to check this out.

Read More at the Artik Blog.

The Open Source Initiative Elects a New President

Simon Phipps was elected as the President of the Open Source Initiative (OSI) in 2012, and his term ends in April 2016. He recently decided not to pursue a new term as president of the board, and the board has elected Allison Randal to replace him starting next year. Allison has a long history of working for open source foundations including the Perl Foundation, Parrot Foundation, and Python Software Foundation. She appears to be an ideal candidate to run the organization.

Read more at the OSI blog.