Wifi with ESP8266 - Part 6

This time, it is about playing with a ESP-201 as well as with the Nodemcu devkit but without nodemcu (the firmware). Here are a few notes about what I discovered while playing with these boards.


As I mentioned in the past, starting with Arduino 1.6.4, there is now full support for ESP8266.


A majority of the Arduino's functions are directly available to be used of the ESP8266 and some additional libraries have been directly developed specifically. The libraries and documentation are changing extremely fast: between my first attempts in the summer and now, a lot of material was added.


The biggest hurdle with these chips seems that timing. While a "normal" Arduino will happily wait for any kind of event to happen, the ESP8266 tends to reset very easily. Too easily maybe and I wasn't able to do some tasks such as the La Crosse decoder and its strict timings.

There is more info about watchdog in the documentation and in this interesting blog entry about porting code from the Spark Core to the ESP8266.


This is the whole point of these modules! If connecting is easy (at least in theory!), keeping the connection alive is a bit more of a challenge. Keeping a eye on the status is essential.


The nodemcu devkit already mentioned here has 2 switchs: "RST" and "FLASH".

But in practice, they are not used thanks to a clever system (See "USB TO UART" on the schematics)... Flashing mode and reset are done automatically!

Debug with GPIO2


The second Serial output is something nice and not widely documented with ESP8266 modules: GPIO2 (aka pin D4) can indeed be used for debug purpose.

For example on one of my modules, if I press reset, I obtain the following message:

ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x40100000, len 29132, room 16 
tail 12
chksum 0x4c
ho 0 tail 12 room 4
load 0x3ffe8000, len 2888, room 12 
tail 12
chksum 0xf7
ho 0 tail 12 room 4
load 0x3ffe8b48, len 8, room 12 
tail 8
chksum 0xbf
csum 0xbf

Not extremely useful (except to check it is properly booting...) but there is more.

Wifi debugging

For example, on another module, here is the message when connecting to Wifi:

f 0, scandone
add 0
aid 1
pm open phy_2,type:2 0 0

connected with MYSSID, channel 3
dhcp client start...

Serial port

Moreover, it is also possible to write from the programme to this serial port and it is very easy. As the Arduino documentation put it:

To use Serial1, call Serial1.begin(baudrate).

But you have to remember that you can only write (only TX exists).


Simply connect GPIO2/D4 and GND to a serial adapter. Speed settings should be 115200 8N1 but as usual with these modules, your mileage may vary.

Different models of Nodemcu

There are quite a few versions of breakout board, all more or less compatible. Below a selection of the most famous ones (I am not even including the clones):

More information on this blog. Check also this one.

And all this without even mentioning the new generation!

    Wifi with ESP8266 - Part 5

    In previous posts, I mentioned a problem with ESP8266 modules when using a Orange Livebox (the router let by my ISP). It was confirmed by someone else (thanks you Sébastien H.) that splitting into 2 SSIDs 2.4 Ghz & 5 Ghz and forcing all clients on the 2.4 Ghz helps.

    I also received a few queries about how I worked around this problem...

    Well, basically, I bought a Wifi dongle I installed on my Raspberry and created a new totally private network aside. It probably helps a tiny bit with security but it is a bit of a pain with kernels/modules as my dongle is not recognised with the standard kernel.

    An alternative could have been to use a cheap Wifi repeater/booster since most of them just create a new SSID bridged to the base network. The risk being this new bridge behaving like the Livebox.

    Help with a Wifi dongle on a Raspberry Pi

    Realtek RTL8188EU

    In theory, the process is straightforward:

    apt-get install -y hostapd firmware-realtek isc-dhcp-server iw

    See, for example, https://learn.adafruit.com/setting-up-a-raspberry-pi-as-a-wifi-access-point/install-software

    As indicated above, I have an issue with the default kernel module 8188eu... The Wifi dongle is only half recognised and doesn't initialise properly. Fortunately, a functional version can be found pre-compiled here: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=62371.

    • First, find the filename name in the list according to the dongle and the kernel version
    uname -a
    • Then the module can be downloaded for Raspberry P1 or P2 (look for dl.dropboxusercontent.com/u/80256631/8188eu-2015yyzz.tar.gz or dl.dropboxusercontent.com/u/80256631/8188eu-v7-2015yyzz.tar.gz on the page).

    • Once installed, all Wifi tools (and in particular iw ) should work properly.

    433Mhz remote sockets - Part 2

    As mentioned previously, the kit I bought has 2 sockets. But knowing that the remote can control 4 (it has a total of 8 buttons), it would be good to be able to use the remaining unused buttons. And why not, since the state of the socket can't be retrieved, to intercept and store the current state.

    Lacrosse/Digispark receiver

    It happens that I already have a 433Mhz reception system which was recently extended.

    Maybe there is a way to squeeze yet another protocol?

    It turned out that it was quite easy to do without much interference to the existing two decoding pipelines!

    Meet the 433Mhz receiver

    433Mhz Receiver

    Basically, the signal from the remote will appear as a series of High pulses which are shorter (~ 320µS & ~ 960µS) compared to the one from the sensors (~ 500µS/1300µS and 1900µS/3800µS). If a string of these specific pulses is detected, then we switch to the remote decoder.

    The signal being sent at least 3 times from the remote, this mean that we can intercept the second or the third transmission. The transmission itself starts with a "very long" pulse (31 times the base pulse). The encoding is based on a tri-state system which basically means, since we can ignore the floating state, that every other bit must always be a 1. The data consists in the address part, the button part and the state (ON/OFF) repeated but inversed.

    For example:

    1010111010 1110101010 1110

    can be decoded in (checking then removing all the odd bits):

    00100 10000 10

    and interpreted as:

    • address (DIP switches): off-off-on-off-off
    • button: A
    • Action: On


    Since there is now a little bit more than Lacrosse sensor decoding, I renamed the project on GitHub to 433Mhz receiver...

    The code can now be found at the following address: https://github.com/guillier/433mhz_receiver

    And now?

    Since I embraced the MQTT protocol, I added the conversion and now any touch on the remote control is translated into something like (to carry on with the example above):

    • Topic: cm/remote-00100/action/a
    • Payload: {"ts": 1451215192, "value": "on"}

    The first part is complete. Hooking up a 433 Mhz emitter (remember this?) on the Raspberry Pi is easy but for both technical and whimsical reasons, I have something else in mind...

    433Mhz remote sockets - Part 1


    A few days ago, as I was in a nearby DIY store (looking for something I didn't find in the end), I came by the Electricity aisle and noticed cheap remote sockets. These are a not new thing, I owned some more than 25 years ago — so unstable there were switching on and off randomly — and in France at least, the Belgian company Chacon made a successful product (DI.O) with this kind if items.

    One of the major issue with them is that they are without any feedback of the status like you could have on a modern "smart plug". Yet, where a Z-wave socket alone is at least 40€, here a pack of 2 sockets was less than 15€ including the remote and its battery. The "manual" includes a EC Declation of Confirmity so I assume there are safe to use. The power is limited to 1000W but for Christmas lights, this is not an issue!


    Obviously, the idea was also the do the reverse engineering on the protocol and if possible try to emulate the remote itself like I did several times in the past. Turns out that this very model of remote is used in dozens of packs and the circuit inside is well known and even officially documented!

    Protocol and Home Automation

    A quick search show pages and pages on the subject. These one are now called "Smart Home" but were previously sold under the Phenix brand by IDK. Protocol seems virtually identical to the Elro Home Easy plugs.

    The main references about the subject seem to be:

    The next question was: What is the best to integrate these elements in the existing installation? There are two main parts for this: controlling the sockets but also making the most of the remote (especially the two unused ON/OFF buttons).

    As usual... A suivre!

    « Page 2 / 27 »