[Mirko Pavleski] has put together a little weather station for himself that combines Internet-sourced forecasts with physical sensor data to give him a complete view of his local conditions. There’s no shortage of weather applications for our smartphones and computers that will show us the current local conditions and the forecast for the next couple of days. It’s so easy to pull weather data from the various APIs out there that you even see the functionality “baked in” to different gadgets these days. Of course, you can dig through every weather API in the world and not find the temperature and humidity inside your office; for that, you need your own sensors.
[Mirko] took a somewhat unconventional approach by essentially building two totally separate weather devices and packing them into one enclosure, which gives the final device a rather unique look thanks to the contrasting display technologies used.
Local conditions are detected by an Arduino Nano connected to a BMP180 sensor and displayed on a Nokia 5110 LCD. The screen shows not only real-time temperature and barometric pressure, but the change in pressure over the last several hours. The three-day forecast, on the other hand, is provided by a NodeMCU ESP8266 development board connected to the increasingly ubiquitous 0.96 inch OLED.
The increase in network-connected devices the past years has been something of a dual-edged sword. While on one hand it’s really nice to have an easy and straight-forward method to have devices talk with each other, this also comes with a whole host of complications, mostly related to reliability and security.
With WiFi, integrating new devices into the network is much trickier than with Ethernet or CAN, and security (e.g. WPA and TLS) isn’t optional any more, because physical access to the network fabric can no longer be restricted. Add to this reliability issues due to interference from nearby competing WiFi networks and other sources of electromagnetic noise, and things get fairly complicated already before considering which top-layer communication protocol one should use. Continue reading “Transcending The Stack With The Right Network Protocol”→
Last year, we saw quite a bit of media attention paid to blockchain startups. They raised money from the public, then most of them vanished without a trace (or product). Ethics and legality of their fundraising model aside, a few of the ideas they presented might be worth revisiting one day.
One idea in particular that I’ve struggled with is the synthesis of IoT and blockchain technology. Usually when presented with a product or technology, I can comprehend how and/or why someone would use it – in this case I understand neither, and it’s been nagging at me from some quiet but irrepressible corner of my mind.
The typical IoT networks I’ve seen collect data using cheap and low-power devices, and transmit it to a central service without more effort spent on security than needed (and sometimes much less). On the other hand, blockchains tend to be an expensive way to store data, require a fair amount of local storage and processing power to fully interact with them, and generally involve the careful use of public-private key encryption.
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.
As the model was originally intended for a board game, it was obviously quite small. So the first order of business was scaling everything up to twice the original dimensions. As [Matthew] notes, the fact that it still looks so good when expanded by such a large degree is a credit to how detailed the original model is. Once blown up to more useful proportions, he modified the head of the turret as well as the barrel to accept the electronics he planned on grafting into the model.
He created a mount for a standard nine gram servo inside the head of the turret which allows it to rotate, and the barrel got an LED stuck in the end. Both of which are controlled with a NodeMCU ESP8266 development board, allowing [Matthew] to control the direction and intensity of the pew-pew over WiFi. He mentions that in the future he would like to add sound effects that are synchronized to the turret rotation and LED blinking.
For the software side of the project, he used Blynk to quickly build a smartphone interface for the turret. This is the first time he had used Blynk, and reports that outside of a little trial and error, it was some of the easiest code he’s ever written for the Arduino. This is a sentiment we’ve been seeing a lot of recently towards Blynk, and it’s interesting to see how often it shows up in ESP8266 projects now.
People often get the impression that home built hardware is destined to have a certain amateurish look or feel to it. It’s as though just because you didn’t buy it in a store, it will look cheap or thrown together. While it’s true a hacked together device could look like it was built from the parts bin (and to be fair, sometimes it is), there are plenty of examples of DIY hardware that could give commercial offerings a run for their money.
A case in point is this fantastic ESP8266 air conditioner controller created by [Sitinut Waisara] (Google Translate). Between the simple yet elegant 3D printed enclosure to the very slick user interface on its OLED screen, this project could easily pass as a commercial device. In fact, we’ve seen commercial offerings that didn’t look half this good, let alone offer the same features for what this cost in components and printer filament. It’s a perfect example of what the modern hacker or maker is capable of with the wide array of tools and components currently available to us.
What’s perhaps the most impressive about this project, especially given how good it looks on the outside, is how little there really is on the inside. Beyond the NodeMCU board and SSD1332 OLED display, the only components inside the device are the three tactile buttons, a photoresistor so it can dim the display’s brightness based on ambient light level, an IR LED so it can send commands to the AC unit, and a handful of passives. The hardware side of this design is so simple that [Sitinut] was able to put the whole thing together on a scrap of perfboard. Not that you’d be able to tell when it gets installed into the 3D printed wall-mount enclosure, complete with printed button caps.
While the hardware side of the project might be rather light, the software is anything but. [Sitinut] really went all-in writing his code for the ESP, adding in the little features like the automatic screen dimming and pulling the current time from NTP that often get overlooked in our rush to get a project out the door. He even included a whole collection of icons to display on the OLED screen, which goes a long way towards selling that professional look. But his effort wasn’t limited to cosmetics or clever features, there was also plenty of work put into decoding the IR signals used to control the AC unit and getting all the features and functions plugged into MQTT.
When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.
I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.
About seven weeks ago, support for the libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.