Difference between revisions of "Status Boards"

From Nottinghack Wiki
Jump to navigation Jump to search
m (Simple NodeJS Server)
Line 59: Line 59:
 
* There is a simple GET that will set the byte values of a board - this is an insecure example!
 
* There is a simple GET that will set the byte values of a board - this is an insecure example!
 
** in reality we would be looking to authenticate users in secure manner (see http://passportjs.org/)
 
** in reality we would be looking to authenticate users in secure manner (see http://passportjs.org/)
 +
* each board should be uniquely identified - most obvious would be to use the MAC address and embed this in the GET request header perhaps
 +
* each board uptime would also be useful - they could send GET queries at startup and every 20 minutes or so
 +
* each board could query its settings from the server
 +
* the server should track hits from individual boards - this info should be downloadable and chartable

Revision as of 11:27, 6 April 2016



Status Boards
[[{{{image}}}|border|frameless|220px|center]]
Primary Contact Michael Erskine
Created 11/03/2016
Completed {{{completeddate}}}
Dormant {{{dormantdate}}}
Version {{{version}}}
Members {{{members}}}
Manufacturer {{{manufacturer}}}
Model {{{model}}}
Location [[{{{location}}}]]
GitHub / Repo {{{repo}}}
Status {{{status}}}
Type Undefined
Live Status {{{livestatus}}}
QR code

Simple means of showing status of Hackspace stuff on web and physical boards.

Basic Project Plan

The driving of the 16 LEDs poses an interesting problem due to the limited number of digital outputs on the NodeMCU: we are looking for a simple low-cost solution so after looking at various ICs to perform the task I decided to throw in another inexpensive micro with plenty of I/O and control it with I2C, serial or similar.

Using a cheap ProMicro for I/O

The NodeMCU can tell the ProMicro what outputs to drive with a simple serial protocol: -

Power Profile

For my first tests I used a cheap 18650 power bank that one would normally use for recharging a mobile phone when off grid. It ran for less than 24hrs but I was not sure of the initial charge. Anyhow, there's no overarching need for this device to be battery powered so I will probably just run it from a spare mains phone charger but it has got me thinking about the power usage so I'm going to learn a little about that:-

  • I'd like a generic current logger that I can attach to various devices - e.g. the SparkFun Low Current Sensor Breakout - ACS712 https://www.sparkfun.com/products/8883
  • there may be ways of reducing the current draw for the LEDs
  • The NodeMCU - is it a power hog?
  • how efficient is our 5v ProMicro and can we save power by making simple mods and running it at 3.3v

Real Data

The various readings need to come from the Hackspace infrastructure. These can be exposed to the local network if we only want status board units to run in the space, but since there's little difference between a public human-readable web interface and the simple ASCII interface used by the NodeMCU, it may as well be a feature of our public facing web.

Simple NodeJS Server

The nodeboard directory (https://github.com/msemtd/nodemcu-statusboard/tree/master/nodeboard) contains a simple NodeJS webserver that dishes up board data cached in memory.

  • it uses the minimalist expressjs web framework (see http://expressjs.com/)
  • At startup it reads boards.json that defines the various status boards, the field labels, and the saved byte values
  • A human visitor would request URL http://server:port/sb/1/ to see a HTML representation of board 1
  • A NodeMCU would request URL http://server:port/sb/1/nodemcu to get a plain text string with the hex value for board 1
  • There is a simple GET that will set the byte values of a board - this is an insecure example!
  • each board should be uniquely identified - most obvious would be to use the MAC address and embed this in the GET request header perhaps
  • each board uptime would also be useful - they could send GET queries at startup and every 20 minutes or so
  • each board could query its settings from the server
  • the server should track hits from individual boards - this info should be downloadable and chartable