The whole process can be technically divided into two parts: Remote Node and Main Controller. To make the program work asynchronously we need to first have a light operating system which contains all the functions for the meter, the radio transmission, and storing variables into the flash memory.
The basic operating system is based on a timer and ISRs. Another future addition will be a watchdog to improve stability; monitor for crashes or stalls. Flash memory is managed to not overwrite program content during operation. The LightOS manages all tasks on the controller. This task program manager serves as an interrupt service for our Arduino to switch from the tasks running now to the request.
Remote node and Controller
From the diagram above we can see that the radio communication system is divided into two parts: remote nodes and controller. The job of remote nodes is collecting meter data and responding to the request of controllers. The controller’s request is of three different kinds currently. The first kind is a ‘Beacon’ which is used by controller to detect the surrounding remote nodes. It can also be used to set the clock for each remote node and to monitor for inactive nodes. The second is aimed to request meter data for remote nodes. The last kind is used to control the status of meters that connected to remote nodes. Meanwhile the remote nodes have to keep collecting the data of meters and storing it in memory. This function is a little special, because it is registered in the lightOS system which means it would be called periodically rather than be called in loop function. The job of the controller is quite similar. It would send the three kinds of requests, illustrated before, to remote nodes and the remote will reply accordingly. Also it is registered as a function in LightOs which is used to read data from remote nodes. Finally it will respond a HTML file when the users request a http visit.
Web server
Here is the web server interface:
The three gauges above show the power measured by three meters, which could be used to monitor the real-time power consumption. The first meter is connected to a 25W bulb and the second is connected to another 25W bulb. The third is monitoring the power draw of the second meter with 25W bulb. Below the gauges there are three buttons that could control the switch of the three circuits. If we press one of these buttons, the corresponding switch in our circuit would change, and short delay, it would respond to our command. This can be seen in the demo video. When a button is pressed that task is added to the main controller’s docket and it must send an RF message to the indicated meter. The meter then must receive the message and send a serial communication to the correct meter to turn it on or off. To update the web server reading it must wait for the remote node to update and respond to a request for the reading with the new reading.
CLOUD SERVICE: THINGSPEAK
ThingSpeak is an open source Internet of Things (IoT) application with an API to store and retrieve data from things using the HTTP protocol over the Internet or via a Local Area Network. ThingSpeak enables the creation of sensor logging applications, location tracking applications, and a social network of things with status updates. Since our device is so simple and there is no on-chip system, it is not very easy to upload the data to conventional database like DynamoDB or other AWS service, we choose to use ThingSpeak to show the accumulated data. In ThingSpeak, one could build many channels and fields to show different types of data. It is a complete cloud service, which mean that unlike the server we build above, the ThingSpeak service does not depend on if we are in the same LAN with Arduino web server or the status of router bridge, it can be visited everywhere to query the historical data. Normal ThingSpeak uses HTTP protocol, but it could also be updated with MQTT. If this change was made our IOT device would have a much lower data transmission overhead. It would save money on data transfer and function better on poor cellular networks.