Killer (ESP8266) Apps for the Weekend

Sometimes, while browsing GitHub for ESP8266-related projects, I come across a user’s page which just happens to “push all the right (ESP8266) buttons” for me.  One which I came across recently was from martin-ger and he has several projects which tickle my fancy.

Those three should keep you amused over the weekend and give you a sample of what Martin is capable of.  Definitely a page worth bookmarking!

 

 

Advertisements

ESP8266 Overclocking & Speedometer

A few days ago I posted the code for a(n almost unusable) version of Zork (or actually, the Zmachine) for the ESP8266.  It was (and is) really, really slow.  The main problem appears to be that it constantly re-writes the Zmachine stack back to SPIFFS which, in addition to causing the running-through-chest-deep-molasses effect, will also wear-out your flash in double-quick time.  The fix for this (obviously) is to shoehorn the whole thing into main memory (which is a work-in-progress), but while trying to squeeze enough performance out of the ESP8266 to make this early cut at least somewhat playable, I thought I’d take the easy option first and run the ESP at 160MHz instead of the default 80MHz.  I should warn you right now that as far as making Zork playable went, it was a total failure, but I was pleasantly surprised at just how easy the speed selection is when using PlatformIO.  I didn’t even have to sacrifice a chicken.

Here’s the simple incantation, which you just need to add to the bottom of your platformio.ini file in the project directory (the comment line is optional):-

; Set the ESP8266 clock frequency to 160MHz
board_f_cpu = 160000000L

…and then just recompile (and, because you’ve just made a change to the platformio.ini file, PlatformIO itself is smart enough to know that it needs to do a complete rebuild, not a partial).

That’s it …you’re done!


 

NOTE – You can also use the system call “system_update_cpu_freq()” to dynamically update the ESP8266 clock frequency from within the program itself, instead of using the platformio.ini “board_f_cpu” setting.  Using the system call will override the compile-time setting.

CODE – Ray Burnette’s adaptation of the Dhrystone test program is available from my repository in both static and dynamic versions.  The static version simply loops endlessly, reporting the performance of the current module (so effectively the compile-time clock setting from the platformio.ini file).  The dynamic version toggles the clock speed using the system_update_cpu_freq() system call on each iteration and displays the performance for whichever the current setting is.

 

 

A present..

…just not a very good one!   🙂

I know that all of you ESP enthusiasts of a certain age will have been waiting for this with bated breath, so without more ado, from the “Why? Because we (almost!) can” department, here’s:-

Zork for the ESP8266

This is a port of Louis Davis’ Arduino Z-Code interpreter to the ESP, but before you get too excited, I should tell you that it is slow …really, really slow.  It’s still a work-in-progress, with a ton of very, very rough edges, but it does actually work (after a fashion).

It uses SPIFFS to store the game files and the included “data” directory has a couple of other games in there, in addition to the default “minizork.z3” file.  All you need to do is change the “G_FILENAME” define in user_config.h to run one of the others.

Using PlatformIO (if you’re not, why not?!?!) SPIFFS can be initialized and uploaded with:-

platformio run -t buildfs

and

platformio run -t uploadfs

(the uploadfs command will take a couple of minutes to complete).

The code can be uploaded using:-

platformio run -t upload

Cat successfully skinned!

Regular visitors may remember a mention I made of an ESP8266/433Mhz gateway project a couple of weeks back.  Well, one of the reasons I found it so interesting was that I have a (fairly long-in-the-tooth) Oregon Scientific weather station installation which has always frustrated me with its lack of connectivity.  It does have a 9-pin, D-type serial connector on the bottom, but that assumes that you have an RS232 equipped machine within cable reach of the display unit (and that HID‡ would not object to yet another trailing cable).

I had toyed with the idea of plugging an ESP8266 into that port, with the excellent serial adapter  firmware from JeeLabs, but it doesn’t really address the HID/cable/ugliness issue.

Both of these methods also suffer from a fatal design flaw with this particular model of weather station, in that data isn’t squirted out of the serial port unless all of the sensors which this model was sold with are operational (otherwise you just get an error message along the lines of “Rain sensor not detected” and nothing else).  So I concluded that, by collecting the (433Mhz) transmitted data from the actual sensors (which are remote from the display unit), I could just use the data directly and ignore the base-station/display part of my weather station completely.  Hence my interest in the 433Mhz gateway project.

The final piece of the puzzle to drop into place for one of those light-bulb moments came when I was reading through the comments to one of Pete Scargill’s recent articles on the 433Mz RFLink project.  Commenter Paul gave a link to a GitHub repository called “rtl_433”, which is a 433Mhz decoder for SDR dongles by Benjamin Larsson.  Benjamin’s project is specifically for picking up the data from remote sensors (from many, many manufacturers) which operate in that open, 433Mhz band.

I’d recently bought an SDR dongle from a vendor on Ebay which was advertised as having an R820T tuner chip, suitable for ADS-B monitoring.  It turned out to be a bogus ad, with the actual tuner chip being a 0012, which doesn’t even cover the 1090Mhz ADS-B band.  I threw the useless dongle into the drawer and ordered a decent one directly from the manufacturer (which, incidentally, has worked perfectly from the first moment it was plugged in – Nooelec.com is the place to go), writing off the $10 Ebay one to experience.

Having seen Paul’s post, retrieved and compiled Benjamin’s “rtl_433” package and pulled out the “useless” dongle from the murky depths of the spares drawer, I had direct data from all of the Oregon Scientific sensors published to MQTT in less than five minutes after plugging it in.  One cat neatly skinned in a completely different way to that which I’d originally envisaged.

Just for your reference, here’s the simple pipe to publish your data:-

./rtl_433 -F json   |  mosquitto_pub -l -h hazeltonrig.throgmortons-bottom.org -t sensors/rtl_433

The “-F json” argument to rtl_433 is to force the data to be output in JSON format.  It will also accept “csv” (comma separated values) and “kv” (key:value pair) format arguments.

And here are a few lines of sample data from the various sensors:-

{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "THGR968", "id" : 204, "channel" : 1, "battery" : "OK", "temperature_C" : 8.300, "humidity" : 49}
{"time" : "2017-03-21 15:52:24", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:25", "brand" : "OS", "model" : "BHTR968", "id" : 66, "channel" : 0, "battery" : "LOW", "temperature_C" : 19.700, "temperature_F" : 67.460, "humidity" : 30, "pressure" : 946}
{"time" : "2017-03-21 15:52:26", "brand" : "OS", "model" : "WGR968", "id" : 183, "channel" : 0, "battery" : "OK", "gust" : 1.400, "average" : 1.400, "direction" : 902.000}

Note that the “direction” readings are meant to be in degrees, so 902.000 (last line) doesn’t make much sense. Looking at the code and at the actual weather station display, it seems like there’s a nibble ordering issue with the decoding of the raw data and that should actually read “290”, instead (the fix is tested here and is now working its way backup the line).


‡  “Her InDoors”

Getting started with PlatformIO and the ESP32

Here’s the shortest “Getting Started” you’ve ever seen (disclaimer†  …I’m making the huge assumption that you already use PlatformIO as your development environment for your ESP8266 projects.  If you don’t, you should!).

Add support for the ESP32 with:-

platformio platform install espressif32

Create your new development (project) directory and, in that new directory, initialize the environment for the type of board you have‡  with:-

platformio init --board=esp32dev

Start writing code, as normal, in the newly created src directory and then compile with:-

platformio run

At this point, PlatformIO will go off and automatically download the framework support for your environment (this first time, only) and then compile your code.

You just can’t get any easier than that!


† I don’t actually have an ESP32 board yet.

‡ List the available target boards with “platformio boards

Ψ If you’re tired of typing “platformio” in full each time, you can shorten it to “pio” (“platformio” is used for clarity here).

ω For more information on getting started with PlatformIO, see the full documentation at:- http://docs.platformio.org/

Nice little TFT screen adapter board

Johan Kanflo has an interesting site which is definitely worth browsing.  One of his ESP8266 projects which caught my eye was the “Commadorable-64”.  Although the Commodore 64 isn’t a shared experience, using a tiny TFT display connected to an ESP is.  Johan has put together a neat little carrier board for the ESP8266 which solders directly onto the pins of the TFT display board.  Instant wireless display!

Johan’s project actually covers more than just one model of display, with the ESP Johan Kanflo's TFT Adapter Boardcarrier board being available for the 2.2, 2.4 and 2.8 inch TFTs (the larger models have connections for touch control, too);  follow the links on Johan’s project page to reach the DirtyPCBs pages for the one which interests you.

Johan has a Github repository with the code for this project (and many more) available for download.

433MHz/IR MQTT Gateway Project

It’s nice to see a project that develops over time and Florian has a good example on his blog.  He started off in the middle of last year by putting together a low-cost, arduino-based sensor for his garden and things seem to have just grown from there :-).  You can follow along on his blog from the initial version of his bidirectional 433MHz, ESP8266-based, MQTT gateway, progressing to the IR enabled version by the end of the year and his OpenMQTTGateway project this year.  It’s a good read and a great little project to follow.