There is an awful lot of people doing hobby projects with the ESP8266. I did not want to come up with the 47th incarnation of something, so the question came up, what an interesting project could look like. In the end I decided to develop a solution for managing a multitude of ESP8266-based devices. From a high-level perspective this will include the following components:
- CMDB: holds information about all devices
- Bootstrapper: prepares the raw module for all further work
- Security Manager
- Lifecycle Manager: Reference processes “from cradle to grave”
In my professional life I have been doing a lot of work on SDLC (Software Development Lifecycle) and configuration management, so the above project choice seemed a natural fit. It also happens that I am deeply interested in both topics and strongly think that poor application of them is often responsible for IT project failures.
The two main approaches for connecting an Arduino to an Ethernet network are the “normal” Ethernet shield or a module based on the ENC28J60 chip. While the Ethernet shield is easier to start with, it is comparatively expensive and also of little use for the smaller Arduino models (e.g. Arduino Nano or Pro Mini).
In contrast the ENC28J60 modules are cheap, small, and universally connectable. This comes, however, with the small downside that they are not supported by the Arduino IDE out-of-the-box. Of course, there is a myriad of web pages out there that deal with it in one aspect or another. There are two reasons why I add yet another:
- My ENC28J60 module (bought from AliExpress) is slightly different from the one usually seen. It does not need 3.3 volts but 5 volts, so the product description is wrong in that respect. Also, unlike all the other modules I have seen, it does not come with 10 but 12 connections.
- The usual recommendation for the library is EtherCard, but this did not work for me.
What finally worked for me was using the UIPEthernet library, which can also replace the standard Arduino Ethernet library. I connected the ENC28J60 module with a recently purchased Arduino Nano v3 clone using the following connections
[table colwidth=”50|50|50″ ]
Arduino Nano,, ENC28J60
SS, (Pin 10), CS
MOSI, (Pin 11), SI
MISO, (Pin 12), SO
SCK, (Pin 13), SCK
5V, , 5V
The Arduino Nano pin layout can be found here. The ENC28J60 module module offers a few more connections, as can be seen on the photo below. However, I used only the “usual suspects”.
The next step is to put this thing to use. I am currently planning some kind of data logger for 433 MHz signals, that are typically used for entry-level remote control purposes.
Mostly as a reminder for myself here is a link to a free book about the ESP8266. It dates from August 2015, so a few things have happened since; including the announcement of its successor, the ESP32 (forum here).
Today I joined the many who have issues to program an Arduino Pro Mini or, like in my case, a clone thereof. The error message very many people seem to get is
stk500_recv(): programmer not responding
There is an awful lot of stuff on the web how to solve this and I have tried to compile them in a list for others so that they can check:
- Programmer’s driver not installed on PC
- Arduino does not have a bootloader installed
- Arduino has other CPU compared to how it was sold
- Speed of serial port does not match with what Arduino expects
- USB-to-serial adapter has no DTR line
- RX and TX line labels mixed up on the board
- Faulty USB-to-serial converter (brand new CP2102 in my case)
In my case, however, it was even worse. Several of my clone board’s header connections were actually not connected! And among them was
TX, so the error message was quite right.
What I did was download the datasheet from Atmel, identify my pin configuration from page 3, and start measuring connections. What I found was that
TX on the six-pin header was not connected properly, while it was ok on the twelve-pin header. Also,
GND was not connected on the bottom twelve-pin header.
Update Jan 06, 2017: The not connected
GND pin was actually my own (soldering) fault.
For someone like me who comes from a non-embedded background (I specialize in things like EAI, SOA, etc.) the ideas of the NodeMCU firmware are really appealing. A nice scripting language, a slick GUI for rapid prototyping (ESPlorer) together with a highly active community seemed a perfect fit.
Unfortunately it did not work for me. The whole setup was unstable and I spent many hours to get a prototype (WiFi and MQTT connection) working reliably. I failed miserably with erratic behavior of the system. Sometimes a code change was “detected”, sometimes the old code was still executed. Compiling helped often but not always.
There are others who made the same experience and obviously spent more time on trying as well as the write-up (e.g. this link). I will now experiment with the Arduino IDE extension.
I feel happy for all those people who use NodeMCU without issues and hope to rejoin them as soon as possible!
After many, many years I rediscovered electronics as a hobby in 2015 and started playing around with sensors connected to an Arduino Uno R3 and Raspberry Pi. It was fun to link them with motion detection sensors and switch lamps on and off. One drawback, however, was the pricing of those components, if you want to have quite a few of them connected by WiFi.
This was when I stumbled over the ESP8266 microcontroller. It is very small, really cheap (around 2 Euros if you order in China) and has WiFi built in already. The downside, compared to an Arduino, is that you need to take care of a lot of things on your own:
- Everything runs on 3.3 volts and 5 volts will kill the thing
- You need to get a USB-to-serial converter with 3.3 volt signal level
- Flashing is less convenient, since you need to change jumpers between normal and upload mode
But there is a really vibrant community out there and many problems have already been solved. So I will start writing about various aspects of this and look forward to feedback.
When you need to start OpenHAB in debug mode, the standard approach is to run the script start_debug.sh. But on the Raspberry Pi (i.e. on Debian) this script does not exist. Instead you need to edit the file /etc/default/openhab that contains an entry DEBUG=no, which needs to be changed to
While exploring MQTT I had installed the Mosquitto message broker on my Raspberry Pi. However, the version that is in the Debian Wheezy repository is, as of this writing, really old (v0.15). So an upgrade was in order and fortunately the guys from Mosquitto have set up a Debian repo of their own and a description how to use it.
But on my system I then got the following message:
xxx@yyy:/etc/apt/sources.list.d# sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
The general recommendation to solve this is run
sudo apt-get dist-upgradeI did not want to do this for various reasons. So the approach I took instead, was to simply remove the old version with
sudo apt-get remove mosquitto mosquitto-clients and re-install it, then taking the new version from the Mosquitto repo
sudo apt-get install mosquitto mosquitto-clientswhich worked nicely for me.