Iteration 4 | IoT Apps | Eric Butler

 

IoT Apps - Connecting Microbit to Cloud, MQTT & IFTTT


MQTT Architecture Diagram





For our system, we will be using DFRobot Cloudboard V1, Microbit V2, Mobile Hotspot (Android - More info below), Beebotte MQTT Broker as well as IFTTT App to connect our Microbits to a mobile hotspot, then to a MQTT server, Which will connect to our app with configuration. This allows us to have communication between multiple microbits at one time.


Issues Found

Having all these devices communicating and connecting to each other as well as servers wasn't without its issues. We had spent multiple classes debugging and recognizing issues, and figuring out what worked and what didn't. 
 A main issue we ran into was the hotspot not working which is an integral part of our system. This was a frustrating time but it definitely got us into the mindset of not just saying "it doesn't work" and more saying "it doesn't work because..." and solving the issue. After some time of diagnosing issues, we came to the conclusion:

 > iPhones didn't work, possibly because of how locked down an Apple Device is which could have detected the cloud board as a sketchy device but this was not confirmed. Another possible issue could have been the iPhone using IPv6 and not IPv4 but again this wasn't confirmed the issue.

> Laptop Hotspot through Windows worked but to mixed results, this is possibly due to the Laptop using Eduroam which can be shakey due to the amount of people connected to the network at once. As well as this, the built-in Windows hotspot feature is known for being slow (source: experience and google search)

> Android worked the best out of all the options and this seemed to hold a stable connection so we continued with this option. 

Background Knowledge on cloud board LEDs

 > Red: The Red LED indicated that there was no WiFi connection being sent to the Cloudboard from the Android hotspot that we were using. The username and password would also have to be set on the Cloudboard.

 > Purple: The Purple LED indicated that the MQTT server had disconnected even though the Cloudboard may have still been connected to WiFi. The MQTT server we were using was the Beebotte and when this issue arose we just made sure our MQTT was still active, not under heavy load and that our API keys were correct.

 > Blue: The Blue LED indicated that the Cloudboard was attempting to connect to WiFi which would take about a few seconds depending on how good our hotspot was.

 > Green: The Green LED indicated that the Cloudboard was successfully connected to our Hotspot and MQTT server and we could start looking into getting our clients onboard.


Red LED

Purple LED

SETUP With No LED



Starting Routine

We developed a starting routine to make sure our MQTT server was deployed consistently and effectively. This included:

 > Turning the Android hotspot on.
 > Switching on our cloud boards.
 > Waiting for the green light to appear on the cloud board which initiates it as being connected.
 > Waited for the heart symbol to appear on the LED.
 > Connect the micro bits of other people (these acted as clients).
 > Verified the connection by having all correct LEDs showing on all Micro: Bits
 > Once all were connected, we looked at the phone client (Which was the 'IoT MQTT Pannel' app)



Pannel made using MQTT Panel App



Code


This is the entire code for the project. Below is a brief summary of the main sections

Above is the setup function for the server side of our system. This first displays the string "Server" to initiate the Micro:bit that this is the server side. It is also using the Micro:IoT extension to setup the WiFi and connect to the MQTT using Beebotte access keys. Once these are all configured correctly and the connection is up and stable we get the heart icon to show our setup is up and running.


In this forever loop, we call the sendToNode function in order to send values from the server to each microbit depending on the input ID of the microbit. Certain LEDs will light up depending on which ID it is.


This small piece of code obtains the message from the MQTT server and parses it through a JSON string in order to have it visible.


This is the structure of the JSON message we sent to our devices through the MQTT app. This essentially takes the ID of which ever input comes through, the value from that input and joined together a JSON string of {"i1": 123, "ispublic":true}


Here the sendToNode function passes in the input ID we want to send to, the value that will be sent as well as the X and Y coordinates of which LED will light up depending on if the message is sent.


IFTTT (If This Then That)

This app is what we used in order to send an email from one of the micro: bits. Here is an example of Hasan using his Micro:bit to send Jason an email telling him that we got the MQTT server up and running on both the server and cloud side and so he can come back into the room to see how we were getting on.












 

Comments

Post a Comment

Popular posts from this blog

Iteration 2 | Jack | HRV Micro:bit Research

Image
Iteration #2 - Micro: Bit Research & HRV Jack Duggan | 20094010 | IOT Apps For the second iteration sprint of the module, I got hands-on with the Micro:bit. I had previously used these devices way back in secondary school for Leaving Certificate Computer Science, so the basics came back to me fairly quickly. We were sent home to 'research' the Micro:bit, and become familiar with it's basic functionality, before class on Friday the 2nd of February. In the class, I worked alone (as we had an odd number of students present) with a Micro:bit V2, an expansion board for the Microbit, and a heart rate sensor. Above is the physical setup Below is the device output screen with my finger on the sensor. The top graph shows my pulse as analogue input as identified by the sensor. Some mathematics is performed (as shown under the below graph) that converts these pulse values to HRV (delta_t). This HRV value is then displayed on the 'boxier looking' graph underneath. The way t...
Read more

Iteration 5.2 | Lock In | Jack

Image
Iteration 5.2 | The Lock-In 🔒 Jack Duggan | 20094010 | 10/05/2024 The "lock-in" was something initially devised months ago, an idea that involved taking a couple of days towards the end of the semester to commit fully to this module. As the semester began to wind up in terms of general workload, it became increasingly apparent that this "lock-in" would be necessary. In week 10/11 when we finally set it in stone, it was a great relief off all of all shoulders, knowing it was one less module to stress about, especially with already rampant workload due in week 12/13. With the lock-in pencilled in for the second week of May, it allowed myself and the others to put increased focus on other modules, and helped reduce the stresses we faced at this time. Eventually, the lock-in week did come around, and I and the others arrived in the room on Tuesday 7th May at 10am sharp. We had split into two teams, one team consisting of Emma, Conor and Eric that would look at adding H...
Read more

Week 1: HRV Review

Image
  What is it? Heart rate variability (HRV) is the measure of the variation between heartbeats. It is controlled by your autonomic nervous system (ANS). This system operates automatically and regulate process such as the heart rate and other bodily functions that are are not under conscious control. This system is broken into two branches the flight or fight (which preparing the body for action and stress) and the rest + digest (which promotes relaxation + recovery). HRV is influenced by the ability to smoothly shift between these two branches.  High HRV: Larger difference between successive heartbeats - Indicates a more flexible and adaptable autonomic nervous system.  Low HRV: Smaller differences between successive heartbeats - Indicates a less flexible autonomic nervous system.                                                ...
Read more