TTGO T-Eight and Espruino

TTGO T-Eight is a small ESP32 board from here. Small OLED, left/right/select input method, microSD slot, and 4 MB PSRAM, LiPo connector, plus of course WiFi/Bluetooth is a good combination of features. The problem as usual is the lack of documentation. The situation is even worse in this particular case:

  1. The official git repo is outdated and describes only the OLED part of the old revision of the board.
  2. There's an old and new revision of the board. Luckily the silkscreen is updated, but if you copy&paste old code, you'll be possibly surprised that it won't work.
  3. There's a TTGO T8 which is similar but different. They could have called it T9, or T8a or T8D.
  4. There's no schematics so finding out what connects to what pin is somewhere between "Trust the docs" and "Detective work"

Anyway, here is what I found:

  1. SDA/SCL is Pin 21/22 as printed on the silk screen (old version: 5 and 4)
  2. microSD would then be at 5/23/18/19 as per silk screen (untested)
  3. Input is Pin 37/38/39 for right/center/left
  4. 4 blue LEDs and one red LED on the back: no idea yet. Blue could be LiPo voltage, and red one simply power

So here a small minimal Espruino program which uses the display and which can read the buttons:

// TTGO T-Eight

I2C1.setup({sda: 21, scl: 22, bitrate: 400000});

function gstart(){
 g.drawString("Hello World!",2,2);

// I2C
var g = require("SH1106").connect(I2C1, gstart, {height:64});

// g.clear(); g.drawCircle(50, 32, 30); g.flip();

// Note: pushing will trigger several times (for repeat: true)
// Need to software de-bounce

setWatch(function(e) {
}, D37, { repeat: false, edge: "falling"});

setWatch(function(e) {
}, D38, { repeat: false, edge: "falling"});

setWatch(function(e) {
}, D39, { repeat: false, edge: "falling"});

Node.js v10 has fs module with promises!

I did not realize that Node.js v10 has promise support for the fs module. Why is this a big thing? It makes it possible to write call-back free code like this:

items = await fs.readdir(path);
for (var i=0; i<items.length; i++) {

instead of the older call-back-style:

fs.readdir(path, function(err, items) {
    for (var i=0; i<items.length; i++) {

Also error handling is so much easier now via a simple try..catch block.

And in case you get the dreaded(?) warning message from node "UnhandledPromiseRejectionWarning: Unhandled promise rejection.", then simply add try..catch blocks or explicit catch handler for promises.


WebStorm and TypeScript

Watching Uncle Bob's videos (those in particular where he refactors stuff with ease thanks to IntelliJ IDEA), I always wanted to try those IntelliJ IDEs out. Not for Java though as I'm not a big fan if it. When JetBrains did a special discount sale, I had to try it out: WebStorm for JavaScript that is. And heck, it's good. It's also complicated to set up, but it figures out a lot of things by itself, e.g. it understands package.json files, the run scripts inside, it knows linters, transpilers and so much more. But the learning curve is steep. And it takes quite some (about 20) seconds to get started. Sublime Text is way faster to start (less than 1 second), so that'll stay my go-to-choice for smaller things, but once a full project is set up, WebStorm is very helpful to have.

So this weekend I took some time to set up WebStorm for TypeScript with its transpiler, linter, unit tests etc. This video was a great help to get everything set up in a sensible way. I used another boilerplate setup for no particular reason. This is the result.

Once cloned and WebStorm is started, it'll ask to run "npm install". Let it do that. Open the file structure (top left) and you should see all files. Find "package.json" and double-click on it. Go to the section of "scripts". You should find them all automatically marked with a triangle:

If you click on the triangle for "test" and let it run it, WebStorm will:

  1. run tslint
  2. run tsc to transpile TypeScript into JavaScript into ./build/ for both source (in ./src) and tests (in ./__test__)
  3. run the tests incl. coverage checks
  4. report the result of all commands in the "run" pane
  5. Also you now have "TEST" in the configuration:

Neat! I start to like WebStorm as I can see that it's made to solve the little problems programmers have. But there's a lot of keyboard shortcuts to memorize...


Espruino and InfluxDB

Espruino did unexpectedly have a module to talk to InfluxDB directly: Given that it's a simple HTTP POST request (see previous blog entry), I should not have been surprised.

That simplifies data ingestion: no need for MQTT broker, no need for an MQTT-to-InfluxDB converter. The InfluxDB instance is on the local network this way since SSL is still not doable on an ESP8266.

This is the Espruino code:

// InfluxDB configuration
 var influxDBParams = {
    influxDBHost: "",
    influxPort: 8086,
    influxDBName: "demo",
    influxUserName: "submit",  
    influxPassword: "submitpw",
    influxAgentName: "ESP32"

var influxDB = require("InfluxDB").setup(influxDBParams);

// bme() is the function to read from the BME280 sensor
let temperature=bme.readTemperature()

let data="env "+temperature+"="+temperature;

That's it. As simple as MQTT.


Yubikey, PGP and SSH and Chromebooks is where my PGP public key can be found.

Why the sudden interest in PGP?

Basically it enables me to put my secret key on a Yubikey instead of a computer. They secret key is secured by a PIN which can only guessed x times (3 is default), then you have to use a PUK (3 times again), and then it's locked. Only a full reset will get it out of this and that will erase the private key too. That's way better than a passphrase secured private key file on a computer which can be cracked over time, though it might take a long time if the passphrase is a good one.

And the best: It works out-of-the-box with my Chromebook and the Secure Shell App via the Smart Card Connector! It also works on my Linux desktop with Chrome. Windows does not work though as the Smart Card Connector does not work as expected as the Chrome Smart Card Connector does not work on non-Linux.

The links to read (not in any particular order):


While not trivial to set up, it's very rewarding to know to not have a private ssh key on an inherently insecure computer.