Categories
Eclipse IoT

Running Eclipse Che on a Raspberry Pi

Eclipse Che is a very cool Eclipse technology that provides you with a browser-based IDE that can be extended with plug-ins for virtually any language, framework, or tool that you may want to use in your day-to-day development.

This means that, right from your browser, you can do Java development and have Maven automatically build your stuff, or do Javascript development and still be able to easily integrate with e.g grunt to build your website.

As you may have guessed, most of the magic of Che is in its server. While in many cases you will run the Che server on your own laptop or private server, it’s also pretty cool to run it on an embedded/IoT device such as Raspberry Pi so as not only you have an “IDE-in-a-box” setup, but you can also actually develop code targeting the Pi itself. And yes, that means blinking LEDs… and more ! 😉

Install Docker

Assuming you are running an up-to-date Jessie distribution, it should be fairly straightforward to install the armhf version of docker provided by the Hypriot team.

cd ~/Downloads
wget https://downloads.hypriot.com/docker-hypriot_1.10.3-1_armhf.deb
sudo dpkg -i docker-hypriot_1.10.3-1_armhf.deb
sudo usermod -aG docker pi

At this point, you want to quickly logout and login again, in order for the addition of the user pi to the docker group to be properly applied. Then, we can test that docker is indeed running:

docker ps

This should grant you with an empty list of running docker containers. How surprising!? But at least it means you have Docker setup taken care of!

FWIW, the Hypriot folks have a Debian repo for making things easier. I have had problems with it though so you may want to stay away from it until they fix it?

Downloading Che

wget https://install.codenvycorp.com/che/eclipse-che-latest.zip
unzip eclipse-che-latest.zip
cd eclipse-che*

Updating Che’s built-in stacks to be ARM-compatible

When Che creates your development environment, it instantiates a Docker container that has the tools you need. That is to say, if you are to do Node development, Che can provision a so-called “stack” that contains npm, grunt, etc. The stacks configured by default in Che are based on x86 Docker images, so you will need to replace them with armfh-compatible ones.

sed -i 's/codenvy\/ubuntu_jdk8/kartben\/armhf-che-jdk8/g' stacks/predefined-stacks.json
sed -i 's/codenvy\/node/kartben\/armhf-che-node/g' stacks/predefined-stacks.json

I’ve built an image for Java and Node development, which means you’ll be able to use the “Java”, “Node”, and “Blank” ready-to-go stacks. Should you want to have a look at the Dockerfiles for those, see here.

Note that you don’t have to use the built-in stacks, and you can also create your on-the-fly, using a custom recipe. There as well, the base Docker image you’re building from will need to be ARMHF. You may want to use images from hypriot or armv7 on DockerHub.

Update other default settings

The Raspberry Pi 3 is quad-core, which means you actually get some very decent performances out of it. However, it’s still an embedded sort of device, and SD cards are typically not fast either. It’s a good idea to increase the timeout Che uses to detect a workspace is properly provisioned.

sed -i 's/machine.ws_agent.max_start_time_ms=60000/machine.ws_agent.max_start_time_ms=240000/g' conf/che.properties

Launch Che!

You’re good to go! All that is left is to launch Che. As you will likely be accessing it from e.g your Desktop computer, you need to make sure to use the -r:<external-IP> command-line argument to make sure it works properly from “non-localhost”:

./bin/che.sh run -r:192.168.2.26

Note that depending on your setup, the JAVA_HOME environment variable may not be set, in which case Che will complain, and you will have to first set the said environment variable:

export JAVA_HOME=/usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt

You can actually add this to your ~/.bashrc to make sure JAVA_HOME is always set.

That’s it! You can now use the Java and Node stacks, and start using your web browser to develop right on your Pi, with *all* the features you would expect from a “real” IDE. Enjoy, and stay tuned for a video tutorial soon.

Categories
Eclipse IoT

Upcoming Virtual IoT meetup sessions

We have some really great speakers lined up for the upcoming Virtual IoT meetup webinars. Please make sure to join the group and RSVP for the sessions you’d like to attend.
As always, we’re happy to hear your suggestions for future presentations, so feel free to drop me a note.

https://www.meetup.com/Virtual-IoT/events/229047493

https://www.meetup.com/Virtual-IoT/events/228706327

https://www.meetup.com/Virtual-IoT/events/228632951

Categories
Eclipse IoT

The real benefits of living a connected life

It might be a bit late in the year to do a write-up on The Next Big Thing for IoT in 2016, but it doesn’t mean I cannot take a moment to take a step back from the multiple announcements around the consumer Internet of Things lately, and focus on the cornerstone for enabling a truly sustainable IoT ecosystem: Over-the-air Device Management. Of course it is important for the IoT industry at large to agree on the protocols and frameworks that shall enable IoT application development, but are we not jumping the gun here? I think we should all be thinking first about how we want to leverage over-the-air management capabilities to really revolutionize the way we can interact with the Things around us.

In fact, here are some of the reasons why you need to think of the IoT in terms of how it really changes our way, as humans, to interact with physical devices on a day-to-day basis, before even thinking about all the fancy things you will do with the data you collect, or the smart sensor networks you will build.

Over-the-air provisioning can greatly reduce time-to-market

Do you remember how, just a few decades ago, you would need to use dozens of floppy disks to setup your brand new PC? This workflow has greatly improved over the years, and it is now very common to do the initial provisioning of an Ubuntu or OSX system completely over the air, and the only manual steps involved are essentially limited to entering your name into the system… 40/365 - 02/09/11 - Windows 3.1 Floppy Disk When you think about it, this is incredibly beneficial to both the computer manufacturer, who does not need to worry and make sure its machines leave the factory with the latest OS version that contains the newest features the market is asking for, and to us as end-users, since we always get the most up-to-date system, both in terms of available features, but also security patches, etc.

TPM.svg In the context of IoT, now that more and more devices have strong cryptographic capabilities and start including Trusted Platform Modules, it becomes possible to perform a 100%-secured bootstrap of any IoT device.

Think about it: when it comes to healthcare or automotive, you would not want to have a single doubt regarding the fact that a device is indeed running software that is originating (i.e. signed by) from the manufacturer. A compromised smart thermostat in your living room is one thing, a compromised car is a totally different story. What’s more, being able to delay the moment embedded software is finally put onto a device indubitably leads to reducing time-to-market while allowing for a few extra cycles to innovate on the software front before the device reaches its user.

Fighting planned obsolescence thanks to over-the-air upgrades

Over-the-air provisioning is only the first step in providing a seamless experience for end-users. What we start witnessing with e.g. Tesla is something the car industry has been secretly dreaming of for a century, and is now finally able to achieve: your car can now be fixed (or better: its performances improved) without requiring you to stop by the repair shop.

Indeed, Tesla brings the concept of decoupling hardware and software to a totally different level. Over the years, the upgrades they deployed went from somewhat minor improvements in the user interface of the on-board computer; to much more advanced fixes to the steering or braking system. It is a huge shift for the whole manufacturing industry: hardware design decisions at Day 1 will no longer be limiting the capabilities of a device overtime, and over-the-air updates will allow for actual improvements in safety, stability and overall user experience overtime.

Bypassing some physical constraints we never thought we could

The lifespan of a house is literally decades, which means that in many cases smart sensors and devices are literally set in concrete. Should a buggy sensor really be forever condemned, when it could be upgraded over-the-air?

Not only can over-the-air updates help fix faulty hardware, but it can actually help you in situations where you don’t have physical access to the culprit. Technologies like 6LoWPAN allow battery-powered devices to communicate wirelessly for years, so why not just deploy a new PID temperature control algorithm in that smart thermostat of yours rather than spending yet another couple hundred dollars for a new one (…just like you did last year, and the year before that!).

Avoiding vendor lock-in for a truly interoperable IoT

5997130009_4e29c6919c_mWhile it is understandable that some vendors may want to lock-in customers to their platform, I really believe that in the long run, the manufacturers who will be relying on open device management standards and give their users some control of their device will be the ones that will stay ahead of the game.

Would we really expect to buy an electric appliance without being sure that the plug would fit in our wall socket? That is exactly what we are talking about here, and that’s why standardization initiatives like what the Open Mobile Alliance is doing with LightweightM2M (LWM2M), or the work of the AllSeen Alliance and the Open InterConnect Consortium are really important. In the mobile and handset industry, a standard like OMA-DM is used in literally billions of devices and, because it’s an open-standard that practically every mobile handset implements, it enables large corporations with a standard way to manage their fleet of phones, without any vendor lock-in.

For the Internet of Things, vendor neutrality is going to be key for finally getting to the point where the general public starts seeing the Things of the Internet of Things as equipment they have control of (as opposed to scary black boxes wirelessly tethered to a company’s backend via an obscure communication protocol). Luckily, many players in the IoT industry understand the importance of device management, and I am hopeful that with Eclipse IoT we are doing our share by providing a framework for open innovation, and open source implementations of technologies like LWM2M, MQTT or CoAP.


This post was brought to you by HARMAN’s Engineering a Connected Life program. The views and opinions expressed in this post are my own and don’t necessarily represent HARMAN’s positions, strategies or opinions.