ESP8266 BASIC WiFi Thermostat is Child’s Play

If you’ve read any of our posts in the last couple years, you’ll have noted that our community is stoked about bringing the Internet to their devices on the cheap with the ESP8266 modules. Why? This forum post that details making a WiFi thermostat really brings the point home: it’s so easy and cheap to build Internet-enabled devices that you almost can’t resist.

When the ESP8266 first came out, there very little documentation, much less code support. Since then Espressif’s SDK has improved, the NodeMCU project brought Lua support, and there’s even Arduino support. Most recently, BASIC has been added to the ESP stable, and that really lowers the barriers to creating a simple WiFi widget, like the thermostat example here that uses a Dallas DS18B20 temperature sensor and an LED as a stand-in for the heater element.

The hardware for this project, a re-build of this demo code from the ESP8266 BASIC docs, is nothing more than a few off-the-shelf parts soldered together. No schematic required.

What makes the project work behind the scenes is some clever code-reuse by [Rotohammer] on the ESP8266 forums. Essentially, he wrapped the Arduino’s one-wire library, giving it simple BASIC bindings. Then all that’s left for the BASIC coder is to read the value and print it out to a webpage.

There’s all sorts of details swept under the rug here, and those of you out there who are used to bare-metal programming will surely huff and puff. But there’s a time for building your own injection-molder to make DIY Lego bricks, and there’s a time to just put blocks together. This project, and the BASIC interpreter that made it possible, demonstrate how much joy someone can get from just putting the parts together.

The Internet of Minecraft Things is Born

Minecraft has come a long way since [Notch] first thought up the idea that would eventually make him a billionaire. The game can be enjoyed on so many levels and become so engaging that grown adults who should know better spend far more time playing it than working on, say, their backlog of Hackaday posts. As if that weren’t bad enough, now Minecraft threatens to break out of screen with the ability to control a WiFi light bulb from within the game.

For those unfamiliar with Minecraft, it’s an open world game that allows players to interact with blocks of various materials. Players can build, destroy, explore and create landscapes and structures. An active modding community contributes everything from cosmetic texture packs to new block types with extended functionality. It was one of these mods that was leveraged to “break the fourth wall” in Minecraft. [giannoug] used the OpenComputers mod, which allows placement of programmable in-game computers with a full complement of peripherals, including an Internet connection. That allowed [giannoug] to send commands to his Brand X eBay WiFi light bulb, the protocol for which his friend [Thomas] had previously reverse engineered. Flip a switch in Minecraft and the real-world light bulb comes on instantly. Pretty cool.

We’ve seen quite a few builds where Minecraft blocks inspired real-world lamps, but this is a step beyond and might be a great way to get kids into programming using Minecraft. But it’s not the first time Minecraft has broken the fourth wall – check out this 2012 effort to build a microcontroller-based Minecraft server that can toggle pins from within the game.

[Thanks to aggvan and Stathis K for the near-simultaneous tips!]

Hackaday Links: November 22, 2015

There’s a new documentary series on Al Jazeera called Rebel Geeks that looks at the people who make the stuff everyone uses. The latest 25-minute part of the series is with [Massimo], chief of the camp. Upcoming episodes include Twitter co-creator [Evan Henshaw-Plath] and people in the Madrid government who are trying to build a direct democracy for the city on the Internet.

Despite being a WiFi device, the ESP8266 is surprisingly great at being an Internet of Thing. The only problem is the range. No worries; you can use the ESP as a WiFi repeater that will get you about 0.5km further for each additional repeater node. Power is of course required, but you can stuff everything inside a cell phone charger.

I’ve said it before and I’ll say it again: the most common use for the Raspberry Pi is a vintage console emulator. Now there’s a Kickstarter for a dedicated tabletop Raspi emulation case that actually looks good.

Pogo pins are the go-to solution for putting firmware on hundreds of boards. These tiny spring-loaded pins give you a programming rig that’s easy to attach and detach without any soldering whatsoever. [Tom] needed to program a few dozen boards in a short amount of time, didn’t have any pogo pins, and didn’t want to solder a header to each board. The solution? Pull the pins out of a female header. It works in a pinch, but you probably want a better solution for a more permanent setup.

Half of building a PCB is getting parts and pinouts right. [Josef] is working on a tool to at least semi-automate the importing of pinout tables from datasheets into KiCad. This is a very, very hard problem, and if it’s half right half the time, that’s a tremendous accomplishment.

Last summer, [Voja] wrote something for the blog on building enclosures from FR4. Over on he’s working on a project, and it’s time for that project to get an enclosure. The results are amazing and leave us wondering why we don’t see this technique more often.

Belkin WeMo Teardown

[Brian Dipert] over at EDN has a teardown of Belkin’s answer to the Internet of Things (IoT) craze: the WeMo. This little WiFi gadget plugs into an outlet and lets you turn a connected device on and off from a smart phone app or something like Amazon Echo.

As you might expect from a cheap piece of consumer hardware, there’s not a whole lot inside. The digital board contains a Ralink WiFi chip, an antenna etched on the PCB, and a handful of components, including an SDRAM and some flash memory.

Continue reading “Belkin WeMo Teardown”

RFM69 to MQTT Gateway on the Super-Cheap

[Martin] is working on a RFM69-to-MQTT bridge device. If you’re at all interested in DIY home automation, this is going to be worth following. Why? When your home automation network gets big enough, you’re going to have to think seriously about how the different parts talk to each other. There are a number of ways to handle this messaging problem, but MQTT is certainly a contender.

MQTT is a “lightweight” publish-subscribe framework that’s aimed at machine-to-machine data sharing, and runs on top of a normal TCP/IP network. IBM has been a mover behind MQTT since the beginning, and now Amazon is using it too.

But most MQTT servers need a TCP/IP network, which pretty much means WiFi, and this can be a killer for remote sensors that you’d like to run on battery power, or with limited processing power. For these use cases, a low-power, simple sub-gigahertz radio module is a better choice than WiFi. But then how to do you get your low-power radios to speak to your MQTT devices?

That’s the point of [Martin]’s MQTT bridge. Previously he had built a sub-gig radio add-on for a Raspberry Pi, and let the Pi handle the networking. But it looks like there’s enough processing power in a lowly ESP8266 to handle the MQTT side of things (over WiFi, naturally). Which means that you could now connect your 868 MHz radio devices to MQTT for less than the cost of two pumpkin spice, double-pump lattes.

On the firmware side, [Martin] has enlisted the help of [Felix], who developed the Arduino-plus-RFM69 project, the Moteino. [Felix] has apparently ported his RFM69 library to the ESP8266. We’re dying to see this working.

For now, we’ve got some suggestive screenshots which hint at some LAN-exposed configuration screens. We’re especially interested in the RFM + MQTT debug console window, which should really help in figuring out what’s gone wrong in a system that spans two radio protocols.

The bottom line of all of this? Super-cheap, power-efficient RFM69-based radio nodes can talk with your sophisticated MQTT network. Keep your eyes on this project.

FCC Clears The Air With Wi-Fi Software Updates

A few months ago, the Internet resounded with news that the FCC would ban open source router firmware. This threat came from proposed rules to devices operating in the U-NII bands – 5GHz WiFi, basically. These rules would have required all devices operating in this band to prevent modification to the radio inside these devices. Thanks to the highly integrated architecture of these devices, Systems-on-Chips, and other cost cutting measures from router manufacturers, the fear was these regulations would ultimately prevent modifications to these devices. It’s a legitimate argument, and a number of the keepers of the Open Source flame aired their concerns on the matter.

Now, the FCC has decided to clear the air on firmware upgrades to wireless routers. There was a fair bit of confusion in the original document, given the wording, “how [its] device is protected from ‘flashing’ and the installation of third-party firmware such as DD-WRT.” This appeared to mandate wholesale blocking of Open Source firmware on devices, with no suggestion as to how manufacturers would accomplish this impossible task.

[Julias Knapp], chief of the FCC’s Office of Engineering and Technology has since clarified the Commission’s position. In response to the deluge of comments to the FCC’s Notice of Proposed Rulemaking, the phrase, ‘protected from flashing… Open Source firmware” has been removed from the upcoming regulation. There’s new, narrow wording (PDF) in this version that better completes the Commission’s goal of stopping overpowered radios without encroching on the Open Source firmware scene. The people spoke, and the FCC listened — democracy at work.

Improving WiFi Throughput with FM Radio

WiFi networking is one of those things that is reasonably simple to use, but has a lot of complex hidden features (dare we say, hacks) that make it work, or work better. For example, consider the Distributed Coordination Function (DCF) specified in the standard. Before a station can send, it has to listen for a certain time period. If the channel is clear, the station sends. If not, it has to delay a random amount of time before trying again. This is a form of Carrier Sense Multiple Access (CSMA) channel management.

Unfortunately, listening time is dead time when–at least potentially–there is no data transmitted on the network. DCF allows you to use various handshaking packets to do virtual carrier detection and ready/clear to send, but these are also less efficient use of bandwidth. There are other optional coordination functions available in the WiFi standard, but they all have their drawbacks.

[Aleksandar Kuzmanovic] at Northwestern University and two of his students have recently published a paper with a new way to coordinate multiple unrelated wireless networks using ubiquitous FM broadcast radio signals called WiFM. Instead of trying to synchronize to the WiFi data channel, this new scheme selects a strong FM radio station that broadcasts Radio Data Service (RDS) data (the data that populates the song titles and other information on modern radios).

Continue reading “Improving WiFi Throughput with FM Radio”