Original concept for child and parent keys
render of reader shell and key cards
Prototype of keys
Both of our Arduino setups; Reader/Controller on the right, Receiver/Device Manager on the right
- Smart home, other IoT systems have no User Account Control equivalent
Ordinarily, lack of user control isn't a problem, but theoretically anyone with access can cause havoc, even by accident. In a worst case scenario, for example, an accidentally-activated oven could cause a massive fire
- Wanted to create something to serve as this
We wanted to create a system to confirm that users knowingly mean to send the commands that are sent, limiting inadvertent (or malicious) damage.
- Also wanted something to show off all of our skills
As a group, our skill set is very diverse, ranging from front-end web development to three dimensional design and printing to Python programming to hardware setup. We wanted to ensure that no part of the group was especially scrambling to learn a new skill in order to be useful; though we all learned new things, we were able to apply our strengths in a useful way
What it does
- Creates access levels for a single IoT network
Each user of our IoST system has a keycard with a number of holes punched. Each hole configuration corresponds to a different permissions level. When these cards are inserted into the reader, the computer the reader is connected to checks the permissions of the card and unlocks the functions that user has access to. The user can then select the function they wish to trigger.
How we built it
- Arduinos communicate with computer and remote Arduinos via master control unit
The reader is a set of three LED-photoresistor pairs. When all three return as unobstructed, there is no card in the reader, and no permissions are given. Each successive sensor blocked increases the permissions given - a final system would have more granularity in the codes given by the sensor. The sensors feed into an Arduino connected to the computer, passing key strings into the Python controller running in the computer terminal. After user input, the terminal feeds codes back into the Arduino, which then signals the appropriate device on a remote Arduino.
EDIT: Python input is currently bypassed to automatically run the highest-level output device when a given permissions level is reached.
Challenges we ran into
- Sensor choice
Our original concept used an array of ultrasonic sensors to scan a more complex key prism. However, we realized early on that mounting those sensors in the array we would need ran too much risk of inter-sensor interference, as well as making it difficult to ensure the keys are read correctly.
- Lack of tools
There were a variety of components we were unable to obtain, either because of low supply or a failure for the pieces to make it into the hardware library, despite being on the manifest. Also, we had access to few tools to process the devices we built.
- Serial Communication
None of us had ever integrated hardware with Python in the past. Creating bridges between the hardware inputs and software controllers was a despair inducing task.
- Python Integration
We had great difficulty in getting the Python program to fully communicate with the Arduino setup. The program is able to listen in on the Arduino serial output, but is unable to pass messages back to the Arduino effetively.
Accomplishments that we're proud of
- Cracking serial communication
Our greatest triumph was making our devices talk to each other. The relief we felt when we finally understood how to convert strings from Arduino to Python and back again cannot be overstated.
- Making sensors work to our favor
Similarly important was figuring out early on that LED-photoresistors were much more viable than ultrasonic-sensors. This choice informed much of our final design, especially the choice to make a card reader rather than a voxel 1 key reader
- Working around lack of tools
Despite lacking tools that would have made our lives easier, we accomplished our core concept fairly successfully - if we had the code to activate and control an actual smart device, our program and reader could handle it seamlessly.
What we learned
- Hard skills; software/hardware integration
Particularly the serial communication, but connecting two Arduinos via radio transceivers, as well as translating the sensor output into usable software input
- Soft skills: work as team in high-pressure environment, how to make best use of limited resources
This was one of the first hackathons most of us have competed in, so a lot of our learning was in how to work in such a high-pressure environment and how to work with our limited resources effectively.
What's next for Internet of (Safe) Things
- Greater Security
In this iteration, the keys can be faked with a torn, irregularly shaped piece of cardboard. The full concept will have greater granularity of codes on the cards. As well, each card will have an RFID chip, in order to ensure that the card is being inserted into the correct reader and that the card has not been tampered with. If either of these conditions were to fail, the card would fail to work.
- Home Version
The version modeled here is effective in small spaces. However, a version with a more decentralized controller would be more effective for larger spaces with more devices. This version would load tokens onto a smartphone or key fob, and access can be initiated at various sub-terminals, rather than a single master terminal.
1: Voxels are the 3 dimensional equivalent to pixels. On the concept keys, the fewer cubes a key had, the more permissions it granted.