Node-Red: Push Notifications to Google Cloud Messaging GCM

The following instructions will allow Android devices to receive notifications from Node-red flows using the Google Cloud Messaging infra-structure. This is achieved by using the Node-js library for accessing GCM (Google Cloud Messaging) node-gcm.

Installing node-gcm:

We need to install the Google Cloud Messaging node supporting module either locally on Node-red or globally. If installing locally just cd to the node-red directory and do npm install node-gcm. Globally the command needs the -g switch added like this: sudo npm install node-gcm -g.

Configuring Node-red:

To be possible to invoke functions from Node-gcm from Node-red steps, like functions, we need to make the node-gcm module available. For that go to the base directory of Node-red and edit the settings.js file.

Modify the file so that the following configuration is now defined:

functionGlobalContext: {
// os:require('os'),
// bonescript:require('bonescript'),
// arduino:require('duino')
Starting up Node-red and our first push notification to GCM:
Start up Node-red by using the command line: node red.js -s settings.js . It’s important and imperative that we now start uo with the modified settings.js file or some other file with the above configuration.
We can now add a function step with the following code to push a notification:
var gcm =; /// Define our message: var message = new gcm.Message({ collapseKey: 'node-red', delayWhileIdle: true, timeToLive: 3, data: { key1: 'Node-Red Notification', key2: 'Hello android from Node-red' } }); // Set up the sender with you API key var sender = new gcm.Sender('AIza...');  // Replace with your KEY!!!!! // Add the registration IDs of the devices you want to send to var registrationIds = []; registrationIds.push('APA.....');  // Replace with your device registration ID!!!!! // Send the message // ... trying only once sender.sendNoRetry(message, registrationIds, function(err, result) { if(err) console.error(err); else     console.log(result); }); return msg;
And that’s it. Note that on the Data JSON object the key names, key1 and key2 are arbitrary. The keys can have any valid name as long that the receiving application knows about them.
For testing I’m using an inject node to activate the above function and I can see at the console (Not on the Debug tab) the following:
{ multicast_id: 9123452345452345, success: 1, failure: 0, canonical_ids: 0, results: [ { message_id: '0:7957832452%3676573df353' } ] }

If you receive other messages, like failure:1, there is something wrong with your Google GCM key or your registration device id is invalid.

For example:

{ multicast_id: 5439642763222344000, success: 0, failure: 1, canonical_ids: 0, results: [ { error: 'InvalidRegistration' } ] }

This means that the registrationId.push value doesn’t belong to any registered device to our GCM project.

If you just receive 401 that means that you’re using an Invalid Browser GCM key. Check the Google developer console to get the correct key.


I’ve done my basic testing with the sample Google GCM client available at

I’ve used Android Studio and the provided gcm-client source code to compile and test the communication.

The problem with the above gcm-client code is that we need first to compile and deploy at the device (or emulator) to make the GCM client application to at least run at least once to get the registration id of the device, so that we can provide the registration key to the above node-red code.

We also can change the provided Google code to send to Node-red the registration ID. This process alows devices to inform the Node-red flows of their registation ID, and for that we need to change the gcm-client program adding a registration process and a registration server on our side.

Upgrading to an SSD, moving from Kubuntu to Arch Linux and setting up KDE

This is a single post just to make notice of some points:

My home desktop PC, was running since 2009 the Kubuntu distribution. I’ve never reinstalled it and did always the upgrades from 8.10 to 9.04, 9.10 and so on until 14.04. Almost six (!) years with no virus, trojan horses, and a single initial installation. I’ve upgraded through the years the KDE desktop since the ill famed initial 4.0 release, to the latest 4.6 release.

But things where starting to go awry… At the beginning I had a ATI 4870 graphic board, but ATI dropped support for it on Linux (and Windows) and since I had so many troubles with the proprietary driver, and to add it up I had no support for the board, I sold it and bought an Nvidia GTX660.

But with both graphic boards, I had suffered from a long time problem: I could only do a sleep/resume a number of times before the system hanged. The symptoms starting from loosing network connectivity and then restoring right back, and some cycling of these symptoms to a complete lockup. At first I thought that was due to the network driver used by my motherboard, a Asus P6T with  a Realtek RTL8111/8168/8411 board, but with the correct driver for it, the issue continued.  Booting up was a painful two/three minute wait from BIOS to desktop.

But after a while I could pin point my issues not to the network board but to the Xorg and video driver combination. Some EQ buffer overflow, hanged X, and finally the machine.

Ubuntu and Kubuntu based distributions have PPA’s repositories where some alternative software and versions of mainstream software are available. I had trouble with some of these alternative PPA’s when upgrading, and had to remove them (with ppa-purge) to be able to upgrade the Kubuntu distribution. Anyway, there is an PPA, xorg-edgers,  where alternative and more recent versions of Xorg Software and Nvidia drivers are provided and that almost solved my sleep/resume problem. The problem was that after adding this PPA the Ubuntu/Kubuntu nvidia driver and the Xorg-edgers driver, after updates the X server was unable to find the nvidia driver, despite being installed, and had to reinstall the driver again to get my desktop working.

That was it. I had enough with Ubuntu/Kubuntu distributions. My bad and my issues, sure…

I’ve being testing Arch Linux on my work laptop for almost an year with great success. I’ve chosen Arch Linux because I didn’t had to loose an unknown number of hours per year upgrading to the next distribution version, and an rolling release version makes more sense. And Arch has the greatest Linux Wiki out there even solving problems that happen on the Ubuntu/Kubuntu line, and also mainly there are only one (well two) repositories. No PPA’s mess.

So I completely moved all my systems to Arch Linux, and my sleep/resume issue is 100% solved.

SSD on a SATA II based motherboard

My desktop computer has an Asus P6T motherboard. This motherboard only has SATA II (SATA 2) ports. Is it worth to use an SSD on such a board without upgrading to a SATA III board?

The answer is YES. If you have a SATA II based motherboard AND not buying an SSD because of that, do not wait any more. Buy it now. It is totally worth it.

Arch Linux is of course way lighter than Kubuntu, and with an SSD ( by the way it’s a Crucial MX100 256GB) my two/three minute boot to desktop time came down to 15s…

hdparm -Tt /dev/sdc
Timing cached reads:   16710 MB in  2.00 seconds = 8361.40 MB/sec
Timing buffered disk reads: 728 MB in  3.00 seconds = 242.59 MB/sec

Note the Samsung EVO 120GB that I have on my work computer, that has the flawed firmware that slows down with time, on a SATA III based motherboard:

Timing cached reads: 23864 MB in 2.00 seconds = 11943.41 MB/sec
Timing buffered disk reads: 164 MB in 3.01 seconds = 54.47 MB/sec

Compare this with my desktop old boot disk, an WD 640GB blue:
Timing cached reads: 16580 MB in 2.00 seconds = 8296.87 MB/sec
Timing buffered disk reads: 356 MB in 3.00 seconds = 118.59 MB/sec

I hadn’t yet had the time to upgrade the firmware on the EVO…

Making KDE looking good on Arch Linux

To end this rather long and tedious post, and also to my future reference, to make KDE looking good:

    • Make sure that the infinality modifications are installed: Make sure that you update.
    • Make sure that the DPI detected by your X server are correct for your monitor. Install xdpyinfo with pacman -S xorg-xdpyinfo. Figure out what might be your monitor dpi using this site: . Execute xdpyinfo | grep -B2 resolution and see if are similar. If not you need to set the correct dpi either in xorg.conf or in the Kde settings.
      In my case I have a dual monitor setup, and hence the weird dpi 95×96.screen

      #0: dimensions: 3200×1080 pixels (856×286 millimeters)

      resolution: 95×96 dots per inch

      So my font settings are:


  • While the above settings make my fonts look good, the taskbar fonts where awful and took me a while to figure out that was not the dpi settings but the Desktop Theme.
  • To solve this first install Krita with pacman -S calligra-krita . This will install the Krita color themes that are, in my opinion very good. And on KDE System Settings -> Workspace Appearance -> Desktop Themes select Get New Themes and get the AndroidBit theme.
  • That’s it:Selection_004
  • I’ve selected the Produkte Desktop Theme
  • And the colors:Selection_005

ESP8266: Setting up native SDK’s on Linux and exploring some applications

The information for installing and setting up the native SDK for the esp8266 from Expressif is readily available in the Internet:

With the native SDK we can develop our own firmware using the Espressif SDK and the C or C++ language. Then we can use directly the internal esp8266 processor, allowing to do interesting things in a more direct way, like implementing MQTT, driving hardware, and so on.

So why this post?  Basically is to put into writing some of my own annotations to the issues that I had installing the SDK and the cross compiler tools on my Linux machines.

Starting up:

The original instructions that I’ve followed where these:
I installed the tool chains in two computers, both running Linux: an Arch Linux distribution and a Kubuntu 14.04 distribution (and time is up for this one because I’m moving it also to Arch Linux. All I’m missing is to install a SSD).

1st) Installed the required pre-requisites that are documented on the above link. On Arch Linux the package installation tool is pacman and probably the package names can be different. I didn’t need to install anything on Arch, but on Kubuntu I needed to install the 64-bit pre-requisites.

2nd) Create the /opt/Espressif directory. The owner should already be your user, except if you have no permissions on the /opt directory.

3rd) Install the Xtensa Crosstool-NG that has the cross compiler and tools for the esp8266 processor:

cd /opt/Espressif
git clone -b lx106-g++
cd crosstool-NG
./bootstrap && ./configure --prefix=`pwd` && make && make install
./ct-ng xtensa-lx106-elf
./ct-ng build

Some notes regarding this:

  •  We are going to clone the git branch lx106-g++ that has the C compiler and the C++ compiler. There is another branch named lx106 that only has the C compiler.  There is some software out there like Ardunet that need the c++ compiler and so that is the reason why I’ve chosen this git branch.
  • I’ve also changed the url for the git repository from git:// to https:// because in I’m behind a web proxy that needs authentication. Just make sure that the http_proxy, https_proxy and ftp_proxy variables are set. The ftp_proxy variable is needed because at the ct-ng build step will connect to a ftp server to retrieve files. One example for setting these environment variables: export https_proxy=http://myproxyuser:myproxypass@proxyip:port. If you have an internet direct connection, like at home, no need to set these variables.
  • The ./ct-ng build step will take a long time, around 30 minutes in one of my computers and 15 in another.
  • The tool will connect to the ftp server on IP: where are located the Gnu compiler sources.

At the end we need to add the path to the crosstools to our PATH variable.
export PATH=/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin/:$PATH
You may want to add this line at your .bashrc file. In my case (I’m using KDE desktop, I’ve created a Konsole profile for this type of work and add the new settings to the PATH variable,)

Installing the Expressif SDK

The instructions on the above link are for the 0.9.3 version of the SDK. I’ve installed the most recent version at this time that was 0.9.4:

cd /opt/Espressif
wget -O
mv esp_iot_sdk_v0.9.4 ESP8266_SDK
mv License ESP8266_SDK/
cd /opt/Espressif/ESP8266_SDK
wget -O lib/libc.a
wget -O lib/libhal.a
wget -O include.tgz
tar -xvzf include.tgz

Except the change of the SDK version, the instructions are the same as the original reference post.

Installing the esptool

The esptool will pick up the compiler output and extract/create the files needed for flashing the esp8266. The instructions for this step are the same as in the original reference post. In my case, I’ve got the tool from the sources and not installed the deb file:

cd /opt/Espressif
tar xvzf esptool_0.0.2.orig.tar.gz
cd esptool

Let’s put the tool on the search path. In my case I’ve choose the Xtensa bin directory. (Edit: it should be put at /usr/bin. See below at building the blinky example)

cd /opt/Expressif/esptool
chmod +w /opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin
ln -s /opt/Espressif/esptool/esptool ../crosstool-NG/builds/xtensa-lx106-elf/bin
sudo cp /opt/Espressif/esptool/esptool /usr/bin

Installing the firmware uploader tool esptool-py

cd /opt/Espressif
git clone esptool-py
chmod +w /opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin
ln -s /opt/Espressif/esptool-py/ crosstool-NG/builds/xtensa-lx106-elf/bin/

With this tool we can upload the generated firmware into the esp8266.


So now we are ready and we can follow the instructions here: to starting building things.

There are some code examples, one of them named blinky but the make file assumes that the esptool is located /usr/bin. This is because I’ve not installed the esptool through the deb package. So we can copy the esptool command to the /usr/bin directory: sudo cp  /opt/Espressif/esptool/esptool   /usr/bin.

We can now build the AT demo and the IoT demo. Just follow the instructions. For example for the IoT example just do the following (Make sure that the path is set: export PATH=/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin/:$PATH):

cd /opt/Espressif/ESP8266_SDK
sed -i -e 's/xt-ar/xtensa-lx106-elf-ar/' -e 's/xt-xcc/xtensa-lx106-elf-gcc/' -e 's/xt-objcopy/xtensa-lx106-elf-objcopy/' Makefile
mv examples/IoT_Demo .
cd /opt/Espressif/ESP8266_SDK/IoT_Demo 
cd .output/eagle/debug/image
esptool -eo -bo -bs .text -bs .data -bs .rodata -bc -ec 
xtensa-lx106-elf-objcopy --only-section .irom0.text -O binary 


For uploading just follow the instructions here: but basically is using the to upload the firmware to the esp8266. Just make sure tha GPIO0 is grounded at boot time.

The IoT RTOS based example:

There is a beta SDK for the esp8266 based on the freeRtos according to this:

To use this SDK (Make sure that the PATH environment variable is correctly defined):

cd /opt/Expressif
git clone
git clone
cp esp_iot_rtos_sdk_lib/lib/*  esp_iot_rtos_sdk/lib
cd esp_iot_rtos_sdk


We should have now the IoT RTOS main image ready. To generate the firmware files:

cd app/.output/eagle/debug/image/
esptool -eo -bo -bs .text -bs .data -bs .rodata -bc -ec
xtensa-lx106-elf-objcopy --only-section .irom0.text -O binary

And we can flash it:

/opt/Espressif/esptool-py/ --port /dev/ttyUSB0 write_flash 0x00000 0x40000

The default baud rate for the IoT example is 74880…

 Exploring some application:

Now that we have all the tools for developing natively we can check out some applications:

  • esp-mqtt – A native MQTT client for the esp8266
  • Ardunet – A work in progress that mimics the Arduino way of making applications on the esp8266.

The download links are:


For building it, first change your connection parameters at include/user_config.h

cd /opt/Espressif
git clone
cd esp_mqtt
cp Makefile.linux Makefile
make flash


For building it:

cd /opt/Espressif
git clone
cd Ardunet
cp -R /opt/Espressif/esp_iot_rtos_sdk/ld .
cd /opt/Espressif/Ardunet/src/.output/eagle/debug/image
esptool -eo -bo -bs .text -bs .data -bs .rodata -bc -ec
xtensa-lx106-elf-objcopy --only-section .irom0.text -O binary

And we can flash it.


So after this long post I hope that things now are a bit more documented from the installation and setting up point of view.

Synology DS: Cross compiling Eclipse/IBM RSMB MQTT broker

RSMB: Really Small Message Broker is an MQTT broker/server, simpler than the alternatives like Mosquitto, RabiitMQ, and so on. While it has its origins in IBM labs (as the MQTT protocol), it is now a project/sub project on Eclipse Paho MQTT related software. While downloading the RSBM does provide some binaries for some common platforms, it doesn’t offer any binaries for, in my case, the DS212+ Marvell 88F628x ARM processor.

So let’s see how to cross compile the RSMB for Synology DS and in this process also learn how to cross compile in your desktop computer native software for the Diskstation.


Setting up the cross compiling environment:

First, a read of the following document The 3rd party developer guide from Synology located here  is recommended. Based on this document (page 6 and 7)and on this page, we can know what version of the Synology tool chain we need to download from here:

Download the required tool chain for your Synology version. In my case I have the Synology DS212+ that has the Marvel 88F628x ARM processor, so download this file:

Uncompress the file into the /usr/local directory. DO USE this directory. The tool chain is configured to get all files, libraries and so on from the /usr/local/… directory:

sudo tar xvzf gcc464_glibc215_88f6281-GPL.tgz -C /usr/local/

(Note: It’s a CAPITAL C. Check Synology documentation).

We can now get the RSMB sources.

Cross compiling RSMB:

Open an shell terminal (preferably bash but other shells might work) and create and change to a working directory. Clone the RSMB repository located in with git tools:

mkdir work_dir
cd workdir
git clone
cd org.eclipse.mosquitto.rsmb/rsmb/src/

While, for this case, not all the below settings are needed, for documentation purposes I document them here:

export INSTALLDIR=/usr/local/arm-marvell-linux-gnueabi
export TARGETMACH=arm-marvell-linux-gnueabi
export BUILDMACH=i686-pc-linux-gnu
export CROSS=arm-marvell-linux-gnueabi
export CC=${CROSS}-gcc
export LD=${CROSS}-ld
export AS=${CROSS}-as
export AR=${CROSS}-ar

Just make sure that the INSTALLDIR variable and TARGETMACH and CROSS variables point to the correct settings.

Also, in this case, for compiling RSMB, we need also to add the following variable:

export GCC=${CROSS}-gcc

Otherwise we need to change the Makefile and change the line GCC=gcc to point to the correct compiler. We can compile now:


And we should have the broker executable among others.

Let’s make sure that it is ok:

pcortex@dune:~/01.Develop/org.eclipse.mosquitto.rsmb/rsmb/src$ file broker
broker: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped

If the output is this:

broker: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=815abb3a1aad7f430c6e825670601c4991b45bd5, stripped

The wrong compiler was called.

Synology installation:

Copy the following files to your synology station: broker and Messages. From your workstation:

scp broker root@diskstation:/usr/local/bin
scp Messages. root@diskstation:/usr/local/bin

Access through ssh the Synology terminal, and make sure that broker is executable and do a test run:

cd /usr/local/bin
chmod +x broker
20150104 190523.162 CWNAN9999I Really Small Message Broker
20150104 190523.162 CWNAN9998I Part of Project Mosquitto in Eclipse
20150104 190523.163 CWNAN0053I Version, Jan  2 2015 20:13:39
20150104 190523.163 CWNAN0054I Features included: bridge
20150104 190523.163 CWNAN9993I Authors: Ian Craggs (, Nicholas O'Leary
20150104 190523.163 CWNAN0014I MQTT protocol starting, listening on port 1883

And success! We can now test with MQTT-Spy (, Android Client, or Eclipse Paho tools.

Configuration and start and stopping:

For configuring the RSMB, we really should really read the documentation… :) that is provided…

A simple configuration file should be located at /usr/local/etc and named rsmb.conf with the following basic contents:

# sample configuration on port 1883 with retained persistence in /tmp
port 1883
max_inflight_messages 50
max_queued_messages 200
persistence_location /tmp/
retained_persistence true

And at the /usr/local/etc/rc.d create a file named with the following content:


case $1 in
    nohup /usr/local/bin/broker /usr/local/etc/rsmb.conf >> /var/log/rsmb.log&
    /usr/bin/logger -p1 -t "rsmb: INFO  " " Service started."
    /usr/bin/killall broker
    /usr/bin/logger -p1 -t "rsmb: INFO  " " Service stopped."

Save and chmod +x

Now the broker should start and stop automatically.

Final notes:

To use the broker from the Internet the port 1883/TCP should be open/forward at your router/firewall, and you should add authentication to the MQTT broker.

ESP8266 Firmware messing arounds…

So after I checked how to restore the base firmware that my board came with, It was time to do some messing with alternative firmwares…

The first one that I’ve heard was the Lua base NodeMCU firmware, now open sourced available at .  The official web site seems to be here:

This one is rather interesting that allows not to control the ESP8266 by using AT commands (tedious…) but to use some of the processing power on the chip itself (it has a processor, ram and flash) using the Lua language. So for example we can use Lua to set up the wifi communication and use the serial port only for data transfer between the Arduino and the ESP8266 without using tons of AT commands.

To use this firmware, use the following procedure:

1st) Download the NodeMcu firmware. Just do a git clone on a working directory.

2nd) Put the Esp8266 in firmware update mode (tie GPIO0 to GND and power cycle)

3rd) With the upload the NodeMcu firmware located at the pre_build/latest/nodemcu_512k_latest.bin directory, by using the following command:
/pathtoesptool/ -p /dev/ttyUSB0 write_flash 0x000000 nodemcu_512k_latest.bin

After the firmware is uploaded, disconnect the GPIO0 from ground and reset the module.

Connect through the terminal and it should show this after (another reset):
NodeMcu 0.9.4 build 20141226 powered by Lua 5.1.4'
And pressing ENTER should show the > prompt.

We can now program the Esp8266 in Lua. The chip when reset calls an init.lua file if it exists in flash storage.

The .lua files can be programmed on our PC and then uploaded to the esp8266 chip, without any need to enter the firmware upgrade mode. There are several tools to do that namely the luatool available at . Just make sure that no other terminal is using the serial port when uploading the files. Just check the readme of the luatool for some samples on using the Lua language.

We can also see some Lua samples and discussion forum here: and some Lua samples for the ESP8266 here:

There is another esp8266 firmware, MicroPython where the language is not Lua but Python, but it hasn’t yet support for the WiFi part of the esp8266 chip I think, so not very useful for the moment.

Finally there are firmwares based on the original esp8266 firmwares, using the AT command set.

These normally are named eagle_something and are uploaded into the esp8266 also with the tool.

I’ve tried this one: that adds NTP (Network time protocol) support to the command set. Please note that after flashing this firmware, the base baud rate changes to 115200 instead of 9600.

ESP8266 Firmware update and recovery

So after I’ve received my ESP8266 I’ve built a support protoboard with pin headers for serial connection, Voltage Shifter (used one for I2C voltage shifting), a LM317 voltage regulator (The board uses an external power source) and a reset button so that I can simply reset the esp8266 easily. I’ve also put the GPIO0 and GPIO2 pins available on pin headers, mainly so that I can short the GPIO0 to Ground if I needed to update the firmware, and of course, I glad I did this…

After some tinkering around I came across these page for firmware update using the interner/cloud:

With the following AT command: AT+GMR I’ve determined that my version was 0018000902-AI03, and supposedly it supports the Cloud update.

Also as far the documentation is saying, there is no need for the GPIO0 pin to be grounded to do the firmware upgrade, so I wrote the dreaded command: AT+CIUPDATE after I did the basics, namely connected to an access point and with available internet connection (no mid path proxys).

The upgraded started, but not at it is shown in the above link. For example it shows the command execution something like: +CIUPDATE:1 found server but all I’ve got was +CIUPDATE:1 and +CIUPDATE:2 and so on and no OK at the end. Just garbage…

At this point I though that the ESP8266 was bricked… because I always got garbage despite of configuring my terminal with several different baud rates, including the baud rate 76800 that according to some sources (well google…) it is the default boot loader baud rate. But I had no success and so I thought it was bricked.

Well that is not exactly the case because we can flash a new firmware using the old procedure of tying the GPIO to ground while the ESP8266 is directly connected to the computer via FTDI.

Please note that these instructions are for Linux:

So what is need is the available here:
and the latest firmware available here:

Download and unzip the firmware file at the same directory where the is located.
I’ve tried both firmwares: ESP8266_AT_V00180902_02_baudrate watchdog and ESP8266_AT_V00180902_04 (0018000902-AI03)_unconfirm version.bin, and kept this last one, the original that my board came with. With both firmwares the cloud update, at least with me fails.

So with GPIO pin grounded, power up the ESP8266, and execute the following command for uploading the 0018000902-AI03 firmware:

./ -p /dev/ttyUSB0 write_flash 0x000000 ESP8266_AT_V00180902_040018000902-AI03_unconfirm_version.bin

Where /dev/ttyUSB0 is my FTDI usb port. Some times when trying to flash I had the following error (While I was in the Cloud update testing cycle):

Traceback (most recent call last):
File "./", line 353, in
File "./", line 138, in connect
raise Exception('Failed to connect')
Exception: Failed to connect

where the failed to connect. But pressing my (handy) reset button, and trying again solved the issue.
As the firmware is uploading we can see the progress of flash erasing and then the firmware upload progress. At the end something like this shows up:

Erasing flash...
Writing at 0x0007ec00... (100 %)


Now power off, by disconnecting the USB cable and the external power source to the ESP8266, disconnect the GPI0 pin, so now it floats (not connected to anything) and power up again.

The ESP8266 should be functional again at baud rate 9600.

At the end I’m still unable to do a firmware cloud update…

Hope this helps

Using KDE Kate editor as an Arduino IDE

The Arduino IDE is the tool of choice for building and programming for the Arduino platform. It has all that is need for casual programming, namely a simple way to choose and select the Arduino board and serial port, a simple interface, and a simple editor.

But those of us used to other tools for programming, like NetBeans, IntelliJ IDEA (I use it as the Android Studio version) or Eclipse, can find the editor lacking in little things that makes programming easier.

Anyway I was able to use NetBeans for programming and deploying arduino sketchs, with a great feature that is/was command auto completion for the Arduino C “language”. But Netbeans is big, and all it does is to call the Atmel tools for compiling and uploading sketchs into the arduino boards.

So I’m a KDE user, and KDE has a great extensible editor named Kate. Why not use it for programming for the Arduino?

As I said, Kate is a powerful extensible editor and  there are two plugins for making Kate “friendlier” in this task as a replacement for the Arduino IDE.

What we need to accomplish this? We need the following files/software:

Syntax highlighting for ino and pde files:

Base project at:

Just download the ArduinoKate.xml file and as root copy it to the /usr/share/kde4/apps/katepart/syntax folder. Just make sure that on your distribution that the path is correct.

Now if opening an .ino or .pde file with the Kate editor, we should have syntax highlight.

Next we need to download an Arduino Make file from Just download it and unzip it to a directory that won’t be deleted or moved. You also need the Arduino IDE to make this work, as this make file will get the tools and libraries from the Arduino IDE installation directory.

Second, change the .bashrc file so the following environment variables are added:

# Base directory where the arduino IDE is installed. Change to suit your directory
export ARDUINO_DIR=/home/pcortex/arduino
# Base directory where the Sudar Arduino Makefile files where installed
export ARDUINO_DIR=/home/pcortex/00.Develop/Arduino-Makefile-master
# Base Arduino tools directory
export AVR_TOOLS_DIR=/usr

We have almost everything ready:

Just launch now the Kate editor and goto Settings->Configure Kate->Plugins and enable the Build and Project plugin.

We are now ready. Let’s develop:

1) Create a directory for your project: mkdir ~/Arduino-project

2) Change to that directory and create a makefile. The content is simple:

#include $(ARDMK_DIR)/
include /home/pcortex/00.Develop/Arduino-Makefile-master/

Save the file. This makefile is for the Arduino Uno. To compile for other boards, on this directory and with this make file saved, just run the command make show_boards to see the available boards. Then change the BOARD_TAG appropriately to your board. For example, for the Arduino Mini Pro 5v the BOARD_TAG is pro5v328 and not uno.

3) Create the Kate project file:  This file MUST be named .kateproject :

"name": "My Arduino Project Name"
, "files": [ { "git": 1 }, {"directory": ".", "filters": ["*.ino","*.pde","*.c","*.cpp", "*.h" ] } ]
, "build": {
                  "directory": "."
                   , "build": "make all"
                   , "clean": "make clean"
                   , "upload": "make upload"    

The JSON “name” tag will define the name that shows up at the Kate Project dropdown box selector.

4) If using Git (as I do) just add a .gitignore file where the *.o and *.d files are ignored.

That’s it.

Create your main.ino file and add code.

To compile, just go to Build->Build Default Target.  This is equivalent to Verify on the Arduino IDE.

To upload, on the Build plugin window, just select (or add) the make upload option, and the Makefile will upload the sketch/program to the board.

If any errors happen, clicking on the Build plugin output tab, on the lines with errors and line numbers, will jump to the exact location of the error.

For more information refer to Sudar documentation for the Makefile.

Happy coding!