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) patter that divides an application into three parts in order to separate:

  • internal representations,
  • elaboration,
  • visualization.

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

Meteor has an interesting module that allow to collect information from a 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) writte in C for ESP8266 following the Arduino style coding allow to interact with the node using JSON messages and the MQTT protocol.

The firmware start with hardware initialization and send a deploy message with all configurations on the queue iot/T/esp8266/I/—CHIPID—/D/deploy/F/json where —CHIPID— is the ID burned inside the ESP8266 chip.

In the normal working the node collect informations and send messages (e.g. with information coming from a sensor) on the queue iot/T/esp8266/I/—CHIPID—/D/sensor/F/json.

The board can receive commands on the MQTT queue iot/T/esp8266/I/—CHIPID—/C/sensor/F/json, when a message is received the relative function is called.

The firmware sketch allow updates via OTA, sending a message on the queue iot/T/esp8266/I/—CHIPID—/C/update/F/json allow to start the update function that download 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 allow 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 readed (WIP) and
  • get hystorical data.

Complete code on

Email this to someoneShare on FacebookShare on Google+Share on LinkedInTweet about this on TwitterPin on PinterestPrint this page

Leave a Reply

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