WEBVTT 00:00.000 --> 00:12.000 Hello, my name is Elisie, and today I'll be sharing my swift is the next-spicting 00:12.000 --> 00:15.000 priority. 00:15.000 --> 00:20.200 So in 2016, I got my degree in electrical engineering, and I started working full-time 00:20.200 --> 00:24.200 in hardware design and embedded systems. 00:24.200 --> 00:29.840 While this type of work was really rewarding, I was super interested in learning modern 00:29.840 --> 00:37.520 software development, specifically iOS and Internet of Things. 00:37.520 --> 00:43.240 So Internet of Things is taking everyday objects, connecting them to the Internet, and making 00:43.240 --> 00:46.480 them smarter and more interactive. 00:46.480 --> 00:52.360 Take a simple example, a smart-white that integrates seamlessly with the home app and can 00:52.360 --> 00:59.520 turn on with a motion sensor. 00:59.520 --> 01:03.800 So as I was working full-time as an electrical engineer, my days were spent coding and 01:03.800 --> 01:09.440 see for embedded systems, but at night I was coding and swift, building my first iOS 01:09.440 --> 01:13.080 app. 01:13.080 --> 01:19.920 At the time, these two worlds, app development, and embedded systems felt miles apart. 01:19.920 --> 01:23.760 I remember when I was coding and seeing, and I would worry that a single type of could 01:23.760 --> 01:29.560 crash my program, or even worse, damage my hardware. 01:29.560 --> 01:35.760 That constant learning made swips modern features like type safety, automatic memory management, 01:35.760 --> 01:39.560 and interoperability with C, even more exciting. 01:39.560 --> 01:43.760 Hensing out its potential to bring my two worlds together. 01:43.760 --> 01:50.760 Traditionally, developers have had to rely on languages like COC++. 01:50.760 --> 01:55.200 These precise languages give you full control of the hardware, but that precision comes 01:55.200 --> 02:05.640 with challenges like manual memory management, error prone code, and a steep learning curve. 02:05.640 --> 02:12.400 Now if we fast-load to 2024, embedding swip was announced, and suddenly my two worlds did 02:12.400 --> 02:19.520 just overlap, being intersected. 02:19.520 --> 02:24.280 Embedded swip is a subset of swip, not a variant or a dialect. 02:24.280 --> 02:32.200 So all the code that I write in embedded swip also works in full swip. 02:32.200 --> 02:36.480 Embedded swip brings modern, safe, and scalable code to hardware development. 02:36.480 --> 02:45.120 And today, I'm going to show you how I used it to create a smart light with motion detection. 02:45.120 --> 02:48.480 I started with the matter example in Swift. 02:48.480 --> 02:52.520 This project was featured in the video Go Small within that is Swift. 02:52.520 --> 02:57.160 Today, I'm only going to go over the additions that I made for my motion sensor, but if you're 02:57.160 --> 03:06.600 interested in the rest of the implementation, go ahead and check out the repo. 03:06.600 --> 03:13.120 So my motion sensor detects motion, and it sends a high signal to my ESP 3026. 03:13.120 --> 03:17.480 Then this signal will update the state of the LED to either be on or off, and the change 03:17.480 --> 03:23.600 of flags in the home app. 03:23.600 --> 03:30.520 In this project, I'm using embedded swip, an ESP 3026 board, and motion sensor, and the 03:30.520 --> 03:36.440 matter protocol. 03:36.440 --> 03:46.640 Here's a quick close-up of the circuit for my motion sensor. 03:46.640 --> 04:00.400 I have my smart light with me here today. 04:00.400 --> 04:04.400 I have the ESP code put up, and my program's already running, and you can see the logs in 04:04.400 --> 04:06.800 the terminal here. 04:06.800 --> 04:12.560 So I'm going to do a quick walkthrough of my code. 04:12.560 --> 04:22.240 So the first thing I did was add the driver for my GPIO pin, my inner app headers, and 04:22.240 --> 04:27.880 a matter C++ call that I will need when I'm updating the state of the LED, so it will 04:27.880 --> 04:30.240 sync with the home app. 04:30.240 --> 04:33.520 All of this is in the bridging header in which you enable an operator ability with these 04:33.520 --> 04:38.080 C and C++ libraries. 04:38.080 --> 04:44.640 Now we can move on to the core functionality of my sensor, and motion sensor.swip, starting 04:44.640 --> 05:00.480 in the initializer, I've added two functions, set up GPIO, and set up task. 05:00.480 --> 05:05.500 Set up GPIO, configure my GPIO pin to interface with my sensor, ensuring that it can receive 05:05.500 --> 05:16.180 the input signals when motion is detected. 05:16.180 --> 05:22.520 The second function, set up task establishes a thread safe inner app handler for my GPIO 05:22.520 --> 05:23.520 pin. 05:23.520 --> 05:28.180 So when my inner app fires, my LED will update, ensuring that my sensor responds in real 05:28.180 --> 05:32.020 time. 05:32.020 --> 05:36.580 One thing that I really appreciate about Swift is it's structure to push to air handling. 05:36.580 --> 05:42.260 So for example, if my GPIO pin doesn't configure correctly, or my inner app fails, it will 05:42.260 --> 05:49.140 follow a very specific error, and here's why I set that up for my pin. 05:49.140 --> 05:54.940 I created a custom extension in Swift that defines all of the specific cases that I could 05:54.940 --> 05:57.780 possibly fail in my functions. 05:57.780 --> 06:04.060 So these errors can be handled with Swift's du-catch or a flat blocks. 06:04.060 --> 06:11.300 So scrolling back up to my initializer, if either of my functions have an error, I gracefully 06:11.300 --> 06:14.780 catch the error and restart my board. 06:14.780 --> 06:18.780 This adds to the reliability of my program because I'm effectively handling issues at one 06:18.780 --> 06:21.940 time. 06:21.940 --> 06:26.900 The next thing I need to do is make sure that the LED state is synced with the home app. 06:26.900 --> 06:31.380 So let's go to matter.swift, where I've extended the pre-existing functionality to add 06:31.380 --> 06:35.940 this function, report light state. 06:35.940 --> 06:43.300 So in the state of the LED changes, I use this matter called to make sure that the home 06:43.300 --> 06:49.380 app can stay in sync with the LED. 06:49.380 --> 06:56.620 Wrapping anything up in main.swift, I initialize my motion sensor on GPIO pin 5. 06:56.620 --> 07:03.100 I chose pin 5 because it was one of the available pins that could configure an interrupt. 07:03.100 --> 07:08.740 I decided to use a closure in Swift because it makes my motion detection logic easy to read. 07:08.740 --> 07:16.140 So in my inner of fires, I've set up a callback that will execute the code in this closure. 07:16.140 --> 07:18.940 I have a variable called LED.enabled. 07:18.940 --> 07:24.100 This was already in the implementation, but what it does is turn the LED on and off. 07:24.100 --> 07:28.140 So that's the first thing that I do in my motion sensor detects motion is I toggle the state 07:28.140 --> 07:30.460 of that variable. 07:30.460 --> 07:36.020 And then to ensure the home app stays in sync, I use my report light state function to update 07:36.020 --> 07:41.340 the state of the LED to the current state. 07:41.340 --> 07:48.980 Lastly I built and flashed the program to my board and I have it running in my terminal. 07:48.980 --> 08:14.580 You can see the logs every time the LED state changes. 08:14.580 --> 08:18.180 And that is Swift has changed the way that I do IoT development. 08:18.180 --> 08:21.900 The reduces risk of memory leaks with automatic memory management. 08:21.900 --> 08:27.860 A voice airplane code with built-in safety features and it's easier for me to read. 08:27.860 --> 08:34.300 It's small memory footprint makes it ideal for IoT devices. 08:34.300 --> 08:36.980 But Swift's potential doesn't stop there. 08:36.980 --> 08:43.380 It connects all parts of IoT, embedded, server, and application. 08:43.380 --> 08:48.220 This simplifies development, removes barrier of entry for start-ups, and enables 08:48.220 --> 08:54.180 the creation of efficient, scalable, and user-friendly products. 08:54.180 --> 08:57.300 And that's why Swift is the next big thing for IoT. 08:57.300 --> 08:57.660 Thank you.