Two early projects approached a similar problem at different scales. In 2012, an Arduino experiment moved a changing signal into a web interface. In 2014, an energy-metering prototype connected local measurement with remote reporting. This note revisits their architecture from the present; it is not a current installation guide for their original dependencies.
Start with the path a reading takes
The Arduino project used a serial connection to a host computer, with Node.js between the board and a live browser interface. Arduino’s June 2012 feature remains a contemporary record of the work. The original CodeProject article no longer serves at its original address.
The energy-metering prototype added a different set of boundaries: an ADE7753-based measurement circuit, an Arduino, a local LCD, GSM reporting, and an application context for customers and a utility. GPS supplied location information for the installed device.
Both architectures can be read as a sequence:
Physical signal → measurement → transport → stored or displayed information → a decision by a person.
That sequence is more useful than a list of components because it reveals where meaning can be lost. A value needs a unit. A reading needs a time. A device needs an identity. A display needs to distinguish a fresh observation from the last value it happened to receive.
A live interface makes uncertainty visible—or hides it
A moving graph is persuasive, but motion alone does not establish measurement quality or delivery reliability. In a new design, I would want the interface to make three separate questions easy to answer:
- What did the device measure, and under what interpretation?
- When was that measurement made, and when did the application receive it?
- What does the system show when the device or connection is unavailable?
These are design questions prompted by the architecture, not claims that every mechanism was implemented in the historical prototypes. They help separate successful transport from a trustworthy representation of the physical system.
The useful unit of design is the whole path
The component boundary is a convenient place to divide implementation work. It is a poor place to stop thinking about behavior. Firmware, a message handler, a database, and a mobile interface can each be locally correct while disagreeing about ordering, freshness, or identity.
The enduring value of these prototypes is that their complete path was visible. They make it possible to examine the hardware and the software as one system, then ask which guarantees the next version needs. That is a more durable starting point than replacing each old dependency with its newest counterpart.
Evidence & further reading
Sources
- Publishing data on the web with Node.JS
Contemporary editorial feature explicitly crediting Bangon Kali and linking the original tutorial.
- Arduino and the Web using NodeJS and SerialPort2 — original article
The original article address no longer serves the tutorial. Arduino’s dated reference survives; a successful HTTP response alone does not establish article availability.
Original resource unavailable - Power-meter platform
2014 repository documenting ADE7753 metering, Arduino, GSM, GPS, LCD, and a custom base board.