During the Forget Me Not challenge, I was lucky enough to win Tim.
I introduced him here
Since he was a lone child, I decided to obtain a Dave, along with the famous 'Dart Gun".
They have been rather chatty, but I suspect that's more to do with who goes past.
It was time to introduce them to the xmas spirit, and in particular Santa Hats.
So having some spare hats and a talented daughter (who's finished school now), it was time to hack material.
Obviously its a little large .. or maybe it could be a Xmas Teepee for a minion
Hayley unpicked the band
The result is a hat and band, which can now be resized to suit.
Measure the heads ... they are different sizes but 350mm seemed suitable.
Rescale the band to 45mm height (folded in half so cut size is 90mm).
Sew the band.
Unpick the hat until the opening matches the band.
Cut the hat excess and sew the band onto the hat.
One very happy looking Dave.
Ready to party ... note the non-alcoholic drink, because the night was long and they didn't want to end up like Jerry (laying down singing)
Thanks to Hayley for the work and the photos.
Have a Merry Xmas and a Happy New Year
(this was Christian's post https://www.youtube.com/watch?feature=player_embedded&v=JGk42E2eSlU )
The day I was travelling to Munich. Even though the flight itself is only about 1h30, you quickly spend half a day travelling.
I started off by taking the train to the airport, getting checked in and through security. I arrived in Munich in the early afternoon, where the taxi driver was waiting for me.
After some trouble with the parking ticket, we finally managed to get on the way. About 45 minutes later, I arrived at the hotel, where I met Christian.
In the evening, I went to the element14/Farnell offices with Christian, which were not so far away from the hotel.
There was a briefing event on the trade show, with something to drink and to eat. I met the people that arranged my flight and taxi, and got to talk to many interesting people.
After the briefing event, we headed back to the hotel and got a good night of sleep, as we were expected to be ready to go at 7:45 the next morning!
Day 1 of electronica. After spending some time at the element14 booth, I started exploring the other booths and halls.
Electronica is BIG. I didn't grasp how big it was until I visited a full hall and realised there were twelve in total!
The following picture gives you an idea of the size of a single hall:
Somewhere in the afternoon, I received a text message from Christian asking if I could pass by the booth. I hurried back, expecting to meet one of the sponsors of the challenge (EnOcean, Tektronix, ...), only to find out that my wife was sitting there chatting with Christian. Apparently, they had, in all secrecy, arranged for my wife to fly over for her to be able to attend the award ceremony on Wednesday. As I didn't fully grasp what was happening at first, my first reaction when seeing her sitting there was "what are you doing here?!" in my best west-flemish (something like "wuk doej gie iere?!").
We continued exploring electronica together for the rest of the day.
The big day. I had the pleasure of meeting some people from EnOcean before the award ceremony. We talked about my project and how I used their sensors.
My wife had made a photo album of the project, which made it easier to explain the different stages and components of the project.
There were originally two albums, but someone must've thought it was a freebie of some kind, because one of the albums disappeared ...
Then came the time for the actual award presentation by Christian together with Markus Kreitmair from EnOcean.
Photo by EnOcean International
I'm not the greatest speaker, and even less so with a camera pointed towards me, but it looks like it turned out OK.
With the formalities done, I was then free to further explore electronica until it was time for my wife to catch the shuttle back to the airport, as she was working the next day.
At the end of the day, I headed back to the element14 booth, as they were having their "stand party" which involved music, food and beer (lots of it).
The Robox 3D printer was on display that day. There were some example prints and some software and printing demonstrations.
It looks like an interesting printer and I'm curious to see what the road testers will think of it.
Eben Upton also came by the booth. Christian had foreseen a duplicate of the award I received the day before so we could have it signed by Eben.
In the afternoon, there were some presentations on IoT security. One of the more interesting talks was by Kerry Maletsky from Atmel.
They have come up with a hardware solution called "CryptoAuthentication". It looks promising and worth giving a try.
The last day of the show, also known as "student day". It's also the day that the element14 crew could swap the suits for more comfortable polo shirts.
It was clearly calmer that day compared to the previous days, which is not necessarily bad, as it was easier to walk around.
I spent some time at the booth that day and got the opportunity to talk about my project.
In the afternoon, the time came to say goodbye to electronica and the element14 crew, as I took the taxi to the airport and headed back home.
It's been a great experience and I'm glad I got to be part of this. Thank you!
Mark developed a brilliant remote monitoring solution for senior citizens called the eLDERmon. Because of his creative design and strong execution, Mark has won an
Concerned about the well-being of seniors citizens in his native New Zealand, Mark sought to create a remote monitoring device which would allow caregivers to unobtrusively monitor a person's health.
As Mark described:
The idea was not to see instantaneous status, but data based on historic information that could be minutes, hours or longer old.
This information would then show trends, or changes in the normal pattern, which may trigger an action.
I called this eLDERmon.
Over the course of the challenge, Mark used a variety of humidity sensors, light sensors, motion detectors, and temperature sensors to quietly track environmental factors in a senior's home environment. It was very important that his device be as non-intrusive as possible:
There are many elderly that prefer to be independent, not rely on others, or have a fuss made. While they are capable, there is still a requirement to passively monitor them to ensure small problems don't become larger health problems.
Mark therefore cleverly disguised the as a book where its many connections would be hidden from view:
You can read all about Mark's eLDERmon system in his synopsis. As he states, the design challenge was "...enjoyable, frustrating, educational, inspirational, rewarding, co-operative, and many other words. It has been a pleasure to be involved, and to learn new 'stuff' from so many other people I've never personally met."
Congratulations to Mark Beckett for winning the Community Choice Award in our Forget Me Not design challenge!
Jay applied his engineering know-how to making his 100 year-old Victorian home more energy efficient using the products sent to him as part of the challenge. For winning the Runner Up Award, he has won:
Living in a 100 year-old Victorian home in New Jersey, Jay outlined the following goals for his Forget Me Not application:
- Did I leave the door unlocked?
- Did I leave the iron on?
- Did I water the plants
- Did I feed the cat?
He built a sensor system based around the which included a modified reed switch to identify an open door, a temperature sensor to determine if the iron was left on, a moisture sensor to determine if the plants need water, and a force-sensitive resistor to monitor if the cat bowl requires refilling:
You can read all about Jay's home monitoring system in his synopsis. He writes, "It's been a very educational experience and I’ve learned a lot about building and integrating systems with wireless energy harvesting devices into IoT smart devices."
Congratulations to Jay Morreale for winning the Runner Up Award in our Forget Me Not design challenge!
Owing to the creativity of his build, Frederick has won:
And an all-expenses paid trip to the Electronica trade show in Munich later this month.
Frederick's project sought to address the following problems which occur when taking a holiday:
As he stated in his first blog entry:
Before we had any kids, we could take holidays whenever we wanted to. The advantage was that when we would take holidays outside of school holidays, our neighbours, with kids, would be home to look after our cats. With two young kids, we are now tied to school holidays as well, which means that when we take holidays, our neighbours are usually away as well.
The hardest thing to arrange is for someone to look after our cats.
Over the course of 12 weeks, Frederick built his system around a , using its GPIO pins and USB ports to connect a variety of sensors. In addition, he used the RPiSoC for tasks such as driving servos to control the automatic dispensing of cat food, the EnOcean Pi to monitor remote conditions such as whether a door is left open or closed, and an Arduino Uno to transmit the status of remote RFID devices. Frederick wrote a great synopsis of his project which recounts the challenges he faced along the way.
There was a significant amount of code produced for his project, including setting up a MySQL server, configuring openHAB to integrate data from multiple sensors en route to the Raspberry Pi, and numerous Python scripts to execute specific steps in his project. He even created a free code repository for anyone wishing to build on his work.
Here is his final build. Check out the video below to see it in action:
Frederick and his family can now take a holiday knowing that their home will not draw unnecessary amounts of energy in their absence, and that their cats will be well looked after in their absence.
Congratulations to Frederick Vandenbosch for winning our Grand Prize for his amazing CaTS project!
It's hard to believe it's been almost 3 months since the start of the Forget Me Not design challenge. As the challenge is drawing to a close, it's a good time to reflect on my performance and progress.
This is my first involvement in a design challenge for Element14. I had mixed feelings when I was chosen as one of the 5 bonus competitors: although there was happiness at having my idea validated, I was disappointed to be starting on the back foot, so to speak, when compared to the others.
My proposal for the project was really a projection of an idea that I had been ruminating on for over a year. Home security is an area ripe for disruption, particularly with modern advances in wireless technology. I think the modern security system should be modular, wireless and easily configurable by an end-user. Initially I was planning on designing some Bluetooth sensors for my idea, but when this design challenge came along, I thought the EnOcean sensors were perhaps a better solution, as their energy harvesting technology would eliminate the need for batteries in many cases.
For this challenge, I wanted to use the Raspberry Pi as a security hub, attaching various wired and wireless sensors and then using openHAB to expose the UI, sounding alarms and notifying the home-owner via email when intruders were detected.
To start with, everything was on track. I began reading up on the EnOcean modules and playing with openHAB. However, it wasn't too long before my efforts on the challenge were overtaken by the curve balls of life. The day before my Raspberry Pi B+ arrived, my laptop and other gear was stolen. Not only had I lost all my work, but it took over a month to get my replacement unit through insurance. During that time, I also had to deal with the unexpected death of a friend.
My challenge entry never really fully recovered, but I managed to interface the webcam and some cheap PIR modules to openHAB to detect motion in the house. I also used a Bluetooth module to detect the presence of "trusted" devices, to automatically arm/disarm the system, although the implementation was not foolproof.
My biggest disappointment during the challenge was that I never received an EnOcean sensor kit (closely followed by the disappointment of not getting a minion! :-) . This meant that I wasn't able to fully implement my proposal. I was looking forward to playing with the sensors, as I had been following EnOcean for some time and have an interest in wireless sensors.
I have definitely enjoyed being part of this challenge, sharing my learnings and reading other people's progress. Thanks to all the competitors and to Element14.
I'll see you at the next challenge!
Forget Me Not Challenge Design Challenge Post 11: Project Summary
By Jay Morreale
Other blogs in this project
The purpose of the Forget Me Not Design Challenge was to answer four questions:
My original proposed sensor system is shown in Figure 1. The system consists of a door lock monitor, soldering iron monitors, cat feed monitor, and a plant moisture monitor. The door lock monitor is based on the STM-320U Magnet Contact Transmitter Module, and the soldering iron, cat feed, and plant moisture monitors are based on the STM-332U Temperature Sensor Module.
Each of the monitors and transmits data to a Raspberry Pi Model B+ with a EnOcean Pi Transceiver Module that is captured and processed by the Friend Home automation and Energy Management System (FHEM) server or by the OpenHAB server. These servers are core tools to upgrade my 100+ year old Victorian home into an Internet-of-things Smarthome. My long term goal is to make our home more energy efficient.
The resulting door lock, soldering iron, cat feed and soil moisture monitors are shown in Figure 2. The door lock monitor uses a foam magnet spring and stabilizer assembly, and bolt hole liner that slides into the bolt hole. The STM-320U Magnet Contact Transmitter module is placed in a small housing and attached to the door frame with its reed switch aligned with the magnet assembly. This door lock monitor requires little or no modification to the door or door frame and should work with most not-metal doors and frames.
The soldering iron monitor uses a thermistor assembly that contacts the soldering to indicate if the iron is on using the set point input of the STM-332U Temperature Sensor module. This soldering iron is fairly old and does not offer this feature. The thermistor assembly was add to the soldering stands and no modification to the soldering station was required.
The soil moisture monitor used the HSM-100 humidity sensor, the STM-332U Temperature Sensor Monitor, and a soil resistance probe to measure the moisture content in the soil. The soil resistance probe used the set point input of the STM-332U. The humidity sensor results seem to be inconclusive. It was hard to distinguish the soil moisture level from the background air humidity. My initial packaging may contribute to this as well. The soil resistance provided a good indication if the soil is wet. More data is needed to determine how to use this monitor effectively.
The cat feed monitor used a Force Sensitive Resistor (FSR) to monitor the weight of the cat food in bowl placed on the monitor. The FSR was connected to the set point input of the STM-332U Temperature Sensor Module. A touch sensor and touch pad was also included to detect the presence of a cat feeding using the occupancy switch input of the STM-332U. An unresolved interface issue between the STM-332 and touch sensor prevent me from demonstrating touch feature before the deadline of the design challenge.
Building and testing these monitors occurred over the last 14 days. Most of my time was spent blogging on learning about how the Raspberry Pi, EnOcean Pi, EnOcean senor modules, EnOcean Universal Programmer Board, FHEM server, Tek TBS1052B-EDU Oscilloscope, OpenChoice Desktop, PC Courseware Editor, and Cadsoft Eagle PCB Design Software all works and how to use them in a network for this design challenge. It's been a very educational experience and I’ve learned a lot about building and integrating systems with wireless energy harvesting devices into IoT smart devices. Now, Light is the new battery. I’d like to thank the organizes for selecting me as a finalist and the sponsors for supporting this challenge.
I guess my approach to this challenge was a bit different from other competitors. I didn't set out to solve specific problems, instead I wanted to implement my current system the Way I Want To™. In the meanwhile, it's not a bad idea to add sensors like the ones provided in the EnOcean sensor kit.
Even if I didn't achieve all that I wanted to, I sure did accomplish a lot. And best of all, with hours to spare compared to the deadline
From the get go, my plan was to create the hardware I needed in my current systems. This meant designing a add-on board for the Pi. The design criteria are as follows:
These functions are (mostly) designed to be independent, so the whole board doesn't need to be assembled. Also, the board can be used as a 1-Wire IO-board without RasPi. This allows the same board to be used without full assembly when needed; as additional IO-board for the whole system, IO-board for other platforms etc.
I have designed the next revision of the board and the total cost for one (fully assembled) unit comes to about 44 euros (VAT 0%). This brings the total cost of a system with Raspberry Pi B+, EnOcean Pi and the add-on to about 95 euros. In my opinion, it isn't that much for a fully capable home automation system
You can download the schematic for RevA2 here. I haven't ordered the PCBs for it yet, nor have I tested it completely. The main thing that has changed is the way outputs are controlled; now they use MOSFETs instead of a darlington array. This is to allow more current to be sent to the outputs. Now it should handle up to 1.2A per channel.
The things that are tested are the RTC, 1-Wire connections, power supply (including resetting of the Pi), I2C level converters etc.
As I mentioned, I haven't ordered the new PCB yet. The following images show the system running with the first revision PCB and some renderings of the RevA2. Once I feel confident from the software side that I have everything I need, I'll be ordering the next batch of PCBs. So far, I've found a lucky "mistake" in the RevA2 PCB design: what were supposed to be outputs can be quite easily be converted to inputs with both pull-ups and pull-downs by a simple solder bridge
Image 1: RevA1 running, with EnOcean Pi attached
Rendering 1: RevA2 PCB from top
Rendering 2: RevA2 PCB from bottom
As I've always done, I'm developing my own software. This is partly because I'm too stubborn to learn the stuff coded by others, partly because I want to do things the way I want. Also, when the code is done by myself, I know who to blame. Of course, this isn't to say I do all by myself, of course I use libraries, frameworks etc written by others. But only the parts I like and need
I started the project by writing a Python interface for the EnOcean serial protocol. This shouldn't be limited to EnOcean Pi, but so far it's the only one I've tested. The library itself was quite easy to develop, thanks to a very good documentation. The only thing I have a problem with is that the XML file containing the EnOcean Equipment Profiles isn't public. Without it, I can't create a library to handle all the device profiles, at least not without a huge effort.
I'm not that happy with the library at it's current form though, changes are coming. I've already done some of them, but haven't released the new version of the library just yet. I'm waiting for me to be happy with it, this way there won't be so much changes in the future...
One of the main changes is to divide the library to subclasses, so one can easily determine by class type what to expect. Also, this would allow the receiver to know what fields to expect from the message. Another major change is the change to a event-based solution for handling the messages. At the moment, messages must be fetched from the queue by the application using the library. Instead of this, I'm planning on implementing a "handler" structure, this way there could be multiple handlers listening for the packets and all handlers would receive the packet, instead of just one getting it from the queue. The listeners will be attached with code something like this:
s = enocean.SerialCommunicator()
This would attach the function "radio_listener" to radio-packets. Of course, there can be multiple listeners for one packet type and each of them will receive the packet. After this, is up to the code in the handler to determine how to handle it.
I chose the excellent Django for the base of this project. On top of that, I chose Django REST framework to provide API functions, django-websocket-redis for real-time communication to clients and Celery to act as task queue.
Following is the current UML of the models, created with the help of excellent django-extensions.
Image 3: UML of current software
As one can see, the whole software at the moment is Device -based. Every object is a Device. After this, it's divided into two main groups; Device is either a Sensor or an IO. After this it does get a bit complicated, but basically that's all you need to know, if designing an user interface etc. There's of course still a lot to come; I'm not even close to finished. I haven't even implemented the most basic functions of the current system, which includes cameras, AD-converters, tasks, home/away -states etc. Most of the stuff will still be derived from Device, but some additions will come; Devices will have different states depending on the system state etc.
Per my initial plan, everything had to be "automatic". Devices are found once they're first seen etc. I uploaded a brief video of this action in an earlier post here: Forget Me Not - 8 - It's alive!
As the Pi is, rmmm, "fairly modest" in it's processing capabilities, software is designed to be as fast as possible. This means that basically every action is event-based and nothing is done if there isn't a need for it. A basic IO change will take less than 300ms from the pressing of a button in UI to the actual change in hardware state and reporting back to the UI. At the moment, it takes about 600 ms to fetch all IO (11), TemperatureSensor (2) and TemperatureSensorLog (~1800) -objects through the API. This is all that is needed to create a full UI, with log from the last 24 hours. If log is dropped, it takes about 150ms.
At the moment, only three of those models are visible outside of the program via the web API; IO, TemperatureSensor and TemperatureSensorLog. This is about to change though, as I noticed a design flaw. There's no need to expose TemperatureSensor etc, just use Sensor and SensorLog. After this, it'll be up to the UI to decide how to group them.
This is because a sensor is always one and exaclty one Device. If a sensor includes multiple measurements, they are added as different Devices.
Following is a few screenshots of the development API view, which is provided by Django REST framework.
Image 4: TemperatureSensor API
Image 5: IO API
User interface of a home automation system basically consists of two interfaces. A physical (easy, thanks to EnOcean) and a virtual. Additional physical user interfaces could be developed with the help of Raspberries, Arduinos, Launchpads etc. So far, I've focused on the virtual UI.
I actually set up the UI today to run on basically every mobile device out there with the help of Intel XDK and all I needed to do was to add 6 lines of code. No removals or replacements, just add 6 lines. Following is the UI running on a desktop browser and the emulator inside the XDK (Nexus 4 and iPad). All systems are fully functional and the UI is updated simultaneously when I press a button (physical or in the UI), thanks to websockets. I have also tested the application on my phone and it works as planned.
Image 6: UI running on Chrome
Image 7: UI running on an emulated iPad
Image 8: UI running on emulated Nexus 4
This has been Awesome™.
For once, I haven't had to worry about a thing when developing something. This provides a great opportunity to create something Awesome™. For this opportunity I'd like to thank all parties involved; not only sponsors, but other competitors as well, for providing ideas and different kinds of use cases to which the system should adapt to.
I calculated the "bare essentials" to do a project like this. It added up to about 300 euros. The challenge supplied covered 260 of those euros by supplying components and devices. Without this challenge, I never would have even thought about testing something like this. Thanks to the challenge, I'm sure I'll use the same setup in the future.
Most of all, I'd like to thank my friends, who have not only listened my worries, but also provided me with useful information and much needed help and ideas.
I learned a lot during this challenge. The most important thing was that there are reliable wireless sensors out there, and even better, with an open protocol. Thanks to the oscilloscope, I finally learned to take measurements which are useful to me, the developer (after maaaany years at a university). Most of the exercises focus on "how to measure", not "what to measure and why". Also, finally I have the tools to measure affects of power failures etc and can design the circuitry to handle it.
At the moment, my plan is to release sources and KiCAD project files "once I feel ready to".
For the time being, the following is released:
Everything is released "as is", without installation instructions etc. I haven't had the time to perfect and optimize the code or instructions.
The nagging questions that I will plan to answer with my project are:
Original Plan in picture update
The Plan result
We misse time to try this part, but using the OpenHab rest api it can be very easy
It really was a success. It was the first time I used a an Oscilloscope but with Tekronix Oscilloscope the learning was fast. This unit really permit me to find the bug and choice the good solution.
With help of the cumunity we find the pull-up bug. Originally we run with 5v to be able to have temperature value and many read value failed now it's run in 3.3v, the good choice for raspberry pi and all work without error. My original plan to fix the probleme was to use DS2482S-800+ chip to isolate each captor but i finally only reduce one resistance and remove some not useful.
Final result is not perfect with perfect square but is work with no error
I made with Raspberry Pi and Adafruit PiTFT very workable control panel with automatique browser start at startup in full screen mode to my OpenHab site.
Originally i plan to screw the control panel on the wall but i finally made a wood stand and put on contoir.
Originally i plan to plug this pi on my tv to make a big home status panel, but using OpenHab on my cell phone do a great job, so I dropped this development. I'll probably relocate the pi with others in the basement.
As you can see in the video it works very well. Really useful when you have other priorities in progress.
The sensors are in place in his beautiful hand made case and data are ready to use in OpenHab but i not take time to implement the rule that control curtain open/close to optimise air cooling or home heating.
This point take many time of the project, more than i expected. It was the first time during this project i use motor. I'm very beginner in electronic, but with the good stepper motor and the adafruit motor shield the result is better than expected.
I made a great summary of all prototype here Pas Home / Curtain opener finalization with great photo of the mechanism.
It's done, but for now is not really useful but some day when i need it, i will write some rule to detect door is open and send notification to prevent baby fall down the stairs.
I ran out of time to start this project.
I did more than try, I used it and I love it. OpenHab is easy to configure, easy to made and modify addons. I will take more time to integrate my 1-wire temp sensor in it.
Pas Home / Proto shield + curtain progress (PostgreSQL persistance support)
I did some research, but not more. It seems that the documentation does not really be available. I find an solution here https://github.com/BitTankInc/BitBridge but i not test.
With the great addition of the RPiSoC, i add my home ventilation control to open hab. This project also took many time but the result works better than the original wall control. Original control not work if you press the button too quickly, this bug was easy solved in software with delay. A project that would of been really difficult to achieve without the Tekronix Oscilloscope
Integration of the RPiSoC with OpenHab and EnOcean temperature sensor equiped with humidity sensor, really makes all most useful and intelligent. I now use this system every day without realizing it. Every second it interact to determine whether I take my shower and turn the ventilation on .
Other Blogs in this project
My original cat feed monitor is shown in Figure 1. This cat feed monitor uses two methods to determine if the cat has fed. First, a Force Sensitive Resistor (FSR)   is used to sense the presence of cat food in the bowl by changes in the weight in the bowl. The second method uses a capacitive touch sensor to sense when the cat was touching the bowl when feeding. A STM-332U temperature sensor reports the force setting through the set point monitor, and reports the touch input ADIO3 input. The capacitive touch sensor is an AT42QT1070 touch sensor breakout board from Adafruit   . The STM-332U temperature sensor, touch sensor, cu foil touch pad all mount on a platform that sits on a base with feet. On of the feet applies pressure to the FSR that is mounted on the bottom of the platform.
I was concerned that the aligning all feet so one would center on the FSR would become too complicated. I revised the packaging method as shown in Figure 2. The electronics, touch pad and FSR are all contained inside a box with a transparent platform that can support any bowl of any material. The platform is hinged on one side and has the FSR that contacts a pedestal and disk on the opposite side. When a bowl of food or any mass is placed on the platform the FSR is compress between the platform and the disk and pedestal. The area of the disk gives some control over the sensitivity and measurement range of the force (weight) monitor. The transparent platform and box was fashioned by modifying a double thick CD case.
The FSR and a 10k Ohm resistor form a resistor divider that connects between SWPWR (switched power) and ground. The center tap of the divider connects to ADIO0. The voltage at ADIO0 is converted to analog by the STM-332U and transmitter out as the set point value.
The capacitance touch sensor is connected to a touch pad made of copper foil that rings the platform edges inside the box. When ever capacitance changes output KEY0 of the AT42QT1070 breakout board goes low. This occurs whenever something touches the platform near the foil touch pad.
Temperature Sensor Modifications
I modified the STM-332 Temperature Sensor as shown in Figure 3. A 1206 size resistor was soldered on the connector pins between ground and ADIO0. Wires with a single pin connector on one end was soldered to ADIO0 and ground on top of the resistor pad. The wire with a connector was soldered to the connector pad for WAKE0,. Two of these wires with connectors were soldered to SWPWR. The modification would still allow the module to be configured in the EOP-350 Universal Programmer Board (UPB).
Temperature Sensor Configuration
The STM-332U was configured with an EPP profile to report temperature, set point, and occupancy (see Figure 4). The threshold for changes in value that should be reported were lowered, and the sensor was configured to report values every 16 seconds to make testing easier.
Figure 5 shows the FSR and the little connector used to extent the pins a bit so that the pin connectors on the STM-332U temperature sensor module would hold on to them. The pins on the FSR are a little too short. These pins are crimped onto the plastic substrate and conductive ink. Soldering these pins melts the plastic substrate and isn’t recommended. The resistance ranges from open circuit with no pressure to about 500 Ohms with high pressure.
The touch sensor breakout board is shown in Figure 6. It provides for 5 touch pads but only one is used for this application. Touch port 0 is used (KEY0 input and Out0). The LEDs have been removed to minimize power dissipation and a 10k Ohm pull-up resistor has been replaced the LED for touch port 0 (modifications were made after the photo was taken).
Figure 7 shows all the modifications to the STM-332U. The single pin connectors on the right side go to the FSR, and the connectors on the left side go to the touch sensor.
Figure 8 Shows the STM-332U connected to the FSR and touch sensor board. A small block was used to apply pressure to the FSR. FHEM reports a set point value of 238. When no pressure is applied, then the set point value is 0 since the FSR is an open circuit.
Figure 9 shows the modified CD case with touch pad and some tests on the FSR, pedestal, and disk to determine location, sensitivity, and resistance range of the FSR for different weights. An empty beaker which is my bowl substitute produces a FSR resistance of 46k Ohms. I added 3 oz of water to the beaker and the FSR resistance drops to about 16k Ohms. The water is my substitute for a single serving of cat food.
Figure 10 shows the assembly of the temperature sensor module, touch sensor, touch pad (copper foil), and FSR all mounted in the inside cover of the CD case (the transparent platform).
Figure 11 shows platform mounted components, force pedestal & disk, and the alignment of the FSR with the force disk. Wood and plastic blocks were used to provide support between sections of the CD case. The center structure was too flexible. Adding the blocks made the structure rigid and coupled the forces to the bottom of the box and to what ever it is placed in.
Cat Feed Monitor Tests
The cat feed monitor was tested with different amounts water as a for substitute cat food (see Figure 12). The cat feed monitor reports a set point reading from 0 with noting on the platform, 65 with an empty beaker, 80 with a beaker with 1 oz of water, 95 with a beaker with 2 oz of water, 105 with a beaker with 3 oz of water, and 158 with a measuring cup with 16 oz of water.
There is a problem between the STM-332U WAKE0 input signal and the touch sensor KEY0 output. The occupancy switch never goes shows closed indicating that the touch pad has been touched. Figure 13 shows SWPWR on channel 1 and WAKE0 on channel 2. I’m so happy to finally measure the switch power signal. SWPWR goes high to 1.8 V for about 2 ms. The output of the touch sensor board (OUT0) is connected to WAKE0 and never goes low no matter how long you touch the touch pad.
I disconnected the touch sensor and connect a jumper between ground and WAKE0, and DolphinView reported that the occupancy button was pressed.
I disconnected the touch sensor from the STM-332U temperature sensor module and powered it separately and measured OUT0. It works quite well and I can touch the touch pad anywhere and get a good reading. I also tried removing the jumper between WAKE0 and UVDDext when the two boards are connected, but this did not help either.
The weight measure of the cat feed monitor is simple and worked quite well. The approach has the potential to make a nice low cost wireless self-power scale. The touch sensor IC and touch pad also worked well by itself, but I could not get the STM-332U to report that the cat feed monitor had been touched through the occupancy switch input (WAKE0). Using another input might be needed and more troubleshooting is required to determine the cause of this interface issue.
 Adafruit, Force Sensitive Resistor
 Interlink Electronics, FSR 400 series Datasheet
 Atmel, AT42QT1070 Datasheet
 Atmel, AT42QT1070 app notes and documents
The Forget Me Not Challenge is running from July 30th to October 24th.
|Name||Super Awesome Blog Time|
|Abhijit Bose||No Updates|
|Daniel Williams||No Updates|
|electronichamsters||Eric Tsai - Final Blog Post|
IQU is an entry in the Forget-Me-Not design challenge aimed at demonstrating Enocean sensors and how easy they are to use.
The project intro is here.
I have found the Enocean sensors to be most impressive in wireless sensing, smaller than I expected and powered only by small power scavenging devices.
There is a lot of software available to monitor these sensors, but this project demonstrates how easy it is to program your own applications to use these sensors. The sensors essentially send wireless messages to a host receiver that converts them into serial port messages, so any program that can handle serial port data can listen to sensor messages.
My application program simply displays a house image where the sensors status is an overlay graphic on the appropriate feature of the house. Here is an image of the house with no sensor indicators:
Here is a picture of the house showing all sensor indicating: rain, window open, door unlocked, coffee maker on, mail in the mailbox. This method of showing sensor status is intended to be very simple and intuitive.
The house sensor status image may also be accessed by a smart phone - shown in a couple of the videos below.
There are videos showing these sensors in action here:
This project was simply outstanding from the point of view of sponsors supplying a phenomenal kit of materials and instrumentation. We all owe deep gratitude to the sponsors. The challenge subject was very interesting and topical, and there were some spectacular entries with extensive effort. I had difficulties in getting parts I wanted, but I learned a lot and had a great time exploring the technology in my project. I hope the entries from all the contestants have provided inspiration to other readers. I found everything in the supplied kit to be extremely useful and easy to use.
Just to illustrate how easy it was to make the Visual Basic application for this project the source code is shown here:
' Wireless Home Program
' written by Doug Wong
'This program monitors wireless Enocean sensors using an Enocean USB300 Gateway
'and indicates status on an image of a house
'The following sensors are supported:
'Enocean STM320U wireless switch sensor monitoring a window
'Enocean STM330U wireless switch sensor monitoring rain
'Enocean STM330U wireless switch monitoring a doorlock
'Enocean STM330U wireless switch monitoring a mailbox
'Enocean PTM210 wireless self-powered switch monitoring a coffee maker
Public InBuff As String ' serial data received from the USB300
Public HouseNum As Integer ' house image number
Private Sub ClearHouse_Click() ' initiallize the screen to show a house with no sensors detected
house(HouseNum).Visible = False ' turn off the house image while setting it up
HouseNum = 0 ' set house image number to 0
HNum.Text = "0" ' indicate house number in a text box (invisible except during debugging)
house(HouseNum).Visible = True ' show house 0
Private Sub Form_Load() ' initiallize the comm port for the USB300 Gateway
MSComm.CommPort = 4 ' set the comm port number to the number allocated by Windows to the USB300 Gateway
MSComm.PortOpen = True ' open the comm port
Private Sub MSComm_OnComm() ' event driven comm port receive routine
Dim InBuffer As String ' buffer to store received characters
DoEvents ' allow CPU to carry out background tasks
If MSComm.CommEvent = comEvReceive Then ' create InBuff string of received characters
Do While MSComm.InBufferCount > 0 '
InBuffer = MSComm.Input
InBuff = InBuff & InBuffer
Timer1.Enabled = True ' restart timer1 - if timer 1 times out it means no characters ' were received for 1 second indicating a full message has been received
Private Sub Timer1_Timer() ' timeout on timer1 occurs when a full message has been received
' - time to determine what the message means
Dim LineNumber, i, ButtonNum, Hdigits, ReedNum As Integer
Dim ASCnum, DevNum, SideNum, InFID, OutFID, HouseN As String
Timer1.Enabled = False ' turn off timer1
' it is not needed again until this message has been handled
OutFID = "D:\A_work\projects\contests\iqu\web\house.jpg"
'set directory where the sensor status (house) image will be stored
For i = 1 To Len(InBuff) ' cycle through the message saving several key characters
ASCnum = Right("00" & Asc(Mid(InBuff, i, 1)), 3) ' get the next character
' pad with 0's to make debugging table uniform
If i = 8 Then SideNum = Val(ASCnum) ' the 8th character indicates which self-powered
' button caused the message
If i = 9 Then ReedNum = Val(ASCnum) ' the 9th character indicates if a reed switch
' closure caused the message
If i = 11 Then ButtonNum = Val(ASCnum) ' 11th byte is collected but not used yet
If i = 13 Then DevNum = ASCnum ' the 13th character indicates which type of
' device caused the message
LineText = LineText & " " & ASCnum ' collect ASCII values of characters
' for debugging
TLine = LineText ' show message as ASCII values for debugging
InBuff = "" ' empty the receive buffer
house(HouseNum).Visible = False ' turn house off while updating
If DevNum = 138 Then ' rain
If ReedNum = 0 Then ' momentarily show red dot - indicate a rain message was received
Sensor(0).BackColor = vbRed
HouseNum = HouseNum Or 8 ' add rain to the house status number (set "bit 4")
Timer2.Enabled = True ' timer2 turns the dot off after a couple of seconds
HouseNum = HouseNum And 23 ' remove rain from house status number (reset bit 4)
If DevNum = 129 Then ' doorlock (if 13th byte is 129 it is a doorlock message)
If ReedNum = 0 Then ' momentarily show red dot - a doorlock message was received
Sensor(1).BackColor = vbRed
HouseNum = HouseNum Or 2 ' add doorlock to the house status number (set "bit 2")
Timer2.Enabled = True ' timer2 turns indicator dot off after a second
HouseNum = HouseNum And 29 'remove doorlock from house status number(reset bit2)
If DevNum = 131 Then ' mail (if 13th byte is 131 it is a mail message)
If ReedNum = 248 Then ' momentarily show red dot -indicate a mail message received
Sensor(2).BackColor = vbRed
HouseNum = HouseNum Or 4 ' add doorlock to the house status number (set "bit 3")
Timer2.Enabled = True ' timer2 turns the dot off after a couple of seconds
HouseNum = HouseNum And 27 ' remove mail from house status number (reset bit 3)
If DevNum = 128 Then ' window (if 13th byte is 128 it is a window message)
If SideNum = 8 Then ' momentarily show blue dot - a window message was received
Sensor(3).BackColor = vbBlue
HouseNum = HouseNum Or 16 ' add window to the house status number (set "bit 5")
Timer2.Enabled = True ' timer2 turns the dot off after a couple of seconds
HouseNum = HouseNum And 15 'remove window from house status number(reset bit5)
If DevNum = 176 Then ' coffee (if 13th byte is 176 it is a coffee message)
If SideNum = 48 Then ' show blue dot to indicate a coffee on message was received
Sensor(4).BackColor = vbBlue
HouseNum = HouseNum Or 1 ' add coffee to house status number (reset bit 1)
If SideNum = 16 Then
Sensor(4).BackColor = vbWhite
HouseNum = HouseNum And 30 ' remove coffee from house status number(reset bit1)
house(HouseNum).Visible = True ' show house with active sensor indicators
If HouseNum > 9 Then Hdigits = 2 Else Hdigits = 1 ' start converting house number to
' text for file name
HouseN = Right("0" + Right(Str(HouseNum), Hdigits), 2) ' house numbers go from 00 to 31
InFID = "D:\A_work\projects\contests\IQU\houses\house" + HouseN + ".jpg" ' make file name
FileCopy InFID, OutFID ' replace house file with new image showing current sensor status
HNum.Text = Str(HouseNum) ' place house number in text box
Private Sub Timer2_Timer() ' timer 2 - when it is time to turn off a message indicator dot
Dim j As Integer
Timer2.Enabled = False ' turn off timer 2 - not needed until another message is received
For j = 0 To 3 ' turn off all indicator dots
Sensor(j).BackColor = vbWhite
My previous post was a textual summary of work done and I just could not shrink it more. In this post I continue by providing demo videos for the project. I try to explain the working and internals without actually tearing down the modules. For that most of my posts in the past have been short in number but long in text and serve the purpose of a teardown. I am focusing primarily on demonstrating the system in order to give a better understanding of the working and application.
Apologies in advance, I have a bad cold and it shows in the videos as a lot of *sniff* * sniff*
Some Screen shots from the above video
The videos above are stripped down versions but are sufficient to demonstrate the working.
In the next installment(if I can upload it in time), I will discuss the internals of each module. Alternatively, in the summary post, the constructional blog posts for each module are listed in the implementation section.
So, now that this challenge is close to its end, its time to look back at the project: what did I set out to achieve, what happened on the way and how did it work out in the end. Somehow I actually managed to write one blog entry per week (at least in average), thats better than my normal writing speed...
First I need to thanks Element14 and all the sponsors for giving out such nice tools to work with, and for providing a project that gave me many up and downs, a great learning experience and a nice and useful addition to our household. Especially EnOcean was very helpful and provide additional tools and sensors to me.
I also want to say thanks to all participants in this challenge. There were many great projects, some ideas I will keep in mind and especially many help for all the problems we encountered. I really enjoyed reading everyday about the progress everybody made.
I did set out to solve a problem that probably everybody knows: when you leave the house, you want to make sure all windows and doors are closed. For my family this problem got imminent when went bought our house seven years ago - since it has three floors checking all windows gets tedious. And it was important since we had a cat back then which must not escape through an open window (apart from keeping all intruders out). That was the reason for my first bigger electronics project, 4 years ago, was already in the context of a more intelligent house. I struggled back then with the hardware not being powerful enough for what I wanted to do - networking was OK, wireless a dream and even a simple web service with its XML parsing was difficult.
And the available computers in a small form factor where also not powerful (and way to bulky to put them in a kitchen). So I ended up with putting a tablet on the kitchen wall, which showed all the information we needed:
(In case you are wondering: the widget to the bottom right will show the next appearance of the ISS space station above our city - its something you need with a 5-year old boy thats fascinated by space).
But even though an Android table can be quite an information machine, it lacked connection to the physical world around it. The original problem - are there any windows open - was still unsolved.
This time my project did not involve any new electronic circuits (thats why I didn't get to use Eagle, but I did so already with my wireless power project a while ago). The EnOcean sensors and the Raspberry Pi B+ provided everything I needed for my plan. It was just the software that was lacking. I really soon discovered that (at least for my setup) the stock OpenHAB Android client was not what I needed. It does not come with a Widget that I could use on the home screen. Also, updates made to the sensors took a long time to appear in the app.
So the task at hand was writing a new client for the OpenHAB REST API, running on Android. First I tried to re-use the provided samples, using the Atmosphere REST library, but it too did not work properly with the server (probably also the reason for the app to not update properly). So I needed to create a new REST client library as well. Fortunately the Apache HTTP client library (that is also used for Android) did work well for me, so that part went rather smooth.
Then I started on the Android App. Had I knew how different it is from what I'm used in programming, I would probably had started earlier with that. I know the programming language very well, but all the libraries used for basic stuff (showing UI elements, storing preferences and so on) are a completely different world (I work on web-based eCommerce systems in may day job...). But fortunately Google and StackOverflow are good friends with aspiring Android developers (much more than for OpenHAB users...), so I made good progress here.
First, its not a finished project for me. There are still some loose ends (see below) to call it finished (stuff that goes into the kitchen needs to be approved by the SWMBO, so it should be polished).
But I already have a state that could go into everyday use. The OpenHAB setup has proven rather stable, and the scripting to handle the sensors was easy enough. the Android application is fully functional now:
(Yes, the ISS should be visible next Saturday evening, provided its not clody during that time)
For better testing I did not mount all sensors right away at their destination, but only the ones that are usually closed. I kept two of the others to be able to open and close them when I need them. The mounting was simple. I used the enclosures from EnOcean, and stuck them with Tesa PosterStrips to the window frame. The same was done to some small power-magnets:
One actually need to care about the orientation of the magnet, since sticking it behind the sensors seems not to be the preferred position for them (from the top they work much better, but there was not enough space to mount them there properly).
First, the Android app needs some more testing, to ensure its stable enough (nothing could be worse than it showing all windows as closed when they aren't). It probably also needs some visual polishing, maybe I will also create a widget the is vertically aligned (to have more options to fit everything on the home screen).
Next step would then be cleaning the app and library up, and polish them to be published. Especially the OpenHAB library might find some good use as starting point for others. But code style and documentation are not at a point where they should be.
But I also have ideas for continuing that project. I already have a system in place (based on a mbed) that monitors and logs the temperature in my house, to see when the heating system fails in winter (happened several years ago with -20°C outside). Since I now have EnOcean sensors available I can move this system over to using OpenHAB, since it can easily handle the logging and also some alerting. Doing so will lead to the next software project: I run the OpenHAB server on my home network, and I don't plan to open this up to the outside world. But I still would like to see the temperature data when I'm on vacation. So I want to set up a second OpenHAB server (using a virtual server I have rented), and run it as a slave to my home server. The master at home would push all item changes to the slave, so it should always see the same events.
Last but not least: I have applied to participate in the "In the Air" challenge. I see it as a good continuation of this challenge here - home automation does not need to be reduced to windows and temperature. We will see whats happening. Even when not selected some of the ideas from there might get applied.
But whats actually the most important item on my list: fixing the PC. It just blew up on my yesterday while starting to write this report (and ironing out some bugs in the Android app), freezing and rebooting at random times. Looks like the motherboard is defective. Fortunately for me I kept everything in git and OwnCloud, so I could continue today with my work laptop (after spending a whole evening looking for possible reasons and cursing about hardware - at least you can kick it if it doesn't work
Figure: Playing Music from OpenHAB
Many thanks to all the sponsors who have put faith in me to participate in this RoadTest Design Challenge.
Raspberry Pi, OpenHAB, CadSoft EAGLE ,Tektronix, iot eclipse.org , EnOcean and Element 14!
Unlike the John Lennon’s saying that life is what happens to you while you’re making other plans, the challenge was both the journey and results. I had a challenging journey and obtained great results. The journey taken was far different to the one planned because of the current Radio Spectrum regulatory restrictions in Australia that prohibit use of the EnOcean wireless energy harvesting sensors’ base frequencies.
There were actually several concurrent journeys. One was discovering the world of OpenHAB, another was an in depth exploration of the Raspberry Pi and its features. These culminated in the creation and assembly of OpenHAB 1.0 system and supporting peripherals on Model B+ Raspberry Pis. Other journeys included a foray into CADSoft EAGLE’s new features and improvements to determine their advantages , road testing a Tektronix TBS1052B-EDU Educational Oscilloscope and finding the improvements from previous generation equipment and research into EnOcean’s Energy Harvesting wireless sensors.
Figure : My OpenHAB Controllers (Wireless and fancy free!)
I had never heard of let alone used OpenHAB prior to this Road Test Design Challenge. I was initially confused as to the difference between Eclipse SmartHome and OpenHAB as these terms were used interchangeably. I searched the net and found this link that fully explains it. http://kaikreuzer.blogspot.com.au/2014/06/openhab-20-and-eclipse-smarthome.html
After installing, using and coming to grips with OpenHAB 1.0 – I found it to be remarkably easy to use and configure. All one needs to know is how to configure the main elements to produce a system to suit one’s needs.
The main elements are;
Start Up script – The script used to launch OpenHAB
Bindings – The interface drivers between peripherals and the OpenHAB
Rules – Instructions for the OpenHAB
Sitemaps – User Interface Presentation Definitions
The main configuration file is to supply configuration information to OpenHAB. Amongst other things, it is used to pass on information such as IP addresses of devices to OpenHAB for communications.
The Start Up Script, Rules and Site maps are text based configuration files that are very easy to adjust. There are other elements present such scripts to provide additional functionality but they do not necessarily need to be used.
It is also not mandatory to use the additional GUI configuration tools. I found that I had no immediate need for them and successfully configured OpenHAB using just a text editor (nano). For less technical users these GUI tools do present a less daunting task.
The Start Up script is configurable to allow the easy interface of any system prerequisites. This may be the need to activate a peripheral’s service or library to make it available for an OpenHAB binding to operate.
Bindings are just copied across into the OpenHAB binding directory as needed. There is a large library of bindings available to facilitate easy integration with many existing Home Automation peripherals. There are even bindings for the EnOcean wireless sensor system to make them easy use. Depending upon the peripherals used you may need to install one or several bindings. Bindings are classified into action, binding, io and persistence to clearly articulate their purpose.
One great feature of OpenHAB is that there’s no need to design web pages to access your OpenHAB system. There’s an OpenHAB app available for both IOS and android devices to give you access to your OpenHAB system. Alternatively a Web browser can be used. These GUIs are defined by the Sitemap configuration files. These are easy to configure text files representing the organisation and displayable items for the GUI. This user interface is consistent across all device options.
Rule configuration files make it easy to define the behaviour of OpenHAB based upon encountered events. These event s can be based upon peripheral reaction and timing events. For instance, you can easily make a doorbell switch event trigger a picture from a camera and sending it off as an email or to display it on the OpenHAB UI or you can make a turn on and off lights according to a time schedule.
Figure: Model B+ and Pi Camera configured as a Network camera
The Raspberry Pi – what can I say that has not been said already? I think quite a bit. Thanks to Broadcom they’ve put together a highly integrated SoC using a POP (package on package) ARM processor coupled directly to ample RAM with a peripheral controller IC that provides a complete computing ecosystem with USB peripheral support HDMI and Ethernet Interface at an inexpensive price.
The Model B+ is an incremental update to the Model B Version 1 and 2 versions and its new features further extend functionality and convenience. The SD Card socket has been replaced with a MiniSD socket and RCA analogue video output connector has made omitted to make way for some additional improvements. The audio section has been improved, 2 additional USB ports have been added, 4 mounting holes have been provided to mechanically support HATs and provide a method to easily attach the PCB to a case and automatic self configuring HAT support has been introduced. In summary, a very convenient and useful upgrade.
Getting the Pi Cameras working is an extremely simple process. It was just a case of connecting the cameras and enabling the Pi Camera option in Raspi-config during the Raspian Wheezy installation. This provided me with the raspistill utility which provided all of the functionality required.
Installing additional software is so simple using apt-get. This program scans the net to obtain the desired packages. Apt-get also provides a simple way to update and upgrade packages. Where possible I limited my choice of software packages to the standard Raspberry Pi Set. This is to see what was possible with the Raspberry Pi in its most basic form.
Getting the GPIO, UART, SPI and I2C buses for application and user use is easy. It is just a matter of informing the operating system (Raspian Linux) via configuration files of their use and may be the installation of some additional apt-get support packages.
Figure: The mighty TBS1052B-EDU's display showing off it's fantastic quality!
Tektronix TBS1052B-EDU Oscilloscope – This is a truly great piece of entry level kit. It is remarkable how Tektronix have improved their test equipment and yet retain the same price point. This instrument boasts a high resolution rich colour display and makes waveforms appear very clearly. Unlike some other Oscilloscopes is operation is silent as I could not hear any annoying fan noise.
Its controls are very easy to use and the incorporation of a push button into the Multipurpose dial makes it even easier to use. You can now select the desired item by highlighting the option you want with the dial and pressing the dial down to select it. The front panel has convenient colour coding to associate the front panel controls with their associated channel.
The USB interfaces make it very easy to transfer screenshots and captured data to a PC workstation or printer and to upgrade its firmware. With the supporting PC software installed a screen capture is a simple as a click of a button.
The Maths functions are ever so handy. With them you can see the accuracy of sine waves with the FFT display function or with the Add functions check the net result of a differential signal for unwanted artefacts.
Figure: Hierarchical Schematic demonstration in action!
CADSoft EAGLE is a great Schematic Capture and PCB Layout program. It is highly configurable and in addition to just producing Schematic Diagrams and PCBs it also can be used to create accompanying SMD stencils. With Version 7 it now has hierarchical schematic diagrams. This feature is used to clearly articulate complex designs with sub assembly or multiple sub circuits. I produced a video to demonstrate this feature. The hierarchical schematic function requires a suitable EAGLE license. One that allows the use of multiple schematic sheets such as the Free Trial (Freemium), Hobbyist, Standard and the Pro license supplied for this challenge.
These are well engineered products that I really wanted to Road Test but to my disappointment I was unable to use them due to Australia’s regulations. The EnOcean Pi interfaces with a Raspberry Pi using its /dev/ttyAMA0 serial port. It also has bindings available for OpenHAB. I just can’t wait to use it when the regulations allow it (which will ll be some time after the challenge end date). In the interim I tried an alternative wireless product to find that its transmission scheme unreliable. Yes it did work but it required a substantial overhead to cater for its limitations negating any power savings required for Energy Harvesting use.
These sensors will be will be hooked up and tested the moment when the regulations allow them to do so! I just can wait to make a limitless range extensible EnOcean Sensor network!
I have set up an impressive OpenHAB system that is ever evolving. It’s fully operational where I have many IoT devices that are accessible from Wireless Android and iPAD tablets. I can turn devices on and off, monitor sensors and display images captured from Network Attached cameras. It even sends alert emails (some with images) as necessary.
This system first started off as a standard run of the mill OpenHAB demonstration system. From this I developed my own system by creating my own custom sitemap to have my own GUI control panel.
To this I interfaced my SqueezeBox Media Player system. This consisted of downloading and copying the Squeezebox bindings into the addons directory, configuring squeezebox binding parameters in the configuration file and adding items to my own sitemap. I can now turn my squeezeboxes on and off, adjust its volume, mute and select the music track played.
I interfaced a COMPRO IP-750 PTZ network camera. It can be controlled using an HTTP interface so the http bindings were copied into the addons directory, added camera control and display items to my own sitemap. I can now pan, tilt zoom and perform snapshots on the camera from my OpenHAB control panel.
Figure: Compro PTZ Network Camera
I interfaced one of the OpenHAB Controller’s GPIO pins as a LED driver. This could be easily extended to drive an external light or device.
I interfaced one of the OpenHAB Controller’s GPIO pins as an input switch to act as a Doorbell switch. This could also be used as an alarm, panic, tamper or other purpose button.
I created my own remote network camera using another Model B+ Raspberry Pi and have it connected as a part of my OpenHAB system. I configured this network camera to operate in a similar fashion to the COMPRO Network Camera making it an HTTP controlled camera. Since the http bindings are already installed for the COMPRO Network Camera all that was required was to add this camera’s items and images to my sitemap file.
This particular camera deliberately does not have PTZ controls for security reasons because it is designed to specifically monitor the Cat Food bowl (and nothing else). PTZ and motion control detection and alerting can also be added as required.
Making a Raspberry Pi and Pi Camera into a network camera is a simple affair. All one has to do is to install Raspian, enable the Pi Camera, install the lighttps package, configure the lighttps application to support cgi-scripting, write the cgi-scripts take snapshot images upon demand, export the snapshot images and configuring the system security to ensure that the system works correctly.
This approach of using Raspberry Pis as remote network nodes greatly expands functionality and reach of OpenHAB systems. The Remote Nodes become responsible for administering and controlling its assigned set of resources and reporting back to the centralised OpenHAB controller.
You can create a large number of these remote network nodes to perform specific functions such as extending the range and increase the number of EnOcean Sensors by having the remote nodes manage their own set of EnOncean sensors and communicating back to the OpenHAB controller using the wired or wireless TCP/IP network.
This Remote Node approach is great for additional actuators and sensors. One feasible solution is to use a Raspberry Pi Model B+ with my Compact TOP HAT.
Time’s beaten me for the completion of my X10 gateway using the abovementioned approach but will have missed out on the deadline for this challenge. This gateway comprises of a Raspberry Pi with CM12 X10 computer interface that reports to openHAB using HTTP. This gateway will seamless allow OpenHAB to control the large variety of existing X10 equipment.
Figure: Compact TOP HAT prototype
My Compact TOP HAT is my method of simplifying connectivity to Raspberry Pi Model B+s. I made a prototype PCB to conform the Model B+ HAT specifications and dimensions complete with an HAT ID EEPROM and camera cable slot and LCD cable notch. The TOP HAT conveniently exports the Raspberry PI’s I2C, SPI an UART pins as separate connector ports. The SPI signals are exported through two PMOD module compatible ports allowing easy connection to existing PMOD devices. The ports also make it a very simple exercise to connect a PSoC to the Raspberry Pi for bespoke I/O interfaces.
The prototype TOP HAT has an onboard MCP23017 I/O extender and DS1317 Thermometer that are made available to the Raspberry Pi’s I2C bus. Other devices were connected to the TOP HAT I2C bus port to expand the Raspberry Pi’s flexibility. It included a 1-Wire Interface using a DS2482S-100+ and a HTU21D Humidity/Temperature Sensor. A larger DS2482S-800+ could be used to provide 8 independent 1-wire busses.
I’m working on a capacitive soil moisture device based upon a PSoC and its CapSense Technology. This is a little complex but has the advantage that the sensors are not in direct contact with the soil so there’s no problem with probe contamination or corronsion.
The system is so flexible and extensible.
The attachment of a SPI, I2C or PSoC thermocouple interface gives this system a large and relatively accurate temperature range.
The use of current sensor via a SPI, I2C or PSoC ADC can be used to monitor AC and DC energy usage.
The use of a light sensor can be used for applications not requiring a camera.
The use of solenoid or similar drivers can be used to turn devices on and off.
Figure: Prototype HTU21D Humidity Sensor, 1-Wire Interface and PSoC 4200
The list is only limited to your imagination and yet is so easy to connect and automate. All you have to do is get an idea of how to measure and control your contraption is to buy your parts from Element 14, hook them up to a Raspberry Pi Model B+ with Compact TOP HAT, electrically test your design with your Tektronix TBS1052-EDU Scope, schematic capture your design and produce PCBs with CadSoft EAGLE and then add them to your OpenHAB system with a bit of simple configuration.
Then you can sit back and relax and control everything from your Wireless Android or iOS device whether it be a Smartphone or Tablet!
Just remember the most important thing. SAFETY FIRST!