Testing the ESP8266 home controller

I continue to fiddle with this setup.  Let me share some of my findings.

First, let me restate the premise for the initial setup: the ESP8266 module starts off in Access point mode.  You start by logging into it in Access Point mode.  If that is successful, the ESP does a scan of available wifis and presents you with a list of available wifis and a login form to connect to one of those.  You submit that form and the ESP tries to log into the target wifi network.  If successful, the ESP stores the login data in EEPROM and switches to Station Mode. Thereafter, when the ESP starts up, it looks in it's stored data and tries to login to the wifis using the data stored in it's memory.  If that works, it goes into Station mode and you don't see the option to login to the ESP directly via Access Point mode.  If the stored data doesn't yield a connection, the ESP goes into Access Point mode and you should be able to log in to it and connect to another wifi network.

The libraries that handle all this are: WiFiManager and ESP8266WiFiMulti.  The first one is supposed to handle the Access Point<->Station negotiations.  The second library is supposed to store login data for up to three different wifi networks.  To make it easier to find the ESP on whatever network it ends up participating with, there are a couple of libraries that attempt to do some DNS work and resolve the ESP to magic.local for the url.

What I'm finding is that some of that works sometimes and other times it doesn't.  Apparenlty, there's a bug in the WiFiMulti library such that it doesn't store connections for different wifi networks.  This kind of drove me crazy for a while until I read it's a known bug.  After connecting to a wifi network, I found that connection to a different network wouldn't happen unless I uploaded the code to the ESP module once again.  That's really inconvenient.

Furthermore, I'm finding that the DNS routines work for some platforms, and not for others.  Using Firefox on a laptop and/or Safari on on iPhone, it seems to work.  However, a generic Android tablet failed to resolve magic.local.  It could connect if I provided the actual IP address for the ESP module on the network.  To make the websocket connection work I had to edit the index.htm file to comment out the connection to magic.local and replace it with a generic link:

    var connection = new WebSocket('ws://'+location.hostname+':81/', ['arduino']);
    //var connection = new WebSocket('ws://magic.local:81/', ['arduino']);

While that works, it requires knowing a bit about how to log into a router and find the IP assigned to the ESP.  Probably takes all this beyond the scope of the intended target audience.

I'm sure someone is wondering: why bother with the AP->Station approach?  The answer is two fold: simplicity and range.  Once setup, you simply login to your home network, go to the magic.local page in a browser and control your MWM devices.  Household wifi routers usually put out a signal strong enough such that folks may login in from across the street and/or a couple houses away.  Once setup, it would be entirely possible to invite users to login into the network and enjoy fiddling with your MWM target devices via their cell phones.  Of course, if inviting all comers to connect to the MWM network, you'd want that to be a separate network from your main home network to prevent the outside world from gaining access to your home network!

As an example, I have MWM paper lanterns hanging in one of our larger windows.  An older wifi/router has been setup just for control of those MWM lanterns.  It has no route to the Internet nor to our household network.  I allow neighbors to login to that network and try their hands at controlling the lights in those lanterns.  The home router has a signal strong enough to reach across the street.  I didn't think the ESP signal would be strong enough to provide a login all the way out to the street level - but it does!  The connection isn't as quick nor quite as consistent as the home router, but it might work.

For folks with shows featuring outside IR emitters, web input adds a new layer of potential user engagement.  Imagine a scenario wherein users pull up a webpage and gain access to controls that will affect both the MWM items you've provided and also affects any MWM items they brought with them to the show!  This could stimulate attendees to want to obtain some MWM items to be part of the show they control.  Might actually work.

The alternative to the AP->Station connected to an existing wifi network motif is to simply run the ESP in Access Point mode, connect directly to it and do all the web stuff directly from the ESP.  This is particularly attractive if you are considering going into the parks with just an ESP module, some IR LEDs and a cell phone.  I'm finding that this approach works just fine.  The code needs some tweaking.  Comment out: //#include <WiFiManager.h> and make the following changes:

/*WiFiManager wifiManager;
 // wifiManager.resetSettings(); //use this if hopelessly stuck on unresponsive network
  //wifiManager.autoConnect("magicAP","bringmagichome");
 
  WiFiMulti.addAP(ssid, password);
  while (WiFiMulti.run() != WL_CONNECTED) {
    delay(300);
}*/
  WiFi.softAP(ssid, password);
  USE_SERIAL.println("");
  USE_SERIAL.print("Connected! IP address: ");
  //USE_SERIAL.println(WiFi.localIP());
  USE_SERIAL.println(WiFi.softAPIP());

Compile the changes and upload to the ESP module.

Look for magicAP and connect to that 'network'

The DNS stuff doesn't seem to work in AP mode, so you'll need to login to the default parameters for ESP in AP mode: 192.168.4.1 and your index.htm file will have to be altered to

var connection = new WebSocket('ws://'+location.hostname+':81/', ['arduino']);

And the edit page will be at 192.168.4.1/edit

In a way, this is really sweet.  No complicated steps.  Login and use.  I've found the effective range to be much greater than I'd expected.  And I've noticed that the connection doesn't time out and reset as quickly as it does when hooked to another wifi LAN.  It could be this is the way to go.  I'll keep testing and see what I think.

The next item to be figured out will be the IR 'coverage'.  The ESP puts out a whimpy signal.  It works, but requires a bit of aiming to be effective.  The available IR LEDs have an effective 20 degree coverage.  That's sad.  To get full room coverage will require either a lot of LEDs in a fixed station or a lot of LEDs that can be individually aimed for maximal effectiveness.  I've done some fiddling with simple PN2222A transistors with good results.  The challenge will be to come up with a solution that is cheap and simple but gives good results that mere mortals can make work.  If you have suggestions, do share!

As a follow-up.  I stated that the standalone version will have the edit page at 192.168.4.1/edit  Actually, that doesn't work.  The edit page requires a javascript download from the internet to do it's thing.  Not being connected to the internet, it doesn't work.  No biggie.  I don't really like that edit page anyway.  All that's really needed is a file listing, a means to upload a file and a means to delete a file.  That last part has been missing in virtually all of the scripts I've seen for working with the SPIFFS.

Looking at a thread http://www.esp8266.com/viewtopic.php?f=32&t=5779&start=16 I think I can leverage that to come up with a simpler filehandler engine.  I also think it ought to require basic authentication for access so that some prankster can't come in and delete all your files. 

I think this really needs to be fixed before dreaming about unleashing this controller on the public.  Updates when available.

And another couple observations.  I find the reset button needs to be pushed each time the device is powered off and then turned back on.  Apparently just applying power doesn't cause the device to perform a fresh boot up.  And I've noted that my laptop has problems initiating a connection if any other device is already connected.  This is not true for my phone which connects readily regardless of there being previous connections.

four 40 degree angle IR LEDs give excellent room coverage when driven by 5V source and switched via the PN2222a.  Coverage is still good when the emitter is placed in either a PET plastic or PS plastic container.  Polycarbonate should also work well, as would acrylic. 

I'm ready to start pushing info about simplistic MWM controllers onto the public side of the site.  The logical place to start would be with the historical entry point, the Arduino Uno.  Reviewing the current marketplace for that micro and thinking about things a bit more, I came away thinking it's maybe not the best place to start.  So I'm going to ask your opinions to see if you think I'm on the right track.

The genuine Unos are going for around $25@.  That's kind of rich for what you can get for that amount these days.  The only advantage I see with going that route is that one is certain the Arduino IDE will work with the purchased micro and the FTDI drivers should be easy to come by. 

Knockoffs can be had for as little as $3-4 but those cheapos use different USB components/drivers that can be an adventure to get to work and seem to use unusual timings (got one with a 12MHz crystal).  I don't know that I'd feel completely comfortable recommending such products to users who may be new to all this.  And, if an Uno user decides to go wireless somewhere in the future, they're gonna need to buy another micro to make that happen.  I imagine that most users will want the convenience of a wireless controller that they can manage from a cell phone.  There are some uses for which the Arduino is the better choice, like simultaneous writes to several ports.  I think those could be left to the more advanced users.

The new Pi zeros are going to take some work to get going.  We're not there yet and Linux isn't good news for a lot of folks.  Eventually there may be a MWM distro on an SD card that folks can pop into a Pi and have it work for them while remaining blissfully ignorant of the underlying details.  That's a future possibility. 

That leaves the ESP8266 as the recommendation.  A single unit can function as either a USB tethered emitter, a E1.31 connected emitter or a standalone wireless controller.  I see the NodeMCU boards available for $10 or less.  If the recommendation specifies the Amica branded boards, the Silicon Labs CP2102 USB chip and the 12E ESP8266 version, Those can be had for less than $4 by ordering direct from China.  That's about the same as the cheapest Uno clones out of China and you get more bang for the buck.

I spent some time last night putting together a script that will do the same thing as the old mouseeartransmissiontest.ino script.  That script is attached to the original post above.  It is designed to turn off prompts if it will be used to get input via the serial port from some program like VenueMagic.  However, I tested it last night and it seemed to work just fine even if the prompts aren't turned off.  The other feature I'm exploring is the ability to include the code for running via the Serial port or as a standalone wifi unit and letting the determination of which to choose be made by the existence or absence of a valid Serial connection.  If I can get this to work, then folks will be able to use the same unit to run in either situation without having to upload a different script.  That's the plan.

I hope to get some sort of info on a MWM controller onto the public side of the web ASAP.  The reimagining of the original devices hasn't gotten any significant traction.  Time to change emphasis.

Yesterday I went on about using an ESP8266 as a simplistic, tethered MWM code transmitter and the idea that it might be possible to have a single ESP act as both a tethered transmitter and alternately as a wireless transmitter, depending upon if a serial connection is present - or not.

That didn't work out.  For some reason, if(Serial) always comes up true and the wifi mode never comes up, at least not as expected.  As a last resort, I simply dumped both the wifi and the serial code in void loop() and gave it a try.  Surprisingly, that works.  I was able to send ir codes from the esp from both my laptop, through the USB port, and using my iPhone.  I tethered the esp to the laptop and sent the codes for MSEP using VenueMagic.  Worked fine.  Uploaded the codes for jingle_bells.txt to the ESP and used the play show option on the cell phone to run it.  That worked fine, too.

Of course, the wimpy pin output of the ESP compared to the Arduinos could be a concern.  With proper aiming, I can reliably hit a target that's within 12-13 ft using a single IR LED.  Insert a transistor/mosfet and split the 5V power supply between the NodeMCU and the LEDs and get all the power you want.

I find fewer needs for my Arduinos almost every day.