Category Archives: Phrobs

MQTT Config

By   October 13, 2015

MQTT Config

So as I work to integrate MQTT into my automation environment, I find myself wishing for some sort of device discovery mechanism. Possibly also a device configuration mechanism.

Here’s the problem as I see it.

If I know the topic of a device, I can subscribe to it and I can even get its last data. I can also subscribe to all topics or a subset of topics. But then I have to wait for a device to publish something in order to discover it.

Unfortunately, I can’t ask Mosquitto what devices it knows about.

There are many use-cases where this just isn’t sufficient:

  • A device that isn’t publishing when you reboot.
  • A device that is turned off and only publishes when it gets turned on (like a device that uses a tilt sensor to power itself on).
  • A device that doesn’t publish at all (a subscribe only device like a Relay).

It would also be nice to be able to re-configure some attributes of a device though I can see how this could be abused in an InternetOfThings scenario.

So I believe I’m going to define a ‘discovery’ record and experiment with that. I’m thinking something like this:




This tells me that is a sensor named “Kitchen” that publishes a temperature as an int in degrees celsius… There’s also a control named “Garage” that publishes a “Relay” state but it also has an output that it subscribes to called “Relay”… They both provide/take a boolean. There’s also a control named “Garage” that subscribes to “RelayToggle” that will conceivably cycle a relay on/off or off/on for some number of seconds.

I’ll experiment with that and see if I can make it useful… It will allow me to maintain an inventory of devices that are available… I will have to come up with some sort of expiry mechanism of course and if an attribute changes, I’ll need to override the old config with the new one presumably.

ESP8266 ESP-12 Deep Sleep

By   October 2, 2015

To address the issue of my temperature reading too high on boards with temperature/humidity sensors, I opted to deploy the ESP system_deep_sleep(us) call to put the board to sleep after publishing the temperature via MQTT.

Current draw when the board boots is 145mA until it connects to the AP, then it seems to go down to about 77mA and then when it goes to sleep, it draws about 55-60uA…

Presently I have it configured to wake up, bind to my AP, after it gets an IP, publishes the temperature/humidity and go to sleep for 30 seconds.

Here is the board:

Here’s a thermal video demonstrating this. At 00:04 and 00:35, you can see the LDO heat up when it wakes up from it’s nap:

Video was taken using a Therm-App android thermal imaging camera borrowed from Angus.

ESP8266 ESP-12 Thermal

By   September 29, 2015

I’ve been working with the ESP8266 chip, specifically the ESP-07 and ESP-12 modules available for cheap… One of my Phrobs has an SI7020 I2C – temperature/humidity sensor on board. As I’m a beginner at hardware, I’ve had to crank out a couple revs of this board due to thermal coupling issues. The temperature reads about 9C higher than ambient which obviously affects the humidity reading. My second rev of this board had the SI7020 isolated with its own grounding vs the LDO ground plane and the ESP8266 ground plane… I was hoping to be able to dissipate the heat other than through the substrate. As you can see below, I was wrong.

Here is the board:



Here we are plugging in the USB power:


Here it is immediately after plugging in the USB power:


And here it is 90 seconds later…


Images were taken using a Therm-App android thermal imaging camera borrowed from Angus.

My Phrob Army

By   September 3, 2015

Things are starting to come together. I’ve made some single-relay versions as I’ve determined they’re more practical. I’ve reduced BOM cost a bit, and my thermocouple Phrobs are coming together. Waiting for some connectors. Also my experimental Hall Effect Phrob is there as well.


Cottage Automation Revisited

By   July 20, 2015

So I’ve been expanding my cottage automation a bit and I think I’m starting to expose some cracks in my plan to use Snap! as an automation language. The biggest is at tasks that are schedule based. Here is the current logic. The whole thing doesn’t do a great deal because I’m not yet ready to trust major functionality to this code. Specifically irrigation. Shari would be displeased if the flower beds dried out.


The block on the right is my experimental irrigation block. First it checks that I’ve enabled irrigation. Then it checks to see if the rain-sensor is wet. Once the unit is ready, it checks for the various days of the week and then checks times and when they match, sets “would_irrigate” to the appropriate sprinkler valve number.

Looking at the whole block, it’s very ‘bit’ relative to the others and something I can do with Cron in about 3 small lines of text.

I need to find a better way to handle scheduled tasks.

Phrobs are in!

By   June 25, 2015

I’ve been working the last few months on learning KiCad which is open source eCad software with an abyssmal user interface. But I’ve managed to layout my first two boards. Both are based on the ESP-8266.

My first board has an SI7020 temperature/humidity chip. My second board has a couple of 16A relays on it (though the traces only support about 5A for now). Both boards are a ‘rev 1’ so a couple things need to be cleaned up for Rev 2.

Here they are:


I’ve also been hacking on esp8266-frankenstein which is a cool u-boot-like environment for the ESP8266’s. Another user had started porting someone else’s MQTT code to Frankenstein and then got busy. I took the code, finished bashing on it, cleaned it up, added some commands, integrated it into the GPIO driver and the SI7020 driver, and now I can MQTT Publish/Subscribe to my Phrobs:

mosquitto_pub -t "RelayPhrob1/gpio/5" -m "1"

Office/si7020/temperature/0 30
Office/si7020/humidity/0 24
RelayPhrob1/gpio/5 0
RelayPhrob1/gpio/5 1
RelayPhrob1/gpio/5 1
Office/si7020/temperature/0 30
Office/si7020/humidity/0 24
RelayPhrob1/gpio/5 1

$ mosquitto_pub -t "RelayPhrob1/gpio/5" -m "0"

RelayPhrob1/gpio/5 0
RelayPhrob1/gpio/5 0
Office/si7020/temperature/0 30
Office/si7020/humidity/0 24
RelayPhrob1/gpio/5 0

Next I will simply add an MQTT plugin to my Phrob ecosphere and I will be relatively self sufficient.

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.


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:


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 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:


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:


The TR60 thermostat has lots of goodies:


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!:


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



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” 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!” Thus my idea was born.

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