Stockie – item centric shopping list

This project is my entry to the Hackaday prize. If you like it, please vote for me by clicking the “Give a skull” button! (quick registration required)

 

Intro

What if every time you run out of a product, the smart tag on it would instantly add it to your shopping list, at the touch of a button?

The system is very simple and everyone in your house can use it, from kids to the elderly, even visitors. The shopping list is updated dynamically in real time and the system can even be configured to automatically order things online. Scattered throughout the house there are small tags or panels called stokies. You can attach the tags to individual products or things that need them, while panels provide multiple buttons and are designed for places where multiple things are stored, like the pantry.

Modern world has advanced with the help of technology, but somehow a shopping list stayed the same. Paper based, on your smartphone or on the cloud, shopping lists are centralised and require you to reach them in order to add things. Cooking a steak and running out of your favourite spice? For the modern person it’s a bit difficult to get your smartphone, unlock it, find the app, search for the item and check it while your hands are still dirty. Etching a board and your ferric chloride could use a replacement – luckily there is a smart stockie label on it.

My goal is to create simple, small, low cost tags, that you can attach to a product or place nearby which together with the system will provide an automatic shopping list and delivery. These tags would enable a one button press add to the shopping list. Adding something is a simple and instant operation, this is why the tags need to be product centric or use centric, instead of a centralised list or an app on your phone. Such a system should be suitable for the elderly, kids or anyone else for that matter, including somebody visiting you. The list is always available for consultation and in the future, integration with online shop will allow items to be automatically delivered.

VIDEO

How it works

System diagram

Throughout the house there are tags (1) and panels (2) that allow you to mark one item as running low with a simple push of a button. Tags are generally dedicated to one item while panels contain multiple buttons for objects clustered in specific places. When a button is pressed the tags and panels communicate through the gateway(3) which provides acces to the internet, reaching the server(4). This is where it all happens: a database keeps track of each tag of the users and applications provide extra functionality. Users(5) can consult the list(6) while shopping at the supermarket or even at home. Online stores(7) connected to the server can provide automatic delivery(8) of specific items.

Applications are not limited to your home, the system can be used in offices, hospitals, warehouses and even supermarkets, basically everywhere you need to keep a sure supply of something. The tags can be placed corresponding to items on shelves so that you can alert about missing items and have them supplied immediately.

sotckie_system

History and inspiration

The inspiration arrived one early morning when I realized I was out of coffee, even though I had the intention to add it to my shopping list. I started pondering about ways to measure the available quantity of things around the house so that I could be alerted when something was running low. I instantly realized that this would be a fairly difficult task requiring different kinds of sensors which would prove complicated, costly and unreliable. But the real goal was actually easier to achieve: since almost everything is used by a person he/she can alert the system about things running low without the need of a high tech sensor.

I wanted the system to be tied to each individual product or right where it is used, such that the user can instantly notify of a low supply, without stopping the activity or having to remember to later add it to the list. Adding a tag for each product might be appear to be an expensive goal at first, but a quick check shows that I could build a one button tag for about 3 euro, even while buying parts in low quantity. The tag is even significantly lower in cost than the annual supply of most things. Still, tags with multiple buttons can be transformed into panels which I can place in cabinets or drawers where multiple things need to be monitored, further reducing the cost per item.

Hence,  the first prototype is ready to be attached to the coffee machine. It will make sure I never forget to buy coffee, tea or milk.

The built is currently ongoing. Check the gallery for pictures of the progress.

As prototypes I will build 2 kinds of tags and the gateway. I have started with the small version, the coffee machine tag, which is intended for single items, but can contain up to three buttons. The larger version is intended for places where multiple items are stored, like the pantry, and will have a larger number of buttons.

Assembled one button stockie, without case. This PCB supports 1, 2 or three buttons.DSC_2762DSC_2741

First tag, fully assembled, this time using all three buttons available on the PCB

DSC_2640DSC_2639

The coffee machine will receive the first tag: no more mornings without coffee

DSC_2654

First module connected to the “umbilical” cord while in development

DSC_2661DSC_2662One of the first steps of the built is to achieve communication between the stockie tags and the main node which will be the gateway to the server. The tags are based around an attiny88 microcontroller and a NRF24l01+ radio module. The gateway will use a router coupled with an XMEGA micro controller along with a NRF24L01+ high power module and external antenna (here shown with a regular one). In this combination the communication range is sufficient throughout the house, including passing through two floors.

DSC_2619

Low power design

The stockie tags need to operate from a coin cell for as long as possible. I have considered designing the tags with touch sensors instead of physical buttons but the sensors need to wake up periodically and consume power do do the readout. Supposed I would have designed a tag with 4 buttons and settled on a 250 ms response time(that is slow actually), then the circuit burns 28uA which means that the coin cell battery would last less than a year. By using buttons, the microcontroller sleep current goes down to 0.2uA which is far less than the self discharge rate of the battery. CR2032 batteries are rated at 1-2%/year self discharge, which combined with the microcontroller consumption should have a life or around 50(yes fifty) years, but I highly doubt that will happen in real life.

When a button is pressed the tag communicates with the gateway which communicates with the server and then returns a response which will be a red or green LED blink. Assuming a worse case scenario of 0.5s of wait time for answer from server and 0.5 seconds of total on time for the LED, I get an average current of 18.8mA for 1 seconds. This  translates to about 40.000 operations from one battery.

With the extreme standby time and high number of operations I think the tags will have a practical life of more than 5 years on a battery.

Schematics

The design of the tags and panels is rather similar, they differ just in the number of buttons. The tags have up to 3 buttons while the first panels have up to 10. The parts list is kept to the minimum, I have even omitted the LED current limiting resistors because the reduced drive strength of the micro controller at 3V will keep the current within levels. Schematics available in PDF: Tag and Panel and the gerbers are avilable here: Tag and Panel.

stockie3_schematic

stockie10_schematic

Build Log

Update 19-20.08.2014

I have finally achieved simple functionality on the website. The whole project is hosted on my personal website, since I still have resources like databases available. The data is stored in a MySQL database which supports multiple users. There are a lot of features that I would like to have, but so far there are just a few things available: some diagnostics, user selection, simple error handling and most importantly a shopping list display. Apart from the user pages, there are a couple of others that will be accessed by the tags in order to change the status of the item or configure the tag.  Here is how my list looks now, I have added just some random things:

website_listThe other functionality is to show the status of all the tags for a certain user. For now the information contained is the HW ID of the tag, status, battery status and when it was last changed by the tag or website

website_configure

Update 18.08.2014

First panels are completed and can go online. Here are the first two assembled PCBs, one for development and one for actual usage in the kitchen.

DSC_2818DSC_2823

As you can see, there is a lot of empty space in the box, but I will design the whole thing again for the next version, the panel should not be much thicker than a battery and PCB. 
DSC_2828

The buttons are designed to come out of the box surface just enough so that they can be pressed through the front plastic panel that comes over them.

DSC_2830

 

And the first completed panel from the front which will take place in one of my cabinets in the kitchen. I have chosen the labels quite randomly, I almost never need flour, since I don’t cook. DSC_2832

 

Update 18.08.2014

To make the prototypes easier to fit in the box I have used a trick: I have placed a proper sized hole into the PCB under the buttons and the LEDs. That way I can install the PCB in the box and use it as a template to drill the holes. It takes less than 2 minutes for the whole 11 holes required for the 10 button panel, but I bet I could do it faster with enough practice.DSC_2625_2

Update 17.08.2014

Success! The first stockie tag(attached to serial port for debug) can now connect to the database and check the status of my coffee. This means that basic functionality in the tag software, gateway software and server side software is done, time to start building up on it. Here is the tag saying I am out of coffee(red led). It takes a lot of things to work together in order for this to happen, I had to develop software for the tag, the gateway(micro and router) and server while using C, bash, javascript, html, php and mysql and of course, everything has to work together.

DSC_2817

 

And here is the tag saying I still have enough coffee(green led not that visible due to flash):

DSC_2816

 

Some terminals for debugging: top is the tag data, middle is data going through the gateway microcontroller and at the bottom is the router

first_debug_all3_1708

Update 16.08.2014

I have assembled the hardware of the gateway. The gateway is made from a TL-WR710N(EU) router and a Xmega header board I have previously designed. The XMEGA32A4U  microcontroller serves as interface between the radio and the router since there is no hardware SPI available on the router. Currently the data transfer between the microcontroller and router is done with a USB-serial adapter because I need the original router serial port for debugging. Once the development is finished, I will switch to the router serial port. There is an additional serial connection between the microcontroller and PC to monitor the data transfers and debug.

The two antennas, router and NRF, are perpendicular to minimize coupling, as the router connects to my Wi-Fi to get online. Alternatively, I could use an Ethernet connection, but that requires an extra cable and limits the place where I can put the gateway.DSC_2788DSC_2791DSC_2794DSC_2801

 

I found a place for the gateway in a socket I never need to use.
DSC_2807

Let the software development commence: two serial ports for debugging:

DSC_2810

Another XMEGA header board

About

I wanted to make a header board to play with the xmega and some radio modules and do some experiments with internet of things.

Includes: XMEGA32A4U, NRF24L01+ or RFM73, one WS2812 LED and headers, regulator, USB connector and passives.

Board files available here for personal use. 

Pictures of the boards including a NRF24L01+ high power module with 8dBi antenna.xmega_header

DSC_2695

DSC_2697DSC_2705

DSC_2706

Web interfaces

Why

Some of the electronic devices I build require some sort of display and buttons for user interaction. This usually leads to a lot of work to design and build a front panel which ends up having a tiny character of graphic display. While in some cases it would be mandatory to have the interface on the device itself, this is not always the case. The simplest alternative is to have the device controlled through the serial port via console and growing more advanced means designing some sort of GUI for your pc. The next step is to have your device be a web server as well and provide control through a web page which in todays world means access is opened to anything that can browse the internet, the PC, tablet, phone. So far, my chioce of HW interface was Ethernet through the ENC28J60. Lately I decided to give something else a chance: routers.

Why routers

Simply because, depending on the goal, a router is able to provide with the following: a power supply with something left for the project, a case for the project, wireless and wired network connectivity, web server and interface, USB port, ample processing power and memory(vs a micro), huge list of bash commands, rather low power consumption etc. Many low cost models ca go below 20 euros and quite a lot of routers have been used for internet connectivity in projects. The down side is that they cannot replace the micro in the project due to limited amount of pins available and lack of ADC. It is worth noting that the price of a low cost version is comparable to purchasing Ethernet PHY, power supply and case, if the project can use those of the router. Alternatives of course exist, there are different tiny boards, my favorite would be the carambola 2 and there are new low power WiFi modules that could serve more power constrained devices like TI’s CC3300 but they are quite needy, requiring a lot around them.

My first experience was with an Asus 500gP which brought remote control to a few things around. Today I am looking at 4 other models. The TL-WR741N(D)  is available as low as 15 Euro, though it will probably be replaced soon. I have successfully used it as IP to serial bridge to replace a “normal” IP-serial bridge. But for more compact designs I would prefer the WR710N European version which I will use in this test. It’s a more compact version of the very popular 703N which has a separate supply and takes a while to be delivered. Have a look at some great pictures of the 710 here. The third option is DIR505 which has a great advantage of splitting in two giving you a nice and compact wireless board and a few extra GPIOs used for the switch. Now if only router manufacturers would do something nice for the hackers out there and bring out some of the unused GPIOs on a header….

A test

I decided to give it a try and found a candidate project: the heatsink tester. I am testing it with a TL-WR710N router, European version which comes with 32MB RAM and 8MB flash (3.5MB available after openwrt install). I took some shortcuts: I used a USB-serial adapter instead of the built in serial port to allow me to work with the console while developing the project, and try to modify the original heatsink tester as little as possible. This is not needed in a final design. Of course, the micro I used has USB port and could be loaded with usb-serial software, leaving the console free. If I am satisfied with the overall feeling I will buy a dedicated router for my heatsink tester and give it a proper „house”.

The web interface

I created a web page for the heatsink tester with the help of jqwidgets which are free for personal non commercial use. It took a while because I have no experience with javascript or html, but as I will be able to reuse parts of it for next projects it should go a lot faster next time.

The webpage has three parts: creating the widgets which includes all their designs, putting them on the page and the scripts for the data. The data flow is insured through two functions: one fetches the data from the router, the other sends data to it, both are called periodically.

Here’s a quick look. router web interface

Router software

The router stands between the microcontroller and the web browsers. The microcontroller sends all parameters required on the web interface through the serial port. A script on the router saves the last entry in a file in RAM. When the web page is opened it calls a cgi script which fetches the data in that file. Any interaction on a web page calls another script which sends some data to the serial port, to the microcontroller. The „middleware” on the router is meant to be universal, independent of the project. This will allow me to create a single image for all routers and use that one for an instant functioning router. For the moment the „history” is implemented on the webpage, not the router.

Results

Response of the router seems to be very pleasant. The browsers show around 25ms response time, with both devices connected over WiFi. I tried opening the page from 3 devices and set the data refresh rate to 10/second and the router had no trouble handling it, there is plenty of power to spare. It is definitely faster than what you get from microcontroller based web servers, while the page is more complex.

While the design of the control panel and display may not be very artistic, it totally achieves the functionality I desired. I have displayed the important status parameters with gauges and text, which gives the user both precise and a fast display of status. A plot shows the evolution of parameters over time, providing a nice history.

Heatsink tester 2.0

My intention was to modify the original project as little as possible, jut to test the overhead of making such a web interface once the console is done.

I have changed the way data is send through the serial port to be comma separated, as this makes it very easy to parse. I have added some other status parameters, like if the heater is on, what is the maximum set power etc. I made minor improvements to the functionality as well: I added temperature limiting, if the temperature threshold is crossed, the available power will be limited. The loop is implemented in a simple way and is not very stable, but I don’t intend to spend time fixing it as it is meant only as a simple safety measure.

The second thing to add was a safety measure: periodically(every 5 seconds) the webpage pings the microcontroller. If no ping is received, after 12 seconds the microcontroller will stop the test and stop heating the heatsink. This means that the heater cannot remain on if there isn’t at least one web page open.

Here’s a quick measurement of a heatsink

heatsink tester connected to routertest with heatsink tester and web interface

Future plans

For the moment the plot is made by every webpage, so a device connecting later does not have access to the history. I will expand the script on the router to achieve this.

As it seems that one single router can handle lots of things, for some projects it might make sense to use a router as a gateway for multiple projects. Data can be sent to the router with simple radio modules, like RFM12 or NRF24L01. This will make each project smaller and possibly battery operated.

Disclaimer and thoughts

This is not meant to be a complete project, just a test of feasibility. So there are no files available or detailed instructions how to achieve this. I will post all details with the first complete project that will have a web interface. I have had troubles getting stable results over the serial port. After many tries I decided to re-install openwrt after which everything worked fine. The webserver on the router comes by default with a very low number of maximum connections which causes frustration and failure to load pages, slow interface etc. So I increased it.

I have been unsuccessful at making it visible as network devices through network discovery, it would work out great if its properties could point to its webpage. Drop me a comment if you know how to.

The power supply should be able to provide the full current of a single USB port, 500mA but I suspect the total available to be more like 0.8A. My sensitive power meter shows the router draws about 1.2W from the mains while connected to the WiFI, while also powering the microcontroller and the CP2102 USB-serial adapter. The router itself needs only 1W of power.