Monthly Archives: February 2015

The Snap! environment

By   February 14, 2015

I thought it might be useful to explain how Snap! works in my device control scenario. I’ve ever so slightly modified Snap! to be able to query my server and get an inventory of inputs and outputs available. These are known as “Phrob Ins” and “Phrob Outs” for lack of a better name.

snapshot1

On the left is a list of all inputs that were discovered during the inventory process.

In the center are the logic blocks I’m currently working with. There are 4 logic blocks there. Two of them are outlined in Green. These two are presently executing. The other two are not. The smallest logic block on the bottom has a speech bubble next to it. I simply clicked on the “Office:temperature” input and the speech bubble popped up and said “2214” which is DegreesC multiplied by 100. I’m currently experimenting on whether to transmit data as integers or floating point decimals. The jury is out. There is a logic block on the middle right that is not executing. I can simply click on a logic block to start or stop the block.

On the right top is a white canvas which presently displays some temporary variables that my logic blocks use. It’s handy to see those variables displayed because it makes debugging easier.

The top running logic block is responsible for collecting some statistics and transmitting a single text message out to the APRS IS network. On this network, I can remotely see what’s happening at the cottage:

2015-02-14 13:40:28 UTC: VF9ABC-9>VF9ABC: T=70.0,OA=32.0,SP=70.0,H1A=0,C1A=0,LRT=21.86,LRH=33.83
2015-02-14 13:45:28 UTC: VF9ABC-9>VF9ABC: T=70.0,OA=32.0,SP=70.0,H1A=0,C1A=0,LRT=22.01,LRH=33.4
2015-02-14 13:56:02 UTC: VF9ABC-9>VF9ABC: T=70.0,OA=32.0,SP=70.0,H1A=0,C1A=0,LRT=22.14,LRH=32.88
2015-02-14 14:06:42 UTC: VF9ABC-9>VF9ABC: T=69.0,OA=32.4,SP=70.0,H1A=1,C1A=0,LRT=22.49,LRH=32.76
2015-02-14 14:12:00 UTC: VF9ABC-9>VF9ABC: T=70.0,OA=32.0,SP=70.0,H1A=0,C1A=0,LRT=22.57,LRH=32.45

While it is somewhat soothing to see the raw data, sometimes it’s nice to see a graph:

graph

Cottage Automation

By   February 13, 2015

My journey had several goals. One of these was to learn Python. I’ve been able to do all the programming I’ve ever needed using “C” and Assembly language with a bit of shell scripting on the side. None of these languages was going to suit me well for this project. I liked the speed with which a person can prototype an idea in a higher level language. My friend Kurt http://www.burgundywall.com is a huge proponent of Python and also a lot more up on current intarwebs technologies than I. So I dove into Python. Kurt thinks of me as a quaint old man so his assistance comes with a small amount of mocking and irreverance. No matter. I know how to code, but I occasionally need realignment as to which direction is correct when it comes to REST, object oriented design, etc.

After some prototyping, and some prototype AVR based hardware from Jeff, I was able to read from an I2C temperature/humidity sensor, turn relays on/off, and read from an SPI Thermocouple amplifier. Already this had many potential applications! A person could conceivably smoke meat on a BBQ with a motorized vent, or roast coffee in a repurposed breadmaker. It was certainly possible to write Arduino code to do these things but it was quicker and easier to just drag&drop some logic elements from Snap! and quickly debug the process. Here’s a simple Snap! program to control a linear motor hooked up to a BBQ with a thermocouple to sense the temperature inside the bbq as well as a thermocouple to sense the meat temperature.

One of the reasons I chose Snap! over something like Blockly was that Snap! logic blocks run in the browser. One of the nice side effects of this is that you can interactively debug your code and even click on an input or output and have an action occur immediately. For example, I can click on the icon of one of my temperature sensors and read the temperature interactively:

inside_temp

Now came the next step. There is some hardware that is just easier to buy than it is to build:

The Etherrain has a rain sensor and 8 valve outputs:

etherrain8

The TR60 thermostat has lots of goodies:

tr60

I can see what the indoor temperature is, outdoor temperature, how long the furnace has run in the last 5 minutes, what the current setpoint is, whether the fan is on, and I can set the current temperature setpoint (for either heat or cool).

Since my cottage is out in the woods, cellphone reception is not always awesome. Since I have an amateur radio license, I can legally transmit APRS packets. So I have an APRS transceiver connected to my server as well. I wrote a plugin for that as well, so I can send/receive messages from Snap!:

mttt4

With the above, I am able to do some interesting things fairly simply:

dr1

 

There are two logic blocks there. The upper one collects the humidity and temperature from a piece of Jeff’s hardware that lives in the Office out at the cottage. It also queries the TR60 thermostat for various bits of information and builds a string that is sent out as an APRS packet to the APRS-IS network where I can monitor it remotely. The lower logic block queries the TR60 thermostat to see what the current setpoint is and takes some action depending on whether the temperature is set to warm or cold. I am using the thermostat as a sort of occupancy sensor. When we set the temperature to 70F, I also want to have the hot-water recirculation pump turned on.

Device Automation

By   February 13, 2015

My friends say I’m a control freak and detail oriented. I’m not sure whether to be insulted or not but whatever.

We have a cottage in the woods that we bought in early 2010 and spent the next 4 years essentially rebuilding the house. We knew we would have to renovate it when we bought it but the further I dug into it, the further I discovered I was going to have to go. Now that I’ve learned a lot about building science, I won’t waste money on a house inspection in the future. But that’s for a separate article.

While working on the renovations, we also lived in the building on weekends.. This was a valuable time to learn about the building during the various seasons and gain an understanding of how we wanted to use it. The bright sunny places to sit at various times of the day, the oppressive heat in the summer, and biting cold of winter. Bug ingress season, Bug egress season. What I also learned was the various things that I needed to keep an eye on. When you put as much money into a place, you want to do whatever possible to protect that investment. But there’s also an opportunity to reduce maintenance and weekend effort. It is, after all, a retreat, not a gulag.

During my day job, I do embedded firmware. This means I write software for small microcontrollers in various applications; specifically interfacing them to the real world. So while working on the cottage, I saw many opportunities for automation and data gathering. When you own a home that you live in, you’re able to take care of things in the home because you’re always there (or you have neighbors who can do things while you’re on holidays)… Things like watering the grass or flowers, fixing leaky pipes, fixing the furnace, fixing windows. When you live in the city, many things are taken care of. Fresh water comes in under pressure for you, sewage leaves automatically, and your furnace turns on/off at the whim of your thermostat. You likely find out pretty quickly when something goes wrong. Not so much when you have a building a couple hours away that you don’t visit during the week, or might not visit for weeks at a time.

Out in the country, there are frequent power failures, or someone can notice that your driveway isn’t plowed and so decide to break in, leaving doors or windows open. Pipes can freeze or burst and before you know it, your basement is full of water. It’s easy to turn off the water when you’re not there but then you can’t automatically water the plants in the garden.

There are also some nice-to-haves… In the winter, it’s nice to be able to set the thermostat before you head out so when you arrive, everything is nice and warm. There’s a lot of heat mass in a building. So your furnace might get the air temperature up to 70F fairly quick, but all the walls, dishes, tiles, appliances, bedding, etc, are all still cold. It can take a few hours before the whole house is at a comfortable temperature. Same goes for summer. There’s nothing quite like driving out after work to discover the inside of the house is over 90F and you have to wait until after midnight before it’s comfortable enough to sleep.

There’s plenty of home automation stuff but was simultaneously horribly expensive while also not offering me the flexibility that I wanted. I know that I can buy a bunch of cheap Arduino hardware and build a whole shwack of custom sensor and control modules, each of them having custom firmware to do a single task. But coordinating them all can be a lot of work. Then the overriding logic is also higher effort than I wanted.

Around the same time as this, my buddy Jeff was wanting some generic sensor/control hardware to control his greenhouse. We quickly realized there’s a need for people to automate their hobbies. My building was my hobby.

My feeling is that the easier you make it for people to write code the more they’re able to accomplish. My dad can hookup relays, thermocouples, and that sort of thing but he can barely program a VCR.

When my son was in Grade 5, he was taught how to use “Scratch” https://scratch.mit.edu/ and that was the first thing that came to mind when I thought of simplifying device automation. After some research and experimentation, I found the reimplementation called “Snap!” http://snap.berkeley.edu. Thus my idea was born.

In the next article, I will go into some detail about what I’ve been working on.