Becoming a new parent is an adventure filled with joy, sleepless nights, and the constant urge to keep an eye on your little one. When my son was born, I found myself concerned about the privacy and cost of commercial baby monitors. So, I embarked on a DIY journey to build a smart baby monitor using a Raspberry Pi. Not only did this project cater to my privacy concerns, but it also turned out to be a cost-effective solution that taught me a lot about electronics and programming.

The Inspiration

The inspiration behind this project was simple: I wanted a secure, smart baby monitor without the hefty price tag and privacy risks associated with retail options. With a background in tech and a passion for learning, I decided to leverage my skills to create a custom solution that could grow and evolve with our needs.

The Components

Here’s a list of the hardware components I used for the project:

• Raspberry Pi (Model 3B, 3B+, 4, or newer)
• MicroSD Card (16GB or larger, with Raspbian OS installed)
• Power Supply (5V 2.5A for Raspberry Pi 3 or 5V 3A for Raspberry Pi 4)
• USB Microphone
• Speaker (3.5mm jack or USB)
• Raspberry Pi Camera Module
• MAX9814 Microphone Amplifier (with Auto Gain Control)
• MCP3008 (10-bit ADC - Analog to Digital Converter)
• DHT22 Temperature and Humidity Sensor
• PIR Motion Sensor (HC-SR501 or compatible)
• Breadboard, Jumper Wires, Resistors, Capacitors

The Setup

Step 1: Setting up the Raspberry Pi

First, I installed Raspbian OS on a microSD card and booted up the Raspberry Pi. Connecting a keyboard, mouse, and monitor made the initial setup straightforward. I ensured the system was up to date with the latest software.

Step 2: Connecting the Camera and Sensors

I attached the Raspberry Pi Camera Module, ensuring it was securely connected to the Pi’s camera port. Next, I wired up the DHT22 sensor, PIR motion sensor, and the MAX9814 microphone to the MCP3008 ADC, which then connected to the Pi’s GPIO pins. This setup allowed the Pi to read analog signals from the microphone and other sensors.

Step 3: Coding the Functionality

Using Python and Flask, I wrote scripts to capture video and audio, read sensor data, and create a web API for real-time monitoring. Flask made it easy to set up endpoints for video streaming, audio playback, and sensor data display.

Here's an example of the Python Flask API

GPIO.setmode(GPIO.BCM)
app = Flask(__name__)
CORS(app)

# Initialize components with config values
camera = CameraModule()
temp_sensor = TempHumiditySensor(Config.I2C_PORT, Config.I2C_ADDRESS)
sound_sensor = SoundSensor(spi_channel=0, spi_bus=0, adc_channel=0)
motion_sensor = MotionSensor(Config.GPIO_MOTION)
speaker = Speaker()

# Initialize the sensor data manager
db_manager = SensorDataManager()

# Initialize the orchestrator with the components
orchestrator = Orchestrator(camera, temp_sensor, sound_sensor, motion_sensor, speaker, db_manager)

# Initialize and start the scheduler
scheduler = Scheduler(orchestrator, Config.POLL_INTERVAL_SECONDS, Config.CLEANUP_INTERVAL_SECONDS)
scheduler.start()

@app.route('/video_feed')
def video_feed():
    def generate():
        while True:
            frame = orchestrator.get_video_feed()
            yield (b'--frame\r\n'
                   b'Content-Type: image/jpeg\r\n\r\n' + frame + b'\r\n\r\n')
    return Response(generate(), mimetype='multipart/x-mixed-replace; boundary=frame')

@app.route('/play_audio', methods=['POST'])
def play_audio():
    audio_stream = request.files['audio']
    orchestrator.play_audio(audio_stream)
    return 'Audio played', 200

@app.route('/sensor_data')
def sensor_data():
    data = orchestrator.get_sensor_data()
    return jsonify(data)

@app.route('/historical_data')
def historical_data():
    limit = request.args.get('limit', default=None, type=int)
    data = orchestrator.get_historical_data(limit)
    return jsonify(data)

if __name__ == '__main__':
    app.run(host=Config.IP_ADDRESS, port=5000)

Once the API was complete I then wrote a simple web app with RazzleJS and Bootstrap to communicate with the API.

Step 4: Ensuring Privacy and Security

To address my privacy concerns, I ensured that all communications between the Pi and my devices were encrypted. I also set up the Pi on a separate network, minimizing exposure to potential security threats.

The Result

The final product was a smart baby monitor that provided live video, audio, and environmental data. I could access the monitor securely from any device within my home network, giving me peace of mind without compromising privacy.

The Learnings

This project was a fantastic learning experience. I delved deeper into Raspberry Pi, Python, and Flask, and learned how to integrate various sensors and modules. It was also a great way to brush up on my soldering skills and electronics knowledge.

Conclusion

Building a smart baby monitor with Raspberry Pi was a rewarding project that combined practicality with learning. For anyone interested in DIY tech projects, I highly recommend trying something similar. Not only can you tailor the solution to your specific needs, but you’ll also gain valuable skills and knowledge along the way. Plus, there’s nothing quite like the satisfaction of creating something functional and meaningful with your own hands.

So, if you’re a new parent with a knack for technology, why not give it a try? Your baby (and your wallet) will thank you!

TreJon House / RaspiBaby · GitLab

GitLab.com

GitLab

In our fast-paced world, convenience has become an integral part of our lives. We constantly seek tools and technologies that simplify our daily tasks, making everything from communication to navigation effortless. The rise of smartphones and the ever-expanding universe of mobile applications has been instrumental in fulfilling this desire for convenience. However, as our dependence on these apps grows, so does the amount of data they collect about us. It's time to take a closer look at this symbiotic relationship between convenience and data, and explore how it has shaped the landscape of app development in the past decade.

As we embrace increasingly robust and intuitive applications, we unwittingly feed them with valuable fragments of our personal information. Apps like Facebook, Instagram, and Twitter meticulously track our preferences, interactions, and even our fleeting interests. They employ algorithms that digest this treasure trove of data to curate personalized feeds and deliver targeted content. While this has become the norm in 2023, it raises important questions about privacy and control over our own data.

Join me as we embark on a journey to explore a different approach to app development—one that places privacy and user empowerment at its core. Drawing from my own experiences in developing a health and fitness app, we will delve into the shift towards privacy-centric design and the challenges it poses. Discover how asking the right questions, reimagining data collection, and empowering users can revolutionize the way we build apps and protect our most valuable asset: ourselves.

According to the history books and my personal experiences, humans are creatures of convenience. We have a rich history of building tools to make accomplishing tasks easier and less cumbersome. In the last decade and some changes, this has been crucial to the survival of the smartphone and the apps hosted on these devices. As smartphones became a more prevalent part of our daily lives, there was a necessity to make the apps exponentially more robust but at the same time intuitive enough for the least tech-savvy users.

To hit these targets designers revolutionized design paradigms, creating beautifully minimalistic user interfaces. Project managers and customer relations conjured up exciting and complex behaviors and features that users love. And then we engineers did the dirty work to make the magic happen. Just so happens the magic we use is your data.

As apps became more robust, the user experience has become simpler, users want the important and most relevant pieces of the app in front of them, and with minimal clicks and taps to get there. To achieve this with relative ease apps both collect and siphon any piece of user data they can get their hands on. Take apps like Facebook, Instagram, and Twitter, as you scroll through content, the app collects what content you interact with most often, how long you stay on a post, and what kind of content you search for, all to feed the same algorithms that populate your feed. In 2023 this isn't new to anyone, we've all done the experiment where we search for a random product on the web, then time how long before we see YouTube ads for said product. But in 2023 this doesn't have to be the case.

Why did this pique my interest?

Those of you who know me, know that I've spent the past two-ish years developing a health and fitness app for Android and iOS. My initial motivation was to develop an app to create and track workouts, suggest meals, track calories and synchronize it with my Samsung smartwatch. It has been a huge passion project of mine, and as I got deeper into development, privacy became a big concern of mine. At the time of initial development, I was working on a team in my full-time role that dealt with locating users in a real-world space. Once the user gave us permission to use their geolocation, we were always listening for changes and updating our services rather our user experience was using the data or not; the justification was to keep the user experience responsive and reduce boot-up time. This never sat right with me. Because a user grants permission, it doesn't mean that data should be collected whenever, especially if it's not in use, but unfortunately, a lot of apps operate this way not just the one I was working on at the time.

A few weeks after some back and forth on my privacy concerns, I listened to a podcast "interview" between Joe Rogan and Edward Snowden. In the episode Snowden, describes his ideal OS and app as one that gives the user the granular ability to track data being collected, network traffic, and the ability to enable and disable each piece of data and traffic being transmitted. At the time I thought of how much work that would involve for an OS or app to cohere to, but at the same time why isn't that the norm. Why is it that users don't control their data, how it's collected, where it goes, and how long it is persisted?

Lucky for me I wasn't too deep into development, and I made a pivot to my app's design and architecture. I wanted to keep as much data on the user's device as possible and treat any APIs' as "pull/fetch" only, and only share the data the user allowed me to, nothing more and nothing less.

How did this change my development?

I had to ask more questions upfront. Instead of synchronizing data with a 3rd or 1st party API, instead, I had to present more forms to the user or lead the user through more prompts to garner the information I needed to drive a particular experience. Once I had the information, I then had to persist it locally (in my case via SQLite) and provide some default experience in the case the information is not known.

Scenario

A user navigates to the screen that displays their weight loss goals, your app needs to display a chart showing their weight over time, the caloric deficit to meet their goal, and suggest meals that fit into their daily caloric needs.

One's initial thought to implement this feature would be to connect to a 3rd party health service (ex. GoogleFit, Samsung Health, Apple Health, Fitbit, etc.) and pull the user's weight data, passive and active calories burned, and then feed that information to an API to fetch recipes that fit the bill. This is a simple and straightforward approach and puts the majority of the work on the 3rd party data providers, and Strong Foundation does, in fact, use this approach but only when the user chooses to connect to a 3rd party provider, and will only request that information in the time that it is needed to drive a particular feature.

But how does that application behave when the user doesn't connect a 3rd party provider? In these cases it defaults to using a 1st party solution that requires the user to give it data, to answer questions about themselves.

With the basic information collected above, we can calculate the passive calories burned on the device, and we can easily collect the calories consumed, and calories burned through similar means, store it on the device, and subsequently fuel the original feature scenario. This solution does increase the code footprint and complexity but it minimizes the data across the wire, and when the user chooses to delete the app, the data goes with it.

The vast majority of Strong Foundation follows the pattern above. A lot of work and research went into finding to calculate and derive values that could otherwise come from a 3rd party source. The pieces of data synchronized (posted to our 1st party services) are highly selective and revolve around sharing content with other users or synchronizing data with the originating source (health data synchronizing with Fitbit, Google Fit, etc.).

Wrapping up

Don't let the list above scare you off of the idea. This list isn't exhaustive of definitive. But the question you should ask yourself is "What is my data worth"? For many years I told myself that my data isn't important enough to be valuable, that if the NSA or some other agency of 3rd party is screening it, then it was a waste of their time. But that just isn't true, especially with the leaps we've made in AI and ML, every piece of data can be marketed, packaged, and sold. Billions of people have their data (collected via smart devices) used against them, and that shouldn't be the norm. More developers are believing in this, and are starting to create innovative and privacy-first apps and experiences that will begin to break into the mainstream.

As apps have been gathering more and more data, there have been a handful of apps out there breaking through the mainstream, showcasing it's possible to build rich user experiences with privacy at the forefront. Both Brave Browser and Signal messaging are the first apps that come to mind when I think of an app that protects my data. Since using them, I noticed a huge drop in targetted ads, and each app is very transparent in how they use my data which gives me a high degree of confidence in them. Is Brave's search engine as good as Google? No, but I don't get fed targeted ads and the results aren't biased. Can I use Signal to message non-Signal users, no, but the people I can message, I know that they are the only recipient of my message. Strong Foundation while still in its infancy, like Brave and Signal, has had privacy top of mind since day 1. We will continue that investment and learn the tools of the trade to continue building a first-class solution that respects what is most precious to us (ourselves and our data). As I continue to refine Strong Foundation and work out (no pun intended) some of the kinks I will share bits and pieces of Strong Foundation's core architecture, to show what a privacy-centric code looks like in the wild.

That's enough ranting for now, until next time

-- Tre

As many of you know Strong Foundation is on a steadfast journey to deliver a world-changing experience. Our aspirations here are extremely high, and we aim to deliver on those goals. We mentioned a few backs that we wanted to build on the fundamental ideas around social media and build SF out to be a social health & wellness platform. In order to provide the best experience to everyone on the platform, we had laid out a rough timeline of changes that must take place to get us there responsibly.

The first milestone we hit that for the most part, many users didn’t experience was the hardening of our backend systems. We invested a lot of effort refactoring and re-writing our backend services to increase security and resiliency to make sure we can be up as much as possible for all our users.

And now we have crossed a second large milestone for SF. A couple of weeks ago we release tablet support for our Android users, and subsequently early this morning we got the approval from Apple, and we released full iPad support. While SF was originally designed and envisioned to be a mobile-only platform, this didn’t fit our model of inclusiveness. So we made a modest investment in trying to understand how tablet users would use the platform, and then re-design our experiences to fit that need. While the re-designs in some areas are not perfect, we wanted to get it out to the community as quickly and effectively as possible, with the promise of continuous improvements for all platforms to build the best experience for the entire community.

With the two biggest milestones completed it’s time we go back to the drawing board to determine what we tackle next to bring the best experience forward. Stay tuned, and stay fit, as Strong Foundation continues to build and become better.

Building a stronger healthier you, starting at the foundation.

For over a year I’ve been working on an app to help me live a healthier lifestyle. The original plan was for it to supplement my Samsung watch’s app, but it quickly grew to be so much more.

Strong Foundation grew to become an app to encompass pseudo everything needed to live and lead a healthy lifestyle. It helps you build define your dietary needs, and meet your weight goals in a strategic manner to help keep the weight off. Need work-out suggestions? SF can automatically build your workouts, or you can have a friend send you one. Need a moment to just digest the day? SF offers a place for meditation and journaling your thoughts. While still incomplete in some areas, I’ve never been more excited to see where an idea can go. I originally had only planned to release SF for Android only, but I got immersive support to release it for iOS. Both platforms have full feature parity and will always be as such going forward.

Thank you to everyone that helped test SF, those who provided feedback, and just let me know they downloaded the app. We still have a lot left to do to get SF where it is we want to be. Stay strong!

You can view the original story here

Strong Foundation

Before we get into the guts of this thing I’ll give you all a little bit of a preamble. I’ve been a physically active person for the greater part of 11 years (when I first started wrestling in high school). Up until I graduated college all of my workouts were hand crafted by one of my coaches, and up until I graduated college this was enough. After I ended my collegiate wrestling career, I also dive mouth first into the life of overeating and not working out enough. For the first few months it was awesome, and I was fat and happy. But over the course of the last year and a half I didn’t like how I looked in the mirror nor the 60+ lbs I put on.

That’s where Strong Foundation (SF) comes into play. In the months I’ve been trying to get myself back into that “good pair of jeans”. While on my journey I’ve tried numerous diets, and workouts. To track all of that I used JeFit to manage my workouts, and Samsung Health to manage my meals, weight plan etc., and I have my pretty cool Galaxy Watch to sync all that data to Samsung Health on my behalf. So what’s the problem?

The problem is, JeFit and Samsung Health are great apps, but I hate having to manage multiple apps to achieve one goal. It wouldn’t be so bad if the two apps shared data so I’d only have to enter data in one and it’d sync with the other, but alas they do not, so I suffered through it a bit and eventually got discouraged from entering data altogether. Yup I’m lazy, it was only two apps, but would a lazy person build their app to get rid of two? Only a software engineer would.

SF is my attempt in writing a micro-frontend based fitness app. My aim is to build a fitness app that will encompass the majority if not all aspects of fitness and health (including but not limited to diet, meal prep, mental health, workout etc.), but allowing user’s to opt-into only the experiences they wish to use. While each experience in itself will be independent of one another, they can work together if the data is there. The secret weapon SF brings to the table is its ability to sync with other fitness ecosystems. SF as it stands today can connect to Samsung Health, Fitbit, and Google Fit.

SF’s ability to connect to these environments was the major motivator for writing this app. I wanted an app that could connect to Samsung Health to easily read data that was synced from my Galaxy Watch, and I could enter data in either app and have them be synchronized. I chose to include Fitbit and Google Fit as they are the other two major players in the fitness tracking game (exempting Apple since SF is Android only at the moment).

Where is SF now? It is currently listed on the Google Play Store in early access. At the time of this writing what can we do?

• Build custom workouts
• Build custom meal plans for every day of the week
• Build a diet to suit your needs
• Create a weight goal with weekly progressions
• Grocery list built around meals of your choosing
• The system can be updated to imperial or metric
• Read various data from Samsung Health, Fitbit, and Google Fit

What’s Ahead?

There’s a lot I want to do with SF, and I put a lot of pressure on it, but if nothing ever comes of it publicly it’s the first app I made for myself that I listed publicly on the app store, so if no one else uses it I will. But here’s what I look to accomplish is the near future:

• Enhance the auto workout generation feature
• Add support for yoga sequences and Tabata flows
• Add workout dictation for yoga sequences and Tabata flows
• Add support for time-based workouts
• Enhance meal prep and recipe management experiences
• Become a Samsung Health partner (so production users can pair with Samsung Health; sorry non-devs)

If any of this has sounded good to you please check out Strong Foundation on the Google Play Store, take a peek at the Kanban and bug board on Taigo to check out features are under development, and let me know what needs to be fixed.

When it comes to writing, whether it be a lab report, email memo, or even these blog posts I have zero idea of how to deliver an intro. I like being direct, but I have this inkling that people enjoy the fluff. However, you didn’t click on this post to read about my poor writing skills, instead you want to know more about my backyard. So let’s begin shall we?

So the title of this post is a bit of a exaggeration, in the sense I don’t have a backyard and haven’t had one since I was in high school living in my childhood home on the Southside of Chicago, and even then it wasn’t very beautiful. But the backyard I’m speaking of today is gorgeous, untapped, jaw dropping, and houses nearly 400 million people. I’m talking about America.

Being raised by a single mother in a “upper middle class” (technically speaking), didn’t award itself many vacations, let alone much travel outside of the city, granted I was fortunate enough to travel across the country in high school through marching band. The traveling I did get to do while I was younger was through a very focused lens, and honestly I did really appreciate it enough.

Recently, like in the last week or so my girlfriend and I moved to the Seattle area from our home in West Allis, Wisconsin. While the majority of people would have taken to the skies and fly in, because we have a pet ferret, we had the luxury of driving. We knew it was going to be a long journey, so did a lot of prep before hitting the road.

Road Trip Checklist

• Download offline maps in case of signal loss
• Hit up Costco for snacks
• Tune up the car (install Android Auto/Apple Car Play)
• Download some baller playlists on Spotify
• Download story based podcasts (We’re Alive)
• Plan out cool sights along the way

Goodbye Wisconsin

The morning of the trip’s start, we finished cleaning our apartment, stuffed the car, hitched the bikes up, and hit Chic-fil-a for that all-star breakfast.

We weren’t more than 2 hours out before we made our first unexpected stop. A gentleman by the name of ‘Steve’ had asked us to pull over. At first I was very skeptical and on high alert as I didn’t know what to expect, and to be honest I was profiling Steve based on his rugged look.

Turns out Steve was a blessing in disguise, and a very nice person. He is a fellow biker, and he had noticed that we had our bikes hitched up in a dangerous way. My girlfriend rides an Electra Townie, and a Specialized Cross Road Sport, both of which are heavier and more awkward than my FX2. Steve noticed that when we had went over a bridge that the bike rack had bounced considerably. This was due to my girlfriend’s bikes sitting quite lower, and in the case of the bridge may have made contact with the bump in the road. Steve had an incident a few months prior when his bike was sitting too low and it dinged the road, and he ended up with some severe damage done to his car and bike. With his help we were safely back on the road nearing Lacrosse onalaska.

Blue Earth, MN

Interior, SD

Keystone, SD

Compared to the rest of the trip, Mt. Rushmore was the least awe inspiring relatively speaking of course, but it was still amazing to see in person. On our way out of the national park we met a very interesting character named Jim.

It was no lie that Jim was a finance guy, and you knew this immediately because all Jim did was spout off numbers, figures, and projections that only a machine could pick up on. I couldn’t tell you what his platform was completely or if he was a farce, but I’ll pass his info along as promised below.

Shell Falls, WY

Wyoming was absolutely breathtaking. Sadly we didn’t plan in our trip to hit Yellowstone, by having our ferret along with us, we were limited to how long a stop could be, based on if it was pet-friendly or if a lot of potential predators were afoot. The parts of Wyoming we did see, however, were gorgeous and terrifying. Terrifying in how remote a lot of it is. I have a couple of friends who love to go snowmobiling up there, and one time their truck’s engine failed on them, and luckily someone was coming down the road otherwise it would have been a long cold walk.

The journey to Shell Falls, was stunning around every bend. We saw huge elk and deer grazing along the edges of camp grounds. Huge stones filled with rich ores; cliffs so sudden that they would intimidate the most seasoned of winter enthusiasts.

Pompey’s Pillar, MT

Bozeman, MT

In Bozeman, we visited the American Computer & Robotics Museum, and if it weren’t for the little one I could’ve spent another hour or more in there easily. Whether you’re involved in the tech industry or not, this place was beyond insightful. It was crazy to see how many great minds it took to produce the machines we use to this very day. The museum was a great end to our trip out west, while we still had another 10 hours to Seattle, we were exhausted, so we rode out the last leg and passed out in our bed. And with that, I’m signing off until next time.