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.
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.
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.
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:
I’ve been doing embedded for a long time but I’ve been doing unix admin stuff for way longer. I’ve probably been using inetd and tftp for 25 years. I’m always shocked at the ability for tftp to take up a couple hours of time the first time you want to get it running on a host.
When doing embedded, I typically like to point tftpboot at my compiler output directory which saves a copy step. Sometimes you forget to copy and you can’t figure out why your printf()s aren’t showing up (because you’re still running an old version).
Anyway, on Ubuntu, you typically install xinetd and tftpd…
sudo apt-get install xinetd tftpd
Then you want to create /etc/xinetd.d/tftpd :
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = hpeyerl
server = /usr/sbin/in.tftpd
server_args = -s /home/hpeyerl/trunk/firmware/esp8266
May 10 06:03:57 pm001 in.tftpd: connect from 192.168.37.30 (192.168.37.30)
May 10 06:03:57 pm001 tftpd: tftpd: trying to get file: antares.rom
May 10 06:03:57 pm001 tftpd: tftpd: serving file from /srv/tftp
The key there is “/srv/tftp”… Since there’s no mention of /srv/tftp in your xinetd.d config file, something else must be happening…
So, here are some gotchas that will consume some debug time:
If you’re testing this by using tftp on the same host as tftpd, you won’t see anything in tcpdump because the packets are short-cutting through your localhost interface.
On Ubuntu, there is also an /etc/inetd.conf which is your culprit:
#:BOOT: TFTP service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp
tftpd is very picky about permissions. You might be tempted to make every element in your path 777, I don’t need to tell you this is a bad idea.
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:
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:
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.
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.
As I get older, I find my desire to do sysadmining is waning. I just want stuff that works; I already have plenty of hobbies. I got tired of dealing with disk failures on my Plex server and my distaste for sysadmining overrode my tendency towards thriftyness. I decided spending $500-$600 on a NAS was a worthwhile purchase. A friend mentioned that a friend of his had a Drobo that he was happy with and I looked there. I compared features with the QNap and Synology units available at the local retailer and decided a Drobo-5N was just the thing.
I was attracted to:
no tools disk install
no real need to do administration. Just slide disks in and it figures everything out on its own.
availability of plugins
industrial design (magnets are what hold the front panel in place)
But mostly, I wanted something that would ‘just work’ and not turn into a hobby. So I bought it, and a couple of 4TB disks and brought it home.
I installed 2 4TB disks, 2 2TB disks and a 1.5TB disk. The lights flashed and all kinds of stuff happened and after installing the Drobo Dashboard software, it all looked cool.
So I went to droboports.com and selected a few packages. Since I wanted NFS for my Plex server, I installed it, along with ssh, vim, and a couple others. In order to install ssh, there’s some jumping through hoops you have to do with /etc/group, /etc/passwd, and so forth. This is where the problems started.
In short, I bricked the Drobo 5N. I followed the instructions on droboports to the letter but it was dead. I realized I’d screwed up so went with a ‘Factory Reset’ but that didn’t solve the problem. I tried the reset button on the back but all I managed to do was clear out my settings but still it was unhappy and I couldn’t use it. I should mention in all of this that my previously created mountable volume became erased as well. Good thing I’d only copied about 4TB onto it that I still had stored elsewhere. But the act of hitting the ‘Factory Reset’ button causes all of your setup to go away, including your disk volumes.
After a bit of back and forth with front-line tech support wherein all the stuff I’d already tried was suggested, I was referred to second tier support who immediately came back with “reflash your firmware, here’s a link to the image and instructions”… After reflashing the firmware, all was well again.
I rebuilt my volume and got NFS installed. I also tried to install Crashplan by clicking the checkbox in Drobo Dashboard but the installation failed. After some googling, it turns out you have to use Droboports again to install Locale and Java. The side question is: why provide a checkbox to install a package when you still have to do all kinds of commandline installs of dependancies? A bit of false advertising there.
I got my Plex media server to stream off the NFS mounted Drobo volume and everything looked great. I settled in for some well earned TV viewing. About an hour in, the NFS mount stalled and the Drobo seemed to hang. Rebooted the Drobo as well as the Plex media server and tried again. It hung again. I punted and went with an SMB mount. That worked well enough. A little sub-optimal but whatever. I guess this Drobo ports thing isn’t all it’s cracked up to be.
I went away for a 4 day weekend, and when I came back, the Drobo was bricked again. In short, I couldn’t get it to respond to the Drobo Dashboard app. After starting another tech-support ticket and going through 7 days of back and forth with frontline support, (one exchange per 24 hour period) I was finally referred to second tier support. By this time, I had discovered that if I removed all the disks, I could talk to the Drobo but of course couldn’t do anything. If I re-inserted the disks one by one, I could talk to it until I put the 5th disk in; then it went unresponsive. The love affair was over. It seems as though I lost a disk (the 1.5TB). The disturbing thing is that this is exactly the scenario that prompted me to buy the Drobo. However, even with the 4 original disks, the Drobo was unable to mount the volume. The message was “there are not enough disks to mount the volume – mount failed”… This is not how a NAS is supposed to work. While messing around, I’m still waiting to deal with Tech Support. All of my exchanges with them told me that they’re not capable of reading the ticket so I was asked to try things I’d already tried and itemized in the first message. Remember, each exchange is about 24 hours. After a few days of this, it came down to “Do a Factory Reset and start over”.. In other words, throw away all of my data and recreate the volume. I asked “is there no useful diagnostic information to be gleaned here as to what happened?” … The answer, “maybe. Let me transfer you to second tier support. After a couple of useless exchanges, wherein we were running out of things to try, tech-support went dark. Over 48 hours with no response and a couple of “Hello? Is there anyone there?”, I decided enough was enough, I went back to my retailer to return the unit. They have a 7 day exchange policy but after reading through a transcript of my tech-support tickets, they refunded my money. I got the impression they weren’t surprised, as in this had happened before. I think it’s likely they’re going to drop Drobo.
After some googling, I decided upon a Synology DS414. I brought it home, installed the 4 disks that were previously in my Drobo 5N (leaving out the 1.5TB that conceivably failed) and it’s been trouble free for over a month. In fact, I’ve started migrating services over to the Synology including DNS forwarding, DHCP, and Asterisk. I’ll move my Subversion repository over to it as well, and then I’ll be able to turn off one of the machines in my rack and realize some power savings. The best part is there’s been a relatively steady stream of free firmware updates which address linux security vulnerabilities and a major upgrade with new features. All free!
I did finally hear back from Drobo tech support with a “Sorry about the silence. I was sick and out of the office”. So apparently there’s nobody managing tech-support. Tech support is ‘a guy who responds to tickets’, not a department with a manager who makes sure all tickets get timely responses. When I responded “Too late, I already returned the Drobo and bought a Synology”, the response (the next day) was “Great!” and the ticket was closed with “Solved”.. I was then sent a Support Survey link where I unloaded my mental baggage itemizing my poor experience with their product. Either nobody reads the surveys or they don’t care because nobody ever contacted me. If I was running a small company in a highly competitive consumer electronics vertical market, I’d be right on top of bad survey returns.
I got a broken Nexus-7 and wanted to use it as a router up at DebtRidge. I wanted it to come up as a wifi hotspot automatically when booted. This means the ‘hostapd’ daemon needs to be started automatically. So here’s what I did.
Since init.d is run in /data/install-recovery-2.sh, it runs too early in the boot process for hostapd to start. Another issue is that hostapd won’t run if Wifi is enabled. However, if Wifi hasn’t been enabled, the wlan driver isn’t loaded and hostapd isn’t able to bind to wlan0 because it doesn’t exist. So I had to find a way to load the wifi drivers so that hostapd would come up.
I discovered that I can run “svc wifi enable” to install the drivers and bring up the wlan0 interface. Then “svc wifi disable” would bring down the wlan0 interface but leave the drivers installed. At this point, hostapd was perfectly happy.
So to bring this all together, I needed a script that could be launched at boot time that would delay the starting to hostapd until later in the boot process. Here’s what I did.
mount -o rw,remount /system
cat > 50hostapd
chmod 755 50hostapd
Now install the following script as /data/start_hostapd.sh:
while true; do
su -c svc wifi enable
netcfg | grep wlan0 && break
su -c svc wifi disable
/system/bin/hostapd -e /data/misc/wifi/entropy.bin /data/misc/wifi/hostapd.conf &