Blog 5 - Development 2 - Igor Kapusniak

 

Blog 5 - Development 2

 

Introduction

 This sprint I was a continuation of the development from the prior sprint. With the core structure of the microbit cloud board code and fullness sensor developed, further additions could now be added such as encryption and sending barcode codes via MQTT to Node-RED. 


Encryption Update 

Using an XOR cipher on both the slave device and cloud board allowed radio communication between the two devices to be encrypted and decrypted after being received. The data sent between the two devices consisted of class ranking from the cloud board to the slave device, and full percentage from the slave device back to the cloud board. Both are encrypted before transmission via radio and decrypted on reception, ensuring that only authorised devices can communicate with each other. 
     

 

The addition of encryption required a rewrite of the radio communication on both devices. Previously, the communication used "radio send value" which sends a string number pair. However, with encryption applied, only encrypted strings could be transmitted as encrypted numbers turned into random characters. This meant the message format had to change to a single encrypted string that could be parsed after decryption to extract both the MQTT topic and the corresponding value. 
For example, the slave device sends an encrypted string like "full,0.85" which is decrypted and then split to extract the topic ("full") and value ("0.85").

 

 

Node Red Update

To allow Node-RED to receive scanned barcode codes, MQTT listeners were set up that subscribe to topics and read published messages from the microbit devices. Once a barcode is received, it is converted into a structured format containing the class information, bin details, barcode number, and timestamp for processing.

 

The barcode is verified using the publicly accessible API from https://re-turn.shanehastings.ie/, which tells us whether the barcode is part of the return scheme or not. If valid, the deposit value is extracted and the data continues to further processing. If invalid, the message is stopped at this stage, preventing invalid items from being added to the leader board. This verification step prevents fraudulent entries into the system.

 
 
 
 
 
 

Next Steps

All that remains is to run the verified return bottle data through Node-RED nodes that update a CSV file, which is then used to update a dashboard page with graphs and other information.

 

Sprint Summary

This sprint successfully implemented encrypted radio communication between the master and slave devices using an XOR cipher, which required a rewrite to handle string only radio transmission. MQTT integration was added to Node Red to  receive barcode scans with verification against the Re-turn API to ensure that only valid bottles are processed.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Comments

Popular posts from this blog

Blog 1 - Igor Kapusniak

Blog 5 - Bin Bot Project - Davin Barron