Repurposing the MIDI protocol to control Led Matrixes

DATA FLOW: Midi out > Sparkfun midi HAT > ESP32 > RX Uart > C++ Processing > FastLED RMT output

Meet Remora-matrix a project that started with the idea to sniff MIDI messages and make simple visuals on a LED-Matrix. Our previous Firmware Remora was intended to receive short commands from ORCΛ and make very simple Neopixels animations on addressable LEDs stripes (WS2812B like)
With this one I decided to go a step further and make two versions, one that uses nodejs as a middleware (Requires WiFi and UDP) and other that uses MIDI serial, received directly via Serial2 (TX, RX) UART and hence requires no WiFi connection.

  1. NODEJS VERSION
    This version uses a middleware script that sniffs a MIDI port (Ex. USB) and converts the messages into UDP messages that fly over WiFi to a destination IP. This script lives at the moment in middleware directory. An npm install needs to be run in order to install the required JS libraries.
cd middleware/midi-to-udp
nodejs midi.js
// Will list available midi entries. Requires port and udp destination IP
-p, --port_id  ID: Port name
                  0: Midi Through:Midi Through Port-0 14:0
                  1: USB MIDI Interface:USB MIDI Interface MIDI 1 20:0
                                                              [number] [required]
   -u, --udp_ip                                               [string] [required]

// EX. listen to port 1 USB Midi and forward them to UDP x.x.x.x:49161
// Port is fixed to the ORCA default port, feel free to update it  ^

nodejs midi.js -p 1 -u 192.168.12.109

This script will simply run in the background and redirect them using a simple short message that we designed to be compatible with both UDP and Serial versions.

2. MIDI SERIAL version
This uses the Sparkfun Arduino midi HAT that cost around 15 u$ and it can be found both in eBay and Aliexpress. The easy task is to build a connecting PCB below that hosts the ESP32 at the side of the HAT with the RX and TX cables from the HAT outputs connected to the ESP32. This HAT has an opto-isolator, also called octocoupler, that converts the MIDI signals into readable UART messages.
My prototype construction looks like this:

MIDI Hat alternative, but you could also build the MIDI to Serial yourself, in my case was easier to get it build

The MIDI Hat was designed for Arduino and requires 5 volts to run, so the 4 cables wiring is pretty straightforward:
HAT midi > ESP32
5v . . . . 5v
GND . . GND
RX . . . . 26
TX . . . . 27

I’m quite sure the TX goes to TX in the ESP32 but may be also the opposite. There is no standard for this I think. But in case it does not work just invert it, there are only signals, so you won’t break anything for trying this. The advantage of Serial are that have less latence than WiFi. Depending on how clean your connection is, sometimes WiFi UDP packages can become clogged, and get out all together which is quite an undesirable effect if you are working with LIVE music. Also UDP nature is designed to be very fast, but has no order like TCP.
It’s possible that a note played comes in different order as expected. Or if WiFi is shared, that while your Router is busy, the packages will accumulate and then sent all together, causing a burst of shapes in the Matrix in a moment that does not correlate with the music. This is not happening with the Serial version since there is no middleware redirecting packages and it cam be run without any PC in the middle. As there are no flying WiFi messages, has less latence and it’s much more reactive and fun to work with. Being the only pitfall being that you need a MIDI cable from your computer or Synthesizer to the MIDI Hat + ESP32 controller.
Most LIVE music lighting equipment does not rely on WiFi and there is a good reason for it!
Reliability.

Building our own internal Midi messaging system

Since this two versions want to achieve the same goal, that is converting the MIDI played into shapes, I though to create an internal messaging that is shared. Maybe this can be a C++ class or component in the future so it should speak the same language, no matter what version you use. The result is very simple, we will keep Channel internally and will use only Note + Status + Velocity.
Status and Channel come in the first byte. Then comes the Note and at the end the Velocity. Once we get the last byte, we will assemble this with the following syntax:

2 chars (HEXA) representing Note played 
1 boolean      representing Status (1 note on, 0 note off) 
2 chars (HEXA) representing Velocity

NNSVV  Note, Status, Velocity

Example: Playing DO in octave 3 that is 36 in decimal, velocity 60, Note ON message would be:
 2413B When the same note is released it could be: 24000 

After building the message the channel is analyzed. It can either hear on all channels leaving the constants in platformio.ini to 0. Or hear in 3 different channels (Also 3 instruments) this can be of course modified, but 3 is a good balance, to see something that can be correlated with the music. The configuration for this is on platformio.ini file using build_flags

   -D SERIAL2_BAUDS=31250
   -D RXD2=26
   -D TXD2=27
   -D MIDI_LISTEN_CHANNEL1=1
   -D MIDI_LISTEN_CHANNEL2=2
   -D MIDI_LISTEN_CHANNEL3=15
   -D MIDI_FIXED_VELOCITY=0
   -D MIDI_BASE_OCTAVE=4
   -D MIDI_TOP_OCTAVE=12

There you can see that this will only forward packages for channels 1,2,15 all the rest will not be sent to the matrix.
There is also an option to ignore Velocity and use a fixed number ( MIDI_FIXED_VELOCITY )
And depending on the song, it could played on a high tone, or in a lower tone. Because our matrix is limited, we need to define BASE_OCTAVE and TOP_OCTAVE so we can have a drawing range.
That is the most important midi configuration. It would be desirable to have a “learning phase” where you can simply hear the first 10 seconds of a song and calculate this BASE and TOP margins automatically. This a future idea that might be implemented.

Interpreting the messages

I left just a demo of how to interpret this in C++. As we have 2 different firmware versions, one that listens UDP messages, and another one that get’s MIDI via UART you have to select what to compile editing platformio.ini File:

[platformio]
default_envs = esp32
# Uncomment only one of the folders to select what example to run:

#src_dir = firmware/udp-midi-matrix
src_dir = firmware/midi-in-matrix

Every message at the end triggers a function that draws a shape. And that part is open to every different implementation. For example, you can draw a different shape per channel, like:
Ch1 – Usually piano or main instrument – Rectangles
Ch2 – Triangles
Ch3 – Circles
Ch4 – Lines and so on

As said this is just an example, but it’s open to draw anything you want, since we are using GFX over the RGB Led matrix. Also you have the Velocity, that is the pressure that is applied to the key, so you can use this factor to make the shape bigger or change colors. The possibilities are unlimited.
There is only one important thing to keep in mind. A note with status 1 should be drawn, but same note with status 0, signalizes that the key was release hence we should delete the shape.
At the moment is just an experiment that will may never see the light out of my studio, but nevertheless I wanted to leave this post as a declaration of intentions, in case someone wants to fork this and make his own take.

Credits go to this awesome libraries

https://github.com/marcmerlin/Framebuffer_GFX.git
With Framebuffer Marc Merlin did an awesome job
https://github.com/FastLED/FastLED.git
FastLED is one of the most powerful RGB Libraries for Arduino / ESP32
https://github.com/marcmerlin/FastLED_NeoMatrix.git
NeoMatrix let’s you map the RGB Led matrix to use GFX

I writed to Marc Merlin who did the amazing job of adding GFX to FastLED and here I wanted to quote his answer

About FrameBuffer GFX: The good news is that your code will now run mostly unmodified on other displays like LCDs, or RGBPanels, or even display on linux.
Like this you can write all your code, run it, and debug it on linux, and then upload it to ESP32 or rPI when it’s done.
After that, you can go big!

Marc
Demo videos, just for fun, not representing at the moment the finished work

Keeping your Crypto assets to generate 4.5% (ETH, BTC) to 12% (stablecoin) yearly interest

As an addition to latest article “Financing a web-project with Ethereum” I wanted to show how to make your Crypto assets grow a small percentage per year and also to have some additional cash per month using Stablecoins.

Stablecoins are cryptocurrencies designed to minimize volatility, relative to some “stable” asset or basket of assets. For example there is EURS that is tied to the € price also 1 EURS = 1 €.
Another one is PAX Gold that is tied to the price of one ounce of Gold. Both of this stablecoins are a subset of Ethereum network. With PAX Gold you can if you go to London, exchange your coins, for real gold. That’s what they claim at least since I would not fly there to prove it. More than that, the point I want to make here, is that in sites like YouHodler you can make 12% APR + compounding interest per year.
Let’s say you have 10.000 € there for one year untouched.
At the end of the year you should have 11.200 € with a 12% interest.
If you want you could extract this 1200 € to your account and have some extra cash at the end of the year for further investments of a short holidays. That is a quite interesting method to generate a passive income over the years.
Below there is a talk about stablecoins that was recorded and had 464 registered participants from 58 different countries, on April 17 2020

Now the only risk I see is that this money is not on your domains. It’s hosted in a secure wallet in the domains of a company. So what I recommend, no matter what site you choose, is to check very well and read about who is behind the company and how secured are your assets in the event something happens with the company you choose.
I use to trust the banks a lot until one day at the middle of 2001 in my hometown, Buenos Aires, the economy crashed and the banks simply will not let you take your dollars out of your acccount. Or even worse, they where converted to argentinian money, something that at that moment was the equivalent to flush your cash into the toilet.
Ater that happened to me, got an offer to work in Spain and moved to the EU in 2004, and I always take care of where I put my assets and making an analysis of the risks. Of course we are in Europe and here the protection laws, would simply not allow a bank run like that to take place, still with that assumptions it is wise to check where you put your money.

Team of YouHodler

In case of YouHodler my analysis was good and as I mentioned in last post, the fact that they are a members of the BlockChain Association and the Financial Commission, and that they open profiles show an extensive and proved career in the Financial tech industry was enough for me. The fact that they have real offices in Malta but also in Switzerland is also a proof that they real and solid.

Disclaimer about 100% transparency: I’ve decided to sponsor YouHodler and will also make some videos and further analysis openly. The links starting with track.youhodler.com are affiliate links since I want to get additional cash in order to film the videos and use my time to share with my readers the road to financial freedom and to generate an additional income each year.
‘This links won’t work from Germany or from Spain due to country restrictions. But from those countries you can enter directly to youHodler.com
This does not mean that I blindly recommend this company. There are also others in the market like Nexo that offer a similar percentage (2% less on stablecoin). Feel free to explore and take your decision solely on your assumptions.

You can also earn crypto faster with Multi HODL but that is something that must be handled with care and deserves a new Blog post. For the moment I only recommend to keeping combined assets, like for example some Bitcoin and Ethereum, along with Stablecoins like EURS or PAX Gold in order to generate a passive income.
Do not try Multi HODL with the dream of making a fast buck. It’s very risky to use it, specially with the variations value of cryptocurrency, that is like trying to take control of a wild snake. This must be used with care and meditation.

Questions for my subscribers:
What do you think about this?
Would you trust an external company part of your assets provided they are trustable and generate a yearly passive income?

I bough some ETH back when it was 260 -> 280€ now it has gone up almost 100€ in two months. That was a lucky desicion. But is not always like this and it can be that due to market changes, external factors, or just the team Ethereum development roadmap that it simple goes down too.
This was a good analysis made by an user of TradingView months ago:

This second analysis was also quite accurate. 1 ETH is worth today 19 Nov. 2020 about 470 dollars (395 €).

New epaper component for ESP-IDF

E-paper component driver for the ESP-IDF framework and compatible with ESP32 / ESP32S2 can be found in this repository:

https://github.com/martinberlin/CalEPD

Codenamed Cal e-pe-de for the initials of E-Paper Display this is basically all what I’ve been doing the last weeks. Learning more about C++ object oriented coding and preparing a class that can be used to send graphic Buffers to different epaper displays. In order to do that I’m documenting on the go and building at the same time CALE-IDF that is our Firmware version for CALE.es but this time built on top of the Espressif IoT Development Framework (IDF)

The mission of this new component is to have a similar library for ESP-IDF that is easier to understand. If possible strictly meeting these requirements:

  • Extendable
  • Maintainable
  • Object-Oriented Programming with human-readable code and function names
  • Easy to add a new Epaper display drivers
  • Easy to implement and send stuff to your Epaper displays
  • Human-understandable
  • Well documented
  • ESP-IDF only (No Arduino classes)

Please find here the Wiki with the models that are already supported in the component:

https://github.com/martinberlin/cale-idf/wiki

Leave us a note if you want to try this. We can guarantee that for big epaper displays (>=400 pix. wide) it runs faster than GxEPD also supporting Adafruit GFX fonts and geometric functions. If you tried and it worked out for you please don’t forget to add a ✰ Star and spread the idea.

Testing the new ESP32-S2

I got one ESP32-S2 Saola board and I will be making some tests on this repository:

https://github.com/martinberlin/ESP32-S2

ESP32-S2 integrates a rich set of peripherals, with 43 programmable GPIOs which can be flexibly configured to provide USB OTG, LCD interface, camera interface, SPI, I2S, UART, ADC, DAC and other common functionality. ESP32-S2 provides the optimal HMI solution for touchscreen and touchpad-based devices.
The arduino-espressif32 is getting it’s finals touches of grace before being available and I will just do a small repository and try to test as much as I can and also make some benchmark comparisons.

In the first tests the impression is that most of the arduino framework is already working with a few exceptions. Not all the features are supported yet but they will be soon.
Sadly the deepsleep is still not optimized correctly in this first revisions of the Saola board and on 3.4 v I measured 0.79 mA/hour. On a good ESP32 board like tinyPICO it’s 0.08 mA/hour (10 times less) now that’s something you can plug to a battery and make it wake up every hour to do something.
Please note this is not a fair comparison at this point. It’s only a test with same firmware, same conditions and bypassing power regulator to see how much it consumes directly powering the board with the 3.3V pin.
On the other hand, making processor intensive tests like receiving UDP packets or receiving and decompressing at the same time, it showed similar speed with much less consumption than the ESP32.

But other than this small annoyance in this first board revision it’s a really promising product and very powerful System on a Chip. The feature list is impressive:

  • Xtensa® single-core 32-bit LX7 microcontroller
  • 43 programmable GPIOs.
  • Standard peripherals including SPI, I2C, I2S, UART, ADC/DAC and PWM.
  • LCD (8-bit parallel RGB/8080/6800) interface and also support for 16/24-bit parallel.
  • Camera interface supports 8 or 16-bit DVP image sensor, with clock frequency of up to 40 MHz.

Please follow the repository and add issues or just leave a comment here if you want me to test any of the features and I will publish the results. Note that the only condition is that the results should be shared with the community on the internet. It’s all open-source, so we will keep the same spirit and share the results with everyone else.
Another example of ESP32-S2 in action, controlling 144 RGB Neopixels using Makuna library https://twitter.com/martinfasani/status/1267015931689144320

What GPIOs not to use in ESP32-S2

GPIODescription / default configuration
0Pull-up
26PSRAM pin
45Pull-down
46Pull-down – INPUT only
43 *default UART0 pin on S2
44 *default UART0 pin on S2
NOTE: GPIO26 it applies primarily to WROVER as those come with PSRAM.
* not sure if you should not use 43,44 but if you will use UART0 output in your project is the best you don’t use them

Important documentation
ESP32-S2 Technical reference manual (page 39-40 for the not-use GPIOs)

Trying out Waveshare E-Paper ESP32 driver board

In my pursuit to make the CALE displays as small as possible but also to learn how different boards interact with Epaper I got last week an Waveshare E-Ink ESP32 driver board.

ESP32 Waveshare Epaper driver

Not all the boards need to use the default SPI GPIOs of the ESP32 and this was one of this cases. Opening the documentation, the first check was to see that Waveshare used this PINS:

#define PIN_SPI_SCK  13  // CLOCK ESP32 default 18
#define PIN_SPI_DIN  14  // MOSI ESP32 default: 23
#define PIN_SPI_CS   15
#define PIN_SPI_BUSY 25
#define PIN_SPI_RST  26
#define PIN_SPI_DC   27

So my first though was Ok nice but this won’t work per se using gxEPD library. Because this great library starts the SPI.begin() withouth parameters hence using ESP32 /ESP8266 default GPIOs for SPI communication. So what I did to test is very simple, I forked GxEPD:
https://github.com/martinberlin/GxEPD-config-spi.git

And updated this part of the library to use defines that can be injected using Platformio build_flags:

SPI.begin(CLK_GPIO,MISO,MOSI_GPIO,CS_GPIO);
Note that MISO is already defined in espressif32 Arduino framework.
So now we can inject the other 3 in platformio.ini and get the Waveshare example working:
build_flags =
  -DCLK_GPIO=13
  -DMOSI_GPIO=14
  -DCS_GPIO=15

If we want to test it with CALE we can also use the same defines to reference the EInk wiring in lib/Config/Config.h

// Waveshare ESP32 SPI
int8_t EINK_CS = 15;
int8_t EINK_BUSY = 25;
int8_t EINK_RST = 26;
int8_t EINK_DC = 27;
So it was not a lot of time to get it working with this simple modification. I find it great to inject defines using build_flags. It’s really straight-forward and in fact, if they are only simple defines, all configuration for a project could be done just in platformio.ini

The party breaker

So I was excited to get this working and avoid using this SPI adaptors that go between the ESP32 and the Epaper display…until I got the idea to connect it to my small 3.7 V Lipo that I use to test the ESP32’s with a Diode in between to lower 0.5 v. and found out how much it consumes in deepsleep:
That’s 13 mA per hour. Unless I’m missing something and there is something big that needs to be switched of before deepsleep this EPD driver will eat your battery and your kids for dinner.
So that was the low point of this test. If someone’s got a clue about this high consumption when sleeping please write something in the comments.
UPDATE: In the measurement below I forgot to put the diode in serie, so I was giving 3.8 v to the 3.3 pin. Don’t try it otherwise you may kill the ESP32.  Adding the diode it went down to 3.4 v and consumption of course went also down to 10 mA. But is still a lot for deepsleep. In good ESP32 boards like TinyPICO and others, deepsleep consumption is as low as 0.08 mA.
Video proof:

Hackaday projects update: CALE Eink Calendar and udpx

I must say although I’m not proud of all the projects I tried to document in Hackaday I do like a lot udpx and Remora, that are made initially to control Addressable LEDs, but they could be expanded and used for another uses.

CALE

This is actually an old project for the agency I work that is finally seeing the light. I started using Waveshare V1 and this is the new 7.5″ e-Paper V2

CALE E-eink calendar ESP32
CALE Eink calendar ESP32

This will be powered by a TinyPICO ESP32 that claims to consume as little as 20uA when in deepsleep. Let’s see when it’s connected to the Waveshare also in deepsleep ;)
But the idea is to connect, refresh the meeting room labels at each door, and then go to sleep for at least 2 hours. And in wakeup check the day of the week, it it’s Saturday or Sunday when we are not in the office, then just keep on sleeping. There is no need to update stuff when no one will watch.
So designed with low-consumption in mind, will be actually my first real battery project, that I hope last at least 30 days without charging. The Firmware is actually not ultra complicated except the BMP image reading part, that I took mostly from the GxEPD Eink library example, with the add-on that I implemented Zlib compression so download takes one second instead of five. Other than that the only thing that does, is to wake up, query a backend passing an URL that renders that webpage screenshot. The image is sent per SPI and it goes to sleep.
EVOLUTION:
Firmware: 90% done and open source
Case: Work in progress
CLIENT: http://www.skygate.de

udpx

udpx sending frames to a 44*11 RGB Led matrix
One of my personal favorites since we are working in team long time already is udpx which is a transmission protocol with decompression support (Zlib and Brotli)
That we are using at the moment to receive animation frames but I can see much more potential in it, like to be used to send small JSON beacons and have real-time charts for anything, they are endless possibilities to use a streaming technology that is proving to work stable. The Max. transport Unit (MTU) of the ESP32 is about 1470 bytes, but you can send much more in that payload if you use Brotli or Zlib, so I see that it can be applied in many other use-cases.

udpx is the first project using Espressif boards where we can use the full connectivity possibilities that the ESP32 offers:

  1. Bluetooth WiFi configuration. That’s one of the main reasons the ESP32 offers Ble and Bluetooth serial, so here we put it to use.
    udpx-app is an open source Android application that offers Ble/Bluetooth serial configuration to send WiFi credentials and also mDNS discovery using zeroconf
  2. WiFi UDP and decompression. ESP32 has enough memory to pack in one sketch both Brotli, miniz (Zlib) and Bluetooth. I did not believe this initially, but udpx is the proof-of-concept that it can be done.

Pixels is the library that is implemented to do the UDP interpretation, read the headers and send the RGB(w) brigthness values of each LEDs to Neopixels. Initially developed by Samuel our colleague in the USA, we work in team also with Hendrik in Frankfurt am Main to develop a Backend controller that will be able to chain animations and route them to multiple ESP32 controllers every millisecond. So this is a very exciting project, that is going slow because everyone is busy in many things at once, but one that I personally steal hours of sleep every time I can just because it’s interesting and beautiful to work on it.
Last addition was the PIX565 protocol, one that’s been inspired in Spectre’s own take on OctoWiFi LED Controller, but one that has been also used in old game consoles. Didn’t know about this, but Neopixels developer Michael Miller put it in words today:

Games also use alternate bit depth images like 565 and even others; to compress in memory textures. Lots of writeups on that and how shaders can use them to render. The graphics stuff you learn for LEDs often overlaps with gaming techniques.

Remora

This streaming little fish is swimming since a while and I’m proud that some music hackers are using it in professional Eurorack setups.

It was initially built for ORCΛ sequencer, and receives short UDP commands of 4 to 6 characters, to launch fast animations at a very high framerate. In the last months it also had the addition that if receives more than 9 bytes, it renders also a Pixel animation frame, so you could send short animations, but also a small animated video.

Remora was also the first product that I could imagine can be a Tindie product, but I must confess that I never selled one, even that I put a price that is mostly the Hardware price. I’m good at building, but not at selling. Everyone has to find their strong point.

 

Cordova cross platform mobile applications

After the small Chrome App experience that resulted in a very compact app that reads Video and sends an UDP binary stream to ESP32 Led controllers I decided to start learning how to program a real mobile app.
Real because I find that the way to do it must end in the App Store and the user should be able to install it with a few clicks.
This start guide is only valid for Linux but it could be a similar approach in Mac.

1.- Install Java 8 SDK
https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
2.-Cordova
https://cordova.apache.org/#getstarted

It’s very straight-forward to start if you have previous html/javascript experience building a web page.

In this github repository:
https://github.com/martinberlin/udpx-app

I’m building my very first Android app. Follow the commits and watch the Repository to see my new steps and also my failures in this new world.

This is a preview of how the app looks like in it’s first version:

udpx Android application is available in the Play store.
udpx app

Soon more posts will follow explaining how to interface with Android OS (Camera as an example). There will be soon more issues to expand and implement in this repository. And my new philosophy to build Firmware for Espressif chips will be simply:

“One firmware, one mobile application”

Meaning that every firmware will have his app, where you can configure and test it, just with one click install in google Play store and setting up some very easy configuration. Starting from WiFi credentials using BLE (Bluetooth low energy) and setting up the App IP address as a last step.

My goal at last, is that internet of the things is easy to use, and not something where you need a 20 minutes complicated setup to start using something. So the mission is that for first weeks 2020 all master branches from our main ESP32 Firmwares like udpx and Remora should be bluetooth configurable.

Met Remora a simple firmware and language to launch addressable led animations from ORCΛ

Remora listens to UDP short commands to trigger LED Animations. Receives ; commands from ORCΛ

As a side fun idea while learning Nodejs and while working for a bigger and more complex project with my partner Hendrik I programmed Remora just to have an easy way to launch animations from ORCΛ

If you want to try it out please check the requirements and components on the repository or on the hackaday project page.
After getting addressable LEDs and any ESP32 board, it’s easy to compile this, reading the provided instructions with Arduino or Plataformio. It needs simple configuration, to know your WiFi credentials and the length of your led stripe.
After initializing and getting online, the firmware will listen by default in port 49161 and launch short animations as fast as the UDP message hits the chip. To test it send an UDP message using netcat or any other way. In Linux that can be done like this:

echo '82O'|nc -w1 -u ESP32_IP 49161

IMPORTANT: If you copy the upper text make sure that the quotes are single quotes otherwise the compiled C will not recognize what animation to start

That is enough if you want to send animations to one controller. If you need more then we created a simple UDP redirector script that lives in the extras folder. This can be run using:

nodejs udproxy.js

After configuring a simple ip-config.json file that has an id to IP lookup table:

{
    "1":"192.168.0.74",
    "2":"192.168.0.73"
}

When this is running in the background, it will just process any message coming, extract the first character and pick up that ID from the table. Then it will redirect the rest of the message to that IP, same port 49161. To explain it more graphically, sending:

echo '282O'|nc -w1 -u localhost 49161

will lookup IP 2 and send 82O to 192.168.0.73 enabling you to send animations to different LED Stripes from Orca sequencer software.

Remora Logo

Schematics

Electronic schema

Additional info

Public repository
https://github.com/martinberlin/Remora Stable branch: master (only ESP32)
Hackaday project page for Remora – Find component list there.
Approximate cost of hardware not including 3DPrint: 19€ or about 22 dollars

Starting to do smart-home appliances with ESP-Mesh

ESPMesh reduces the loading of smart light devices on the router by forming a mesh with the smart light device.”

I’ve started months ago getting some smart lights for home and I’ve chosen Osram since it was about half the price than Phillips VUE. But the thing with this systems, though they work nice and with very little configuration, is that you need always a “Gateway”. A central point that receives signals and then send via Radio frequency to the lights what they have to do.

The Espressif ESP-Mesh took a different approach: Every device is a network member making a Mesh of interconnected devices. There is no gateway because there is no need for one.

There is also a very important point that is very interesting if you are a maker like me. It’s open source. That means you don’t need to buy a 60€ light to test it, you can just go to the ESP-Mesh github repository and download ESP-Mesh-Light example to compile it in one of your existing ESP32 Boards. Then you can get easily something like this working :

So what I’m working on the free time to take a rest from another pending projects is to take this PWM output and amplify it using a 74HC125 Quad Bus Buffer to power more than one led.

For those interested in reproducing this example:

https://github.com/espressif/esp-mdf/tree/master/examples/development_kit/light

Command lines to execute the compilation are only 2:

make menuconfig
make erase_flash flash

Compile this into your ESP32 and then download Espressif official Android App or if you are using I-phone / I-Pad just search for “ESP-Mesh”
The Mesh devices are configured using Bluetooth so keep in mind to have this enabled on your device. Instead of taking the “WiFi Manager” Approach, using an App, you have the benefit that you can just send the WiFi Credentials plus configuration directly to the ESP32.

Postman self documenting tests and runner import

I’ve been working on the last days doing extensive API testing and needed to find an easy way to document my tests. Postman offers already something very useful that uploads your tests documentation to their website. But sometimes we need just a simple HTML that can be privately delivered to the client.

That’s where this project was born:

https://github.com/martinberlin/postman-reporter

The intention of this simple PHP script is to generate a Standalone HTML for your Postman tests that you can send to the client without the need to upload all the tests in the open internet.

It serves to achieve two things:

  1. Make a standalone HTML document from your Postman Collections
  2. Import the test run-results into a mysql database

With the second one only the importing is done. It’s then up to you how to present this data. It populates two tables, resume and detail, first one with the performance result and the detailed with a line per test. Much more information can be extracted from the runner json this is just a kickstart idea. Have fun with it!

If it calls your interest then please read more details in the github repository.