site banner

Tinker Tuesday for September 30, 2025

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service

1
Jump in the discussion.

No email address required.

TRON bike lighting update.

Got a black helmet for myself and for one of my kids and did the final fit of the LED strips before the last push to get them all soldered together. Done, though after hot gluing and heat shrinking it all down, two of the ... 20 connections short out if they flex a bit, so I need to cut them open and redo. It's actually the second connection I did and also the third to last. It makes sense I would screw up near the start before I got the hang of it but near the end doesn't.

Anyway once those are fixed and showing enough durability it'll be time to VHB tape them to helmets.

I was all set to try some demo runs with ESP32-C3s I had on hand but then I noticed a variant which comes with a postage sized OLED screen so I obviously need that so it blinks ach kid's name and maybe a cute bitmap design.

Lot's of work at work, so I didn't get a lot done this week. I did manage to chip away a little bit at the refactoring, and I am quite sure this is the right way to go as it will save me some work in the future, but it's still not finished. Until then, no Substack integration, and not much new.

How are you doing @Southkraut? I was planning to respond to your report last week, but never got around to it, so let me say here:

...as it turns out, it's Unreal's fault. Apparently ProjectileMovementComponent doesn't detect collisions if the collider isn't the actor's RootComponent. And I had written a custom RootComponent that I put in charge of situationally instantiating subcomponents, including said collider and the MovementComponent. Sad. So my options now are:

  • Always make the collider the root. But that leaves a blank spot for actors that shouldn't have a collider, and they'd have to be treated differently. But I guess I have to do that anyways.
  • Let my custom RootComponent inherit from collider. Wait, no, that won't work because there are separate collider classes for each primitive shape. And also doesn't account for acotrs that shouldn't collide.
  • Write my own MovementComponent that doesn't require this specific setup.
  • Attempt to fix Unreal's MovementComponent and hope they accept my changes, most likely only to learn that it has to be the way it is and I am abjectly ignorant of the many good reasons.

I think every non-game programmer that dabbled in game engines had the brilliant thought of "I'm going to design it in an 'engine agnostic' way, so if I need to switch the engine, it can be done easily"... and then you always run into to this sort of shit. I swear to god, the GameDev people hate us.

I recently picked up a Longer Ray5 5-watt laser engraver for $170 on an Amazon special on a lark. It required a bit of assembly but was fairly straightforward. So far I am impressed with its capability. It has a large, roughly 2x2 ft work area. Using Inkscape and the free LaserGRBL program, I have been able to generate a variety of engraving and cutting patterns. I have successfully engraved wood, stone, painted metal, and successfully cut cardstock and thin pieces of wood. It doesn't really make a dent in any polished metal and I have yet to test many plastics, although it should be able to cut 3mm cast acrylic. The best thing I've made so far is an A4-sized cardstock stencil of the Paris Metropolitain logo. I also haven't tried engraving any grayscale images, though it should be possible with paper and certain types of wood. One thing I hope to be able to use it for is to make my own serial tags or controls panel layouts, by engraving a black painted metal blank and then rubbing in white paint.

Which one of you can teach me about home automation? Here's my use case:

  • I have a cabin in the country that I would like to preheat in spring and fall with space heaters
  • This means I need a way to remotely see the temperature and switch the heaters on until the temperature reaches 20C
  • I want zero data leaks

What I have learned so far:

  • I need smart plugs for my space heaters, ideally with built-in temperature sensors
  • Home Assistant is the only real option for the management server
  • Zigbee and Z-Wave are the fancy low-power wireless options for smart devices, but for a literal plug they are unnecessary
  • There are two options for smart plug firmware that use WiFi: Tasmota and ESPHome
  • My router/modem is not powerful enough to run Home Assistant

The DIY option is to buy:

  • a small computer to run Home Assistant and Tailscale on
  • a small UPS to protect the PC (my router/modem already has one, but it's too small to be shared)
  • two smart plugs to control two space heaters, ideally with a temp sensor, flashed to run Tasmota or ESPHome

The "happy wife" option is to buy:

  • two Chinese smart plugs, one with a GSM module
  • a SIM card with an IoT phone plan

Am I even moving in the right direction?

You should be able to get Dell or HP micro-desktops off a five-year lifecycle pretty cheaply at this point, which is more than sufficient for running Debian + Home Assistant. Upgrade the RAM to 32 GB and Proxmox might even be practical. Or, get a laptop with a broken screen or keyboard. You should be able to find one for very cheap or free, you can configure it with peripherals attached to work around broken bits, and then it has its own built-in UPS.

I agree with pigeon this seems like overkill for this particular application, but this is the kind of project that can start to snowball, particularly if you are going to need Internet access anyways to trigger the preheat cycle. If so, the latter option might be better to dip your toes in. You can always set up a Wireguard tunnel to Home Assistant running someplace more convenient in that case.

This means I need a way to remotely see the temperature and switch the heaters on until the temperature reaches 20C

Do you? I imagine the space heaters have a thermostat that can already do this task with no input from you, don't they?

I get the instinct to want to DIY it to get a feeling that I actually own my shit, I tend to do the same. But if you're not planning to expand this into a bigger system, in the end, if your smart plugs are really just smart "on-off" switches, you're probably overthinking the data leak aspect.

It's not like you're putting cameras there. Yet. Which you probably will eventually.

Do you? I imagine the space heaters have a thermostat that can already do this task with no input from you, don't they?

They do, but I don't want them running during the workweek, only when I'm actually driving there.

Ok, but then all you need is smart plugs with remote activation.

Set the space heater's thermostat to 20C, turn the smart plug off when you leave, turn it on when you head there. You don't need to know the temperature; if it's already hotter than 20C turning on the smart plug won't do anything, if it's colder it will run until it reaches 20C.

Yeah, but you don't strictly need an entire smart home setup for that. The ghetto setup I'd use looks something like that: set the space heater thermostat to whatever number corresponds to 20C, plug them into any Chinese ethernet power strip, connect the power strip to your router.

The rest depends a little on the router/modem you have, but basically all modern prosumer/enterprise routers or just any openWRT box will allow you to just send the power-ON command to the power strip once you've connected from the outside. I'd just use SSH over VPN to trigger a one-line bash script.

If you want to monitor the inside temperature, you could add a cheap Raspi + analog thermometer to the setup, which you can also query over SSH.