Skip navigation
1 2 3 Previous Next

Pi IoT

204 posts

After a series of timeline delays due a lot of (several) personal troubles I can restart the publication of the project blog posts with some smart updates. The project is near to be finished and in few days also the presentation location and dates will be official.

Full 3D printed

Art-a-tronic_Assembling 22.jpg

The Art-a-tronic opera is totally 3D printed and the final assembly has been finished. To make the final moving object (35x35x20 cm size) it was necessary to design 28 different mechanical parts resulting in 41 different printed pieces:

  • 13 White parts: the image background
  • 7 Blue parts: the moving shapes of the image
  • 11 Black parts: elements and supports to make the blue parts moving
  • 7 Orange parts: to lock the special nut moved by the vertical axis
  • 4 Red parts: to create the support base and the stepper motors support to the bottom of the moving elements.


{gallery} Components design


The white parts composing the background exposed surface (35x35 cm)


The four blue parts composing the main shape. These parts moves toward the viewer laying on the white background


The three blue parts composing the image details (eyes, nose and lips). These parts moves inside the background holes from the bottom of the base


The eleven black parts supporting the blue parts movements


The four red parts. When assembled these are the main base of the entire structure.


The special nut motion screw holder, top view


The special nut motion screw holder, bottom view


The images below shows some details of the final assembly

IMG_20160926_175807.jpg IMG_20160926_180623.jpg

Every vertical moving part has an actuator built with a 28BYJ-48 geared stepper motor controlled by a LM298 motor controller; a total of 7 steppers + 7 controllers.

Stepper screw holder changes

GiuntoMotore2.png GiuntoMotore3.png GiuntoMotore4.png

As shown in the above images the original design for the stepper screw holder was 3D printer components too. The reason was the difficulty to find on the market similar metal components cheap and of the exact measure to fit the design. An easier solutions has been adopted instead as I have found strong and semi-flexible small hose: this material common use if for fuel and gasoline, so it is also resistant including temperature and solvents. And easy to manage and cut too. The images below shows in detail shows the final assembly.

Art-a-tronic_Assembling 6.jpg Art-a-tronic_Assembling 8.jpg

Art-a-tronic_Assembling 7.jpg Art-a-tronic_Assembling 1.jpg

Cabling the system

As show in the previous images, every stepper motor and controller are already connected together and fit inside the base. Then there are three different wiring solutions to be adopted: powering the system, controlling the motors and controlling the end-stop switches.

Art-a-tronic_Assembling 22.jpg

The final aspect as should appear (not yet boxed) to the visitor is shown in the image above.

Below the top view of the base with the stepper motors connected to the controllers and the powering cables. The motor controllers also provide a 5Vcc output and are used for all accessory powering than the motors.


End-stop switches

A special solution was needed to control the position of the mobile components, including the auto-zero finding. The three components that raise from the bottom has their zero point at the max height while the rest of the image mobile parts (the four blue ones) has their zero point laying on the white background surface. The startup sequence should include the initial auto zero position then parts are moved to their standby level. The form factor and the kind of end of stroke makes it impossible to use common end-stop switches as we are used to see in the 3D printers, mill machines etc.

Custom end-stop switches has been created with copper wire glued (with conductive glue) on both sides of the contact surfaces. The images below show ow the cabling has been setup on the bottom side of the white background.

Art-a-tronic_Assembling 26.jpg Art-a-tronic_Assembling 25.jpg

The nut holder is also used as the end-stop contact. This means that the auto-zero is inverted respect the lower position, but this is a bare question of the software on the microcontroller.

Art-a-tronic_Assembling 12.jpg Art-a-tronic_Assembling 14.jpg Art-a-tronic_Assembling 13.jpg


Using the same method the three bottom components has been set with their end-stop custom switches.

Welcome to installment number twenty seven of the Design Challenge Project Summary series here at Element14. For those of you who are new to my content, in this series, each week, I chose single Design Challenge project from the current challenge, or past challenges, and write a short summary of the project to date. If the challenge in which the project is part of is ongoing, I will periodically update this post until the challenge is finished. I am sure that some project summaries will get more than one update if they themselves are updated frequently. Unfortunately, projects that stall out, or get abandoned, will not receive any updates. Additionally, some project creators like to keep their own project summary going, and this series is not meant to overshadow those post, but to highlight each project from an outsider's perspective.




The subject of this installment is project Thuis, by Robin Eggenkamp (rhe123). Thuis was part of the 2016 Pi IoT Design Challenge dubbed Smarter Spaces. In this challenge, participants were tasked with creating a smart environment using a Raspberry Pi and several accessories such as the EnOcean PiEnOcean Pi system.


Robin has been an IoT enthusiast for quite some time, and it was natural that he apply to join the Pi IoT Smarter Spaces Design Challenge, as he had some of the home automation infrastructure in place already. In his project’s introductory post he laid out the plan for what would eventually become the challenge’s second place finisher. Robin set the goal of building a system that would be able to control several aspects of his home including lighting, TV entertainment, energy monitoring, an easy to use mobile UI, and a welcome home system.


“The end product of this challenge will be an improved home automation system in my home. The core of the system will be a Raspberry Pi 3Raspberry Pi 3 with a WildFly server. The Java EE application running on this will manage the logic of the house and bridge the several parts together. On this same Raspberry the Razberry/Z-Way software will be installed to be able to communicate with Z-Wave devices. Another Raspberry will be used as part of the Home Cinema setup and will be hooked up through HDMI to the AV receiver. It will control a.o. the receiver and TV via CEC. Other apps in the system include the iOS apps for both iPhone and iPad, which act as remotes,” Robin said.




The project’s second post briefly clued us in on some of the hardware that will be used to control several features of the home including, Z-Wave lighting dimmers, iBeacons, and Move, a motorized Bluetooth controlled device that can open and close blinds and shades. Robin did mention that his home already has several Z-Wave devices, and Raspberry Pi boards in it, so he does have a bit of a head start already.




In update number three, Robin introduced us to the software architecture for the project. “At the heart of Thuis there is a Java EE application running in a WildFly container on a Raspberry Pi 3. On the same node Z-Way (a Z-Wave controller), Mosquitto (a MQTT broker) and a database (which one is to be decided later) are running. They are sharing the same node to save budget, but because of the modular set up they can be split on to multiple nodes.

Initially the core application will be built around a MQTT observer: it subscribes to all available topics and knows what to do when certain messages arrive,” he said. “All the rules live here, has knowledge of all devices, and keeps their status up-to-date. Different types of commands can be linked to each device and executed for them. Execution happens in prioritized JMS queue. This makes it possible to execute some commands in a predefined order and prioritize user initiated actions above background tasks.”




Update number four focused on using a program called Chef to build an install profile that would automatically provision Raspberry Pi nodes with identical software and settings. Unfortunately, Chef does not support the Raspberry Pi out of the box, which makes bootstrapping much harder than it is with other platforms. Robin has found a workaround for this though, and he provides a full tutorial on how to use this workaround to make Chef work correctly. This post also covers the basis of how Chef works, and helps the reader to better understand some of the nomenclature that Chef uses.




In update number five we learn more about what a Chef recipe is, and how the Thuis cookbook is created. The Thuis cookbook is made up of several different prewritten recipes found in the Chef supermarket, as well as some that were written by Robin himself. “I selected several cookbooks from the Supermarket and wrote some myself,” he said. “Using a series of recipes I defined the software and configuration of two of the nodes of Thuis in the Thuis Cookbook. In this post I’ll show you my choices and give some code samples to let you set up your own Chef config.” I have used a similar program called Puppet before to automate website development environments with a CMS called Drupal, but I have never even thought of using something like this to deploy multiple Raspberry Pi with the same configurations, but I can not wait to give this a try for myself.




The official challenger kit arrived in update number six, and Robin got started with getting the new Raspberry Pi 3 up and running. Thuis will use a distro called raspbian-ua-netinst as a basis for its install, as this gives the Pi 3 a very lean install of Raspbian. Unfortunately the project’s maintainer has not gotten around to updating the software to be compatible with the Raspberry Pi 3 yet, so Robin had to perform some manual steps to get everything up and running correctly. Luckily for us, he documented the whole process, so that we could easily follow along at home. The post concluded with bootstrapping Chef to the device, and then we got a brief tutorial on how to configure Z-Way and how to deploy an application to WildFly.




Update number seven walked us through the process to publish activity from Z-Way to MQTT. “Whenever the status of one of the selected devices changes it will be published to a topic. Based on these topics some other topics are available to change the status of the devices or request a status update,” he said. This tutorial was quite eye opening for me as I am working on a smart home project, and one of the things I have not figured out yet was how to connect Z-Way and MQTT together. As of this writing, I have yet to try this out for myself, but I am sure that the method described in this post will work perfectly for my application.


Update: September 30, 2016




In update number eight we got a brief glimpse into Thuis’ past as well as its future. If you have not yet read the post, Thuis got its start well before this challenge was announced, and the project’s namesake is actually the control software for Robin’s current smarthome setup. Thuis is written in Java, and currently runs on a Raspberry Pi 3Raspberry Pi 3, with the actual software being inside a WildFly container. This update mainly focuses on improving the Thuis core, and how to more efficiently utilize MQTT. “In a later stage some more external systems will be added to the core, for example for controlling the Home Theater. I'm also aware that, to keep this blog post from growing too much, I have simplified some code samples and didn't cover every detail,” he said.




Update number nine focused on providing readers with a sort of visual update to how the project is progressing so far. Robin made this post to update readers as to why progress on the project had stalled out for most of the past month. As everyone knows, life does get in the way sometimes, and we have to step back and focus on more important things. Thankfully, Robin returned, and progress will move forward from here. If you are confused about where all of the systems development sits as of this update, this post covers everything.




Every home automation system in the world would be mostly useless if it’s owners had to connect to a terminal, and then issue text commands to use the functionality of the system, and Robin agrees with this. In update number ten, he walked us through how he created a UI for IOS that features elements that can be linked to MQTT. To keep things simple for now, he decided to only create the three elements that would be most useful with the current system: a button, slider, and an info tile. The button will play a dual role as an indicator, as well as a trigger, meaning that it will display the state of the toggle and pressing it will change that toggle. The slider will mostly be used with the lighting dimmers that we saw in an earlier post. Finally, the Info Tile element will be used to display the current state of something such as the temperature of a room. If you are getting ready to build an UI for your home automation system, this is definitely a post you need to read.




Update number eleven continued with the Thuis UI build for IOS, and as you can see from the image above, it turned out very well. Robin even managed to get the UI working on iPad devices and not just iPhones, and he even wrote a short tutorial so that readers can enable their app to work with both devices as well. “From my holiday location at the coast of Bulgaria I finished up the implementation of the UI of Thuis. It works nicely on both the iPhones and the iPad on the wall,” Robin said. He included a demo video of the Thuis UI in action, but you will have to read the post itself to check that out.




One of my favorite aspects of home automation is the ability to manipulate any connected lighting you have in your home, and in update number twelve, Robin educated us on how to properly install a Z-Wave based dimmer unit into an existing light fixture, and then how he added a control for it into the Thuis UI. Connected lighting was one of the first things I tackled in my home, and from my experience, that statement is true for most novices to home automation. I am sure this post will help many people for years to come.


Update: October 2, 2016




Update number thirteen saw the start of the presence monitoring system for Thuis, and in doing so it also accomplished the “Welcome Home” use case. Utilizing iBeacons, small Bluetooth LE devices, Robin was able to develop a system that is capable of detecting who is home, and what room that person is in. This allows Thuis to perform a specific command, or set of commands based on which user is where in the home. An example of this functionality would be to turn on the foyer lights when the foyer’s iBeacon recognizes any of the home’s residents entering into that room. To top this system off, Robin was able to tie everything back to the main Thuis hub, and then use that data to perform other tasks. This is yet another update post that you have to read for yourself to fully grasp all of the possibilities that this system opens up.


2016-10-04 20_26_03-Pi IoT _ Authors _ r... _ element14 _ Pi IoT.png


In update number fourteen, Robin began working on integrating his home theater into the Thuis system, a series which he says will complete over three separate update post. In this first part he showed readers how to begin communicating with CEC-enabled devices from a Raspberry Pi. “Let's start with a short introduction of CEC itself. CEC stands for Consumer Electronics Control and is a feature of HDMI. CEC enables HDMI-devices to communicate with each other. In the ideal situation this means a user only needs one remote control to control all his devices: TV, AV receiver, Blu-ray player, etc,” he said. “Unfortunately many manufacturers use their own variation of CEC and therefore in a lot of cases one still needs multiple remotes.” To get around this issue, Robin made use of the libcec library, which enables the Raspberry Pi to “interact with other HDMI devices without having to worry about the communication overhead, handshaking and all the differences between manufacturers.”



Home theater integration continued in update number fifteen, with Robin focusing on device control. “Before we can use any devices in Thuis we have to define them. You might remember from [Pi IoT] Thuis #8: Core v2: A Java EE application that we have a class Devices containing static definitions,” he said. After some quick code snippets were written, Robin was able to control the power on and off functionality of his TV, Apple TV, and stereo receiver. He finished up the post by integrating a Wake On Lan (WOL) command into Thuis that would turn on his Network Attached Storage Array (NAS) when Thuis needed to connect to it.



Update number sixteen covered one of my favorite pieces of  software for a home theater setup, Plex. For those of you who are not familiar with Plex, it’s “software which makes it possible to enjoy all of your media on all your devices. When on the server you create a library based on video (and music, photos, etc) files, Plex finds the corresponding metadata and gives you an easy to use interface to browse and play your movies,” Robin said. “You can interact with Plex through its API and you can keep up-to-date with what's happening on each client by subscribing to the WebSockets channel.” I won’t go into detail here on how Plex is setup, but Robin covers the more advanced aspects of his install in this post.



Update number seventeen concluded Project Thuis, and Robin clued us in on what parts of the project were made available in the open source realm on his GitHub. Overall Robin contributed five segments of the project back to the open source community, and seven unique use cases that are sure to find their way into the home automation projects of others. Watch the demo video above, and then head over to the full post to find out what the future holds for project Thuis.


That is going to wrap up my project summary coverage of project Thuis for now. Robin ultimately won the second place prize for this project, and I have to say that I personally feel that it deserved a top three finish! This project has been an absolute joy to follow, and has been educational throughout. Please visit the project’s blog page to read it in it’s entity! Tune in next week for another Design Challenge Project Summary here at Element14. Until then, Hack The World, and Make Awesome!  


The Challenge


Before I get into the reason for this post, let's take a moment and talk about what this design challenge was all about. The Pi IoT Smarter Spaces Design Challenge was the second official design challenge of 2016, and tasked its contestants, and anyone else who wishes to participate, to create a command center to control all the IoT devices in their favorite space - the entire home, a work space, a media room or even an outdoor space. More information can be found at the challenge's official Terms and Conditions page.


Fourteen projects were chosen to participate, with their creators receiving an official challenger kit that contains the sponsored hardware that must be used to create their projects. The challenge was not limited to these thirteen people though, and anyone can enter their project into the challenge, but they were also required to use a Raspberry Pi 3Raspberry Pi 3 in their design along with some of the other sponsored items that are included in the official Challenger Kit. More information can be found on the kit in this post outlining all of the hardware the challengers received.


The Prizes

2440163-40.jpg duratool.png


The challengers competed to win an awesome assortment of prizes, including a CEL - Robox 3D Printer CEL - Robox 3D Printer, and an assortment of tools from Duratool. More information on the prizes can be found here.



Thoughts on The Challenge


The summer is almost over here in the northern hemisphere, and that means that the Pi IoT Smarter Things Design Challenge has come and gone. Over the past seventeen weeks or so, I have read through every update post its challengers have made, and I want to say that I am beyond impressed with everyone who took part in this Challenge. I personally know how hard it is to build a complex project on a very tight and precise schedule, and I can honestly say that the participants from this Challenge figured out the secret to keeping it all together. For that, I applaud each and every one of you.


All of the projects from this Challenge were very inspirational, and beyond anything I have seen so far in the last several Design Challenges. With that said, I would like to congratulate everyone who managed to finish their project in the allotted time, while also encouraging those who did not finish, to keep pushing forward to complete their projects. Even though the Challenge has concluded, there are still many of us who return to the content page every day looking for new updates. In fact, there is nothing to stop anyone taking on this Challenge anytime in the future.


On a personal level, several of the projects have inspired me to begin building out my own custom smart home interface, and I have even begun writing my own tutorials based around some of the ideas the Challengers brought to the table. From Frederick Vandenbosh’s Alarm Clock, to the competition aspect of Caterina Lazaro’s Smart Competition Home. I have even included some automated elements into my small hobby farm, thanks to Jon Morss’s Remote Horse Feeder System. I can not thank the Challengers enough for this inspiration, and I can not wait to see what each of them develop in the future!



The Winners

With my personal opinions to the side, let's jump straight in and get to the reason you clicked on this post in the first place, but first one of our judges, Roger Thornton, Principal Hardware Engineer at the Raspberry Pi Foundation would like to say a few words about the challenge and congratulate all Challengers and Winners personally and on behalf of element14 and all the Sponsors.



As you all know, the Challenge started off with fourteen projects chosen to compete, and of those fourteen, twelve projects stayed active almost all the way to the end. Of course, not all twelve could make their way to the winners podium, and only three could take the main prizes home. So without further adieu, here are our top three projects for the Smarter Spaces Design Challenge.


Pi IoT Grand Prize Winner1st Place - Project IoT Alarm Clock by Frederick Vandenbosch(fvan).




Frederick’s IoT Alarm Clock  is one of the most polished projects I have seen posted to any of the Design Challenges since I started covering them last year. The clean lines of the wood enclosure, combined with the feature rich interface that he built to control his smart home was simply second to none. Each of Frederick’s update blogs were clean, consistent, and very informative for both engineers and hobbyists. Furthermore, his ability to document every aspect of the project made things very simple for those at home to follow along for themselves. To top all of this off, Frederick actually moved to a new home mid-way through his project’s build, making the end result even more impressive. To read through the entire project, head over to its blog page.


For his first place win, Frederick will take home a CEL Robox 3D PrinterCEL Robox 3D Printer, and a full compliment of Duratool tools for his workbench. Congrats Frederick, you deserved this!


Pi IoT Second Place Winner2nd Place - Project Thuis by Robin Eggenkamp (rhe123).



Thius by Robin Eggenkamp is one of those projects that you simply fall in love with as an engineer. Its clean execution, excellent documentation, and ability to be easily replicated at home makes it the trifecta of perfection. Robin did an amazing job of bringing his original concept to life, and I commend him on such an excellent execution.  As I mentioned in my opening paragraphs, I was inspired by many of the projects in this Challenge, and Thius was full of inspiration for me. Head over to the project’s main blog page to read it from the beginning. Congratulation Robin, and I hope to see you in future Challenges here at Element14.


For his second place finish, Robin takes home an awesome assortment of tools from Duratool, including an awesome Field Service Kit, Mechanical Tool Kit, and much more. Head over to the official Smarter Spaces prize page for a full rundown!



Pi IoT 3rd Place Winner3rd Place - Project Plant Health Smart Camera by gpolder (gpolder).



Taking home the third place trophy is Gerrit Polder with his project Plant Health Smart Camera, one of the most innovative agriculture-based IoT projects I have seen in a long time. The utilization of OpenCV, and comparisons of images taken in different spectrums of light truly amazed me. Much like the other two top projects, Gerrit was masterful at documenting the progress of this project, and I felt that it was easy to follow along with at home. If you would like to read more of this project, please head over to its main blog page!

For his third place finish, Gerrit takes home a Duratool Tool KitDuratool Tool Kit, and Rotary Tool Accessory KitRotary Tool Accessory Kit.



First Honorable Mention - Smart Competition Home by Caterina Lazaro (clazarom).




I really enjoyed this project, and it’s fresh approach to making a smart home even smarter. The competition aspect of it simply blew me away, and really gave me a new outlook on what a smart home can truly be. Instead of just a bunch of sensors, and relays, a smarthome can include competitions, games, entertainment, and anything else we can dream up. I want to offer a huge thanks to Caterina for working so hard on this project, and for demonstrating such amazing out-of-the-box thinking. If you have not yet read through the whole project, I highly suggest doing so by visiting its blog page.



Second Honorable Mention - Project DomPi by Sergio Martinez (mg.sergio).




When I talk about gaining inspiration to create my own smart home interface because of this Challenge, I can not speak highly enough of this project. Sergio’s sensor integration using arduinos and MQTT to relay data back to a Raspberry Pi Raspberry Pi in the beginning of the Challenge was what started the gears in my head turning. I really enjoyed watching this project progress over the last few months, and I will be incorporating many of its aspects into my own smart home. If you too have been inspired to create your own Smarter Space, please read through the project by visiting its blog page.



That is going to wrap things up for this post. I would like to once again congratulate our winners, as well as everyone who took place in the Pi IoT Smarter Spaces Design Challenge.

Today on the national newspaper "La Stampa" in Turin, Italy. Thanks to the journalist Noemi Penna that has mentioned the sponsors sites.

In attach the pdf version, as soon as possible I will update the post with the English translation.

Nasce in Piemonte il primo quadro che prende vita per parlare ai non vedenti - La Stampa Full.png

Today on paper and digital format. Italian version, soon the translated update. Pdf version in attach.


The internet of things (IoT) is the internetworking of physical devices, vehicles, buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data.

In 2013 the Global Standards Initiative on Internet of Things (IoT-GSI) defined the IoT as "the infrastructure of the information society."

The IoT allows objects to be sensed and/or controlled remotely across existing network infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy and economic benefit.

(source: Wikipedia)


IoT is strictly related to the human behaviour and his interaction with certain kind of environments.

The most common approach and widely recognised as human-environment interaction consider the user (the interacting subject) as the actor, controlling the change of the surrounding environment (room, house, working place, public area etc.), locally or remote with some kind of tool; Maybe it is a smartphone or something more specific.

We see the Internet of Things as a fast growing technology embracing almost all the places where human live; the biggest player seems to be any kind of home automation, from the door lock to the audio-video media system, the home lighting and many more.

Muzieum-1600x1600 1.jpg

Thanks to the support and sponsorship of Element14 itself and the company, it was possible to design and develop a significantly different project: a self-adapting environment modelling its behaviour depending on the kind of detected interaction.

The MuZIEum project represents the evolution of the initial idea, the perfect reading place, originally designed for the Element14 PiIoT challenge. It has been created with the cooperation of the MuZIEum in Nijmegen, Netherlands and the MuZIEum itself is the reason of this evolution. Thanks to the support and precious collaboration of Carlijn Nijhof - project manager of the MuZIEum - the idea evolved aiming to create an environment able to self-adapting to the user interaction as a new user is autonomously detected by the environment itself.

The MuZIEum is a particular structure near downtown in Nijmegen, Netherlands, exhibiting ad very special kind of experience offered to the visitors; it aims to remove the prejudice bareer that usually people have towards visually-impaired persons. This is ruled through a series of different experiences, including a one-hour visit in a totally dark recreated real place assisted by a blind person. A totally unexpected and incredible experience for us, used to base most of our life on the reality we can see with our eyes.


More details on the MuZIEum experience and their project can be found in the previous posts below:

PiIoT - The perfect reading place #3: Open your eyes, the challenge in the challenge

PiIoT - The perfect reading place #4: first live broadcast report and project design activities


In this article we define the components of the project and their functionality and usage; as agreed with the MuZIEum staff next December, 8 this Internet of Things installation will be available to the visitors as a permanent installation in the MuZIEum in Nijmegen together to some other new elements to give to the visitors a unique and unbelievable expericene.


The name originates by joining the two words Art and Animatronic. Based on an original opera of the digital artist Lorenzo P. Merlo, I have further processed the opera to make it animated. The final goal is to empower the image components of a visual-art image making it a series of solid parts linked together that can be touched as well as viewed.

Test 3D printing_IMG-20160705-WA0001.jpg.jpeg

The animated opera will be exposed together with the original one; both are sized about 35x35 cm.

The original subject is a one-copy digital printed on Aluminium. Both will be signed by the author(s)

Due the depth size of the Art-a-tronic version of the opera it will be included in a red box (the MuZIEum color) obtained by hacking an Ikea Valje wall cabinet as shown below.

Screen Shot 2016-09-10 at 18.21.26.pngMuZIEum Live 1600x1600 8.jpg

As already discussed with Carlijn Nijhof the ideal installation for the work seems to wall-mount it; maybe we will provide a movable installation, still to be decided. The Art-a-tronic component will be one of the nodes connected to the rest of the project.


Features and interaction

  • When in standby condition (no interaction) the moving surfaces are at the same level of the rest of the opera.
  • A low intensity traversal led light will create visual effects with cyclic colour changing
  • An ultrasonic sensor detect the presence of a visitor that automatically activate the moving parts so that the subject becomes easy to be perceived in its components.
  • A set of predefined text to speech messages invite the visitor to touch it
  • After a number of seconds (maybe a minute) that no presence is detected the system returns in stand-by position

(Note: the text content will be reviews by the MuZIEum team)



Both the visually-impaired and the non-visually impaired visitor can experiment how the same opera can be perceived at different levels by seeing, touching and hearing it.


Provided by the MuZIEum

The Art-a-tronic installation - better if wall-mounted in a permanent location - includes in the red box all the circuitry and components that are not accessible to the visitors.

  • A power-plug is needed to power the installation
  • WiFi access to the MuZIEum WiFi


Sense Interactive



We need an interactive user interface supporting some special features: should be usable and ergonomics for any kind of user. No right or left-handed, no buttons, not special motion paths of starting position. Sense interactive is a mouse-sized device easy to be managed with one hand covering the characteristics mentioned above and more. The user - any kind of user - interact with the sense interactive interface and the connected system react. But when the system detect the user presence it is able to notify the user speech where he is and what he can do. This maybe very helpful for a visually-impaired user as well as showing an uncommon perceptive experience to a non-visually impaired user. To do this the common interface and feedback approach has been revised and reinvented.

As the subject is detected the system speaks to him inviting him to interact through a coloured and fast reactive interface. If the subject can't see the device the controller is anyway able to give responses. The user can follow a fast and easy self-learning path based on the suggestions of the system, his actions and his gestures.


Sense interactive includes a hands-free Bluetooth device and support the voice recognition. The device and its audio component is part of the adaptive desk and is another Internet of Things node connected to the system.

As a matter of fact every node can be displaced in a separate location but as already discussed with the MuZIEum team manager we aim to organise different devices on a single surface accordingly with the needs of the location

Provided by the MuZIEum

The Art-a-tronic installation - better if wall-mounted in a permanent location - includes in the red box all the circuitry and components that are not accessible to the visitors.

  • A power-plug is needed to power the installation. If the Sense interactive device is connected together with other pars it will be powered by a single power plug.
  • WiFi access to the MuZIEum WiFi


Dynamic Surface


Dynamic surface is another subproject, alias another node of the MuZIEum Internet of Things project. It is an independent moving platform: it is a physical 8x8 matrix built with big (8 cm diameter) moving pixels.

The Dynamic Surface is a series of 81 modular, physical pixels - named m-Pix - assembled in a square matrix creating a flexible and reactive surface.

We can also think to this structure as a Robotics POP modular dimensional display

The Dynamic surface installation has a dimension of about 70x70 cm and a depth of about 25 cm. It can be installed independently on a desk or flat surface or together with the other interactive nodes.



The Dynamics surface aims to show to the visitors how a graphic representation - e.g. an icon, a sign, a character, a colour shade - "converted" to a touch perceptual surface. One of the features of the Dynamics surface is changing the m-Pix heights miming the orientation of the Sense interactive device as well as representing "touchable" imagery elements.


Provided by the MuZIEum

The Art-a-tronic installation - better if wall-mounted in a permanent location - includes in the red box all the circuitry and components that are not accessible to the visitors.

  • A power-plug is needed to power the installation. If the Sense interactive device is connected together with other pars it will be powered by a single power plug.
  • WiFi access to the MuZIEum WiFi


Main controller and connected nodes

There is a main controller node coordinating the parts explained above and provide a set of common sensors, used to adapt as fast as possible the environment behaviour to the visitor interaction:

  • Presence and movement detection ultrasonic sensor
  • Camera for face recognition and gesture control
  • Generic audio output
  • Data storage
  • Voice controlled and gesture controlled web navigation and e-book reading with test-to-speech


The main controller can be installed on the same desk of the other components or as a separate unit.

Acrylic Case


I'm not sure if it is proper to continue the blog after the challenge, so someone could smack me around if not, but I plan to continue working on the project so here be a short post post.


At the end of the challenge, the parts of the Feeder System were sprawled out on the table but I do plan to have them tucked away into some sort of enclosure.  I decided to take a stab at creating an enclosure using acrylic sheets, and after 2 days of work using a Radio Shack dremel tool and a drill, I was able to get the Pi Face Display and Control enclosed.  It would have been much easier to tap into the local Hacker Lab or MakerHQ to use their laser cutter or 3D printers, but I'm a glutton for punishment and wanted to see what I could do on my own.  What I did learn is that acrylic is not easy to work with.  Getting 99% done with a part to have it crack or break while trying to drill the final hole can be frustrating.  Also, when gluing ( or rather welding Acrylic ), it would be best to obtain the proper material for doing so. In my case, the local ACE Hardware folks had no idea of what to use to weld acrylic, so I snatched up a bottle of Gorilla Glue (a.k.a. Gorilla Snot); later I discovered there is a Tap Plastics location not far from my home.  What I found with the Gorilla Snot is that it has a strange chemical reaction with plastic and the little dabs of glue that were placed in the cracks of the case kept growing and expanding leaving what certainly looks like Gorilla Snot.  The good thing was that this covered up any gaps in the seams and disguised the flaws in the cuts.

PiFace Display and Control case Gorilla Glue


I found a good video that showed the proper way to drill the holes in acrylic which includes starting with a small size drill bit and working up bit by bit to the size needed.  Otherwise, if you drill a pilot hole and then try to use the larger bit, the acrylic will crack. I found drilling the piece when it was still part of a lager sheet made things a bit easier.


So, after all the frustration, I ended up with a fairly nice looking case for the PiFace Display and Control which will be part of a larger case to enclose the rest of the devices.  "Baby Steps."

This is what the case looks like with the Display and Control place in it; note the white snotting looking stuff on the edges and in the lower part of the case; this be the dried Gorilla Snot.

PiFace Display and Control Acrylic case

The bottom with button access.



That is all I have for now, and unless someone tells me otherwise, I'll just keep posting the updates to this and work to completing the system.






prowl.pngThe challenge may be over, it doesn't mean the project cannot be further improved or expanded!


In this post, I will cover the notification feature for iOS devices using Prowl, which can be useful to notify the home owner in case of anomalies. An example could be that the garage has been opened while the key is still in the key holder, or that the front door remains open longer than a certain amount of time. I have covered this in the past, during the Forget Me Not Design Challenge, but as I'm using OpenHAB 2, some steps are different in the deployment of the notification feature, hence the new, updated post.


OpenHAB 2


The main difference since last time, is that I'm using the OpenHAB 2 beta, and not all bindings have been ported to the beta yet. As a consequence, I have to manually add the OpenHAB 1 Prowl binding into my OpenHAB 2 installation. Though I'm currently using this procedure for the Prowl binding, this should be applicable to any other OH1 binding not yet available for OH2, assuming they are compatible.




Because we will be running a OH1 addon in OH2, we need to verify this feature is enabled in OH2. This is done by manually starting OH2 and entering some commands at the prompt.


Manually start OH2:


pi@pictrl_livingroom:~ $ sudo /usr/share/openhab2/
Launching the openHAB runtime...

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.0.0.b3

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.



Verify the "openhab-runtime-compat1x" is installled, it was in my case:


openhab> feature:list | grep compat
shell-compat                              | 4.0.4            |          | Uninstalled | standard-4.0.4          | Karaf Shell Compatibility
openhab-runtime-compat1x                  | 2.0.0.b3         | x        | Started     | openhab-aggregate-xml   | Compatibility layer for openHAB 1 addons


If it isn't, install it:


openhab> feature:install openhab-runtime-compat1x


That should be enough to run OH1 addons in OH2.




Next, deploy the actual addon.


Go to the "/tmp" folder and download the addons from the openhab website:


pi@pictrl_livingroom:~ $ cd /tmp/
pi@pictrl_livingroom:/tmp $ wget


Unzip the package and move the desired addon to the OH2 addons folder:


pi@pictrl_livingroom:/tmp $ unzip
pi@pictrl_livingroom:/tmp $ sudo mv /tmp/org.openhab.action.prowl-1.8.3.jar /usr/share/openhab2/addons/


Cleanup the remaining addons:


pi@pictrl_livingroom:/tmp $ rm -rf org.openhab.*


The addon is now deployed.




Finally, configure the addon with the necessary parameters. In case of the prowl notifications, and API key is required. This key can be obtained by creating a free account on


Screen Shot 2016-09-02 at 21.46.11.png


Once you have a key, create the prowl service config as follows:


pi@pictrl_livingroom:~ $ sudo nano /etc/openhab2/services/prowl.cfg



Prowl is now ready for use!






On the server side, OpenHAB rules can be used to trigger notifications when a certain condition is met. A sample rule would look like this:


import org.joda.time.*
import org.openhab.model.script.actions.*

var Timer alertOn

rule "Alert Light"
    Item EnOcean_sensor_00298B1A_B received update
    sendCommand(TowerLight, 1)
    pushNotification("Alert!", "You have been summoned.")

    if(alertOn!=null) {
    alertOn = createTimer(now.plusMinutes(5)) [|
        sendCommand(TowerLight, 0)



This rule will light up the Tower light when the correct button is pressed, and will in addition, trigger a push notification.




On the client (your smartphone, tablet, etc ...) an app is required: Prowl. Download and install the app, use the same credentials to log in as used to request an API key. You are now ready to receive notifications!


When the above rule is triggered, a notification appears in the device:




Et voila, custom notifications!





Navigate to the next or previous post using the arrows.


Welcome to installment number twenty four of the Design Challenge Project Summary series here at Element14. For those of you who are new to my content, in this series I will pick a single Design Challenge project from the current challenge, and write a short summary of the project to date. Over the course of each challenge, I try to revisit each project that I cover at least once, and I am sure that some project summaries will get more than one update if they themselves are updated frequently. Unfortunately, projects that stall out, or get abandoned, will not receive any updates. Some project creators like to keep their own project summary going, and this series is not meant to overshadow those post, but designed to highlight each project from an outsider's perspective.




The subject of this installment is project Alarm Clock Control Unit (ACCU) by Frederick Vandenbosch (fvan), a project that is actually the first of two sub projects of a larger IoT smart-home control center. ACCU will be based on a previous design that Frederick built two years ago, but will upgrade to a Raspberry Pi 3Raspberry Pi 3, and get some software tweaks. Like many of the projects in the Smarter Spaces challenge, ACCU will based around OpenHAB and will feature both touch control and voice input control. As I mentioned earlier, the ACCU is just the first part of a bigger project. The second device will be very similar in design, and will utilize Puppet to ensure that both of the device’s file systems stay in sync with each other. Head over to the project’s introductory post if you would like to read more about the overall goals of this project.




In the project’s first update post, Frederick clues readers in on Puppet, a key piece of software for the project. “Puppet is an open-source configuration management tool that helps automate the deployment and management of files and applications on target hosts,” he said. “A puppet master contains the definition of the desired configurations in files called manifests or modules. Agents can query the master in order to know which configuration changes to apply.” This post is a definitive guide to installing puppet in Raspbian, and reading the entire post is highly recommended before moving on with this summary. I have used Puppet in the past for speeding up multiple web server deployments, but never to sync settings and files between two Raspberry Pi’s, so this post was very intriguing to me.


2016-09-01 05_33_22-Pi IoT_ [Pi IoT] Alarm Clock #04_ Installing Op... _ element14 Community.png


In the project’s next update, Frederick showcases a Puppet Module that he is building to make deploying OpenHAB automatically to the Puppet Master. This will allow him to quickly and easily deploy OpenHAB instances to as many Puppet agents as needed, with the new install being identical to the master. Once again this post is pretty much a definitive guide to deploying OpenHAB in this manner, and the tutorial is simply a joy to follow. Frederick never ceases to amaze me with how well he structures tutorials.



On June 14th, the next update to the project was posted, and it clued us in on how EnOcean PiEnOcean Pi and its various range of sensors will be utilized in the alarm clock. Frederick said that he has been using EnOcean Pi and it’s wireless sensors in his home for two years now, and that he is very pleased with their longevity, and lack of maintenance. He does note however, that if you are using an EnOcean Pi in conjunction with a Raspberry Pi 3, you will need to make some additional changes during installation to get everything working correctly. The post goes on to detail how to configure everything, and to get EnOcean Pi and OpenHAB working together.




With some of the sensor integration out of the way, Frederick moved on to adding in energy monitoring to the project. In the sixth update, he introduced us to emonPi, an open-hardware energy monitoring solution that is based on the Raspberry Pi. Since emonPi runs on a Raspbery Pi, Frederick is able to use MQTT to relay data to the main control hub, which can then be pulled into his OpenHAB install. The install is fairly simple, as the emonPi team have created their own image based on Raspbian Jessie Lite, but he does walk us through a few steps to turn off unneeded services the image has pre-configured.



In  the project’s seventh update Frederick walks us through some of his experiments with the Raspberry Pi Sense HATRaspberry Pi Sense HAT. He says that he had not originally planned on using the Sense HAT in this project, but some downtime between moving from one home to another provided the perfect opportunity to check out what it had to offer. If you are interested in seeing some of the features the Sense HAT has to offer this would be a good post to start with. At the end of the post, Frederick took a few moments to discuss an issue that has arose with some of the Sense HAT modules that were sent to other challengers, and confirmed that his was also affected by the faulty temperature sensor.



In post number eight, Frederick shows us how he incorporated a previous project, the IoT Tower Light, into his system using OpenHAB. The light will be used for notification announcements. In the light’s build tutorial, Frederick shows us how to connect it to the IoT using IFTTT, but for this project he wanted to stick with MQTT as the main protocol, so he details the process of integrating the light with OpenHab using the MQTT binding module.




The project took a colorful step forward in update number nine where Frederick took us down the bright path to understanding how to control a Philips Hue light bulb using OpenHAB. This is a fairly simple task, but it does take a good bit of footwork in the software to get the item list, sitemap, and rules configured correctly, if you are having trouble getting your Hue lights connected to OpenHAB, this would be a good post to read. Frederick finished off the post by showcasing a small nightlight he built to house one of the Hue bulbs.




In update number ten, Frederick pushed the project closer to completion with the additions of two IP cameras using the supplied Raspberry Pi camera modules. “The first one is the ZeroView,” [which is] “useful to stick a Pi Zero and camera on any window in a very compact format,” he said. “Even if you don't attach it onto a window, the spacers can be used to attach a string or similar to attach it somewhere else while keeping everything as one unit.” After enabling the camera in the Raspi-Config menu, Frederick chose the lightweight StreamEye program to manage the camera’s image feed. This allows the Pi Camera to stream an easily embeddable MJPEG stream of images to anywhere on or off his home network.


Updated Sept 9, 2016



The actual clock portion of the project began in update number eleven which features a LED matrix and a seven segment display that both utilize I2C. This saves a lot of data lines from occupying valuable GPIO pins, and will make coding for these two displays much easier. This post features a very good mini tutorial on how to enable I2C on the Raspberry Pi as well as some concern that logic level shifting might be needed to prevent damage to the Pi. Fortunately this concern was alleviated after some research in which Frederick used an oscilloscope to ensure that the I2C GPIO pins could power both the 7-segment display, and the LED matrix. The source code to control both displays is also included in this post, so head over to the link above to check it out.



In update number twelve, Frederick tackled the task of getting voice control working on the alarm clock. This proved to be one of the larger hurdles in this project that had to be overcame, due to a requirement to retain functionality if the alarm clock lost it’s connection to the internet. This issue was solved thanks to a roadtest article by Alan McDonley ( . Alan chose to use a Speech To Text tool called PocketSphinx, which has offline functionality built in. The post includes a full tutorial to replicate this feature on your project at home, so be sure to give the full post a read.



With voice control working on the alarm clock, the next step was to jump on the text to speech functionality. Once again, this feature needed to work even if the internet connection was lost, so Frederick looked around the internet, and finally stumbled across a lightweight version of Festival called Flight. Once again, Frederick wrote an entire mini tutorial on how to install and configure Flight on the Raspberry Pi, and as you can see from the demo video above, it actually works quite well, and has several different voices and accents.




In update number fourteen Frederick switched gears from software integration into full on woodworker mode and used his ShapOko2 desktop cnc milling machine to cut out the clock's face plate. “To make the necessary cutouts for the clock display and button, I'm using my ShapeOko2 Desktop CNC machine. It uses a Dremel to mill and is controlled via an Arduino UNO with gShield used to control the stepper motors of the CNC,” he said. “On the software side I'm using Easel, Inventables' web-based all-in-one software application for CNC milling. It combines the CAD software to create the design, the CAM software to set the tool paths, and additional software to send the resulting G-Code to the Arduino.“ As an added bonus, Frederick included a link to the project in Easel, the cloud-based cnc controller software from Inventables, that is used to control the ShapOko. This means that anyone with the same cnc mill, or even the X-Carve or Carvey can replicate the housing for this alarm clock!




Update number fifteen continued the alarm clock’s housing build, and I must say that it turned out very nice! “In my previous post, I showed you the start of the enclosure: the front panel. I have since then been working on the rest of the enclosure, trying to figure out which style to go for, one piece at the time,” he said. “I'm a software guy, not a product designer (or a wood worker for that matter), but I enjoy experimenting and giving projects a finished look.” As always with Frederick's projects, the design files are included in this post so those following along at home can build the same enclosure.




With the case built, Frederick was able to move on to beginning the final wiring process. A Raspberry Pi prototyping board was sacrificed to create a right-angle header in which jumper wires could be used to quickly connect various components together. As you can see from the image above, space was tight, but by the end of the post, things were looking good, but you will have to check out the post itself to see how it turned out.



In the project’s seventeenth update, Frederick moved back into the software side of things, and detailed how he integrated I2S audio into the project, and talked about the amplification circuit that he used. “I just realized I didn't explain the audio amplifier of my alarm clock introduced in the wiring post. Silly me ... Anyway, as you may have seen from the wiring in my previous port, I'm using the I2S pins to get the audio from the GPIO header and amplify it. I2S (or Inter-IC Sound) is a digital sound protocol, meant to pass audio data around between integrated circuits,” he said.




With most of the first control module finished, the time came to begin to build the second control unit. Since the second control unit will feature most of the same software as the alarm clock, development on this unit will move very fast. “Starting this challenge, I set out to build not one, but two control units. The idea behind this was that a single control unit would require the user to move to that room in order to be able to trigger actions (aside from using a smartphone of course). That's why I planned to have a control unit in the bedroom (the alarm clock) and one in the living room,” Frederick said. “This control unit will make use of the Raspberry Pi 7” Touchscreen Display as provided in this challenge's kit. Because the touch screen's resolution is limited, different views will be created, each focusing on a different aspect of my smarter spaces.”



With most of the hardware work done on the second control unit, work on the kiosk user interface could begin, and that is exactly what Frederick covered in the project’s nineteenth update. We have seen something similar to this from Rick Havourd (rhavourd) in his project Hanger Control System, but Frederick decided to go with Chromium as a way to offer a second approach to using a browser based UI in kiosk mode. Unfortunately, Chromium is not available in the Raspbian repositories, but Frederick walks us through how to install it from the Unbuntu repositories, as well as how to configure everything to get kiosk mode working




With just a few days to go in the challenge, Frederick doubled down and worked hard to finish up everything before the deadline. Update number twenty was dedicated to finishing up the enclosure for the second controller. Using his ShapOko2 a sheet of white acrylic was milled to create the final pieces needed to complete the enclosure. Getting a good result from the acrylic did prove challenging though. “Milling acrylic using the CNC required a few attempts before achieving clean results. During the initial runs, the mill's feed rate was too low, causing the acrylic to heat up too much, melt and stick to the milling bit. This in turn, caused damage to the piece because of the molten blob swinging around,” Frederick said. “By increasing the feed rate to 1000mm / min, with passes of 0.7mm, the mill travelled fast enough to cut without melting, resulting in clean cut pieces, as demonstrated below.”




Update number twenty-one was all about failure, and how to learn from those projects that do not go as planned. During the challenge, Frederick actually moved to a new home which was already outfitted with some rudimentary home automation from a company called Domestia. This worked perfectly into his project and he was excited to get the system integrated into the system that he just built. “The installation consists of two relay modules, capable of turning lights and outlets on or off. There are also two dimmer modules for lights,” he said. Unfortunately the system did not like his new LED bulbs, and the dimming functionality ceased to work. After some sleuthing, and a bit of research, Frederick decided to place this portion of the project on pause until he could make sense of why things were not working correctly.




Frederick wrapped up the project in its twenty-second update post by building a small bonus device that is designed to hold the family’s keys. “The idea was to make a key holder allowing up to four different (sets of) keys. It serves two purposes: a fixed place to hang our keys (we tend to misplace them a lot!) and assuming proper use, could be used as an alternative/additional presence check,” he said. This simple little project is quite awesome, and I honestly may replicate it in the near future.



Two subsequent post were made that same day, with one of them being Frederick’s summary of the project, and the final update being a post that links to all of the sources used in this project.



That is going to wrap up my project summary coverage of project Alarm Clock Control Center. Once again, I am simply amazed at the quality of not only Frederick’s work, but his ability to document every step of the process. As a professional content creator, I know how difficult it can be to thoroughly explain how a project works, and keep things readable by everyone, including readers who might not me “engineer minded.” Overall I feel that the project turned out great, and I see it being one of the major contenders for the top prize. Thank’s again for taking the time out of your day to read my summary of this project. Head over to the project by visiting its blog page if you have not visited it yet. Tune in next week for another Design Challenge Project Summary here at Element14. Until then, Hack The World, and Make Awesome!  


This PiIot Challenge evolved in a very strange mode for me; as much the project was growing as much a new scenario was emerging imposing as the main track.

So what happened? I had to make a choice: close the challenge just in time or smoothly follow the project evolution. There was not time to do both. Closing the challenge by the deadline would require a series of simplifications in the project. Then the remaining time for the next - and, why not? More ambitious - deadline was too few for refactoring the idea and prototype to the next target.

Muzieum-1600x1600 4.jpg


I have done the choice: the challenge deadline become just the most important part of a wider project focusing to a more complex design. It was clear to me that it was a necessary choice seeing the first media coverage and - most of all - the interest and support from the other partner, the MuZIEum where the project will take place, the same Element14 supporting and encouraging me, the approach of the second sponsor and the first interview that are under publishing next weeks.


Muzieum-1600x1600 17 strip.jpg

Few words about the new timeline

The new timeline necessarily changed the project approach. This perfect reading place, become focused on the Internet of Things technologies supporting visually-impaired users: it will be a really reading, chatting, discussing and interacting area place to be installed in the MuZIEum site. Many new aspects to take care made things more complex but also more interesting. The design idea becomes a use case adding one more complexity level: usage, color choices, networking, usability, and more. The points below focus the main aspects:


  • The system is a series of installations connected as IoT nodes
  • Visually-impaired staff will be trained on how the components work to be able to illustrate their usage to non-visually impaired visitors
  • The components of this IoT network will be accessible and easily understandable by the visitors: together with rest of the MuZIEum context should be part of a very special and intriguing experience for the visitors (trained and supported by visually-impaired personnel)
  • The MuZIEum staff and the precious consultancy of the project manager Carlijn Nijhof will supervise the project content and features: the colours of the 3D printed parts, the texts-to-voice preset messages, the interaction choices etc.
  • The perfect reading place should work dynamically adapting to the presence of a detected user
  • The system is headless: no monitor, no screen, no keyboard


The next three months timeline

  1. The full working and installable prototype will be completed during the month of September. Every part will be tested on-site as it becomes available. Then a pre-installation full setup will test the IoT nodes
  2. A final project design will be produced to be supervised by the MuZIEum staff for the ergonomy and colour choices: 3D printed parts, powering system, accessibility
  3. The text content of the spoken messages will be tested then supervised by the MuZIEum staff to reach the best content
  4. As well as text and colours also the physical accessibility of the components and the control gestures should be discussed with the MuZIEum staff for the more comfortable user experience
  5. Between the month of September and October a group of visually-impaired MuZIEum collaborators will be trained to illustrate the IoT self-adapting experience to the visitors
  6. Starting by the end of October - first week of November the final reviewed installation will be ready on-site. The system will be used for a period by test-users to verify the installation robustness and reliability.
  7. The official presentation to press and public visitors, together with other projects all focused to give to the visitor a unique perceptual experience will be on the date of 8 December.


During this period a series of video-podcasts with Periscope are planned for streaming on Twitter about project advance news, interviews to the staff members and more.


The project updates will continue as usual by the next 5 September.


I hope that element14Dave, spannerspencer and the resto of Element14 challenge sponsor will appreciate the scenario. And I also hope that the users continue following the project development status.

It's been a very interesting challenge! 3 months to learn a bunch of new things (specially in server and services implementation) and one common enemy... TIME! Only the basic structure of the proposed plan was implemented in the end. However, this is only the beginning


Thanks to element14 for this chance. And thanks to y'all who commented and helped. Of course, thanks to all who read thru these post and maybe found some interesting information.


It was also amazing reading what other participants were doing (that is a good use of the challenge period time), all the projects are incredible and there are some extremely original ones ^^


Alright! Let's do a wrap up:


List of past posts:

Sources and links

Most of the code is available on GitHub


The plan: what was planned and what is


In the end... I let time past by and most of the work was done during the first weeks or the last ones ^^u  I am not even going to think of how many post I uploaded tonight u.uzZ. Lesson learn!


Looking back to that optimistic first weeks...



                                                                                                                                                                                                     Green = completed




How to

Connectivity setup: MQTT

Raspberry Pi 3

Raspberry Pi 1


Broker installed in Raspberry Pi 3

Publisher client in Raspberry Pi 1

Subscriber client in smartphone

Subscriber client in Raspberry Pi 3

Sensors reading

Sensors type 1:

I2C protocol – connect to the corresponding Raspberry Pi 1 I2C ports


Sensors type 2:

  • Door switch
  • Alarm button

Direct connection to Raspberry Pi 1 GPIO ports


Raspberry Pi 1

Reads GPIO ports

Implements MQTT publisher client -> sends data to Raspi 3


Raspberry Pi 3

Implements MQTT broker

Data storage

Raspberry Pi 3

Implements MQTT subscriber client -> read data from Raspi 1

MySQL database to store data

GUI – general home access

Raspberry Pi 3

Same MQTT subscriber client

Displays read data

Mobile app – individual home access


Implements MQTT subscriber client -> read data from Raspi 1

Displays info

Web portal – remote access

Raspberry Pi 3


Extra 1: Announcement board



How to

User sets

  • - Task
  • - Announcement

Raspberry Pi 3

Include a menu to input:


Task that should be finished within a deadline (i.e. cleaning)

Data storage

Raspberry Pi 3


Display task/announcements

Raspberry Pi 3

Update main GUI to include an “Announcements” tab



                                                                                                                                                                Green - completed

Basic: Run competition



How to

Record user’s run distance

Android smart phone

Mobile app.

1) record run distance with either:

  • Use maps framework: get miles
  • Count steps/use phone gyroscope

2) send distance to smart home

       - Send to home server IP address

Data storage

Raspberry Pi 3

Implement home server – Apache

Create PHP interface to fetch data coming from phone

Store data in smart home database - MySQL

Display data

Raspberry Pi 3

Update home GUI:

  • Individual data
  • General table with best results

Extra 1: Tourist/Discovery system



How to

New destination selection

Raspberry Pi 3

Select a reasonable location to visit

Display it on the home GUI

Allow remote access to the selected location

Mobile app- geo location

Android smartphone

Update mobile app:

  • - Map frame work to detect person’s location
  • - Read new location from Raspi 3
  • - Send when the person gets to that location

Extra 2: Smart house inner challenges





Well, the basic modules were developed. A pity that the extras, more interesting ones, were left behind.



What now ??

Interactivity - Central Node and User Node

Even though technically both nodes are working, they are to simplistic! I want something to actually be used in the house and even appealing to my roommates. Which means that:

  • Central node needs a better GUI
    • Nicer touch and look
    • More competition options and some grand announcement of the winner
  • User node application could include also Google map integration


Casing, covers and finishes

All the components and elements were wired up and left as they were brought to this world. However, there are multiple options (ie 3D printed models) out there to have each node decently cover.  It will make it more protected, easier to deal with and not so prototype like looking.


It is difficult not wanting to start with this after seeing what other participants have done, that is a great work !


The extras

While I feel I should implement some of the proposed extras, I have discarded the tourist option (it is too complicated). The announcement board though, it looks like a nice must! (Cleaning schedules are difficult to keep in the new house u.u).


Also, the new apartment I recently moved in gave me another interesting extra (for the laziest if you may): have a camera intercom in the main door of the building. We live in a 3 stores house and everytime the door rings we should walk one full floor (aaaaall the way ) down. However, there is a convenient window thru which one of the cameras could be looking thru.


Tools for improvement

All the development process has been built from scratch. Nevertheless, there are plenty of tools (specially server kind of plugins) which could give the platform a more efficient, easier and professional solution (cloud is quite popular these days). My knowledge is kind of limited here, so I can not really give any practical example, but will be looking for something of the sort :3



Always key in a smart house, and yet, I left it for the very end... till it was too late


That's been all for now


Caterina Lazaro

Last day (+ 1) of Pi IoT competition, and a Smart Competition Home is ready to run

In this post, I wanted to show how the system looks like: both in paper and in the house itself. So here comes the pictures:


System Description








  • 1 Central Node - Raspberry Pi 3
  • 1 Sensors Node - Raspberry Pi
  • 4 User's Nodes - Smartphones













System "Installation"

I want to show where each node is being working in real life. Installation is a very kind work to use in this case, as each node has been location in a best-effort basis (but it works!)

Sensors Node

Attached to the back door in the Kitchen

IMG_20160829_094056_hdr.jpg IMG_20160829_094203_hdr.jpg IMG_20160829_094231_hdr.jpg


Central Node

In the corner of the living room. Accessible and not in the way.

IMG_20160829_130557_hdr.jpg   IMG_20160829_125356_hdr.jpg


User's Node


The User's Node is intended to be each of our smartphones


However, I also had an old Tablet which was only used to control Netflix in a the home Chromecast. Well... it is now a general User's Node to read the smart house information.

Screenshot_20160827-114104.pngThis new post finalized the User Node (an Android device). It will include the smart-house functionalities to that of the competition system. This way, any resident will be able to check the smart house information while connected to the WiFi and switch to Competition mode when leaving to gain some miles.


*In other words... I will make the Smart Competition button work





User's node - include MQTT Publisher Client



Screenshot_20160830-013638.png                                                              Screenshot_20160830-020609.png  Screenshot_20160830-020616.png

      NOT CONNECTED                                                                                                              EXAMPLES OF SUBSCRIBE RESPONSE

Smart competition Activity

Initial setup: Nexus 5 / Android / SmartCompetitionHome App v 3


It is a direct implementation of the MQTT Clients, thanks to the Paho library


MQTT Clients subscriber & publisher

I create both kind of clients in the app. To do so, the code needs:

  • Client id
  • url - local IP of the broker
  • port - that of MQTT Service (or the one our broker is listening to) Default port = 1883


Both types of client (subscriber, with its callbacks and publisher) are implemented in the Paho libraries. Very great news

public static void createMQTTDefaultClients(){
String url = protocol + broker + ":" + port;
clientId = "phone_"+action;

try {
  //Create an instance of this class
   sampleClient = new MyCustomMqttClient(url, clientId, cleanSession, quietMode,userName,password);

   // Perform the requested action

   //For the async
   clientId = "phone_"+action_async;
   sampleSubscriber = new SampleAsyncCallBack(url,clientId,cleanSession, quietMode,userName,password);

} catch(Throwable me) {
   // Display full details of any exception that occurs
   System.out.println("reason "+((MqttException) me).getReasonCode());
   System.out.println("msg "+me.getMessage());
   System.out.println("loc "+me.getLocalizedMessage());
   System.out.println("cause "+me.getCause());
   System.out.println("excep "+me);



In order to create the subscriber, I instantiate the class SampleAsyncCallback (implementing MqttCallback). The subscription will be performed as a combination of the function subscribe() method (which starts and manages the process)and the waitForStateChange(). As a result, the code will navigate through all the connection steps:


While the client is subscribed, the information will get to the phone as a callback, messageArrived(). This method is used to:

  • Get new data of the topic
  • Update the interface to include this new information

More details of this callback:

 * @see MqttCallback#messageArrived(String, MqttMessage)
public void messageArrived(String topic, MqttMessage message) throws MqttException {
   // Called when a message arrives from the server that matches any
  // subscription made by the client
   String time = new Timestamp(System.currentTimeMillis()).toString();
   System.out.println("Time:\t" +time +
   " Topic:\t" + topic +
   " Message:\t" + new String(message.getPayload()) +
   " QoS:\t" + message.getQos());

  if (topic.equals("sensors/door")){
   //Change door values
  //MainActivity.doorState.setText(new String(message.getPayload()));
   SmartHomeActivity.readDoor = new String (message.getPayload());
   receivedDoor = true;
   }else if (topic.equals("sensors/temperature")){
   //Change temperature values
  //MainActivity.tempState.setText(new String(message.getPayload()));
   SmartHomeActivity.readTemp = new String (message.getPayload());

   receivedTemp = true;

   }else if (topic.equals("sensors/pressure")){
   //Change pressure values
  //MainActivity.pressState.setText(new String(message.getPayload()));
   SmartHomeActivity.readPress = new String (message.getPayload());

   receivedPres = true;

   }else if (topic.equals("sensors/warning")){
   //Change warning
  //MainActivity.warningState.setText(new String(message.getPayload()));
   SmartHomeActivity.readWarning = new String (message.getPayload());

   receivedWar = true;

   }else if (topic.equals("sensors/altitude")){
  SmartHomeActivity.readAlt = new String (message.getPayload());

   //Change anything
   SmartHomeActivity.readTemp = ("?");
   SmartHomeActivity.readWarning = ("?");
   SmartHomeActivity.readDoor = ("?");
   SmartHomeActivity.readPress = ("?");

   if (receivedDoor && receivedTemp && receivedPres ){
   receivedDoor = false;
   receivedTemp = false;
   receivedPres = false;
   receivedWar = false;
   //Go to the next step of the connection
   SmartHomeActivity.subscribed = false;



At this point, I use the subscribe() function when pressing SUBSCRIBE button.




I have been using it mainly for debugging purposes: I can check whether messages are received by the broker when the sensor data seems to be lagging.


NOTE: Clients id! Along this project, I have been creating a few different clients. It might be obvious, but sometimes it is not... I have been given them different ids. The broker will refuse any connection if there is already a client with that name


Not the best features


I wanted to refined this Smart home activity, since its missing both a nicer look and additional useful commands. Regarding this commands, I wan to point out that:

  • The connection IP is hardcoded, which means that the user has no way of selecting a different device. Consequently, an extra field needs to be included for that purpose
  • There is no alert when the connection fails.
  • It is not automated - I have to press subscribe button every time a want to get new data
  • There is the "Publish" option on the interface, which will actually create MQTT_Publisher and send the message to the broker. However, the Central Node only logs the result:
    • With a bit more of coding, we can use the smart home application to control some actuators (if some are installed in the house)

All in all... it will get the job done but it is still not the most comfortable to deal with



This post closes the implementation of our User's Node. Now, we have the two main functions of the system:

  • A distance tracker linked to the competition server
  • An MQTT client which can be use to read data from Sensors Node order to have a bit more of feedback and add some thrilling while running ("wait! when did he run all those miles?? no way I will let this be"), I want to have an updated table of the current's month competition state. That means:

  • Including a new function into Competition Service - in Central Node (Raspberry Pi 3). This way, when requested the competition information, it will send back he appropiate data
  • Implementing the "Podium" activity on the Competition Android App - in User's Node




Central Node - Send competition information

Existing file: insert_into_table.php

New functionality: Obtain last row of each column


So, apart from inserting information to the database, the competition service should be able to:

  • Read last row of each of the users table
  • Send it back to the phone


Read last values upon request

The main .php file is now able to read different types of messages. As a result, we differentiate:

  • type = insert -> to update values in a table
  • type = get_row -> to get last row of each table and extract its monthly distance


This request , the get_row, also contains the names of all the roommates, which will be use to select single tables. Then, the file will


1. Once we obtain the value from the right HTTP_POST ($json), the code extracts the roommates requested. Each roommate = table

2. Fetch last row of each of user's table

3. Extract monthly distance

//Decode JSON Into Array
$data = json_decode($json);
foreach($json as $key=>$val){
     $row_last = $db->read_rows($val);
     $month = $row_last[NUM_MONTH_COLUMN];

(*) read_rows function is been developed to contains the corresponding SQL calls to obtain the last row, and fetch it as an array to return


4. At the end, Send it back to the requester, User's Node


User's Node - Podium activity

Initial setup: Nexus 5 / Android / SmartCompetitionHome App v 2


In this section, I explain how the is implemented. It will request the current state of the competition from the server and display in a table. Again, results will be organized from top to bottom.


This Activity will only display a table (and later on,  a REFRESH button).

When the Activity is created, it will request the monthly information for each user from the Central Node. Once the response arrives, the table is updated with the most recent data. The interesting part of this file is the new AsyncHttpResponseHandler which handles successful messages as follows:

//Handle succesful response
public void onSuccess(String response) {
  System.out.println("Get comp Server response: "+response);

  try {
   //Convert to a JSON Array and get the arguments
   JSONArray arr = new JSONArray(response);
   //List<String> args = new ArrayList();
  //Analyze each JSON object
   JSONObject jsonObj = (JSONObject)arr.get(0);
   Iterator<?> keys = jsonObj.keys();
  while( keys.hasNext() ) {
  String key = (String);
   lastMonthValues.put(key, jsonObj.getString(key));
   //Update gui values:

   } catch (JSONException e) {

(*)lastMonthValues is a Map<String, String > structure holding each roommates monthly distance. updateTableValues() we use this information to organize the Podium table.

Competition Application running in the smartphone


NOTE: There should be a way of reducing that long delay when retrieving data




The competition android application is completed! With this version, each user can:

  • Record their traveled distance
  • Check what is the current status and the other total distance