Meteor.js demystified


Some month ago I was choosing a framework for a simple web application and I decided to give a try to meteor.js.

Meteor use the Model–View–Controller (MVC) pattern that divides an application into three parts in order to separate:

  • internal representations,
  • elaboration,
  • visualization.

Unfortunately, eteor actually supports only MongoDB, a very powerful solution for simple application but very hard to use for complex solutions.

Meteor has an interesting module that allows collecting information from an MQTT queue (you can also decide to save all the messages or just last one) and in the same time, I was searching a fast way to show information coming from a collection of ESP8266 boards with different firmware/sensors.

The ESP8266 is a low-cost SOC capable of WIFI connection, compatible with Arduino IDE and with the following characteristics:

  • 32-bit RISC CPU: Tensilica Xtensa LX106 running at 80 MHz
  • 64 KiB of instruction RAM, 96 KiB of data RAM
  • External QSPI flash: 512 KiB to 4 MiB
  • IEEE 802.11 b/g/n Wi-Fi
  • Integrated TR switch, balun, LNA, power amplifier and matching network
  • WEP or WPA/WPA2 authentication, or open networks
  • 16 GPIO pins
  • SPI
  • I²C
  • I²S interfaces with DMA (sharing pins with GPIO)
  • UART on dedicated pins, plus a transmit-only UART can be enabled on GPIO2
  • 1 10-bit ADC

The firmware template (present in the GitHub repository) written in C for ESP8266 following the Arduino style coding allow interacting with the node using JSON messages and the MQTT protocol.

The firmware starts with hardware initialization and send a deploy message with all configurations on the queue

where —CHIPID— is the ID burned inside the ESP8266 chip.

In the normal working, the node collects information and send messages (e.g. with information coming from a sensor) on the queue

The board can receive commands on the MQTT queue

when a message is received the relative function is called.

The firmware sketch allow updates via OTA, sending a message to the queue

allow to start the update function that downloads last available firmware, install it and finally reboot the board.

The WIFI connection is managed with a captive portal, when the ESP board don’t recognize the know wifi network, the same board emulate an access point and allow the configuration via a captive portal, then the credentials are stored in hardware and the board rebooted.

The firmware allows a debug via serial port in order to debug the firmware via the USB connector.

Boostrap3 theme and custom tables completed the scenario allowing to write a clear interface for:

  • edit firmware template and upload on your board(WIP),
  • get info on running firmware for each node and update the board with last firmware if possible,
  • get last values read (WIP) and
  • get historical data.

Complete code on

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.