标签：#Home

A growing collection of pocket-size gadgets lets you easily make recordings and extract info from them. Here are our favorites.

The QS90H actually delivers on the all-in-one soundbar promise thanks to new woofers and a unique driver layout.

Shark’s new PowerDetect Speed is lighter and more affordable than the original, but still managed to ace most of my vacuum tests.

I put handheld, wearable, and misting fans through a sweltering summer to see which ones kept me coolest.

Ring has debuted a new version of its smart doorbell camera that's designed to be easily installed as a replacement for a door's peephole without drilling or running wires. The Peephole Cam 2K is a replacement for the brand's Door View Cam that first debuted in 2019 and, alongside a sleeker design, it features a […]

Peloton's new bikes do more to warrant the space they take up in your home.

I didn't put Shelly Plus 1PM and 2PM behind my wall switches for the app or the cloud. I put them there because each one quietly does two jobs at once: it switches a circuit locally, and it measures exactly what that circuit draws. The moment I had them wired in, every light group and every roller shutter in the flat became both controllable AND measurable in Home Assistant — with no separate energy meter and, deliberately, no cloud in the loop. This is the part most Shelly write-ups skip: the metering isn't a bonus, it's the reason to use them. This is how I set them up, kept them fully local, wired the physical switches so they still work like switches, and pulled per-channel energy into the HA Energy Dashboard. Why the Plus series for in-wall use The Plus 1PM and 2PM are Gen2 devices. That matters: they speak a local RPC API over HTTP and WebSocket, they're supported by the native Home Assistant Shelly integration out of the box, and nothing about them needs the internet once they're on your Wi-Fi. The 1PM is a single relay with power metering — I use it behind light circuits. The 2PM has two relays with metering and a dedicated cover/roller-shutter mode — that's what sits behind my shutters. The catch you plan for up front: both need a neutral wire in the switch box. Older installations often don't have one at the switch, so check before you order. If the neutral is there, the rest is easy. The first thing I change: kill the cloud, pin the IP Straight out of the box I do two things in the Shelly web UI (just browse to the device's IP). First, I disable Bluetooth and Cloud under Settings — I don't want the device reaching out to anything, and Home Assistant talks to it directly on the LAN. Second, I give it a fixed address via a DHCP reservation on my router, so the native integration never loses it after a reboot. That's the whole hardening story. No firmware flashing, no third-party firmware — stock Shelly firmware with the cloud switched off is already a fully

Clean your house without the constraint of a power cord, thanks to these stick vacuums.

Part 1 established the hardware, the runner, and the primary model. This entry covers what governs inference on that hardware — the two phases of inference, the cost of long context, and the cost of loading a model from disk — and compares the local machines against a free-tier cloud model. The two phases of inference Inference has two phases. Prefill processes the input prompt before any output appears; it is compute-bound and wants a GPU. Generation produces output tokens one at a time and is bound by memory bandwidth. Casual use is almost all generation and hides the difference; the cost of prefill surfaces only when prompts grow large. The machines, and how they were measured Machine CPU / RAM GPU (VRAM) Storage (read) Prefill (tok/s) Gen (tok/s) Load (18 GB) Primary desktop 5950X / ~80 GB DDR4 RX 6900XT (16 GB) NVMe (~2.1 GB/s) 360 18.3 8.4s Secondary box 5600G / 32 GB DDR4 GTX 1060 (6 GB) SATA SSD (~0.35 GB/s) 253 17.1 50.6s Laptop 8840U / 32 GB DDR5 Radeon 780M (none) NVMe (~2.4 GB/s) 20 10.0 7.5s All inference figures come from a controlled run: the same model (Gemma 4 26B, 18 GB) on each machine, a unique random prefix per prompt to defeat caching, a fixed 8,192-token context, warm, on an identical ~6,855-token prompt (generation timed over a 200-token output). Two things stand out. Prefill varies about eighteen-fold across the machines (360 to 20 tok/s) while generation varies less than twofold (18.3 to 10.0), and prefill is what dominates large-prompt workloads — so a machine can look fine on generation yet be useless in practice. Model-load time, separately, is set by storage rather than compute: the secondary box's budget SATA SSDs load the 18 GB model in 50 seconds against eight on NVMe, which turns a cold request into a minute-long stall. Secondary box Request time Warm (model resident) ~4s Cold (model reload) ~54s If the model is allowed to unload between calls, every call silently pays that reload — a real source of intermittent timeouts. The fix is

There is a good chance you have heard, read or have been told by other developers that you should start your homelab. It does not need not be an expensive hobby. In fact, all it takes is one laptop. I have seen people like Jeff Geerling build and document amazing homelab setups and they have been my inspiration through this journey. In this post I explain how my homelab experience has been. Why I started, how it's going and lessons I have learned along the way and how they translate to my skillset. What I run on my homelab First let's get a quick overview of the things I run on my homelab. Personal website. A simple html/css/js site built with astro . Astro was very useful because I wanted something very lightweight to test out when I started. Jellyfin . A homelab is never complete without a personal media library. Jellyfin was the first big app I decided to run. I wanted to see how well the hardware could handle workloads like encoding and decoding media files. It is a pretty good stress test. Immich . I have been working to move away from google photos. Immich is a great open source alternative. With geotagging and machine learning to identify faces all running locally. And you can have multiple users with multiple accounts, this was a no brainer for me. Mailcow(currently exploring). While I have not entirely migrated off gmail, I am considering other self hosted mail providers. Tailscale . A Zero Trust identity-based connectivity platform. Honestly, the swiss army knife of homelabbing in my opinion. Pet projects. Whenever I have a new phoenix, rails or node application I need to test in a production environment, I usually build it and run it on my homelab. How it started. Well, like everything else, I wanted to practice my linux devops skills. Granted, I have been a linux user for about 8 years now, running a headless server was a new challenge for me. But I will admit, it has made me more confident that I will in fact figure it out if I do not know how something

I tested modern locks, lights, climate controls, and more in a historic home that I very much wanted to keep historic.

Originally published at wostal.eu . TL;DR : My Hetzner k3s lab quietly became a platform. Dozens of operators with leader-election leases hammered the default datastore — SQLite via kine — until compaction entered a death-spiral: 1.36M rows, a 13.8 GB WAL that wouldn't checkpoint, CPU pinned at 99%, load average 79 on 8 cores. I stopped the bleeding by truncating the WAL, then migrated the control plane to embedded etcd (7.5 GB SQLite → 313 MB etcd, load 79 → 5). This is the full postmortem — and the lessons. This is a war story, not a tutorial. It's about the moment a homelab stops being a homelab and starts behaving like production — without ever announcing it. The cluster in question, homelab , is the Hetzner k3s setup I wrote about previously . It started small. It did not stay small. In this post I'll cover: How an overgrown lab broke the default datastore — the kine/SQLite compaction death-spiral The firefight — measuring instead of guessing, and the fix that actually worked The permanent fix — migrating the control plane to embedded etcd, and the honest caveats The meta-lesson — how to recognize when your lab has become a platform A diagnostic runbook — so next time it's minutes, not hours There's a companion piece to this incident. The CI pipeline that ran this etcd migration was itself freshly — and badly — migrated, and debugging it cost me hours over a single missing newline. I split that into its own post: I Let an AI Re-Platform My CI Pipeline. Here's What Broke. Context: it's "just a homelab" — except it isn't homelab began like any homelab: one k3s node on Hetzner, a few things to play with. The problem is that over months it quietly became a platform . A single master node ( cx43 , 8 vCPU / 16 GB, untainted, and also carrying Longhorn and workloads) now runs: ArgoCD, Kargo, Crossplane/Upbound, CloudNativePG, EMQX, Longhorn, trivy-operator, kubescape, Gatekeeper, Goldilocks/VPA, VictoriaMetrics, Loki, OpenTelemetry, Argo Workflows/Events/Rollouts, kga

The start of a new school year can feel hectic, as parents juggle their kids’ classes, extracurriculars and sports on top of work, appointments, and other responsibilities. It’s easy for things to slip through the cracks, but Skylight’s shared smart calendars can help keep everyone on track, and from August 2nd through August 9th they’re […]

These portable vacuums make quick work of snack crumbs, tracked-in dirt, pet hair, and the mysterious debris beneath your seats.

In a world of plasticky water filter pitchers, I tested three new-generation stainless steel filter systems.

On Dreo’s summer flash sale from August 1 to 3, a great misting fan and an even better air fryer are at the lowest prices we’ve seen them.

No other gadget knows as much about your home as a robot vacuum. They map your space, learn your routines, and many now carry a camera and microphone into every room in your house. As AI gives them a better understanding of what they see, the privacy and security risks these autonomous robots pose are […]

Feeling the pull of a new clean machine? We’ll help you make sense of Dyson’s whirlwind vacuum lineup.

This is the first in a series of build-log posts documenting a local LLM project, in which models are run on owned consumer hardware rather than through a cloud API. The present entry covers the hardware, the software stack, and the benchmarks by which a primary model was selected. The hardware Two machines are used, both consumer-grade. All benchmarks reported below were obtained on the primary desktop. Machine CPU RAM GPU Primary desktop Ryzen 5950X ~80 GB DDR4 AMD RX 6900XT (16 GB) Secondary box Ryzen 5600G 32 GB NVIDIA GTX 1060 (6 GB) The software stack Ollama serves as the model runner across two GPU vendors: ROCm 5.7 for the AMD card on the primary desktop, and CUDA for the NVIDIA card on the secondary box. The primary model is Gemma 4 26B, a mixture-of-experts model with roughly 3.8B active parameters, quantized to Q4_K_M and occupying approximately 18 GB on disk. On the RX 6900XT it is run with an automatic GPU/CPU layer split, as the Q4 weights together with the KV cache exceed the 16 GB of available VRAM. Several Ollama settings were enabled to recover headroom: flash attention, and an 8-bit ( q8_0 ) KV cache, the latter approximately halving the cache footprint. A free cloud tier is retained for occasional heavier tasks, though the objective is to run as much as possible locally. Selecting a model: benchmarks Before a primary model was chosen, the installed models were benchmarked. Two properties were of interest: throughput and output quality. Throughput was measured on the primary desktop with a 500-word essay prompt ( ollama run <model> --verbose ): Model Tokens/sec Duration Tokens out gemma4:26b 18.86 50.11s 945 gemma4-26b (64K ctx) 17.96 51.99s 934 mistral:7b-instruct 34.81 10.17s 354 llama3.2 57.11 3.99s 228 The smaller models are substantially faster; their token counts, however, are lower, and in practice their responses were correspondingly shallower. Quality was assessed with a five-task suite spanning logic, coding, summarization, creative writ

Back in February I published a post about osx-proxmox-next , a tool that builds a macOS VM on Proxmox with one command instead of an afternoon of OpenCore plist editing. About 1,500 people read it. Some of them installed it. On hardware I don't own. That's when the interesting bugs showed up. 150 commits later, here are five failures that don't appear in any macOS-on-Proxmox guide I've found, with the actual root cause for each. 1. The installer stalls at 100% CPU and nothing moves Symptom: macOS installer reaches the copy phase. CPU pegged at 100%. Disk IO and network throughput both flat zero. It sits there forever. Only on Xeon E5/E7 v2-v4 hosts. My first fix was wrong. The stall looked like a network problem, so I assumed the vmxnet3 kext was failing to load during install and swapped those hosts to e1000-82545em . Shipped it. Then issue #103 came back from someone with the actual hardware: vmxnet3 got network fine, and e1000-82545em did not attach at all. I had made it worse. The real cause is two layers down. Those chips are genuine HEDT parts with dual-socket / multi-die topology, and -cpu host leaks that topology straight through to the guest. Pair it with a MacPro7,1 SMBIOS, which macOS treats as multi-socket capable, and XNU's scheduler livelocks under heavy multithreaded IO. The installer copy phase is exactly that workload. The fix is to stop passing the host topology through: _XEON_HEDT_PATTERN = re . compile ( r " Xeon.*E[57][ -]*\d+ *v([234]) " , re . IGNORECASE ) def _xeon_hedt_cpu_model ( model_name : str ) -> str : match = _XEON_HEDT_PATTERN . search ( model_name ) if not match : return "" if match . group ( 1 ) == " 2 " : return " Haswell-noTSX,model=158,stepping=3 " return " Broadwell-noTSX,model=158 " Lesson I keep relearning: the symptom showed up at the network layer, the cause lived in CPU topology. Guessing from the symptom cost me a release. 2. The VM boots into Recovery forever Symptom: Fresh install finishes. Every subsequent boot lands b