Door Guardian - FU

Project Introduction

What does it do?

Door Guardian - FU is an interactive door decoration inspired by the traditional Chinese Fu (福) character and door guardian culture.

In many Chinese homes, we paste Fu on the door during Chinese New Year. It means blessing, good fortune, and the hope that something good will enter the home. Door guardians also have a protective meaning: they stand at the boundary between outside and inside. My project tries to reinterpret these two ideas with electronics. Instead of making a decoration that only stays still on the door, I want to make a small calm-technology device that quietly belongs to daily life.

Normally, the device behaves like a digital Fu decoration. It can show:

• the Fu character
• time
• weather
• ambient information
• a quiet visual state on the ePaper display

When a visitor arrives, they can touch the interactive surface. The system detects the touch, sends the event through WiFi, updates the indoor interface, changes the ePaper display state, and updates a webpage dashboard.

Image idea: Use this concept image near the beginning as the emotional starting point. Caption suggestion: "Early visual concept of a digital Fu decoration, before the interaction and system architecture became clearer."

Why I chose this topic

This project starts from a very personal object. Last year, I hand-wrote a large Fu character with ink on special paper. I liked it a lot, but after one year the color had faded. That made me think about a simple question:

Can I make a Fu that does not fade?

At first this sounded like only a material problem: replace paper with LEDs or a screen. But the more I worked through Fab Academy, the more I realized the interesting part was not only the display. It was the relationship between the object, the door, the family, and the visitor.

A door is a threshold. It is the place where inside and outside meet. A doorbell is useful, but it is often loud and direct. A traditional Fu sticker is beautiful, but it cannot respond. I wanted to combine these two qualities: the warmth of cultural decoration and the usefulness of a gentle notification system.

Cultural inspiration

In Chinese New Year tradition, Fu is often placed on doors, walls, and windows. Sometimes it is pasted upside down because "Fu dao le" (福到了) sounds like "good fortune has arrived." The character is not only a word, it becomes a seasonal signal and a family memory.

I also thought about the idea of being round on the outside and square on the inside (外圆内方). "Round" suggests harmony and adaptability. "Square" suggests integrity and inner structure. This idea influenced the visual direction of my project: soft, welcoming, decorative on the surface, but structured and logical inside through electronics, PCB design, and communication protocols.

Caption idea: "Visual references for the Fu character: round composition, my handwritten Fu, and square composition. These became the cultural and formal starting points of the project."

Problem statement

Many smart home devices look technical first and domestic second. They are useful, but they often feel like gadgets placed inside the home instead of objects that belong to the home.

My question became:

How can I design an interactive home notification device that feels culturally familiar, calm, and useful, instead of loud or purely technical?

The project is not trying to replace a full smart doorbell system with camera and cloud service. It is smaller and more poetic. It focuses on a simple interaction: someone touches the Fu at the door, and the people inside receive a quiet notification.

Calm technology concept

I am interested in calm technology because it does not demand attention all the time. A calm device should stay in the background most of the day, then move gently to the center only when something meaningful happens.

For Door Guardian - FU, this means:

• The default state should be beautiful and quiet.
• The interaction should be simple enough for visitors to understand without instructions.
• The indoor notification should be noticeable but not stressful.
• The display should not constantly flash or compete with the home environment.
• The webpage should show useful state information without feeling like a control center for a machine.

This is why I chose touch instead of a mechanical button as the main interaction. A touch surface can be hidden inside the Fu decoration, so the object still looks like a decoration first. It also feels more ceremonial: the visitor touches the Fu character, and the blessing becomes a message.

Idea Development

Early idea: a Smart Fu decoration

At the very beginning, my idea was more like a digital Fu ornament. I imagined a decorative object on the wall that could display Fu, time, and weather. I also considered a pull-ring interaction, similar to an old bedside lamp. One pull could show time, another pull could show weather.

That idea was useful because it gave me a clear starting image: a traditional symbol with everyday information. But after discussing it and testing different modules during weekly assignments, I started to feel that the pull-ring was not the strongest interaction for a door object. It made the device feel more like an indoor lamp than a door guardian.

Instructor feedback and turning point

The biggest feedback was that the project needed a clearer interaction scenario. A final project should not only contain many technical parts; the parts should support one strong use case.

So I asked myself:

• Where does the Fu naturally live?
• Who interacts with it?
• What moment should trigger the system?
• What information is actually useful?

The answer was the door. At the door, Fu already has meaning. Visitors already expect to interact with a doorbell or door surface. This helped the project evolve from "a smart decoration that can show information" into a door guardian system that responds to visitors.

How the project evolved

The project evolved through several stages:

1. Decorative Fu object: focus on the traditional symbol and visual style.
2. Smart Fu display: add time, weather, and digital information.
3. Interactive Fu: add a physical interaction so the object can respond.
4. Door Guardian: connect the outside visitor action to an indoor notification and webpage dashboard.
5. Two-board system: separate touch/network logic from the ePaper display control, because the display and communication each have their own complexity.

This evolution made the project more complete. It still keeps the emotional starting point, but now it has a stronger interaction loop.

System Architecture

Main idea

The system uses two XIAO boards because the project has two different jobs:

• The main board detects touch and handles WiFi communication.
• The secondary board controls the 7.3 inch ePaper display and updates the visual state.

Separating the jobs makes the system easier to debug. During Fab Academy I learned many times that when everything is connected at once, it becomes hard to know whether the problem is wiring, code, library, board selection, WiFi, or the display. Two boards give the project a clearer structure.

Hardware roles

Main Board - Custom PCB

• XIAO ESP32C3
• touch sensing input
• WiFi communication
• visitor event detection
• sends state update to interface or secondary board

Secondary Board

• XIAO ESP32S3
• controls the 7.3 inch ePaper display
• receives data from the main board
• changes display state when a visitor interaction happens

Workflow

The basic workflow is:

1. Door Guardian stays in normal display mode.
2. The ePaper shows Fu, time, weather, or calm ambient information.
3. A visitor touches the Fu surface.
4. The main board detects the touch value crossing a threshold.
5. The main board sends a visitor event through WiFi.
6. The indoor webpage dashboard updates from "normal" to "visitor arrived."
7. The secondary board receives the state update.
8. The ePaper display changes to a visitor notification state.

flowchart LR
    A[Visitor touches Fu surface] --> B[Main custom PCB]
    B --> C[Touch threshold detected]
    C --> D[WiFi message]
    D --> E[Web dashboard updates]
    D --> F[Secondary XIAO ESP32S3]
    F --> G[7.3 inch ePaper changes state]

Diagram idea: Redraw this workflow as a clean visual diagram later, using the same red/gold/black visual language as the Fu interface. Caption suggestion: "System workflow from visitor touch to indoor notification and display update."

Input and output relationship

The main input is touch. This is the visitor's action.

The outputs are:

• ePaper display update on the door device
• webpage dashboard update indoors
• optional future notification sound or mobile alert

The important design decision is that the system should not overreact. A touch should create one clear event, not repeated noisy triggers. This means the code needs debounce or state control, similar to how a button needs stable reading. For touch sensing, I also need to test the threshold carefully because humidity, hand size, material thickness, and grounding can all change the value.

Hardware Development

Custom PCB

My PCB work started in the electronics design and electronics production weeks. I designed a board around the XIAO ESP32C3, first as a "Hello World" style board with LED, switch, and expansion headers. At that time I was still thinking about a pull-ring or simple switch input, but the board design process taught me the structure I need for the final project:

• a reliable microcontroller base
• clear power and ground routing
• input pin broken out for interaction
• output or communication pins available for future modules
• enough space for headers and testing

In Week 6, I learned KiCad step by step: schematic symbols, footprints, ERC, DRC, routing, edge cuts, and Gerber export. I also made mistakes. My instructor found a missing ground line, and my first trace width was too thin for milling. I increased the trace width and revised the design. At the time it felt like a small correction, but later I understood that these details are exactly what make a board manufacturable.

In Week 8, I produced the board. I first tried the JLCPCB version, then milled my own PCB in the lab. The JLC board powered up, but the LED and button did not work as expected. I suspected several problems: LED orientation, wrong resistor package, and switch orientation. Instead of forcing that board to work, I went back to the design, fixed the real problems, and made a cleaner milled version.

This process connects directly to the final project. Door Guardian - FU cannot be only a breadboard demo. It needs a custom PCB because the object is meant to be mounted near a door, hidden inside a physical structure, and used as a real interactive object.

Photo idea: Add a close-up of the custom PCB here. Caption suggestion: "Custom XIAO ESP32C3 board used as the main interaction and communication controller."

Touch sensor

The final interaction is touch sensing. The touch surface is part of the Fu decoration, so I need to test both the electronic reading and the physical material on top of it.

The touch input should behave like this:

• In normal state, the touch value stays below the trigger threshold.
• When a hand touches the surface, the value changes clearly.
• The code detects the change once.
• The system waits before accepting another touch, so one long touch does not create many repeated visitor events.

This is similar to my input device week, where I learned that sensor readings are not always clean. With the DHT11, I lost a lot of time because of wrong GND wiring, missing power breakout, loose jumper contact, and pin confusion between D0 and D2. That experience changed how I debug inputs. Now I do not assume the sensor is wrong immediately. I check:

• pinout
• power
• ground
• signal pin
• code pin definition
• serial monitor output
• whether the same code works on a simpler test board

For the touch sensor, I want to follow the same debugging habit: first make the simplest touch reading work on the XIAO, then move it to the custom PCB, then add WiFi, then connect it to the display and web dashboard.

Photo idea: Add a photo of the touch electrode or copper/touch surface test. Caption suggestion: "First touch sensing test before hiding the sensor under the Fu surface."

ePaper integration

The 7.3 inch ePaper display is important because it changes the feeling of the project. Unlike an LED screen, ePaper is quiet, paper-like, and readable without glowing all the time. This matches the calm technology direction.

The ePaper should show different states:

• Normal state: Fu character, time, weather, or a calm decorative layout.
• Visitor state: a gentle message or visual change that means someone is at the door.
• Idle state: low-power, static image, or minimal update.

My output device week prepared me for this part. I tested a buzzer, a 16x2 LCD, and an OLED. The LCD never showed readable text, and the OLED first showed "snow" before I corrected the setup. That was frustrating, but it taught me an important display lesson: when a display lights up, it does not mean the display is working correctly. The library, driver, constructor, board selection, pin mapping, and refresh logic all matter.

I expect the ePaper display to have its own difficulties:

• slow refresh time
• partial refresh artifacts
• wrong driver or display size selection
• SPI wiring mistakes
• power instability during refresh
• image format conversion problems

Because ePaper refresh is slow, the interaction design should respect that. The display does not need to animate quickly. It should change state deliberately, like a paper sign being updated.

Photo idea: Add a bench photo of the 7.3 inch ePaper wiring. Caption suggestion: "ePaper bring-up test, checking driver, wiring, and refresh behavior before integrating into the final enclosure."

Physical structure ideas

The physical structure should still read as a Fu decoration first. The electronics should disappear as much as possible.

Possible structure:

• front Fu decorative layer
• hidden touch electrode behind or inside the Fu surface
• ePaper display placed in the central visual area
• custom PCB mounted behind the front panel
• secondary board and ePaper driver mounted with enough clearance
• back plate for cable management and wall/door mounting

My 2D and 3D design weeks are directly connected to this. In Inkscape I designed a Fu panel with a screen cutout and explored vector tracing. In Onshape I started thinking about the frame as a real object with dimensions, thickness, holes, and slots. During 3D printing week, I learned that a beautiful Fu shape is not automatically printable. My second print failed as a single object because the strokes were not structurally connected. The final successful print needed a continuous base layer.

That lesson is important here too. For the final enclosure, visual lines also need physical support. Decorative cutouts, thin strokes, and mounting points all need enough material behind them.

Embedded Programming

Main board logic

The main board program has four jobs:

1. Connect to WiFi.
2. Read touch input.
3. Decide whether the touch is a real visitor event.
4. Send the event to the webpage and secondary display board.

The code should be built in layers. I learned from previous weeks that jumping directly into the final combined code makes debugging much harder. A better sequence is:

1. Print raw touch values in Serial Monitor.
2. Add threshold detection.
3. Add one-event debounce logic.
4. Add WiFi connection.
5. Add a simple HTTP endpoint or request.
6. Connect the webpage dashboard.
7. Send the same state to the secondary board.

WiFi communication

In networking week, I used two XIAO ESP32C3 boards over WiFi. One board acted as an HTTP server, reading a DHT11 temperature value and serving it at /temperature. The other board acted as a client, polling the server every five seconds.

That assignment gave me the base logic for Door Guardian - FU:

• one board can host or expose a simple state
• another board can request the state
• a browser can also test the endpoint directly
• HTTP is easy to inspect because the response is visible as text

For the final project, the data is not temperature only. It is a state message, for example:

• normal
• visitor
• display_fu
• display_weather
• display_time

The simplest version can use HTTP routes such as:

• /status
• /visitor
• /reset

Later, I could improve this using JSON instead of plain text, because JSON can include more information such as time, weather, visitor count, and display mode.

Debugging communication

One of the most useful mistakes from networking week was the 5 GHz WiFi problem. The ESP32C3 only supports 2.4 GHz WiFi. I spent a long time waiting for connection dots in Serial Monitor before realizing the board could not see the network at all.

For the final project, this means the documentation and testing should always record:

• WiFi SSID band
• IP address
• board role
• server URL
• what response is expected
• what the Serial Monitor prints

Communication bugs can feel invisible, so I want to make each layer visible: first Serial Monitor, then browser endpoint, then second board, then webpage dashboard.

Display logic

The secondary XIAO ESP32S3 controls the ePaper display. It should not redraw unnecessarily. ePaper refresh is slower than TFT or OLED, so the code should update only when the state changes.

Basic display states:

• NORMAL_FU: default Fu page
• WEATHER: daily weather page
• TIME: clock page
• VISITOR: visitor notification page
• ERROR: communication or display error page

The visitor event should update the display once, then wait for reset or timeout. This avoids repeated refreshes if the touch sensor stays active.

Webpage interaction

The webpage dashboard is the indoor interface. It should show the current state of the door device and provide simple controls for testing.

During interface programming week, I made a small web control panel for a round display. The first simple version worked better than the more beautiful version. When I made the page heavier and more styled, the control became unstable. That experience taught me that for embedded web interfaces, reliability matters more than decoration.

For this final project, the first dashboard should be simple:

• current state: normal or visitor
• last touch time
• display mode
• reset button
• optional buttons to test Fu / time / weather / visitor states

After it works reliably, I can improve the visual design.

Interface Design

Calm UI direction

The interface should not look like an industrial control panel. It should feel like part of the same Fu object: quiet, warm, and simple.

Visual direction:

• red and gold as the main cultural colors
• black or warm dark background for contrast
• large readable text
• no unnecessary animation
• one clear visitor state
• simple icons for weather and time

In Week 15, I designed a round screen UI with Fu in the center and temperature, humidity, and weather around it. The Chinese character did not render properly at first, so I simplified to English text to test the pipeline. This was a practical compromise. For the final ePaper version, I can avoid font problems by using prepared bitmap images of the Fu character instead of relying on live Chinese font rendering.

Visitor notification system

The visitor notification should be minimal. I do not want a dramatic alarm. A possible dashboard state:

Normal

• "Door Guardian is calm"
• shows time/weather
• display status: Fu mode

Visitor

• "Someone touched the Fu"
• shows timestamp
• button: "Clear notification"

The ePaper display can also change gently, for example:

• Fu character becomes larger
• border pattern changes
• message appears: "Guest arrived"
• small door guardian icon appears

Minimal interaction logic

The visitor does not need to choose anything. They only touch the surface. This keeps the outside interaction simple.

The indoor user has slightly more control through the webpage:

• check current state
• reset visitor notification
• switch display mode for testing
• see whether the device is online

This split makes sense because the visitor should not need instructions, while the indoor user can access more information.

Weekly Assignment Integration

This final project is built from many smaller Fab Academy assignments. Looking back, each week gave me one part of the system, even when the weekly result was not perfect.

Week 2 - Computer-Aided Design

How it contributed to the final project:
This week gave the project its visual foundation. I used Inkscape to trace and edit the Fu character, explored round and square compositions, and designed an early panel with a screen cutout. I also used Onshape to start thinking about the project as a real object with dimensions, thickness, and space for hardware.

Key learning:
I learned that digital design for fabrication is not only about making a nice image. A vector path has to be clean, closed, scalable, and suitable for machines. I also learned that Onshape is better for structural precision, while Inkscape is better for decorative surfaces and visual composition.

Connection to the final system:
The Fu character is not only a graphic element in Door Guardian - FU. It defines the touch surface, the display composition, and the cultural identity of the device. The early screen cutout also connects directly to the later ePaper display layout.

Recommended media to insert:
Use one image showing the final Inkscape Fu panel composition, such as /img/week02/week02-30.jpg, and one image showing the screen cutout or frame layout, such as /img/week02/week02-9.jpg or /img/week02/week02-28.png.

Caption suggestions:

• "Early Fu panel design in Inkscape. This was the first moment when the traditional character became part of a fabricated interface."
• "Screen cutout study for the future display area, connecting the visual Fu design with the physical ePaper layout."

Week 4 - Embedded Programming

How it contributed to the final project:
Embedded programming gave me the basic confidence to work with microcontrollers directly. For the final project, both XIAO boards need firmware: one for touch sensing and communication, and one for display control. Week 4 was the foundation for writing, uploading, testing, and debugging code on the board.

Key learning:
The most important learning was that embedded programming is very physical. A line of code only works if the board, pin number, wiring, USB connection, board selection, and power are also correct. Serial Monitor became one of my most useful tools because it lets me see what the board is thinking.

Connection to the final system:
The final touch logic, WiFi connection, visitor state, and display update all depend on stable embedded code. The final system will be programmed step by step: first raw touch values, then threshold detection, then WiFi messages, then display state changes.

Recommended media to insert:
Use one representative image from Week 4 that shows the XIAO board connected to Arduino IDE or a simple working output/input test. If there is a short upload or Serial Monitor video, use only one short clip.

Caption suggestions:

• "First embedded programming tests with the XIAO board. This became the base workflow for programming both boards in the final project."
• "Serial Monitor output helped me move from guessing to observing, which is essential for debugging touch and WiFi behavior later."

Week 5 - 3D Scanning and Printing

How it contributed to the final project:
This week helped me test how the Fu character behaves as a real object, not just a flat design. I tried a quick image-to-STL workflow, then a more controlled Inkscape and Onshape workflow, and finally printed a stronger version with a base layer.

Key learning:
The big lesson was that a shape can look connected on screen but still fail as a physical object. My second print came out as separated parts because the Fu strokes were not structurally connected. Adding a continuous base layer made the print stronger and more reliable.

Connection to the final system:
This lesson is directly useful for the final enclosure. Door Guardian - FU needs decorative Fu details, but those details must also survive fabrication, hold the touch surface, and protect electronics. The final structure cannot only be beautiful; it has to support the display, PCB, and mounting.

Recommended media to insert:
Use one image of the failed disconnected print, such as /img/week05/week05-33.jpg, and one image of the successful orange Fu print, such as /img/week05/week05-29.jpg. If the page feels too image-heavy, keep only the successful print and describe the failed one in text.

Caption suggestions:

• "Failed print iteration: the Fu strokes looked connected digitally, but the physical object separated because there was no continuous backing."
• "Successful Fu print after adding a base layer. This taught me how to balance decorative detail with structural strength."

Week 6 - Electronics Design

How it contributed to the final project:
Week 6 was the beginning of my custom PCB work. I designed a XIAO ESP32C3-based board in KiCad with input, output, and expansion connections. Even though it started as a simpler board, it became the base thinking for the final project's main controller board.

Key learning:
I learned the full PCB design flow: schematic symbols, footprints, ERC, PCB layout, routing, DRC, edge cuts, and Gerber export. I also learned from mistakes: a missing ground line and traces that were too thin for milling. These were not just small details; they affected whether the board could actually be produced and tested.

Connection to the final system:
Door Guardian - FU needs a custom PCB for the main XIAO ESP32C3 board. The board must handle touch sensing, WiFi communication, and stable connections to other modules. Week 6 gave me the design process for turning a breadboard idea into a cleaner integrated circuit.

Recommended media to insert:
Use one schematic or PCB layout image, such as /img/week06/week06-15.jpg or /img/week06/week06-20.png, and one revision image showing the corrected trace width or ground fix, such as /img/week06/week06-24.png.

Caption suggestions:

• "First custom PCB schematic in KiCad, using the XIAO ESP32C3 as the main controller."
• "Design revision after feedback: fixing the ground connection and increasing trace width made the board more suitable for fabrication."

Week 8 - Electronics Production

How it contributed to the final project:
Week 8 turned the PCB design into a physical board. I milled the board, soldered the components, checked continuity with a multimeter, and tested the LED and button with code. This was the week when the electronics stopped being only a file.

Key learning:
I learned that production adds many new failure points: board movement during milling, component orientation, solder paste amount, resistor package size, and continuity issues. The multimeter became very important because the continuity beep confirmed that the board had real electrical connections.

Connection to the final system:
The final Door Guardian needs a reliable custom board inside the object. Week 8 gave me the process for producing and validating that board before integrating touch sensing, WiFi, and the display system.

Recommended media to insert:
Use one image of the milled PCB, such as /img/week08/week08-03.jpg, and one image or short video of the board being tested, such as /img/week08/week08-30.jpg or /video/week08-01-video.mp4. Do not include every milling screenshot; one board photo and one working-test proof are enough.

Caption suggestions:

• "First milled custom PCB after revising the design for production."
• "Testing the board with a simple LED and button sketch before using the same workflow for the final interaction board."

Week 9 - Input Devices

How it contributed to the final project:
Week 9 trained me to debug sensor inputs. I used a DHT11 temperature and humidity sensor, but the process was much harder than expected because of wrong GND wiring, missing power breakout, loose jumper wires, and pin confusion.

Key learning:
The key learning was that input problems are often physical before they are software problems. I learned to check pinout, power, ground, signal wire, board pin definition, and Serial Monitor output before changing the code too much.

Connection to the final system:
The final project uses touch sensing as the main visitor input. Touch sensing will also need careful threshold testing, stable wiring, and Serial Monitor observation. Week 9 gave me the patience and method to debug an input until it becomes reliable.

Recommended media to insert:
Use one messy but meaningful debugging photo, such as /img/week09/week09-10.jpg, and one Serial Monitor success image, such as /img/week09/week09-05.jpg. These two images tell the story better than many clean setup photos.

Caption suggestions:

• "Input debugging setup with jumper wires. It looked messy, but it helped me isolate wiring and pin mistakes."
• "Successful sensor readings in Serial Monitor. This same raw-data-first method will be used to tune the final touch threshold."

Week 10 - Output Devices

How it contributed to the final project:
Week 10 prepared me for display debugging. I tested a buzzer, an LCD, and an OLED. The buzzer worked quickly, the LCD failed to show readable text, and the OLED only worked after I corrected the setup and tested it on a simpler XIAO + Grove shield system.

Key learning:
I learned that output devices need both correct hardware and correct software. For displays especially, the library, driver, board selection, communication protocol, and pin mapping all matter. A screen lighting up does not always mean it is displaying correctly.

Connection to the final system:
The final project uses a 7.3 inch ePaper display as the main visual output. The OLED debugging experience gives me a practical strategy: test the display with the smallest working example first, then move it to the final board and final interface.

Recommended media to insert:
Use one failed or debugging image, such as the OLED "snow" photo /img/week10/week10-02.jpg, and one successful display image, such as /img/week10/week10-05.jpg or /img/week10/week10-04.jpg. This shows the iteration without overloading the page.

Caption suggestions:

• "The OLED first showed noisy pixels, reminding me that display problems can come from the wrong driver, board setting, or code."
• "Successful OLED test on my own board. This gave me confidence before moving toward the larger ePaper display."

Week 11 - Networking and Communications

How it contributed to the final project:
Week 11 gave me the communication logic for the final system. I built a simple network with two XIAO ESP32C3 boards over WiFi: one acted as an HTTP server, and the other acted as a client that requested sensor data.

Key learning:
I learned how WiFi communication actually becomes a request-response system. I also learned a very practical lesson: ESP32C3 only supports 2.4 GHz WiFi, so choosing the wrong network band can make the board look broken even when the code is fine.

Connection to the final system:
Door Guardian - FU uses the same idea, but instead of sending temperature data, the main board sends visitor state information. The webpage dashboard and secondary display board can both react to this state.

Recommended media to insert:
Use one image of the two-board setup, such as /img/week11/week11-08.jpg, and one screenshot or short video showing the browser endpoint, such as /img/week11/week11-06.png or /video/week11-01-video.mp4.

Caption suggestions:

• "Two XIAO boards communicating over WiFi. This became the base model for the final main-board and display-board relationship."
• "Browser test of a microcontroller HTTP endpoint. For the final project, this same idea becomes a visitor status dashboard."

Week 15 - Interface and Application Programming

How it contributed to the final project:
Week 15 connected a physical display to a webpage interface. I designed a visual UI direction, tested a round display, and made a simple browser control panel that could change what appeared on the screen.

Key learning:
I learned that interface design on embedded hardware needs compromise. The first simple web interface worked more reliably than the later, more beautiful version. I also learned that Chinese text rendering can be difficult on small embedded displays, so bitmap graphics may be more reliable for the Fu character.

Connection to the final system:
The final project includes an indoor webpage dashboard. Week 15 directly informs that design: first make the dashboard stable and clear, then polish the visual style. It also connects to the ePaper display logic because both need simple states and readable information.

Recommended media to insert:
Use one UI mockup image, such as /img/week15/week15-03.png, and one working web-control proof, such as /img/week15/week15-08.png, /img/week15/week15-11.jpg, or /video/week15-01-video.mp4. If using the video, skip one of the screenshots.

Caption suggestions:

• "Early UI mockup using Fu, weather, and sensor information as a calm visual layout."
• "First working web control page. The final dashboard will use the same simple state-based logic before adding visual polish."

Source code and downloads

Arduino sketches and related source files for Door Guardian - FU live in this repository under sources/. These are relative links so they work in GitLab browse mode and after you clone the repo.

What	Link
Touch input + Grove OLED (combined test)	hello-alison-touch-loed.ino
7.3 inch ePaper bitmap example	Bitmap_07inch30.ino, driver.h, image.h
Week 10 OLED: debug / I2C scan	sketch_may12a.ino
Week 10 OLED: Hello / Alison graphics	OLED-ALISON-light.ino

For Week 10 output-device assignment documentation, see the Week 10 page and its downloadable sketch list.

Challenges and Iterations

Debugging frustration

Many parts of this project look simple in a diagram, but each one has already shown possible failure points in weekly work.

The most common frustration is not knowing where the problem is. When a display stays blank, is it the library, wiring, power, board selection, or code? When WiFi does not connect, is it the password, network band, signal strength, or board support? When a sensor gives strange values, is it a real reading, a floating pin, or a loose wire?

Fab Academy helped me accept that this confusion is part of the process. The solution is to reduce the system until one piece can be tested clearly.

Unstable display issues

I saw several display problems before reaching the ePaper stage:

• LCD black/white screen with no readable text
• OLED showing noisy "snow"
• round display flashing then turning black
• Chinese character rendering problems
• web-controlled display becoming unstable after UI styling

For the final ePaper display, I will expect slow refresh and possible artifacts instead of being surprised by them. I will also prepare static bitmap assets for Fu and icons, so the visual result does not depend too much on live font rendering.

Communication failures

The networking assignment showed that communication problems can be quiet. The board may simply keep printing dots forever. For Door Guardian - FU, I want to design communication debugging into the process:

• print WiFi connection state
• print IP address
• print each touch event
• print HTTP request result
• show dashboard state clearly
• include an error state on the display if possible

This will make it easier to debug when the two boards do not agree.

Balancing aesthetics and functionality

This project has a constant tension: I want it to look like a warm cultural object, but it also needs to work as an electronic system.

If I only focus on aesthetics, the structure may be too fragile, the touch area may be unreliable, or the display may not fit. If I only focus on function, it may become just another smart device with a Fu label added on top.

The best version should let both sides support each other:

• Fu shape guides the touch interaction.
• ePaper supports the paper-like cultural feeling.
• red/gold/black interface connects to traditional decoration.
• custom PCB makes the object cleaner and more integrated.
• calm notification keeps the home atmosphere gentle.

Future Development

There are several directions I would like to explore after the Fab Academy final presentation.

AI greeting system

The system could generate gentle greeting messages depending on time, weather, or festival. For example, on a rainy day it might show a warm message for visitors, or during Chinese New Year it could display festival greetings.

Smart home integration

Door Guardian - FU could connect with home systems such as lights, speakers, or messaging platforms. A visitor touch could trigger a soft indoor light or send a notification to a phone.

Emotion interaction

The device could have different moods or visual expressions. Instead of only "normal" and "visitor," it could show calm, festive, resting, or welcoming states.

Festival-themed Fu display

The ePaper display could change for different seasons and festivals:

• Chinese New Year Fu
• Lantern Festival pattern
• Mid-Autumn moon theme
• winter blessing theme
• family birthday greeting

This would make the device feel alive across the year, not only during one festival.

Documentation Layout Plan

To make the final documentation clearer, I plan to organize the page with a mixture of story, process photos, diagrams, and testing evidence.

Recommended image placement

• Project introduction: concept image and cultural Fu references.
• Idea development: early sketches, instructor feedback notes, old pull-ring idea, new touch-door idea.
• System architecture: workflow diagram showing touch, main board, WiFi, dashboard, secondary board, and ePaper.
• Hardware development: PCB schematic, PCB layout, milled board, soldering, touch sensor test, ePaper wiring.
• Embedded programming: Serial Monitor screenshots for touch values, WiFi IP address, HTTP response, and display state.
• Interface design: Figma/web dashboard mockups and final browser screenshot.
• Challenges: failed display photos, messy jumper-wire debugging, wrong pin notes, communication error screenshots.
• Final result: clean hero photo of the assembled Door Guardian - FU on or near a door.

Caption style

I want captions to be specific, not only "test photo." Good captions should explain what the image proves.

Examples:

• "First touch sensing test, before adding WiFi. The Serial Monitor helped me choose a threshold."
• "The ePaper display refreshed successfully, but the update was slow enough that I redesigned the interaction as a state change instead of animation."
• "Messy but useful debugging setup: keeping the wires visible helped me isolate the touch input before hiding it inside the enclosure."
• "Final dashboard state after a visitor touch: the webpage changes to visitor mode and can be reset indoors."

Diagram ideas

Add three diagrams:

1. System workflow diagram: visitor touch to display/dashboard update.
2. Board role diagram: ESP32C3 main board vs ESP32S3 display board.
3. State diagram: normal, visitor, reset, and error states.

stateDiagram-v2
    [*] --> Normal
    Normal --> Visitor: touch detected
    Visitor --> Normal: reset or timeout
    Normal --> Error: WiFi/display failure
    Visitor --> Error: communication failure
    Error --> Normal: reconnect/reset

Final Reflection

This final project brings together many things I learned during Fab Academy: design, electronics, programming, networking, interface, fabrication, and documentation. But more importantly, it helped me understand how these skills can support one idea.

At the beginning, I thought of the project mainly as a smart Fu decoration. Now I see it more as a conversation between culture and technology. The Fu character carries memory and blessing. The electronics add responsiveness. The webpage adds visibility. The ePaper display adds a quiet, paper-like presence. The custom PCB makes the system more real and less like a temporary experiment.

I also learned that making something interactive is not only about adding sensors. Interaction means deciding what should happen, when it should happen, how strongly it should respond, and what the user should feel. A visitor touching the Fu should not feel like pressing a machine button. It should feel simple and natural.

The most valuable technical lesson is debugging step by step. Almost every weekly assignment included a problem: wrong pin, missing ground, unstable display, wrong WiFi band, bad library, disconnected 3D print geometry, or too-complicated web interface. At the time those mistakes were annoying, but now they form the real foundation of the final project.

Door Guardian - FU is still a work in progress, but it represents the kind of maker I want to become: someone who can connect personal culture, physical form, electronics, and software into one object that feels meaningful, not only functional.