Forem: Leif

DIY Holding Tank Sensors Part 2: "The React Native App"

Leif — Fri, 03 Oct 2025 22:25:00 +0000

In my previous article, https://dev.to/mergewithcare/diy-holding-tank-sensors-part-1-or-mommy-the-ai-made-me-code-in-c-4llg , I went over the process of "vibe coding" a working ESP32 app in C using the Espressif toolchain.

I'm going to go over the journey of "vibe coding" out a React Native app to read values from the sensors on the microcontroller as described in Part 1, and as always my code is up at https://github.com/leifdroms/tank-level-public for anyone that so desires to download it themselves.

We are off to a rocky start.

Claude thinks our React Native project structure is incorrect, and asks us to eject the project. I don’t want to do that- I want to build it with the latest snazzy version of Expo, the framework that sits on top of React Native to make things easier. It suggests that we install the package expo-dev-client, and work from there, which I agree with because a limitation of using React Native with Expo Go: Expo Go on its own only allows you to work with native modules included with Expo Go. Unfortunately, a Bluetooth client is not one of them.

…And unfortunately things did not work out.

Each time my bundler would crash, Claude would take some feedback and output something like the following:

There came a point where I stopped auditing each change it made, crossed my fingers, and hoped that it would all sort itself out. This message was the result of the culmination of several changes Claude made without explicitly approving each one as I had been doing for the microcontroller app section of the project:

It was to no avail.

Why are files in my node_modules folder corrupted?? Something isn’t right. Maybe Claude should stick to its “day job” and not try to replicate the function of command line tooling to bootstrap projects, when that tooling is available, mature, and free. I think to myself to pivot at this point, start over from scratch with a proper React Native project, and have Claude do what it does best – work from there. I will take a peek at the app structure as we have it:

And again we have one giant application file that’s about 700 lines of code long as well:

I have finally hit a point where I’m putting on my judgement and deciding to get things done “the traditional way” and bootstrap the app in the traditional means rather than hoping an LLM will replicate this on its own. Maybe someday when context windows and training data is much better, but for now I can feel myself getting into an AI-driven “coding death spiral” and it’s important to notice when you’re going in circles and to pull yourself out. Sorry Claude, I’ll be back to you in a moment.
And now we’re back to sanity, after setting up Expo and the dev client the “normal” way on the command line:

Ok. Let’s let Claude do some of its automagic. I’m in a salty mood while writing this blog entry, so I’m going to make Claude earn its keep today. Before I created a new app with the official command line utilities, I changed the old app’s folder name to mobile-app-backup. Opening up the new app folder and a new Claude instance in the VS Code terminal, the “annoyed Dad” side of me comes out:

At least Claude can pretend to understand my feelings:

Hmm doesn’t look bad after some iteration, although we don’t need the “Explore” tab anymore that came with Expo. Will get rid of that in the next iteration, and probably drop the "tank history" view because it's really not that important.

Which brings up an interesting point - why did Claude put that in there? It just sort of hallucinated a product requirement, and now I have the associated cruft along with it.

Oh no! We can’t connect to Bluetooth!

And unfortunately Claude wasn’t able to get it spinning after a few more prompts. Time for me to get my hands dirty on my own.

After some juggling and coaxing, we’re connected! We have an app that shows tank levels and changes based on sensor input!

But now we have even more questions, like -

Why is it asking me to authenticate with a pin at the beginning, but this seems to do absolutely nothing?!
Why can’t I set an “admin” pin?
Why can’t I change configuration settings on the ESP32 (which was the whole point of an admin pin in the first place)?

Thus we are really starting to see the pitfalls of “vibe coding”. This thing, while completely, wholly impressive and saving me days or weeks, will NOT crank out a production-ready app just by waving my fingers and making a wish.

Let's focus on the bright side though, and maybe I'm being more critical of the phone app/"front end", because that's been the direction my career has taken the past few years.

Mid-way Conclusions

I was able to go from zero to a working microcontroller and companion phone app that would serve my purposes well in about 2-3 days. This is insane and my mind is still a little blown. The initial product WAS pretty rough and nowhere near production grade, and required quite a bit of human intervention, but I was particularly impressed with how AI was able to handle the embedded/C code. This was a huge weight off my shoulders since it is out of my usual comfort zone, although upon inspection it appears fine without memory leaks. Like my other “vibe coding” project on my blog thus far, the overall risk surface area is pretty low and in fact lower for this project since there’s no exchange of secret keys other than a PIN number over Bluetooth, and this would require a hacker being within about 30-90 feet of the RV while the PIN was being sent sniffing the Bluetooth traffic somehow, just to have the privilege of turning off tank monitoring for that particular bank of tank sensors (grey, black, or both). The obvious way to mitigate this risk would be to set the pin making sure that nobody is within about 30-90 feet of you while setting the PIN.

In a future iteration I may implement encrypted Bluetooth traffic, but for now it’s just fine.

And On To Encryption
I declared the future to be NOW and that I was going to implement encryption, so we're going to journey back for a moment into microcontroller land in C.

Claude gave me several options as far as implementing encryption, and I picked #1, “MITM” (“Man In The Middle”) protection, being the most secure. Changes were made and I rebuilt the app, but when connecting on my mobile app…there was no dialog that popped up for pairing. I asked Claude about this and:

Now. At the end of the day, this would only be a problem in my app if someone nearby sniffed my Bluetooth traffic to get my admin PIN, and then was able to turn off my tank sensors, which I trust completely at this point, and then allow my sewage tank to overflow leaking human waste everywhere. Ok, that probably wouldn’t actually happen since it would be apparent I’m reaching the top of the tank when using the restroom, but it’s an unpleasant thought.

Point I’m making, is if I was working on an application where I was truly concerned about security, I’d be really, really concerned right now! Claude, we have some trust issues to work on.

Now, I’m feeling lazy again, so let’s go back to React Native land and see how much of this we can vibe code, starting with refactoring the app to use a global context with a reducer function rather than having state management all reside in index.tsx and be dependent on that component (or at least through prop drilling which isn’t how the app is setup).

WHAT THE HECK HOMEY! AHHH! LAST TIME I TRUST YOU TO IMPLEMENT A GLOBAL CONTEXT WITHOUT ADULT SUPERVISION!

In fact, maybe it’s time we got a second opinion. On a suggestion from someone else, I installed Codex, OpenAI’s answer to Claude Code, fired it up in my IDE, and posed a question:

Well goll-ey. Doesn’t seem like bad advice at all.

Going back to Claude Code, and purposely introducing it with a hostile tone (per someone’s suggestion), I asked Claude Code:

Claude disagreed with me. At least I know now it will give me honesty, even when I need to hear it:

And one more prompt just to be sure it wasn’t a fluke:

To which Claude Code replied:

And Codex isn’t budging:

And Claude Code backtracks:

Now let’s examine reality, shall we:

Indeed. Claude Code was complaining about nothing, and “subscription” is provided as a ref in the global context.

Codex, you get to refactor everything.

Now will you suggest more when running on the command line rather than in the sandbox? Indeed!:

Well. That’s a mouthful. But go for it. I agree, we shouldn’t duplicate the functionality of our code base if we can avoid it.

…15 minutes later, it finished. This seems a lot slower than Claude Code, but whatever. No red errors popping out except for one- that’s a good sign:

Just a little Typescript boo-boo! All better now:

Things seem ok for now, so why not write some tests?

Oh no they’re failing! And failing! And each time I prompt Codex to fix it, it tries to catch the error when maybe we should be asking it a question:

And…

Well, better:

But we’re still not having passing tests.

Hmm. We seem to be having a memory leak when mocking these components.

Welp, let’s hope the AI isn’t just trying to be agreeable.

But we’re still failing tests. Maybe it’s time to close the window and create a new one with ample context.

And now we’re passing, hooray!

Conclusions and Final Thoughts

What grand wisdom have I gleaned from this…thinking…thinking…

I wish I had code snippets and proof for all of my thoughts here, and maybe I will go through that effort in future blog posts (if anyone cares), but I decided I wasn’t going to be so methodical on a personal project. In that regard, I apologize for lack of objective proof for any statements going forward, but convince me it’s worth my time and I will do so in the future.

As I sit here and gather my thoughts on the experience of creating an embedded app for a microcontroller in C that relies on Bluetooth to communicate with a React Native phone app within a couple weeks time, part-time (!!! YEAH!), I feel it’s necessary to highlight just how COOL this is.

If I had to judge based on the output, what I was able to do with my time probably would’ve taken a team of developers about 3-4 weeks, so I’m thinking roughly two standard sprints worth of time, to accomplish.

The code itself probably would have been functional but a lot rougher; there wouldn’t have been such neatly memoized functions and abstracted classes and libraries and so on.

Security for the Bluetooth would have been much simpler.

In other words, the Ais supercharged my output as one single developer and allowed me to come up with gorgeous code closer to the speed of my thoughts and wishes, as a sole developer, rather than at the speed of programming things by hand. This is assuming familiarity with the various components that I had zero familiarity to begin with, such as programming with the Bluetooth stack, which the AI shaved off several days or weeks for me in pouring through documentation and deciding which parts were relevant.

At the end of the day though, it still took ME, a “real human”, to stand over the AI generated code and come up with a judgement of whether it smelled right, whether it was overengineered for the application (A DIY hobbyist liquid level sensor where there is no risk to life or finances if it doesn’t work properly), and whether it actually did what it intended.

A lot of it was wrong. A lot of it was unnecessary – I don’t need to know what the readings of the sensor were 5 minutes ago or at 3 am while we were sleeping vs. now; I just need to know if I can use the sink or the restroom without overfilling my tanks when I use the sinks or the restroom. For some reason Claude Code decided this was necessary and threw it in there, and it was up to me to take it out.

I was thoroughly impressed with Codex’s ability to analyze documentation and create clean, elegant, testable and readable code, but also found it creating code that looked wonderful, but actually failed in its objective at optimization: there was one spot where it memoized a function to only run when the black or grey tank sensor levels changed, which should save a re-render if non-UI related state variables change independent of this, but it was constructed in a way that it would still re-render on every state change…because it ingested the entire state (rather than just those two values). In addition, the memoization itself added a small performance penalty, so in essence…the performance was probably negligibly worse.

I do give lots of credit for Codex for thinking to do a memoization in the first place, which if I’m being honest, I probably would have skipped, because this is a personal project I’m not getting paid for, I’m not trying to actively maintain it for 10 years, I’m not passing it to other developers, and I have a vested interest in getting out “something that just works while I’m on the road” and don’t personally care if there’s a slight inefficiency in renders, for example.

I think this is the biggest value add of AI going forward though – the excuses to NOT push clean, elegant, and efficient code, going forward, are going to be wearing extremely thin. Used with care rather than blindly trusting the output of the LLM, we are entering an era where the gap between publishing really gorgeous code vs. “do it dirty and on time” is becoming very narrow.

I ridiculed “vibe coding” at first because it threatened me, I still ridicule it when the term means people pushing code to production that hasn’t been vetted and is the result of a non-coder beating up LLM prompts until it “looks right”, but now I find myself very optimistic going forward that AI will allow me to accomplish what I never have been able to on my own: to create things, really, really useful things, closer to the speed of my thoughts and creativity.

All of the boxes of unopened crap I have in my garage, the piles of microcontrollers and electrical components and this and that and the other that I bought once thinking I’d find the time to learn how to use it, might actually be put to use going forward.

I’m ecstatic and I can only hope my thus-far extremely patient wife will be so as I empty out the garage and actually make use of the things collecting dust in there.

Regarding which tool is the “best” right now, I can say that I will be likely reaching for Claude Code when I want it to accomplish the “quick and dirty” and test a feasibility of an idea, and Codex when I really want to hone something down and consider multiple angles.

This might already be outdated advice to myself, because people are hyping Claude Code’s model that was released a few days ago, and I greatly look forward to seeing how THAT compares to Codex! I just have to make sure no matter which tool I use, that if I find myself and the AI “going in circles”, to close the current context window and reopen a new one, and pray that this takes us out of an AI-driven "coding death spiral".

If you got this far, I strongly encourage you to download the code posted in the repo at the top of the blog entry, and let me know if you love it, hate it, or are indifferent. I’m looking forward to people tearing it to pieces so please do your worst.

DIY Holding Tank Sensors Part 1: Or "Mommy, the AI made me code in C"

Leif — Wed, 01 Oct 2025 01:04:40 +0000

All code up at: https://github.com/leifdroms/tank-level-public

Microcontroller code in the /esp32 folder.

Intro

Having made myself ~~$100~~ $200 poorer by signing up for a month of a Claude Pro subscription to start evaluating Claude code, it was time to really put it to the test. I had success “vibe coding” a simple app using ChatGPT to read input from a GPIO pin hooked up to a touchless liquid level sensor on an Esp32-WROOM-32 development board I had sitting around, and it was time to scale things up to do something really useful: build a touchless liquid tank level sensing system for my RV wastewater holding tanks that would communicate over Bluetooth to give readings to a companion phone app.

Background
Anyone that owns or has owned an RV knows the struggle of accurately reading their grey and black water holding tank sensors is real. For anyone that’s unfamiliar, most RV’s contain three tanks: one for fresh (potable) water to supply water to the faucets and shower while boondocking (camping away from a water faucet), a grey water tank to collect the wastewater from the sinks and shower, and a black water tank that directly connects to the toilet. While more sophisticated systems exist to properly read the tank levels, they’re not cheap, on the order of several hundred dollars, and I haven’t rolled the dice with them because their interface is stuck in the early 90s: LED and hardwired only, with one exception that offers a Bluetooth model, but users complain of “sensor drift” over time and other inaccuracies. Most of us RVers are stuck relying on a system to detect waste tank levels that’s archaic and unreliable: 4 metal probes are screwed into the sides of our waste holding tanks, that when the waste liquid level rises to meet the lowest probe and 1-3 of the probes mounted above it, a simple circuit is formed with the probe in the bottom of the tank, and 1-3 of the probes above it, and a display located in the living area of the RV will display whether the tank is “1/3”, “2/3”, or “Full” depending on which probes are connected together by the conductive liquid connecting them (wastewater).

Now why are these sensors notoriously unreliable, you ask? Well, if you have ever cleaned out a toilet or a sink drain, you are aware at how quickly a truly disgusting, and electrically conductive biofilm can form. Once that forms, or something else causes a “short circuit” like toilet paper bridging two sensors, you end up getting false readings. Ways to deal with this involve chemical treatments that aren’t cheap and not always effective to break up and release solids and films, or a series of “sprayers” you either put down the toilet attached to a garden hose through the window, or installed into the side of the holding tank, that hopefully clean things out and prevent false readings on the sensors.

I personally couldn’t stomach the idea of passing a nasty hose connected to a nasty sprayer through my living area and hosing out my black tank that way, so I installed a tank sprayer into the side of the tank. While it does seem to help a bit, my black tank still seems to be perpetually stuck at reading at least 2/3 full, even after I’ve gotten rid of everything in there. My grey tank doesn’t like to drop below a reading of 1/3 full, even if it is completely empty, due to the thick biofilm that has likely developed inside of there. I have completely replaced the sensors, twice, but quickly false readings crop up and we more or less judge when to dump the tanks based on personal experience of how many days and/or showers we can go before filling the tanks up. And then there’s the anxiety that we’ll overdo it one of these days and have nasty shower drain water (or worse) crop up into the RV.

So. Now that the reader knows more about RV wastewater than they ever intended, or if they are an RV-er themselves the rumblings of PTSD are starting to creep over their spine, we ask: “What if there was a nice “Do-It-Yourself” solution I could come up with, where I knew exactly how it worked, I had access to the source code because I wrote it, and if any part broke down, I could easily find a replacement one that wasn’t manufacturer-locked?” This solution would have to be a “non-contact” so any sensors would not get fouled up by waste and solids in the holding tank. Fortunately, “non-contact” sensors, already bundled into simple packages that either turn “ON” or “OFF” a wire when connected to a power source and can be easily read by a microcontroller like an ESP32, are cheap and plentiful on Amazon.com or Alibaba.com. Their operation is simple: a fluid like wastewater coming near the sensor changes the capacitance of the circuitry, which is easily detected and tripped. Three sensors per tank would give a resolution of “1/3”, “2/3”, or “Full”, which is adequate for the application; there’s no need to know that exactly 54.2323% of your grey water tank is full. Just a ballpark figure of when it’s time to move on.

Stumbling Blocks
Why not try and build one? Well, I’m no expert in C (or a variant), which is a necessity when working with microcontrollers, but, since we’ve entered the “vibe coding” area, why not give it a whirl? The phrase “liquid courage” is used to describe someone who feels much more confidant in their abilities after drinking a couple units of alcohol, and it’s high time that we recognize “vibe courage”, because it’s a thing. On this wave of vibe courage, I gave Claude code a ridiculously complicated prompt, using the Opus 4.1 model:

It thought for a while, and was happy to announce its progress:

Pretty cool. Let’s hope.

Ok, the initial folder structure looks ok:

But oh my, we’re getting the red squiggles in Vs Code:

And…it looks like nothing is set up as a properly configured ESP-IDF project that will actually build. Maybe it would have been a better idea to set up a separate project first using the ESP-IDF VS Code plugin and their “new project wizard”, but I digress. Here we are.

After some prompting and playing around, the file structure looks a little more realistic:

But sadly,
Still red squiggle city.

Well, ok then Claude Code.

Oops. Didn’t compile. Errors.

Yes, please, get rid of the unnecessary variables that are causing the compiler to not compile.

Fingers crossed…and it builds! And Flashes! Holy smokes, when I put my finger next to the sensor to trip it, seems to be working!:

But alas, still have those red squiggles. Hmmm.

After prodding Claude a bit and it making suggestions to some IDE configuration files, my squiggles are gone! I’m not thrilled with Claude Code’s approach of everything being in a nearly 700 line main.c file, so I asked Claude politely to backup main.c and do a refactor.

And we’re more organized, but oof looks like ble_gatt.c, the file necessary for setting up how the microcontroller sends its data over Bluetooth, is unhappy.

Prodding Claude several times on the command line to inquire about the line with the red squiggles.

Claude’s explanation of why seems to make sense:

But now it won’t build:

When asked why and what changed in the refactor:

I suppose Claude Code is more human than I thought, it even forgets to include headers when refactoring.

The build then failed, but after cleaning the build folder with the “Full Clean” command in the ESP-IDF extension, …we’re still failing. Oh. It had a naming conflict and named two functions “config”. Ok cool. Fixed that.

It built and uploaded to the ESP32! Hooray!

Now this wasn’t without issues. I installed a BLE Utility on my Mac (LightBlue), connected to the ESP32 over Bluetooth, and every time it tried to read the data it would throw an error. Prodded Claude a bunch, and it decided to abandon its approach of storing the sensor values in the Bluetooth stack database, and rather directly send them via a callback. Then it started working:

Which is slightly funny. I wonder why Claude decided to store readings, which changed all the time, in the database and then create a response calling on this data, and it responded it was slightly more efficient as far as the CPU goes. Not sure if this reasoning is accurate or a hallucination meant to please me, but the code is working now, I’m reading hex values over Bluetooth, and I’m feeling very happy.

Security
In my original prompt, I had told Claude I wanted an optional PIN number implemented. Of course, it didn’t do anything other than setting a password called “AUTH”. I decided that a PIN number shouldn’t be necessary to read values, since I wasn’t that concerned about some weird person going near my campsite with a Bluetooth sniffer and discerning how much human waste I had in my holding tanks, but since there are some real odd people that show up where RV’s can be found, that it would be a good idea to have a PIN in order to set configuration settings on the ESP32 (so far, the only settings in mind being whether or not to enable the bank of black or grey tank sensors, as well as setting/resetting the PIN itself). It took some wrangling but Claude and I eventually made it work.
Additionally, while the original version merely reported what the level of the tank was at (1/3, 2/3, or Full represented by the integers 1,2,3), I decided to report raw sensor data along with tank levels to the client app – this way I could add in code to detect an abnormal condition, like the “full” sensor was registering but the 2/3 level sensor was not, indicating a potential problem with the 2/3 sensor because on planet Earth with its gravity, the adage “s*** always runs downhill” holds true. In other words, it should be impossible for the “full” sensor to register without 1/3 and 2/3 both indicating their level as well.

Refinement

Lastly, instead of having to buy another momentary on/off switch in order to rig it to a GPIO pin in order to reset the PIN number (or do something like upload new firmware whenever I wanted to reset the PIN number), I decided to have Claude rig this to the “BOOT” switch on the ESP32 development board. It took some finagling and trial and error, but Claude eventually got the right GPIO pin, and I was left with a nice little working package where if a user held down the “BOOT” switch for 10 seconds it would reset the PIN code back to “000000”.

Oh, and now the README file was inaccurate. Fixed that.

You can lead an AI to a prompt, but you can’t force it to pick the right Bluetooth stack.

One last point of contention – it looks like Claude ended up using the Bluedroid stack to implement Bluetooth, rather than the smaller and more lightweight “NimBLE” stack, but I don’t really care. The package compiles, it fits onto my development board’s memory, and seems to run great.

I went through everything and while I am no expert in C, it looked fine, and all variables and pointers were on the stack rather than the heap so I didn’t have to be concerned about long-term heap corruption after I let it run for months or years on end off my RV batteries.

Euphoria

At this point, I am ecstatic. I have a fairly professional little ESP32 package that reads tank sensors and reports them over Bluetooth. Even if I didn’t develop the phone companion app, I could still read tank levels using a Bluetooth sniffer and interpreting the hex string sent to Bluetooth to indicate tank levels. All in a nice, neat DIY package where I know exactly how it works and can fix on the road as needed.
Our little mobile home on wheels now allows us to function just a little bit more like we do at home, without guessing our wastewater levels.

I feel…human again. Thanks to a happy robot in the cloud named Claude.

Now in the next blog entry, on to the React-Native companion app...

More Adventures in Vibe Coding...

Leif — Thu, 04 Sep 2025 22:32:44 +0000

It looks like the LLM totally forgot to actually do anything with the Apple Watch background scheduler and I didn't catch this on the first iteration. And this is why we need to check, check, and check again every line we "vibe code":

import WatchKit

class ExtensionDelegate: NSObject, WKExtensionDelegate {
    func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {
        for task in backgroundTasks {
            switch task {
            case let backgroundRefreshTask as WKApplicationRefreshBackgroundTask:
                Task {
                    print("Performing background refresh for TempStick data")
                }
                backgroundRefreshTask.setTaskCompletedWithSnapshot(false)

            case let urlSessionTask as WKURLSessionRefreshBackgroundTask:
                urlSessionTask.setTaskCompletedWithSnapshot(false)

            default:
                task.setTaskCompletedWithSnapshot(false)
            }
        }
    }
}

chmod a+x ./facepalm.sh; ./facepalm.sh

**Note: there is no actual shell script in the app called facepalm.sh

import WatchKit

class ExtensionDelegate: NSObject, WKExtensionDelegate {
  func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {
    for task in backgroundTasks {
      switch task {
      case let backgroundRefreshTask as WKApplicationRefreshBackgroundTask:
        Task {
          defer { backgroundRefreshTask.setTaskCompletedWithSnapshot(false) }
          print("Performing background refresh for TempStick data")

          await WatchModel.shared.fetchAllReadings()

          WatchModel.shared.scheduleBackgroundRefresh()
        }

      case let urlSessionTask as WKURLSessionRefreshBackgroundTask:
        urlSessionTask.setTaskCompletedWithSnapshot(false)

      default:
        task.setTaskCompletedWithSnapshot(false)
      }
    }
  }
}

That's better! Now we should actually be scheduling background tasks in the Apple Watch, which is important...because for battery purposes and so on, Apple doesn't let you arbitrarily run long running processes in the watch (like continuously polling our temperature sensors) in the background; at most you can "request" a background task lasting no more than a few seconds is executed at a given interval and the watch will decide whether or not to let it happen. Currently configured to try at the max given interval specified in the user settings per sensor.

Code fixes pushed to public repo https://github.com/leifdroms/TempStickMonitor-public. Thank you for listen to this public service message.

"Vibe Grokking" My Way Into an Apple Watch App

Leif — Wed, 03 Sep 2025 23:08:57 +0000

Tl;dr:

I needed an Apple Watch app to check the temperature sensors in my RV while my dog was in there, which didn’t exist. The company that made the sensors (TempStick, https://tempstick.com) graciously opens up their APIs to developers, so you can build your own software as needed. The only problem? I don’t know SwiftUI and there’s no cross-platform JavaScript/Typescript library to build watch apps that I’m aware of - you HAVE to do it in Swift. I heavily relied on partial “vibe coding” to get a prototype down, and am pretty happy with the results, although uneasy about potential security problems I don’t know to catch due to lack of experience with building Swift apps, although this is balanced against the low-risk nature of the project itself.

If you would like to work with me, please reach out - I’m always looking for new opportunities, primarily in the JS/TS domain, but am happy to branch out. Pictures of the doggie doing what she loves to do, which is sleep on the travel trailer couch, for the algorithms. I am not paid by the TempStick company but it’s not for lack of trying; unfortunately their paid affiliate program is not accepting new applicants at this time but I’d love to pump their product and get a commission.

Link to public github repository with the Apple Watch and companion iOS code:
https://github.com/leifdroms/TempStickMonitor-public

Intro:

Whew! What a journey this has been, “vibe coding” my first Apple Watch App and companion iOS app.. Well - not entirely. I didn’t exclusively beat up an LLM with prompts until I had a fully functioning Apple Watch App loaded onto my Apple Watch, but I did manage to use Claude and ChatGPT to get things going and prompt as needed to fill gaps in my knowledge, and the end result is a fairly simple, but functional Apple Watch app that does exactly what I wanted it to do. And some more - which was unnecessary, but harmless (I will dive into that).

Background:

My wife and I love traveling in our travel trailer and are not afraid to admit it. It provides most of the comforts of home, and our extremely lazy, chunky dog “Luna” (pictured above, hiding under a blanket) is more than happy to curl up on the RV couch for a nap with either the air conditioner or the heat pump going if we are out and about without her (no, we don’t burn propane in the furnace with her alone in the trailer - it gets shut off when we’re away for safety).

Which brings up some issues of safety. For those who are unaware, most RV’s are just plywood boxes, maybe with some aluminum siding, with minimal insulation and a rubber roof. It doesn’t take long if the air conditioner or heater fails for the inside to either get dangerously hot or cold depending on the weather, either through an equipment fault or power loss where we are staying. As a measure for peace of mind, like many RV-ers with pets, we keep temperature sensors in the RV which monitor and report environmental conditions inside the vehicle back to the cloud, which we can then check with our phones, and are programmed to give SMS and app alerts if something is amiss so we can rush back and take care of it before the situation gets dangerous.

Because I tend to be a paranoid person, we were as until recently running 3 different temperature sensors in the trailer: two by one manufacturer, TempStick (https://tempstick.com), which I built the Apple Watch app for and will get into in a moment, and another by a competitor that shall remain unnamed. The problem with the competitor’s sensor is that the subscription was very expensive for what it does (report temperature and humidity to the cloud), compounded by the fact that it relies on an internal cell modem, whereas Tempstick monitors are Wi-Fi only. Now, that would normally be a feature, not a bug, but as mentioned before, the siding on our RV is aluminum, which functions as a makeshift Faraday cage blocking cell signals pretty well, and the competitor’s temperature monitor has no place to attach an external antenna. At this point, the “Wi-Fi” only monitors are actually more fail safe in our situation, since I have attached an external 4x4 MIMO cell antenna to the roof of the RV to circumvent the signal blocking effects of the external aluminum siding, plus our travel router not only connects to cell towers, but has the feature of allowing backup WAN sources (Wide Area Network; i.e. connections to the Internet) to function in the case of a failure of the primary WAN. Most of the time we stay at a campground or park with some rudimentary, weak, and overloaded free Wi-Fi, but offering more than enough bandwidth for sensor uploads to the cloud as a backup. If that’s not available, we also have our Starlink we can set up which would also offer more than enough bandwidth for these purposes. All in all, at this point, there is not as much value in a “standalone” device with its own internal cell modem given our current setup with multiple fail-safes to provide internet access to our devices. Except for one thing the competitor did great that unfortunately TempStick has not implemented yet: An Apple Watch App to check sensor information.

Normally, there is no issue because I’m usually near my iPhone and can check the monitors anytime, but while doing things like swimming or tubing (as we love to do in the hot hot Texas heat), my phone is usually stashed in a pool locker or back at the truck, and I like to check in on the RV every half an hour or hour just to be safe. Not to mention, the less I pull out my phone while hiking with my wife, the less annoyed she is by all the distractions it offers that inevitably suck me in, which an Apple Watch is not quite as overloaded with. In these situations it would be very beneficial to have an Apple Watch app so I could check in on the RV right on my wrist, but sadly TempStick hasn’t implemented one yet, and didn’t have immediate plans to implement one after contacting them.

I did have the sensors configured to send alerts in case things went awry, and in testing I did in fact receive these on my Apple Watch, but I would only do so if something was wrong. I didn’t want to only get notified if something was wrong, but also to have the power to check that everything was alright and functioning properly. Not to mention, I frequently pause alerts when the trailer is unoccupied and sitting on the storage lot, and while I try to remember to turn them back on, I am human and sometimes forget.

Which leads us to the interesting part of this blog post: “vibe coding” to get this project done.

Well, not purely vibe coding, I suppose. I did look over the first 2 weeks or so of Paul Hudson’s excellent and free course, Hacking with Swift UI (https://www.hackingwithswift.com/100/swiftui), so I would have SOME understanding of what the code was doing and the concepts that were unfamiliar to me coming from a JS/TS background. Additionally, while the definition of “vibe coding” is not solidified in popular culture yet, I’m going to define it somewhat strictly and as “completely divorcing yourself from the code, allowing the LLM to handle everything, only supplying the prompts, and stopping when the results match what you intend”. I did not strictly do this, and to the best of my knowledge I could not do this at this time, because there’s no LLM that’s hooked up to fully release an Apple Watch app that I’m aware of like there currently are to release Web apps and handle all of the supporting infrastructure. But, credit is due where credit is due, so I’ll call what I have been doing as “grokking with vibes”, because that’s how I perceive it: using the LLM’s to get started, iterate from there, intuitively make my way through the code based on heuristics, and when the thing fails to compile, asking it for its opinion on what to change.

While I did not document every detail of this journey, it’s been an interesting one and I’ve had some take homes from it, in no particular order of importance:

Vibe coding has been a great starting point when coming out of my “comfort zone” and doing something I haven’t done before in earnest- Swift development. Outside of tweaking some configuration files and installing libraries via CocoaPods in Xcode to make a React Native project work, I was nearly completely new to the idea of poking around in Xcode to build something, and certainly completely new to developing an Apple Watch app. Plugging in your requirements into ChatGPT or Claude and saying “now build me an Apple Watch App” is a great way to jump off, and probably saved me several months of churn as I developed into a real SwiftUI developer, which was great, because - at this time I don’t have a need to be a “real” SwiftUI developer. I need to fake it well enough to develop one Apple Watch app for personal reasons, and probably won’t need to develop another Apple Watch app again, or at least for a long while. And now I have my watch app, without having to take time to become an expert.

Vibe coding is great to get a sketch of an idea and build on it, but relying on it completely would lead me into complicated loops of prompting the AI that were completely unnecessary. I was able to understand when this was happening based on my previous coding experience in other languages and frameworks, stop what I was doing, analyze the code and realize, “oh, this is simple, I just need to pass in a dictionary rather than converting it to an array like the first iteration of the AI was attempting to do”, but if I had no clue what any of this meant because I had never programmed anything and was unfamiliar with the concepts, I’d likely be stuck in these frustrating loops for days before eventually giving up (or paying someone to fix it if the end result would potentially make me money).

When deciding to build something where I knew “just enough” to get it going, security was in the back of my mind. Frequently with “purely vibe coded” projects done by people with zero coding experience, major security problems are introduced, including but not limited to leaking sensitive credentials like API keys in cleartext in the final product, configuring databases with no security, and so on. The worst secret that could get leaked in this project would be my sensor API key, which could potentially allow a hacker to see what the temperature and humidity in my RV is, or change my configuration without my consent, deleting sensors, etc. Both of these situations would be “pretty darn annoying” but neither would potentially ruin my life and could be rectified by creating a new account with TempStick to get a new API key, or contacting customer service. Since my sensor lacks a GPS receiver, I’m not running the risk of some weirdo hacker tracking my movements. That being said, I did look at the code that Claude/ChatGPT spat out, and did my best to decide whether or not it “made sense” and was reasonably secure for what I was doing; the LLM’s had made the decision to store the API key in secure Apple keychain storage and their implementation of this looked ok to my eyes. Additionally, I did check to make sure that communication between the iPhone app and the Apple Watch app through Apple’s Watch Connectivity framework is secure and encrypted (https://support.apple.com/en-in/guide/security/secc7d85209d/web). I’d say the biggest glaring loopholes to security that I was able to spot were pretty obvious: after developing, it was important to erase any calls to “print()” that would output credentials to the debugger. If someone had absolutely no clue about programming they might not catch this and it could be a problem.
Frequently, the LLM would do something I was unfamiliar with, and it was useful to prompt it to ask “why” it was doing so. For example, when implementing an observer in the Notification center in order to “do something” when either the watch app or the phone app would communicate with each other, ChatGPT-5 came up with some code using “weak self”. I didn’t know what this was or why, and could ask it. Was it a hallucination? Possibly, but considering it’s trained on the wider internet (including countless StackOverflow answers), its explanation appears plausible and correct, and I didn’t see an issue with going with its suggestion (ChatGPT-5):

Different LLM’s had different strengths and weaknesses. I found Claude was great for getting the initial project structure out, but it lacks the ability to output everything as a .zip file and simply load it in; the best you’d get was a pdf of all your files. I could then plug that into ChatGPT and split things up, as well as ask for its opinion on the code Claude had spat out.
I’m fairly impressed with the UI the LLM’s generated on the first try. While a lot of it was unnecessary for the use case in that I only really needed the companion iOS app in order to input my TempStick API key and adjust the polling settings for each sensor, I decided to keep it for simplicity and aesthetics. It recreates a lot of the functionality that the official TempStick phone app already created; i.e. displaying sensor names along with online status, battery level, temperature and humidity, but…it looks good and I don’t feel the need to cut it out since the LLM’s generated it with little effort on my part.

A lot of the code that the LLM’s output is messy and repetitive - which is not a good practice. Ideally the shared code between the watch app and the phone companion app would appear in one place, rather than be duplicated for each target, but I didn’t want to spend time to clean things up and make it look nice. The goal was to get a watch app out as quickly as possible for personal reasons, with a minimum amount of time spent on it. “In real life” at a “real company”, this should not and would not fly - this is a common way for nasty bugs to come up in the future as different people work on different parts of the codebase but don’t update everything as needed, especially as it grows. If I get really bored I will probably refactor this for my own purposes, but for now I’m going to purposely leave things as is, if anything to demonstrate one of the pitfalls of “vibe coding” as things stand as of the time of this writing.
Some of the functionality seems redundant but I’m going to leave it as is; pressing “Save Settings” in the iPhone app settings also functions to “Sync to Apple Watch”.
I’m not sure I trust some of the functionality but it appears pretty benign and not worth my time to correct for now; for example it appears that enabling Global Polling and setting the interval doesn’t actually change the interval of the sensors to hit the API on the iPhone app and they can only be changed individually, although it does appear to affect things on the watch app. Again, if I get bored, I’ll probably just cut out Global Polling completely to prevent confusion and require individual sensor configuration.
The LLM’s are NOT great at crawling documentation you link to in order to generate a functioning app that connects with the backend provided, or at least weren’t at the time I was developing the app. Maybe if I had copied and pasted all of TempStick’s API documentation directly it would have come up with something better on the first go, but the AI’s solution to this was to find a wild repo on the internet that made use of TempStick’s API, crawl that, and make its decisions from there. Which, as you may guess, didn’t work at this time (although maybe it would have worked with a previous incarnation of the TempStick API that the repo was based on). I had to look in the documentation myself and fix the problems. I still feel that this saved me some time vs. doing everything from scratch, but again, I’m relying on my ability to program or at least grok through something new-ish to me, whereas I’d be at a dead halt if I had none of that in the back of my brain. Interestingly, I tried again today, asking it to “make a demo web app” using the URL of the TempStick API documentation, which it spat right out, but when pressed (ChatGPT-5):

-Certain critical parts of functionality, like having the Apple Watch app poll the API on its own (rather than relying on data sharing between the phone app and it) were strangely commented out at the beginning and marked as “optional”. If I wasn’t looking for this in the code, everything would “appear” to work fine at first since generally speaking, my phone and watch are on at the same time, and the phone usually has a connection to the internet. If it were stuffed inside a metal locker in a concrete building at a pool or boathouse, there’s a good chance it wouldn’t be able to connect to the cell towers though, my watch wouldn’t receive updates on its own, and thus the whole purpose of the project would be defeated since in its initial form the watch app wasn’t configured to poll the backend on its own.

Summary:

As many have said before, AI is a great tool for those that already have foundational programming concepts under their belt, both in order to properly articulate what they’re looking for in addition to spotting and dealing with potential problems as they come up. In my opinion if I hadn’t had the experience I already had, I would have never been able to bring this specific personal project to fruition. For a purely web app, I do think it is possible to purely “vibe code” something and in this narrow regard the hype is indeed real, but except for the simplest client-side only web app with no authentication, no database access, no API usage, etc., doing so runs a huge risk of security problems, or at a minimum vendor lock…unless someone was able to vibe code their way around the cloud as well to set up the necessary infrastructure, and trusted the results (although I remain extremely skeptical this is possible at this point in time). At the end of the day, it’s important to remain vigilant, skeptical of the AI output, and to not use it as a substitute for your own reasoning and decision making, as Open AI warns about itself, right in the chat prompt box:

Although at the time of writing, it appears we are starting to hit a point of diminishing returns with new LLM’s and a plateauing of progress, I do think AI will continue to be a great resource for developers to brainstorm and sketch out rough ideas as well as slap together some boilerplate, greatly speeding up the process of development. Especially in a situation like I found myself in, where I NEEDED to learn and adopt a technology I didn’t have much experience with, I did not want to take months to become an expert in this domain because I will probably not use it much outside of this one project (at least for now), but didn’t want to wait for the company to produce their own Apple Watch companion app which doesn’t appear to be happening soon. I remain optimistic that I’ll see a more polished, “official” app though, since now one exists in the wild: mine!

Those are my thoughts for now, feel free to comment, and if you’d like to download the code and run it yourself, I created a public repo containing just the Swift files and the assets:

https://github.com/leifdroms/TempStickMonitor-public

I’d like to thank in particular the TempStick customer service team as well as the company in general for graciously opening up their APIs to developers. They make a great product and I’d recommend it to RV-ers or anyone else that needs to do cloud based environment monitoring. Gavin in customer support, if you’re reading this, thank you in particular.