When I was given an ESP8266 by Don, I was on the fence about things. I had invested a lot of time on the AVR platform and wanted to go as far as I could with that. However, there comes some limitations. One of those major limitations was interaction with the device. On an AVR I'd need additional hardware to handle screens or inputs or even wifi. The ESP solves this with its inclusion of wifi. Another limitation was the size of the flash and I was fighting my urge to prematurely optimize whereas on the nodeMCU version of the ESP8266, there's 4 MB of space to work with rather than the 32kB on the AVR. The ESP8266 doesn't come without its own issues. The documentation is rather sparse and access to low level features is spotty at best.
However, for the last... two weeks? Three? I've been developing on it and will probably use it going forward. Being able to interact with it over a web browser vs. a hardware controller allows for a lot more customization and features. I'm actively developing features constantly and try to work as much on the client side using Javascript as much as I can. There's no security issues I'm worried about and I can use the high level language features to do things like multi-threading (such as being able to respond to requests while playing a show).
I initially posted some code on the ESP8266 Home Controller thread for some basic features but should be focused more on general development rather than our individual projects.
Sections are hidden initially but can be opened by clicking on the header.
If things look similar to Don's, that's because I referred to it a lot while coding. I've also set an option in my Glow.js library so you should be able to use Don's ESP8266 backend if you wish. I haven't tested this, but to the best of my knowledge it should work fine. It just sends things back in RAW mode.
There's notes.txt in each of the high level folders to tell where it should go and what it does. Notes are light as I'm still developing stuff quickly. I'm probably going to use this dev page also as a chronicler of code, like GitHub is supposed to be. I don't know HTML/Javascript/CSS very well but learning along the way.
Comments6
Welcome to the dark side
Great news that you are hacking on this platform now.
I've taken a quick look at some of your notes.txt files but am sitting in an airport right now with my 8266 in a suitcase. So I'll try to catch up with things this weekend - as time allows or while Lesley is running.
I, too, have been working on stuff. In standalone mode, the edit.htm file doesn't work. So I've been reworking that. After a lot of trial and error, I think I have that worked out. To some extent, the approach to take depends upon the intended audience and their usage. Right now, I see that the device can handle up to 4 users. I'm thinking of this as a family resource. That would mean kids and their loser friends might have access. So maybe some of these features need to be protected by, at least, basic authentication. In particular, I'm thinking the ability to upload and/or delete files.
Another item on my wish list is the ability to keep a log of what has been sent during a single session. I can see poking around to get something the way I would like it to be and want to save that sequence to call up later. The usual way to do this is to push the session data into a session cookie that can be recalled at will. Haven't gotten around to this yet, but that's a direction I'm headed.
Similarly, I usually find that I want the MWM targets to be set upon power up. I can see how this could be handled by having code in the start up section that looks for a file something like: setup.mwm and have it run that first thing. By making that a file that gets automatically loaded, it could be changed at will to match the situation/season.
The "ping" you mentioned is another thing on the wish list, but I could see it going a little different. Most of the MWM devices tend to shut down after about 5hrs if running solo and not receiving a code in the interim. I've been thinking about adding another button "keep alive" or something like that, that sends d005ff every so often to prevent this from happening.
I've also been fiddling with the IR LEDs to see what works best for a typical room setup. Ultimately, we'll want to recommend an IR LED setup to complement the coded ESP8266. I've switched to 40 degree beam IR LEDs and those work better than the 20 degree LEDs I had been using. Now I see there are 60 degree LEDs available, too. 3 of those would cover 180 degrees and require 4.5V. Most wall warts for phones/tablets these days put out at least 1A. The ESP8266 needs a 250mA allowance, leaving about 300mA for driving the LEDs. That would make it easy to drive 100mA@ to 3 parallel banks of 3 LEDs in series with a 5 ohm resistor. Stack the respective series and angle them to cover 180 degrees of vertical space and a room should be covered by that setup. The simple PN2222A transistor I've been using is rated for 1A. So it should be sufficient to drive all the LEDs. Still working on how to package those LEDs that would make sense for recommending to casual MWM owner.
All this is quite exciting. I think we'll eventually come up with a solution that should appeal to MWM owners and come in at a price point/difficulty level that will be do-able for them. Real nice. Keep up the good work.
package missing glowutils.*
Finally got some time during the Seahawks game to see if I could compile this. Looks like it needs GlowUtils.* which wasn't packaged along with all the other stuff. I think you sent that to me before but is probably on the other laptop that I'm migrating away from. I'll look when I get home.
uploading files
here's the code for the page doing the uploading. I've changed this to files.htm but may switch to admin.htm in the future.
// progress on transfers from the server to the client (downloads)
function updateProgress (oEvent) {
if (oEvent.lengthComputable) {
var percentComplete = oEvent.loaded / oEvent.total;
// ...
} else {
// Unable to compute progress information since the total size is unknown
}
}
function transferComplete(evt) {
console.log("The transfer is complete.");
document.getElementById("stat").innerHTML = "The transfer is complete.";
}
function transferFailed(evt) {
console.log("An error occurred while transferring the file.");
document.getElementById("stat").innerHTML = "The transfer is complete.";
}
function transferCanceled(evt) {
console.log("The transfer has been canceled by the user.");
document.getElementById("stat").innerHTML = "The transfer is complete.";
}
function upload(){
var targfile = document.getElementById("inputfile").files[0];
var oform = new FormData();
var path = document.getElementById("path").value;
oform.append("file",targfile,path + "/" + targfile.name);
//outputform.append("file",targfile);
document.getElementById("stat").innerHTML = "uploading " + path + "/" + targfile.name;
var oReq = new XMLHttpRequest();
oReq.upload.addEventListener("progress", updateProgress);
//oReq.open("PUT", path + "/" + targfile.name, true);
oReq.upload.addEventListener("load", transferComplete);
oReq.upload.addEventListener("error", transferFailed);
oReq.upload.addEventListener("abort", transferCanceled);
oReq.open("POST","/files" , true);
oReq.send(oform);
return false;
}
note that the esp data needs to be changed:
in setup()
server.on("/files", HTTP_POST, [](){server.send(200, "text/plain", "");}, handleFileUpload);
and
void handleFileUpload(){
int i,c;
if(server.uri() != "/files") return;
forgot the html
Sorry, forgot the corresponding html form:
<fieldset>
<legend>Upload to ESP</legend>
<p>
Specify a target directory (default is /): <input type="text" name="path" value="/" id="path"/><br />
</p><p>
Pick file to upload:
<input id="inputfile" type="file" name="file" required>
</p>
<p>
<button onclick="upload();return false;">Send file</button>
</p>
</fieldset>
<div id="stat"></div>
Spent the weekend cleaning…
Spent the weekend cleaning up code and implementing show timing code. At first I wanted to do all show timing on the ESP, then I realized that I could have better show control using Javascript. I re-implemented everything in Javascript that would download the show file, parse it, and set up controls and delays and everything needed and have "accurate" timing for shows. While I was writing code, I kept having issues with undefined variables when I knew for certain I had already assigned data to it. I'm not sure the cause of it but I'm marking it up to not getting the correct reference. This lead me to a realization, all I really am using Javascript for on this was for show control/timing. Re-coded things and now I just have a timer wakes up every 100 ms. to send a control message to the ESP with the current show time. I think I could set it down to 25ms. but why push it, for now. The ESP receives the message and checks things out to see if it should send anything out. Forward correction commands are built in. I'm still using a binary encoded .mwm file so none of that has changed but I have better control of the bytes at the C/C++ than I did at Javascript. I need to do a bit more testing too see what happens when I submit bad data and implement show scrubbing and replaying a show (it plays it once and then you can't play another show without a refresh). For now the player can play a show, play/pause, show the current progress in a MM:SS.sss/MM:SS.sss format, and show a visual representation of the progress. I know I need to write better instructions for... everything but I'm focusing a lot on the Javascript side of things before I put too much into the visual design.
I noticed that too. For some reason, initially it did work for me for a few days/weeks but suddenly it stopped working one day, I assume the cache had expired. I was doing some wonky stuff to make things work right until I decided to dig in a little more on what was happening. The edit.htm page calls two external libraries, ace.js and html-mode.js, the former is required for file editing and the latter doesn't seem to be required at all. I changed the location it looks for the library in the edit.htm page to look for it locally at "./js/ace.js" and it's been working well since.
I think that's a setting in the WebSockets library, I believe there's a #define setting for it.
Agreed. While I'm coding about I don't have any thought about security, I'm just getting the feature to work.
I think we can use WebStorage for this. I use something similar on my Android app called Shared Preferences to hold per-user commands. So if I have a certain command that I like or that I'm testing and want to reference back to it later, I can save it and go about my day. There's also Web SQL Databases and IndexedDB however I think those might be a little much. All this is client side so nothing would need to be stored on the ESP itself, unless we wanted to.
When I'm at the parks I call these area commands. They're not specific to any show, they just get continuously sent out, blanketing an area with a certain effect. You can change the color/effect for a little while but 30 seconds later it's back to an area command. I think this is most noticeable around Christmas.
Erm, different ping, Ping Pong frames . I didn't know the devices shut down after 5 hours. Probably a safety feature to "save" batteries. (It would be really cool to convert them over to rechargeable lithium-ion).
Fun fact, area commands use a similar command along the lines of 0C XX D0 05 3C to keep everyone in sync, at least for the next 60 seconds.
Have fun with that. That's an area I'm waving to, in a far away land, probably going to get someone else to figure out all the hardware stuff. I'm happy enough with my breadboard or shoddy solder job boards for now. Literally have not even moved anything around on the ESP since you handed it to me.
Whoops. I intended on using more out of there but I'm really only using the CRC functions, I've pulled out the dependency and added the CRC functions to the ESP library so it can function on its own. Did a compile check and everything is fine, even removed a few other #includes that I wasn't using anymore.
I explained my patch to the edit.htm above but this is a good direction. We do need to figure out a way for working with authentications and binary encoded files (assuming we continue with those instead of text files).
Btw, to reduce load times we can mini-fy javascript libraries. Mini-fying removes white space and can do some tricky things like text replacement to shrink down the size of the .js file. My Glow.js file is ~19 kB normally but through mini-fying and gzip-ping it it goes down to 3kB. During development I've been leaving things at normal size but we can compress things down pretty well for release. Any of the static files I've been gzip-ping to reduce load times.
... I'm not seeing a place to attach a file, I'll just update my original post with my code so far.
I'm trying to use a git vcs…
I'm trying to use a git vcs called GitLab to keep track of my code. It's probably a lot better than uploading snapshots. I'll try to upload major milestone versions here with snapshots and and in-development versions there. So if anyone is a user or would like to become one, send me a message or something and I can add you to the project as I have it set to private currently.