On 6 July, our whole group met up in person for the first time since the end of the academic year and headed down to (Pulau) NTU. Our objectives were simple: The coding and electronics team (Glen and Yu Yun) were planning to test out whether the code for operating the GPIO pins on the Raspberry Pi worked, while the design team (Bryan and Zann) were planning to print out the casing for the fan attachment.
Coding and Electronics Team
The initial plan/workflow was this:
-
- The IFTTT Applet that was created will receive a request from Webhooks, and run
- After the Applet runs, it will publish a Particle event
- The Raspberry Pi will receive the Particle event, and run a function that will output a
HIGHon one of the GPIO pins - The LED that is connected to the GPIO pin will light up
We borrowed an RGD LED, a 100 Ω resistor, a breadboard, and 2 M-F jumper wires, set up the circuit, and prayed for good luck.
And of course, the LED didn’t light up as we expected. After all, what electronics project goes right on the first try? Let the debugging commence!
Due to the interdependence of the services that we chose to work with (IFTTT, Webhooks, Particle.io), there were so many things that could have gone wrong, so we tried everything one by one.
First, the LED. Maybe it was broken, or maybe we connected it wrongly. The RGB LED that we used had four pins, one for each of the colours and one for the common cathode/anode. As the LED was (unfortunately) not labelled, we tested it using DC voltage supply. After some trial and error, we found out that the LED lights up when the longest pin was connected to the positive terminal, hence our RGB LED had a common anode.
Since our LED was not spoiled, the next thing to test was the Raspberry Pi’s GPIO pin. We uploaded an example code through Particle.io that was supposed to make an LED connected to the GPIO pin blink. The LED blinked as expected and we moved on to our next step of debugging.
Perhaps Webhooks was the one that was not working. When the correct URL is accessed, Webhooks is supposed to update IFTTT and run the respective applet to publish an event. After checking the logs, we realised that the applet was run without errors, so on to the next service: Particle.io
Particle.io is responsible for receiving the event published by IFTTT, and running the code after the event has been received. To check if the published event was received, we checked the console, and saw that the event was indeed received. However, the function that was supposed to run did not run! We have successfully found the source of our problem. Now, were we able to fix it? Let’s find out in the next blog post We will give our dear reader the satisfaction of instant gratification, because we are nice people 🙂
After poring through the documentation and reading up in great detail about the different functions and workings of Particle.io, we gave up. Pretty anti-climatic, right? We realised that there was no way we could fix the issue, so we decided to look for another service that was not Particle.io.
A quick Google search led us to another service, Adafruit.io. At this point of time, we started to wonder why everything we used seem to have a domain name of “.io”, including all the popular games, Scribbl.io, Agar.io, Slither.io…but… we digress.
With Adafruit.io, there is a feed and a dashboard system, where the feed is like a terminal or a means of talking between the device and the service (in our case, IFTTT talks to our Raspberry Pi through the feed), and the dashboard is a place where we can send commands to the feed. We won’t be needing the dashboard, as IFTTT serves as our way of sending information to the feed for the Raspberry Pi to read.
After installing the necessary dependencies on our Raspberry Pi, we edited our IFTTT applet to send a message to the Adafruit.io feed when the correct URL is accessed. With some tweaking of a script that uses the MQTT Client (more details in our working principle here), lo and behold, our LED finally lit up as expected!
Coding and Electronics Team Out!
Design Team
The design we were going to print was expected to take a whopping EIGHT hours to print on the Creality Ender 3 printer, and we just wanted to test out if the fan attachment was going to fit on the fan body. Tony mentioned that as the curve of our fan attachment was quite thin, it was prone to breaking, and this could be a problem as we needed the attachment to expand slightly to fit the fan body. Nevertheless, we decided to just try it out, and if it broke, then we knew for sure that it was too thin.
To skirt around the problem of the long print, we decided to get rid of the “HDB blocks” which were the housing for the solenoid actuators, as the current purpose of printing the attachment was just to see if it fits the fan. By removing the “HDB blocks”, we managed to slice off our print time to around 3-4 hours.
While waiting, we finished up the slides for our progress report on 9 July, looked around online for our solenoid actuators and other electronic components.
After arriving home, in case the fan attachment snapped into two while trying to fit it in, we took a photo of the attachment beside the fan. Luckily, the fan attachment did not break, although it was under quite a bit of stress due to the fan’s front being less curved than the design. The buttons also do not pop out as much as we wanted them to, and this might cause the bars to be unable to push the buttons as we had expected. Back to the drawing board!
