zms.jpg_1200x1200.jpgA few months ago I was really excited to order a NodeMCU IoT Board to experiment with. It basically runs Javascript (Lua) and from what I’d read about it, it was easy to use, and easy to program. Cheap, easy to program, powerful, etc., etc. You all know the drill by now. Sounds like a great platform to build stuff on! I’m in! When I bought it a few months ago I immediately opened the box, plugged it in and … nothing. So it’s been sitting on my “big board of IoT devices” for a few months until I had more time to actually see what was up with this device.

First, let me run down a bit of my philosophy on IoT developer platforms. It’s pretty simple, but apparently not many IoT developer Platform builders believe in it as I do:

  • The platform should be dead-easy to get started on. I should be able to plug the device in, have clear, simple instructions for getting it running, and be able to start developing in a few minutes.
  • The Documentation should be simple, easy to follow, and detailed. And easy to find. If I have to resort to multiple google searches to get the thing working in the first place, it’s already suspect.
  • I don’t mind developing in C, Java, Javascript, Python, Arduino Script, or whatever other language your device supports. (Yes, I develop in al of those, and many more) but I should be able to get up and running quickly.
  • There should be examples of how to do lots of things included, or at least referenced. How to get SPI up. I2C, PWM, ADC, etc.
All of these (and others, but I’m not going to make this a manifesto) are, to me, basic out-of-the-box requirements. And I have written a lot of installers in my day. I’ve written them in Java and even bash shell scripts, to make things dead-simple and repeatable. It’s part of the job of a platform developer to make sure that the user, the customer, isn’t burdened with doing things that I, the product developer, should have done right in the first place. Installing all the required packages and bits and making sure they work is one of the things I should always make sure is done, and done right, before shipping anything.
Ok, </rant> On to the NodeMCU itself. Here’s the Executive Summary:
Not. So. Much.

According to the NodeMCU site, it is “USB TTL included, Plug & Play” but that’s where things already start to go slightly wrong. Yes, it does have a micro-USB on-board. But Plug & Play? Not so much. You see, they used a cheap Chinese USB/TTL chip instead of going with an FTDI chip, so the drivers for it are a little less than ideal. I plugged it in and … nothing. So I poked around in the internals a bit (I’m running Mac OS X currently and not only have I installed all the FTDI drivers, I even went so far as to port the FTDI LibMPSSE-SPI drivers to Mac OS X.) Nothing shows up anywhere in the device tree. Clearly the device is not recognized, hence not ‘plug and play’.

Hmmm … so next I spent a fair amount of time on the Google Machine hunting for answers. The forums are mostly in Chinese, but I did manage to find a mention of the fact that the DevKit uses a Chinese USB TTL chip, and a link to some drivers for it. I downloaded and installed them and was forced to reboot my machine. Maybe it’s the old Solaris/UNIX guy in me, but rebooting my machine is something I typically avoid at all costs. I like my uptime. I really hope that those Chinese drivers didn’t include a rootkit hidden in there, since they are now part of the kernel. I poked around in the package using Pacifist before installing, and it appears clean, but who knows.

Ok, so now the device shows up in the device tree. That only took an hour. So what do I do with it? The answer to that is non-obvious. How do I get code on it? How do I update the firmware? I can build my own custom firmware using but how do I get it onto the device? Not much documentation on that. Back to the Google Machine where I find ESPlorer. That looks promising. Nice Java-based GUI for developing and managing your NodeMCU device. So I grab that.

I can connect to the device now, and … wait, what?

PORT OPEN 115200
Communication with MCU...
Got answer! AutoDetect firmware...
Can't autodetect firmware, because proper answer not received.
�#��ng�$gn��� c p��d{$sd8�o�   � $   bg�|  l��c��go�d��$` �  gnd`   gs�ۓn  � dp�g�    s�����  cn�| � #��no� d` �  nod�l    o;���g {�` `�o ��c�nl���g'�� dp�g�   s������d�cn�| � #��ng�$� l  �  no � $  g{���o r��`  r��g {�` {l��n���gn�����{ 'og�d�c sd � �$� ���    � �$dl {l� �lllo��   �d�dl d � �$Ęn�� o��o~  � LJ '� $l��o  �'���gd�| c d` ;l                    j
Ai-Thinker Technology Co. Ltd.

That does not look good. Let’s run through some of the built-in commands and see what we get. First lets try a simple reset:

ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x40100000, len 816, room 16 
tail 0
chksum 0x8d
load 0x3ffe8000, len 788, room 8 
tail 12
chksum 0xcf
ho 0 tail 12 room 4
load 0x3ffe8314, len 288, room 12 
tail 4
chksum 0xcf
csum 0xcf
2nd boot version : 1.2
 SPI Speed : 40MHz
 SPI Mode : QIO
 SPI Flash Size : 4Mbit
jump to run user1
Ai-Thinker Technology Co. Ltd.


Get the chip ID maybe?


Nope. Check the heap?



So let’s turn on the WiFi and see if that helps.

+CWJAP:"Murray Home"

Hey, something actually works! That’s at least some measure of progress, right? So let’s try the button that says it will do a cloud-based update of the device, since based on the above reset, it looks to be almost 3 years old:



At this point I’ve spend about 3 hours on this device, and about all I can do it get it connected to my WiFi, but it won’t run any code sent to it, and it won’t even successfully perform any of the basic system-check commands. This, combined with the extremely sparse documentation and I’m ready to add it to the pile of “good idea, poorly implemented” pile and move on. It’ll probably sit on the Big Board for a while longer, in case I have a few more hours to kill and need to up my frustration level, but I don’t see any real future for this device.

If you’re developing a platform for developers, don’t do it this way. Don’t make your developer’s life harder, more frustrating, or waste their time or they won’t use your platform. It really is that simple.