My partner and I both got ourselves SteamDecks in 2022. Since then he’s repeatedly mentioned that he’d love to have colored buttons on his, matching the XBox controller layout, as many PC games use these colors for their button hints during quick time events and similar. But sadly, nothing like that is available yet.

With that in mind, and after losing my initial fear about opening up the deck thanks to swapping my fan and upgrading my SSD on January 1st of this year, an idea for a surprise started to form in my head. I had watched a ton of videos on silicone molding and resin casting, I have several 3d printers at my disposal, and there was just enough time left in my vacation and until our anniversary to pull this off. So I went to work. In total secrecy.

Research & material collection

The first thing I jumped into was some research in order to be able to make a plan and know what to get.

I ran across this interesting thread on button casting which gave me a good idea of what I’d need in terms of materials. It also taught me that I needed to figure out what kind of mold I’d even need to create for the buttons. Were they flat on the bottom in which case a single part mold would suffice, or were they curved or otherwise featured, in which case I’d need to create a two part mold? Instead of disassembling my deck right away (too obvious with my partner being around) I decided to instead checkout this excellent disassembly guide on iFixit which showed me that the buttons are indeed inset on the bottom, and so I’d need a two part mold.

That in turn meant I needed to look into mold release for multi part silicone molds in addition to silicone and resin. The material list in the thread sadly didn’t help me - I couldn’t get half of this stuff in Germany - but here’s what I finally settled on:

• Reschimica Silicone RPRO 30 (silicone)
• Trollfactory Silicone Mold Separation Cream (two part mold release)
• clear two part epoxy resin (I got this from a friend who happened to have some collecting dust for several months, still sealed)
• food vacuumizer pump and container (to degass silicone and resin, based on an idea from this hackaday article - a real vaccum chamber and also a pressure pot would have been nice, but I didn’t want to break the bank over a bunch of buttons here 😅)
• Mica powder (to color the resin)
• white 4mm rub on letters (to put the lettering on the buttons)
• clear UV resin (to seal the lettering in)
• wooden stir sticks
• plastic mixing cups
• small paper mixing cups
• 10ml syringes and 14g blunt needles (for injecting the resin into the mold)
• plastillina clay (to fix the buttons during the silicone pour)

Thanks to owning a resin printer, I already had a UV flashlight, nitrile gloves and a respirator on hand.

And at least one ready to go FDM 3d printer for helping me in the mold creation process.

Creating a two part silicone mold

Next step was to create my two part silicone mold and for that I first needed something to fix the buttons to, do the pour for the first part of the mold, flip that over and create the second part of the mold. I did some more research and came across two interesting videos, “How To Make Custom PS5 Controller Buttons” and “Upgrade Your PS5 Controller with DIY Resin Buttons - Better than the Original!”. In both, EJ uses a 3d printed box with custom bottom to hold the buttons in place and create a keyed two part mold. So, I did create just that as well. My mold box consists of several parts: two halves forming the box, a bottom for the first part (creating the keying), a smooth bottom and a top brace for the second part. The bottoms slot into the box halves, the top brace is just friction fit. Why the top brace? To hold some toothpick halves in place that create channels for resin to go in and air to go out when the mold is closed.

I designed all this in FreeCAD¹ and this is how it looks:

You can find the STLs here. All of the parts were printed on my heavily modified Prusa MK3 with a 0.6mm nozzle and a 0.3mm layer height in black extrudr PLA NX2 - you might have to adjust the tolerances on other printers or with other filaments, which is why I also included the FreeCAD file (which could be cleaner, but it worked for me).

Once I had the mold box ready it was time to disassemble the deck and get the buttons in my hand. So I waited until my partner was out of the house and then got going.

First, I disassembled everything based on the aforementioned iFixit guide. I attached the buttons to their spots on the keyed bottom plate of the mold box with some thin, rolled clay wormy dealies and then thoroughly cleaned them with some q-tips and isopropyl alcohol. It is important to be very thorough here - any dirt or even just a fingerprint will show up in the silicone mold and thus in the resin casting as well. I actually found that the outlines of the letters molded into the original buttons left an impression. The level of details you can get from silicone molds is astonishing!

Also make sure that you keep the lettering of the buttons oriented the same way, that way you will also be able to re-use the mold later for buttons with inlayed lettering (which is my plan for version 2.0 of this project).

I then slid the bottom plate into the grooves of the mold box halves, sealed the seam with some blue painters tape and just to be safe also wrapped two rubber bands around it.

Now came the time for the first pour. I weighed out 35g each of part A and B into a plastic mixing cup (my silicone gave instructions for mixing 1:1 by weight, stick to your instructions!) and then thoroughly mixed it with a stir stick. Then I poured that into a second cup, from high above, in a thin stream - this is first to get some of the bubbles out but more importantly to prevent any unmixed silicone from getting into the mold. This cup I then degassed. For my first pour I actually used a power sander to vibrate the bubbles out, but for the second pour I went with the above mentioned food vacuumizer - it’s easier, you get way less shaky hands out of it, and the results also look better. So, into the food container, lid on, pump on. I degassed until bubbles stop coming out. Then I slowly poured the silicone into a corner of the mold box, once again in a thin stream from up high. Take your time here, the slower, the less risk of errant bubbles making it into the mold. Then I degassed the mold again for a couple minutes and let it cure based on the instructions.

Next, I demolded the first part by removing rubber bands and the tape around the box and then carefully pulling the two halves apart. I then slowly removed the bottom plate from the silicone part as well, being careful to keep the buttons inside². I then cleaned them off of any leftover plastillina clay and any small bits of silicone.

After that I placed the first part of the mold on the smooth bottom plate and slid that back into the mold box. I then applied a generous coating of two part mold release. I used an old drybrush for that and liberately spread it all across the silicone and box surfaces, making extra sure to get into all the corners and creases. I taped the box seams again and then put the top brace in place. I broke four toothpicks in half, also broke off most of their tips, and then inserted one into each of the brace holds, pushing into opposite ends of the buttons underneath. This was to create channels for the resin to flow into and air to push out of the mold.

I once again mixed 70g of silicone from 35g of each part A and B, moved into a second cup, degassed it and slowly poured it into the mold. Then that was degassed as well and left to cure.

Another 5h later I carefully demolded my two part mold. I once again removed tape, rubber bands and the top brace, pulling out the toothpick halves in the process. I then carefully pulled the two halves of the box apart again and equally carefully peeled the two parts of the mold apart from each other.³ I could now remove the buttons, clean them, place them back into the deck and reassemble it. Then I cut off some of the silicone bits that had been sucked into the internal hollow structure of the buttons which I did not want to replicate. I was very diligent here to not cut away too much. And then I was the proud owner of a two part silicone mold for SteamDeck action buttons.

Resin time, resin time, do do do do, resin time

Wear gloves and a respirator during this!

With the mold now ready for action, it was time to try my hand at resin casting. I first assembled the mold, securing the two halves with four rubber bands. I also attached the mold to a piece of cardboard in the process on which I noted down the location of each of the buttons inside the mold. This is really important to keep track of which button goes where. With everything being mirrored thanks to the buttons basically lying on their faces in the mold you otherwise get terribly puzzled and end up with buttons of the wrong color. Ask me how I know 😅 If you get confused on which button is which, take a close look at the spaces they left in the mold. The B button of the deck is slightly curved on its outer side due to following the deck’s case curving, and that has helped me a ton to keep track of it and everything else in relation to it.

Next, I mixed up 40ml of resin, so 20ml of each part A and B (my resin gave instructions for mixing 1:1 by volume, check your instructions!). I degassed it in the vacuum container and then spread it across four small paper cups, roughly 10ml each. I then added red, greed, blue and yellow mica powder to each of the cups, mixing that in thoroughly, before placing the cups into the vacuum container and degassing them again. Next, four syringes with blunt 14g needles were filled with the four colors of resin and then the buttons were filled with the respective color. After getting confused with the colors on my first try, I double and triple checked each color before filling it in on the second. I carefully inserted the needle into the inner channel and then slowly pressed the resin in until it came out of the outer channel. On my first try I made the mistake to overfill, which caused some unintentional color mixing, so be sure to really stop right when the resin comes out of the air channel.

I then let the buttons cure for 24h before taking a first peek.

They looked great, but a quick fingernail test on one of the resin pots showed the stuff was not fully hardened yet. It turned out to take 72h until I could proceed with the finishing steps.

Finishing the buttons

I kept the buttons attached to the mold for the final steps, as that helped a lot with keeping everything aligned and less fiddly (it was fiddly enough as is). I carefully placed the sheet with rub on lettering I had bought over each button, making sure to center the corresponding letter. Then I rubbed the letter on using the blunt tip of my letter opener. The stuff didn’t want to stick to the smooth top surface very well, which had the upside of allowing me to redo something if I messed up, but also the downside of me having to be very careful to not mess things up that were already fine. In the end, it took me some tries but I prevailed.

Then I got out the UV resin, put on the respirator and gloves, and with an old brush softly brushed on a thin layer of resin on each button, careful not get any drops on the side or pooling, but sealing in the letter. I then cured that for several minutes with the UV flashlight.

Once the resin was cured I carefully pulled out the buttons from the mold and then cut off the sprue with a flush cutter.

A quick test fit in my deck showed that I needed some light sanding on one side of X, but that was quickly taken care of and then I had a working set of custom SteamDeck buttons 👍

Where do we go from here?

Considering that until Monday January 9th 2023 I had never before touched silicone or epoxy resin, and that by Monday January 16th 2023 I had four self-cast SteamDeck buttons in my hand that while far from perfect looked great, I’m very happy with the result. And the same goes for my partner, who really had absolutely no idea of this until I presented him the finished buttons on our anniversary. He was and is in awe 😊

However, single colored buttons with rubbed on letters sealed in with UV resin is not my end goal here. After seeing the amazing results one can achieve with inlaying in EJ’s videos, I’m really looking forward to trying that out. So the next step will be to cast some inlayed buttons with the same mold. And I have already printed out the letters on my resin printer 😁

Update from 2024-02-14: The buttons have now been in very heavy use by my partner for over a year, and they still look the same as on day 1! No changes on the letters that I rubbed on and sealed with UV resin, and no changes on the buttons themselves either. 👍

And thus I finally integrated the CO2 sensor unit I bought a couple weeks ago into my Home Automation setup, with the help of a Wemos D1 Mini and ESPHome. At first I went with an ESP12, a voltage regulator and a different firmware, but that didn’t work out due to the ESP not wanting to behave (my guess is I didn’t wire the barebone module up correctly or the voltage regulator was causing issues) and I also got some weird readings reported by the firmware (20k ppm CO2 - I know the air in my office can get bad after a couple of hours of coding, but not THAT bad).

The CO2 sensor is an “AIRCO2NTROL MINI” from TFA Dostmann, but it is also available under other names with a very similar case and more or less the same internals, as I learned from the ESPHome docs. Where my Dostmann edition seems to differ from the majority is the pin order of the internal debug port, which turned out to have CLK and DATA swapped in my case, which caused me quite the headache and a bit of frustration. So just for future reference, the pin order I found in my device is 5V - Data - CLK - Gnd from left to right with the hose to the left:

I hooked these up to the Wemos D1 Mini (clone) like this:

So 5V to 5V, Gnd to Gnd, Data to D1 and CLK to D2.

The ESPHome config I then flashed to the D1 is the following:

esphome:
  name: dostmann-office
  platform: ESP8266
  board: d1_mini

logger:

mqtt:
  broker: !secret mqtt_iot_broker

ota:
  password: !secret ota_pass

wifi:
  ssid: !secret wifi_iot_ssid
  password: !secret wifi_iot_pass
  ap:
    ssid: "Dostmann Office Fallback"
    password: !secret fallback_pass
  power_save_mode: high

captive_portal:

sensor:
  - platform: zyaura
    clock_pin: D2
    data_pin: D1
    co2:
      name: "Office Dostmann CO2"
    temperature:
      name: "Office Dostmann Temperature"

  - platform: wifi_signal
    name: "Office Dostmann WiFi Signal"
    update_interval: 60s

(If you are wondering about the !secret stuff, those values are contained in a secret.yaml file in my esphome folder, and you can read all about that in the ESPHome docs here.)

And with that I could now see the sensor in my Home Assistant instance and forward the data easily to my InfluxDB & Grafana monitoring stack.

To put everything together physically, fully contained, I used this alternative backplate by Stefan Kern.

However, I’ve noticed a temperature increase of around 3°C with it and the ESP in place, and I fear this might be screwing with the CO2 sensor’s calibration (as the measurement is temperature sensitive). I already mitigated this a bit by setting the chip to power save and adding some strategically placed aluminium tape, but that’s only improved things slightly. Due to that I plan to redesign the backplate to have the ESP outside the sensor case, in its own compartment. I hope that will solve the “running hot” issue for good then, but we’ll see.

Update from January 27th 2022 I redesigned the backplate and now have a solution that seems to work better, based on the reported temperature and CO2. I’ve published it here.

In any case, for now I at least got a reliable indicator of my office’s CO2 levels that also now are trackable long term, and I have also forwarded the current values to my AWTRIX mini via some NodeRED flow that also takes care of color coding. Further possibilities include flashing the office lights or some audio cues, should just the visual warning turn out to be insufficient in the long term 😉

I had heard of this approach before: growing plants in an inert grow medium instead of soil and feeding them with controlled nutrient solutions pumped around the roots. It’s a fascinating rabbit hole to go down and it always tickled my interest (especially given the automation and sensoric evaluation possibilities), however it also felt way too involved to get started with unless I had some more actual space and some actual need to grow plants, what with all the lights and pumps and pipe systems that I saw associated with it. That is, until I came across the Kratky method.

The Kratky method is a pretty much passive approach to hydroponics. The idea is simple: you take an opaque container for your nutrient solution, cut a bunch of holes in the lid and then place your plants into netpots or similar in those holes so their roots reach into the solution. So far, so similar to the Deep Water Culture approach. But instead of now aerating the solution with an aquarium air stone or similar to give your roots the oxygen they need, you instead simply allow the level of your nutrient solution to drop, creating an air gap and leaving parts of the roots hanging in the air. That way the roots can get nutrients but can also breathe (which is important so they don’t rot). You’ll have to fill up the solution a bit if needed (always leaving an airgap), but apart from that the whole setup is completely self managed. No power needed, no moving parts. And easily set up in something as small as a mason jar.

This was intriguing to me, and I had wanted to try my luck with growing some basil and oregano for pizza and such anyhow, so I decided to give this approach a shot. I ordered a kitchen herb seed kit, some 1l mason jars, some rock wool cubes (as growing substrate) and some hydroponic fertilizer. Then I fired up FreeCAD and designed a small lid with integrated rock wool cube holder (STL here, FreeCAD file here), printed a bunch of them and then went to work.

The seeds were planted in the rock wool cubes, watered and then I waited. The first green soon showed up and thus I transferred the cubes into their holders, filled the jars with 1l water plus the recommended fertilizer amount (thus creating a nutrient solution) and then put the lids on. The cubes sat right in the solution and thus were kept watered. To keep light out of the container (to prevent algae growth and also to not have everything heat up so much) I simply wrapped some aluminium foil around the jars. If I’m honest this was just meant as a temporary solution until I got around to sewing a little cover out of some light blocking fabric I have on hand, but I still haven’t gotten around to do that and the foil works just fine 🤷‍♀️

That was on July 18th and since then I’ve been able to witness some astonishing growth, especially on the Basil. Have a look at the progress:

As of today, both Basil plants had reached a plant height of around 50cm. The Oregano also looks healthy, but sadly I accidentally got hold of a hanging variant, making everything a bit tricky in this setup 😅

Sadly, I had to emergency-harvest one of the Basil’s today. While topping up the nutrient solution the other day I noticed the roots to be way darker than they should be. They didn’t look particularly healthy. Some of the leaves also started to look a tad unhappy. I came to the conclusion that I might have caught myself some root rot on this plant. Doing some research I learned that with the Kratky method, if you grow for longer than 4-6 weeks you really should occasionally replace the nutrient solution completely and clean the container to keep bacteria from taking root in your roots (pun not intended). I guess this is what happened here. I tried to save the plant with a 2:1 water and 3% hydrogen peroxide bath yesterday, but either it was already too late or that was too much stress. This morning the leaves were hanging and the whole plant looked quite sorry so I decided it was time to harvest and now I have a jar of fresh pesto verde.

Further reading revealed that it’s apparently an option to add a teeny tiny amount of 3% hydrogen peroxide to the nutrient solution itself to help keep any unwelcome guests away (and also help with aeration), so I’ve now added 0.5ml to my freshly topped off jar of the other Basil and hope that won’t do harm but rather good. Wish me luck 😉

All in all, I call this whole first dabbling with hydroponics a great success. The Kratky method allowed me to get up and running quickly without huge investments and space requirements, and the results were amazing. I’ve also now planted some peppermint seeds and they are already sprouting, so my hopes are high for some amazing fresh teas later this fall! If you’ve always wanted to experiment with hydroponics but it always felt way too involved, maybe take a look at the Kratky method 😊

I already had an InfluxDB and Grafana setup running anyhow for my Home Assistant instance to dump values from my home climate sensors into, so it was a logical next step to simply add some additional sensors to the mix.

Throughput

I currently run a speed test of the network throughput every 20min and log the results via MQTT into InfluxDB. I had to find out that neither the speed test integration in Home Assistant nor the official speedtest-cli tool were performing reliably enough for this – I was constantly getting dips in measured throughput and thus alerts, even when everything was completely fine with my uplink.

I solved this by turning to speedtest-rs and a small shell script that parses the output and pushes it into MQTT to Home Assistant, which then processes it further for some visualization right on my dashboard but also forwards it further into InfluxDB. You can find the Dockerfile and the script plus some further info in this gist.

In Grafana I then use this data to provide me with some single stat panels for the current downstream, upstream and ping values as well as the averages over the selected time range:

Additionally, I also plot the down- and upstream speed in a timeline, together with the current bandwidth consumption as extracted by Home Assistant from my ISP’s cable modem/router (thanks to the Fritzbox NetMonitor integration). Together, this gives me a good picture of whether there is actually an issue when I see a dip in the measured values, or if it’s just too high bandwidth utilization:

You can see in these screenshots that I recently upgraded my plan with my ISP – from 200/20 to 500/50 MBit. The problem: The speedtest run by my monitoring setup doesn’t hit the 500 mark, whereas running a manual test on speedtest.net works just fine. Looking at the speedtest-rs README it becomes apparent that this is a known issue with the legacy (open) Speedtest.net API:

This tool currently only supports HTTP Legacy Fallback for testing.

High bandwidth connections higher than ~200Mbps may return incorrect results!

The testing operations are different from socket versions of tools connecting to speedtest.net infrastructure. In the many FOSS Go versions, tests are done to find an amount of data that can run for a default of 3 seconds over some TCP connection. In particular, speedtest-cli and speedtest-rs tests with what Ookla calls the “HTTP Legacy Fallback” for hosts that cannot establish a direct TCP connection.

I fear I might have to look into reimplementing the current speedtest-to-mqtt setup with another container utilizing the official (and sadly proprietary) Speedtest CLI tool to mitigate this issue. Thankfully, it should be quite easy to build a drop-in replacement thanks to the modularization in effect.

Update from March 30th 2021 I’ve now done that and here’s an updated gist that works identically to the speedtest-rs approach, but instead utilizes Ookla’s official command line tool. The results are stable numbers that reflect the expected bandwidth and also match the web based test results.

Update from March 31st, 2021 I wasn’t too happy with running a proprietary tool for my speed testing, went looking for an OSS alternative, came across librespeed and therefore have now replicated the setup again using that. You might want to experiment a bit to find a server close to you and define that via --server <id>, the auto discovery appears to be a bit wonky. Or just use your own server list via --server-json or --local-json.

Latency and packet loss

In addition to the available up- and downstream speeds, I constantly monitor latency and packet loss to a selected number of hosts both external and internal to my network as well. For this I ping some public DNS servers (Google, Cloudflare and Quadnine) and some of my own vservers for the remote side, and the ISP’s Fritzbox, my managed network gear and internal servers for the LAN side. I used to do this via Smokeping, but when I set up my InfluxDB/Grafana stack I wanted to find a solution to have everything together in one place.

Thankfully I almost immediately found this post by Tor Hveem who solved this with a little custom Go tool to run fping against a number of configurable hosts and push the results right into InfluxDB. This was exactly what I wanted and thus I replicated the outlined setup, albeit with a slightly different color scheme.

I use a modified version of Tor’s infping tool maintained by Nick Van Wiggeren and run that in a Docker container on my NAS. You can find everything needed to run this on your own in this gist.

As a result I get ping output for all hosts every 60 sec with times and packet loss information pushed right into InfluxDB. This is easily queried by Grafana and looks quite nice when visualized:

And on my network dashboard, I plot only the avg values across all hosts and a mean loss value into one single graph each for external and internal hosts:

This allows me a good overview of the current state of uplink and internal network at one glance.

Alerts

Since just graphs won’t give me an immediate heads-up when something goes wrong, I have a bunch of alerts set up in Grafana:

• Measured download speed falls beneath 250MBit for more than one hour
• Measured upload speed falls beneath 35MBit for more than one hour
• Mean packet loss across all external hosts rises above 25% for more than ten minutes

All of those trigger a notification to a private Discord server (via Grafana’s own notification mechanism). In theory this notification should even include a screenshot of the panel for which the alert was triggered for, but I’m having some problems with that still that I need to investigate.

This notification channel has an obvious problem: When the uplink goes out completely, I won’t get the notification if my phone is in my LAN. I really need to add a local alert as well at some point 😅

Still, it usually will give me a heads-up in time for me to reach out to my ISP on short notice and request they start troubleshooting.

Conclusion

This monitoring setup has proven valuable in debugging network performance issues and also getting an early heads-up about current ISP issues. I have successfully used screenshots for proving ongoing issues to my ISP, and also sped up the one or other troubleshooting session when there was in fact an issue with my LAN. In my book, that makes it absolutely worth the time it took me to set this up and maintain it. And: it kinda looks cool 😎

If you want to give this a go yourself, this might be of interest to you:

• Dockerfile, compose and instructions for speedtest container
  • Ookla speedtest based version
  • speedtest-rs based version
• Dockerfile, compose and instructions for infping container
• Panel JSON for the mentioned visualizations