Kitchen Brainiac: Intro

Hi folks!  I'm not going to go into unboxing the contest items - that has already been done pretty well by the other folks, so I'll defer to them.

I'm going to jump right into this project, which I'm calling the Kitchen Brainiac.  This entails a centralized controller, turning on, and off remote controls located on various devices, such as crock pots, coffee makers, bread machines, beer distilling rigs, sous vide cooker, meat thermometers, etc.  Each "device" will house either a simple Wifi enabled board, such as a ESP8266, or will use a node Raspberry Pi with a relay output, such as the Piface.  To keep costs down, I will initially go with the ESP8266 based node (an Adafruit Feather Huzzah), and connect back to the host controller with Modbus TCP, which is a widely used industrial protocol which has good Arduino and Python support. 

https://en.wikipedia.org/wiki/Modbus

A bit about myself.  My background is building industrial control systems typically built around PLCs, Programmable Logic Controllers, so I work quite a bit with them, and look to apply some of the techniques and methods I use in building those types of systems.  Rather than building a single smart device or item for the kitchen, my goal is to build a system, which can be implemented for any number of devices in the kitchen, or even expanded to the whole house (think smart control, or even holiday lights).

I love the capabilities of the Pi and the richness of the community in terms of inspiration and content, and it's no different from the PLC side of things.  Granted, most every bit of software out for the Pi is open source, and is widely available in the form of libraries, and how to guides, and is mostly free.  For my project, I am using a very inexpensive component for the PLC runtime from a company based in Europe called 3S Systems, who make a product called Codesys.

To make a long story short, 3S systems develops and licenses their PLC runtime technology to hundreds of manufacturers around the world, probably including many large companies you may know or have heard of, who will remain unmentioned here, but take my word for it, it's a lot.  Most amazingly, 3S, has made their flagship runtime available for the Raspberry Pi for a pittance (about $50), which is comparable to industrial PLC systems costing 10X or more for the same capabilities.  It's also a really good way to learn some PLC languages and methods you probably won't be exposed to in the Pi world unless you use PLC's either.  I won't get into Codesys or 3S anymore than that, but feel free to navigate to their site, particularly the store where you can download the IDE, and the runtime package itself, as well as their active forum on the Raspberry Pi.  The runtime runs for free up to 2 hours, but the license removes this time restriction.  The IDE is free also, and requires no license for it.  There are a lot of videos on using Codesys with the Pi on Youtube.  I will post some hopefully as well, as I document the project progress.

Install the IDE first:

The install the Raspberry Pi package:

Here are good resources for questions on the Pi with Codesys on their forum:

In a nutshell, the main controller, the Kitchen Brainiac, will consist of the Raspberry Pi 3, with it's associated HAT.  The contest provided a wide selection of available HATs to use.  One problem with this, is that most of them are top HATS - so using more than one can get tricky.  It's possible to create a sort of mini backplane, with the Pi's 40 pin header getting split to multiple header's for each board, but I want to stay away from that for simplicity's sake.  My alternative, is to use MULTIPLE raspberry Pis, all interconnected over the network, and keep each Pi with it's own HAT.  This way, it solves the TOP hat issue, but it also demonstrates another nifty capability of the Pi with Codesys - distributed control using network variables.

For the project, I will be using the Sense Hat, the Piface Digital 2, the NFC expansion, and the Raspberry Pi camera 2.  I won't be using the touch screen, since it requires a modified kernel to use, which might break the Codesys runtime (or it might run just fine).  This will basically require 2 more additional Raspberry Pi 3 boards, of which I'm sure most of you out there have 8 or 10 lying around like I do

I will be using the built in Web visualization capability of Codesys, so that you can access and control the system from any browser based device.  This is also how we will utilize the Raspberry Pi camera - with an embedded video window on the GUI control screen.  Here's an example in a robot I built.

Each Pi will "publish" it's own network variable list, and will "consume" the network variable lists from the other Raspberry Pi's in the system.  This provides a sort of shared memory model, between the various CPUs of the system.  It also allows expansion of the IO, among many different Pi's, and provides a mechanism to distribute programs among the various boards where they make sense.  This can also be used for redundancy in the system, with identical programs running on all Pis, a heartbeat signal can be used to enable a redundant program, if the main CPU goes down.

One of the Pi's will utilize a Modbus TCP server, which will provide a centralized hub, for each end node to connect to and transfer data.  Each node will be running a client, and will have several registers dedicated to just that particular node.  This is an easy and clean way to have lots of "nodes" pushing data into the centralized Modbus server repository.  The master controller program running in Pi with the server, will then act on the data provided, and will turn on and off outputs back to those nodes accordingly.

One nifty feature we will be using, in using Modbus, is the ability to tie Raspberry Pi python code or other code (like C or NodeJS, or whatever) running outside of Codesys, back into Codesys.  Codesys provides a "framework", to have multiple, independently running programs, each with it's own task run clock.  This allows you to run faster processes quickly, and run slower processes independently of each other. When we have something that we want to run in the underlying linux subsystem, such as that nifty Python code or other sample program generously provided for by Adafruit or some other resource, you simply add a Modbus Client sending and receiving the data from the Python code to local host, at 127.0.0.1, which just so happens to be the Modbus server being run by the Codesys system. A nice and easy way to move data into and out of Codesys.  I have done this very successfully with boards like the Ultimate GPS hat and others.

I will set up and demonstrate the use of the wonderful OSCAT libraries in Codesys.  These are three large, open source libraries that are available to install into Codesys, that provide a huge amount of well documented, ST code, which not only can be used as is in most cases, but can be easily modified and ported into your own code for your own use case.  It's truly a wonderful tool.

Finally, I will introduce and demonstrate a couple of custom device drivers that I have tested around with, and will show how to use them for use in your own projects.  I have used these custom I2C drivers to talk to everything from Parallax Propeller's to Cypress PSOC4's to Teensy 3.2 chips to Grove sensors, to you name it.  Codesys provides support for the Sense HAT, the GPIO, the Pi camera, the Piface, etc.  It doesn't support the NFC board - but I will attempt to use my two drivers to accomplish this.  Once you see how that is done, you can use them for your own devices as well.

Needless to say, all of this is quite easy to configure and set up in Codesys, and I will show and demonstrate everything.

To configure and monitor everything, I will go over the setup I use on the Pi, to get everything up and running well, and provide a nice headless interface to the Pi using VNC.

Feel free to make suggestions on some of the other devices in the kitchen that may be useful.

I have attached a quick run through on getting a Pi set up with Codesys and running headless.  It's lean on detail for now, but for folks who may have done these things before, may be adequate for detail.  I'll add more detail over time, but I wanted to get this out early, so perhaps others can follow along as I go.  Feel free to make suggestions to add steps also for clarity.

Attachments:

Startup Pi Doc.pdf