{ "version": "https://jsonfeed.org/version/1", "title": "Umbo", "home_page_url": "https://umbo.dev", "feed_url": "https://umbo.dev/rss.xml", "description": "Full Stack Engineer at Elastic", "icon": "https://umbo.dev/icons/icon-512x512.png", "author": { "name": "Umberto Pepato" }, "items": [ { "id": "unusual-git-hooks-that-work-wonders", "content_html": "
\"A
#git#version control#devtools#devops

Unusual Git shell aliases that work wonders

Some simple operations require verbose Git commands I always struggle to remember correctly. Here are custom shell aliases for them that I find extremely useful.

Undoing the last operation

\n

I always forget how to undo my last commit without losing the changes. I use gundo to do this: it undoes the last\ncommit while keeping the changes in the stage.

\n
alias gundo='git reset --soft HEAD~1'\n
\n

Unstaging changes

\n

Removing files from the stage can be a bit wordy. I use gunstage to do that:

\n
alias gunstage='git restore --staged .'\n
\n

Discarding changes

\n

Sometimes you realize you're on the wrong path and just want to quickly discard your work. This is not always\nstraightforward, especially when there are newly created and staged files that don't go away with a simple checkout.\nHere's a handy gdiscard alias that unstages all the changes, discards them, and cleans new files and directories,\nbringing you back instantly to a clean git status ✨.

\n
alias gdiscard='git restore --staged . && git checkout . && git clean -d -f'\n
\n
\n

Warning

\n

Use with caution: you likely won't be able to recover any of the discarded changes!

\n
\n

Git log

\n

gl is frequently used as an alias for git log. I prefer to assign it to a concise log with one line per commit:

\n
alias gl='git log --oneline'\n
\n

while the default (more verbose) log has one \"l\" more.

\n
alias gll='git log'\n
\n

Working with multiple remotes

\n

When working on forks you might frequently pull new updates from the upstream repository, here are some aliases I ended\nup creating for this use case:

\n
# When you want to make sure you don't introduce merge commits\nalias gpu='git pull upstream main --ff-only'\n\n# When merge commits are fine\nalias gpu!='git pull upstream main'\n\n# If you prefer rebasing on the latest upstream main\nalias gpureb='git pull --rebase upstream main'\n\n# When you want to reset your fork branch to the last upstream commit\nalias gru='git fetch upstream && git reset --hard upstream/main'\n
\n

I find the last one especially useful when I need to start working on a new feature after a while. I gcb to a new\nbranch, no matter how old is the commit where I currently am, and then just gru to the latest upstream changes.

\n

Stash management

\n

To manage the stash, I find using this couple of commands very handy.

\n
alias gst='git add --all && git stash'\nalias gpop='git stash pop'\n
\n
\n

Note

\n

For some mysterious reason I frequently type gpoop 💩 instead of gpop... Well I ended up adding that as an alternative\nalias too 😅

\n
\n

Quick amending

\n

When you realized you missed something in your last commit and quickly want to add it without creating a new commit,\nthis alias might prove useful: it stages all the uncommitted changes and amends the last commit without opening the\nmessage editor.

\n
alias gamend='git add --all && git amend --no-edit'\n
\n

And when you feel crazy and want to ignore git hooks, here's a variant for that too!

\n
alias gamend!='git add --all && git amend --no-edit --no-verify'\n
\n

Getting the current branch name

\n

Sometimes you may need to obtain a clean output only containing the name of the current branch (i.e. to be used in other\nshell commands). I use gwhere for that:

\n
alias gwhere='git rev-parse --abbrev-ref HEAD'\n
\n

Progressing with merges and rebases

\n

When you're going through a tough merge or rebase and quickly need to continue the process without typing long commands,\nyou may find these two useful. gmcont marks all the changes as resolved and continues with the merge:

\n
alias gmcont='git add --all && git merge --continue'\n
\n

while grcont continues a rebase process:

\n
alias grcont='git rebase --continue'\n
\n

Saving work in progress

\n

When you're in a rush, but want to save some work in progress in a commit instead of the stash (stash entries get lost\nquite easily, and it's hard to guess which is the one you're looking for without going through diffs etc.) here's a\nsub-second WIP committer alias:

\n
alias gwip='git add --all && git commit -m \"[WIP] Edit me before pushing\"'\n
\n

It adds all the changes and commits with a notice message.

\n
\n

Tip

\n

Add --no-verify if you don't even want to wait for hooks, but please make sure to re-commit properly before pushing!

\n
\n

If –like me– you don't trust yourself and want to be alerted about these commits, here's a script you can add to a\npre-push hook:

\n
if git log --oneline --branches --not --remotes | grep \"[WIP]\"; then\n  echo \"\\n👆 WIP commits found. Please edit them before pushing.\";\n  exit 1;\nfi\n
\n

But what if you accidentally added more commits after a WIP one? Well in that case you can just copy the sha of the WIP\ncommit from the git log output and then git rebase -i <sha>^ (note the ^ at the end), marking the WIP commit for\nediting in the list:

\n
edit XXXXXXX [WIP] Edit me before pushing\npick XXXXXXX Other commits\n...
\n

When you're done editing, amend the commit with a new message git commit --amend (or gamend 😉),\nthen git rebase --continue (or grcont!).

\n

Grab 'em all

\n

Like these aliases? Here's the zsh/prezto file I use, feel free to copy it and customize it!

", "url": "https://umbo.dev/articles/unusual-git-hooks-that-work-wonders", "title": "Unusual Git shell aliases that work wonders", "summary": "Some simple operations require verbose Git commands I always struggle to remember correctly. Here are custom shell aliases for them that I find extremely useful.", "image": "https://umbo.dev//article-assets/unusual-git-hooks-that-work-wonders/cover.png", "date_modified": "2025-07-25T00:00:00.000Z" }, { "id": "use-js-quirks-at-your-advantage", "content_html": "
\"A
#javascript#languages#devtools

Use JavaScript quirks at your advantage

Dubious null representations, creative equality checks, funky object behaviors. These are usually JavaScript meme material. But what if I told you that, if used with caution, some of these quirks may turn out to be useful?

JavaScript is famous for its quirky behaviors and extravagant linguistic features. While this is extensively covered in\nliterature and social media for both fun and educational purposes where the negative aspects are –rightfully–\nhighlighted, I think there's a positive side no one ever talks about. So pack up a bit of open-mindedness and\nlet's see how some of these characteristics can be used at the developer's advantage and how even famous libraries\nuse them in creative ways.

\n

Representing empty values

\n

JS’s dualism in the way to represent empty values with both null and undefined can be confusing and if not used\nproperly can easily cause issues but, well... that's how it is, so we might as well use it strategically.

\n

To give a bit of context: undefined is used to indicate the absence of a value and is assigned by the\nlanguage to

\n\n

null, on the other hand, is produced much less frequently by the language (mainly in the object world, as the\nend of the prototype chain). This difference makes of null a good semantic empty value: a representation of an\nexplicit empty option in your application-specific data model, something you don't want to be confused with an\nuninitialized value (where undefined might be more appropriate, and assigned by default from the language). null\nalso serializes to its JSON symbol, which makes it portable through network payloads, where it's more likely used to\nrepresent an intentional empty value.

\n

In general, I try to apply this mental model when dealing with empty values: never explicitly assign undefined to\na variable, let the language do it. Use null otherwise. Take this snippet for example:

\n
let preferredLayout: string | null | undefined;\n\npreferredLayout = await loadPreferredLayout();\n
\n

The declaration implicitly assigns undefined, which represents a pending/uninitialized value; then the async\nfunction loads and assigns the loaded value which could be either a string, or an intentional null empty value.

\n
\n

Note

\n

There are, of course, many exceptions where using the undefined keyword is necessary or more convenient. Think for\nexample when you want to conditionally assign a value to a React component prop that internally has a default\nvalue, leaving the default value working:

\n
const Component = ({prop = 'defaultValue'}) => { ... };\n\n// If you pass `null` here, `defaultValue` will not be used\n<Component prop={condition ? 'value' : undefined} /> \n
\n
\n

Loose equality

\n

When it comes to loose/strict equality, the general recommendation is to always use the latter. While this is a\nprecious recommendation we should all follow for writing more solid code, sometimes loose equality may come in handy.\nThere are cases, for example, where you don’t have full awareness of the exact empty type (null? undefined?) a\nvariable will hold (i.e. coming from an external dependency with missing/poor TypeScript typing). In this case using\nloose comparisons is a nice, concise option to catch them both, since they coerce to the same boolean value:

\n
// !== null would exclude undefined\nif (varThatMightBeEmpty != null) {\n}\n\n// This is even more concise, but you may not be able to use it if\n// you have to take into account non-nullish but falsy values, like empty strings\nif (varThatMightBeEmpty) {\n}\n
\n

Arrays are objects

\n

Arrays are technically objects. As such, and unlike many other languages, you can assign arbitrary properties and\narbitrary indices without having to fill all the previous elements:

\n
const array = [];\n// This is totally fine\narray[10] = 'An element';\n// And this too!\narray.nonNumeric = 'property';\n
\n

While this is likely not too useful in everyday coding, the language itself has an interesting usage of this that I\nthink it's worth mentioning: regex match results. Take this simple day-month-year date parsing regex for example:

\n
'01-02-2025'.match(/(?<day>\\d{1,2})-(?<month>\\d{1,2})-(?<year>\\d{2,4})/);\n\n// ['01-02-2025', '01', '02', '2025', index: 0, input: '01-02-2025', groups: {day: '01', month: '02', year: '2025'}]\n
\n

The resulting match is an array where numeric indices contain respectively at index 0 the full matched portion of the\nstring, and from 1 onward all the matched capture groups in their order, so you can conveniently access them using their\n1-based position in the regex (match[1], match[2], etc.). The array has some additional non-numeric props too though,\nsee index, input and groups where other useful information is stored.

\n

The in operator and for...in loop

\n

The in operator is often overlooked and even sometimes considered harmful for its limitations and lack of type\nsafety. I think that with the right precautions this nice little operator can be very useful. Say for example that you\nwant to check the presence of a particular property in an object, regardless of the value it holds (and\ncareful, because in full JavaScript style it can be defined, but contain the value undefined too! 😆). So again say\nthat the mere presence of the property (even if undefined) has a particular meaning to you, then the in\noperator may come in handy:

\n
// This passes even if options = { someOption: undefined }\nif ('someOption' in options) { ... }\n\n// This does not\nif (options.someOption) { ... }\n
\n
\n

Important

\n

The in operator searches up the prototype chain too, so use with caution, when you know that the object's\nhierarchy doesn't interfere with the props you're interested in. If you want to be sure you're only targeting the\nspecific object and not its inherited props, use Object.prototype.hasOwnProperty\nor the more recent Object.hasOwn.

\n
\n

When it comes to type safety, the in operator and hasOwn/hasOwnProperty functions don't excel and are quite\nsusceptible to errors caused by prop name changes. But TypeScript comes to the rescue in these cases:

\n
if (('someOption' satisfies keyof typeof options) in options) { ... }\n\n// Or if you have direct access options' type\n\nif (('someOption' satisfies keyof Options) in options) { ... }\n
\n

This gives us a nice type error if the prop name is misspelled or was renamed, and enables auto-refactoring.\nHere, look how beautifully WebStorm refactors everything 🥹:

\n

\"WebStorm

\n

The for...in loop, I'll be honest that's a bit harder to recommend, especially since in recent ES versions we have\nmany new and less controversial tools at our disposal (see Object.entries\n, Object.keys,\nObject.values),\nbut granted that:

\n
    \n
  1. you don't mind prototype properties from being included (or having to add an hasOwnProperty/Object.hasOwn\ncheck otherwise),
    2. \n
  2. you don't mind about corner cases such as iterating over arrays (for which for...of would be more suitable anyway),
    3. \n
\n

if you really want to use it here's a little TypeScript trick you can use to make it more type-safe. The immediate\nthought would be to type the key variable, but unfortunately that's not supported.

\n
for (const key: keyof Options in options) {\n        // ^^^ TS2404: The left-hand side of a for...in statement cannot use a type annotation.\n}\n
\n

The interesting thing is that the variable part of the for...in loop takes an entire LeftHandSideExpression\n(basically whatever can go to the left of an equal = sign of an assignment). This means that we can declare the\nvariable outside and type it correctly (or even assign it to a property of an object!).

\n
let key: keyof Options;\nfor (key in options) {\n  // key is typed!\n}\n
\n

Generators and async generators

\n

Ok, well, generators are not really a quirky feature, they're a very powerful, well-thought-out and spec'ed tool, but\nI'm including a chapter on them since they have a peculiar syntax that is quite intimidating at times. And I'd\nlike to do that by citing a library (Effect) that\nuses them to do something quite incredible: adding type-safe errors and dependency injection to the language. Take a\nlook at this code extract from their website (which I recommend visiting, they have some awesome hover types):

\n
import { Effect } from 'effect';\n\nconst addServiceCharge = (amount: number) => amount + 1;\nconst applyDiscount = (\n    total: number,\n    discountRate: number,\n): Effect.Effect<number, Error> =>\n    discountRate === 0\n        ? Effect.fail(new Error('Discount rate cannot be zero'))\n        : Effect.succeed(total - (total * discountRate) / 100);\nconst fetchTransactionAmount = Effect.promise(() => Promise.resolve(100));\nconst fetchDiscountRate = Effect.promise(() => Promise.resolve(5));\n\n// This is automagically typed to Effect.Effect<string, Error, never>\n//                                                |       |      |\n//                                             return  errors  services\nconst program = Effect.gen(function* () {\n   const transactionAmount = yield* fetchTransactionAmount;\n   const discountRate = yield* fetchDiscountRate;\n   const discountedAmount = yield* applyDiscount(\n       transactionAmount,\n       discountRate,\n   );\n   const finalAmount = addServiceCharge(discountedAmount);\n   return `Final amount to charge: ${finalAmount}`;\n});\n\nEffect.runPromise(program).then(console.log);\n
\n

The generator syntax allows to perform operations in a synchronous-looking code, while automatically keeping track of\nall the possible successful return types, error types and even dependencies that might be required by the code block,\nwithout needing to explicitly declare the dependency at all!

\n

Somewhat unreadable, but absolutely beautiful ✨

\n

Labels

\n

Another lesser-known, somewhat weird feature of JavaScript that has surprising uses is labelled statements.\nIt's meant to be used to mark loops with a name that can be passed to break and continue to manipulate complex\nnested loops:

\n
let i, j;\n\nloop1: for (i = 0; i < 3; i++) {\n  loop2: for (j = 0; j < 3; j++) {\n    if (i === 1 && j === 1) {\n      // Without the label we would only be able to break the inner loop\n      break loop1;\n    }\n    console.log(`i = ${i}, j = ${j}`);\n  }\n}\n
\n

But, of course, someone found an absolute genius way to apply them to a completely different use case: Svelte\n(up to version 4) used them to mark statements as reactive. Basically the equivalent of React's derived state\nhooks (useMemo, useCallback), but without the dependency array.

\n
<script>\n\texport let title;\n\texport let person;\n\n\t// This will update `document.title` whenever\n\t// the `title` prop changes\n\t$: document.title = title;\n\n\t$: {\n\t\tconsole.log(`multiple statements can be combined`);\n\t\tconsole.log(`the current title is ${title}`);\n\t}\n\n\t// This will update `name` when 'person' changes\n\t$: ({ name } = person);\n</script>\n
\n

Unfortunately they ended up removing this exquisitely elegant reactivity model because of the poor portability, what\na pity...

\n

Directive prologues

\n

Another peculiar trait of the language that has been used in unique ways is directive prologues. Remember the good old\ndays when we were supposed to start all our JavaScript files like this?

\n
'use strict';\n
\n

That's a directive prologue. One or more expression statements made of only string literals at the beginning of a\nfile or of a function body. In the use strict case, it was used to configure the execution of the subsequent code\nusing strict mode. I never thought I'd write about this in 2025 but apparently this trend is in vogue again with\nReact, to mark server/client components.

\n
'use server';\n'use client';\n
\n

Spread operator

\n

Again not necessarily a quirk, but it's worth mentioning that people are doing pretty crazy stuff with this too, see https://dev.to/jonrandy/js-magic-making-a-range-syntax-55im\nfor example.

\n

To conclude

\n

In the years I've been using this language, I've seen a bit of everything: it's genuinely incredible what people manage\nto do with it, and how fast it's evolving every year with new syntaxes, functionalities, and APIs.\nI think we sometimes underestimate just how flexible and open JavaScript is, and how that openness allows for everything\nfrom imperative to declarative to functional patterns and so much more.

\n

That's it, I hope you enjoyed this detour into oddities and came away with something both interesting and useful.\nHappy coding!

", "url": "https://umbo.dev/articles/use-js-quirks-at-your-advantage", "title": "Use JavaScript quirks at your advantage", "summary": "Dubious null representations, creative equality checks, funky object behaviors. These are usually JavaScript meme material. But what if I told you that, if used with caution, some of these quirks may turn out to be useful?", "image": "https://umbo.dev//article-assets/use-js-quirks-at-your-advantage/cover.webp", "date_modified": "2025-10-16T00:00:00.000Z" }, { "id": "velociraptor-an-npm-style-script-runner-for-deno", "content_html": "
\"The
#deno#package.json#npm#scripts

Velociraptor, an alternative to npm scripts for Deno

Velociraptor is a script runner for Deno. It offers a similar experience to npm scripts, but with out-of-the-box support for declarative Deno CLI options, environment variables, concurrency and git hooks.

I've been playing around with Deno in the last few months (if you haven't already, try it out, it's awesome) and one of the things that frustrated me the most was that I easily ended up writing endless deno cli commands, like this:

\n
deno run --allow-read --allow-write --allow-net --config tsconfig.json --importmap importmap.json --reload file.ts\n
\n

I mean... I just wrote it and I've already forgotten it 🤦‍♂️

\n

The instinctive reaction of my webdev-y brain was:

\n
\n

Easy. Let's write it down in a package.json script.

\n
\n

Yeah, no. There ain't no package.json in the land of Deno.

\n

So I left aside my acute npm run nostalgia and started working on an alternative for Deno, and after some weeks of coding here it is:

\n

https://github.com/jurassiscripts/velociraptor

\n

To get started, install it with deno install:

\n
deno install -qA -n vr https://deno.land/x/velociraptor/cli.ts\n
\n

Then create a file called scripts.yaml (.json and .ts are supported as well) in your project folder

\n
scripts:\n  start: deno run my-script-file.ts\n
\n

and run the start command

\n
vr start\n
\n

In this form script files are essentially a remake of the scripts section of package.json: keys are script names, values are arbitrary shell scripts. But there's more.

\n

More script options

\n

Use objects to superpower your scripts:

\n
scripts:\n  start:\n    cmd: deno run server.ts\n    desc: Starts the server # This description is shown in the list\n                            # of available scripts when running vr\n                            # without arguments\n
\n

Compact deno run

\n

When a script starts with a .ts or .js file, deno run is automatically prepended:

\n
scripts:\n  start: server.ts # Equivalent to deno run server.ts\n
\n

Env variables

\n

Use env to pass env variables to the scripts

\n
env: # Sent to all the scripts\n  PORT: 80\nscripts:\n  start-dev:\n    cmd: server.ts\n    env: # script-specific override\n      PORT: 8080\n  start-prod: deno run server.ts\n
\n

Deno cli options

\n

A subset of deno cli options can be passed to the scripts (to name a few: --allow-* permissions, tsconfig.json, import maps, lock files...)

\n
scripts:\n  start:\n    cmd: server.ts\n    allow:\n      - net\n      - read\n    tsconfig: tsconfig.json\n    imap: importmap.json\n\nallow: # Global options\n  - write\n
\n

Compound scripts

\n

A list of commands is executed in series

\n
scripts:\n  start:\n    - deno run one.ts\n    - deno run two.ts\n
\n

and parallel commands are supported as well

\n
scripts:\n  start:\n    pll:\n      - deno run one.ts\n      - deno run two.ts\n
\n

Bonus

\n

Support for husky-style git hooks is coming soon! 🐶

\n

Check out the documentation in the repo for more details.

\n

Hope you'll find it useful! 🙌

", "url": "https://umbo.dev/articles/velociraptor-an-npm-style-script-runner-for-deno", "title": "Velociraptor, an alternative to npm scripts for Deno", "summary": "Velociraptor is a script runner for Deno. It offers a similar experience to npm scripts, but with out-of-the-box support for declarative Deno CLI options, environment variables, concurrency and git hooks.", "image": "https://umbo.dev//article-assets/velociraptor-an-npm-style-script-runner-for-deno/cover.webp", "date_modified": "2020-05-14T00:00:00.000Z" }, { "id": "wires-tubes-and-fancy-switches-how-i-built-my-smart-home", "content_html": "
\"A
#smarthome#matter#thread#ikea

Wires, tubes and fancy switches: how I built my smart home

These days smart homes are all about wireless, battery powered devices, cloud connections and walled gardens. When I renovated my apartment I wanted something more solid, privacy-conscious, and long lasting.

\n

Important

\n

Disclaimer: I'm not affiliated or paid by the companies cited in this article. All opinions are personal and\ndo not constitute commercial advice.

\n
\n

It all started when

\n

In 2023 I bought my first apartment. It was in terrible conditions after many years of neglect, but it's a stone's\nthrow away from the city center and in a beautiful 1923 art deco building with a lot of character. So I decided to\ntake the plunge and do the kind of renovation that scares your contractor. Construction fun aside, this gave me\nthe opportunity to start from scratch, and explore my wildest software engineer home automation dreams.

\n

The ground rules

\n

This is more or less what I wanted to accomplish:

\n
    \n
  1. Essential appliances should work without an internet connection, after power outages and not be subject to\nwireless signal issues.
    2. \n
  2. Essential automations should run locally, preferably on-device and then be exposed to a smart home system, not\nthe reverse.
    3. \n
  3. Wall switches should work like in traditional installations. In general, things should have some sort of manual\ncontrol or override.
    4. \n
  4. Non-essential appliances can be wireless, but use a unique connectivity protocol, hub and automation system.
    5. \n
\n

Bonus rule: I knew that renovating was going to be very expensive and full of surprises, so I wanted to keep costs\ndown as much as possible.

\n

The essential part

\n

Options I considered

\n

To commit to rule number 1 –and since I was starting from scratch– I decided to use a wired setup for all essential\nlights and wall switches, controlling them through a central unit. For this role, I considered different\nproducts and protocols. My geeky side would have wanted to run everything (lights, thermostatic valves, security\nsensors, etc.) on the KNX standard. Unfortunately, I encountered more\nresistance that anticipated from electricians: it's quite common in industrial settings, but it's not easy to find\nprofessionals willing to work on domestic installations. Time was running out, so I had to take the sad decision\nto abandon it.

\n
\n

Note

\n

If you're interested in KNX installations, there's a nice company called Ekinex not far\nfrom here that makes some stunning domestic KNX electrical components.

\n
\n

Going back to more \"traditional\" switch controls, I considered the\nControl4 DIN-Rail 8 channel relay switch,\nbut I would have needed to buy at least two units to cover all the essential lights of the apartment, and I didn't\nhave enough space in the central unit for them. Also, the Apple Home integration didn't seem too easy to set up,\nrequiring paid dealers assistance and dedicated drivers.

\n

Final choice

\n

I ended up installing all electrical conduits with a centralized topology, running controls and power lines directly\nfrom the central unit to the appliances and wall switches. This might seem normal to some, but it's actually quite\nunusual here in Italy and in many other European countries, where we usually adopt a tree topology, and run switches\nin-line with the power delivery to the lights.

\n

What really made the difference was finding the Atios SmartCore\nall-in-one\nsmart controller. It's an absolutely clever piece of equipment made by a Swiss home automation company. It\noffers 12 input and output channels, Ethernet and DALI connections with local programming and built-in Matter/Apple\nHome integration, all within a 10-units din-mounted device.

\n\"Atios\n

I decided to use it to control all the 12 essential lights in the house (ceiling/wall mounted or floor lamps\npermanently connected to the same wall outlets). The control signals come from push buttons from around the house,\nsome of which I simply wired in parallel, to control the same light from multiple points of the apartment. They (and\nthe other wall-mounted components) are from the\nBiticino Living Now domestic series, of which I'm a\nbig fan. I mean, aren't they beautifully overkill for being wall switches?

\n

\"Bticino

\n

The cool thing here is that they adopted a momentary push mechanism for both switches and push buttons, so they\neffectively look, and behave the same (as in they click and retract immediately). This is great for smart homes,\nbecause you can mix the two types together without even noticing the difference between normal switches and \"smart\"\nbuttons.

\n

Lights programming

\n

In accordance with rule #2, the button-to-light programming is done on-device through SmartCore's web UI. It's simple,\nbut more than enough for the basic functionality of lights and other devices such as garage door openers, smart\nlocks etc., which I didn't need.

\n

\"Atios

\n

If internet goes away, physical buttons still work. If power goes away, a couple of seconds after it comes back\neverything starts working as normal again. Solid.

\n

All of this gets exposed to Apple Home instantly, by scanning a QR code from the web interface. The SmartCore\nappears as a home gateway, listing all the devices programmed locally so you can integrate them into your home\nautomation system. A nice thing is you can expose the same input devices that are used for the local mapping as\n\"Programmable Switch\", so you can assign secondary actions (i.e. long press) to advanced automations. For example,\nI set up the switch just next to the entrance door to trigger the Leave Home scene, which turns off all the lights in\nthe apartment, when I long press it just before going out.

\n

The non-essential part

\n

All the permanent light fixtures are covered by the smart controller, but there are, of course, more than 12 lights in\nthe apartment and other devices I wanted to control. Some of them (that I rarely use) are just manually activated and\nthat's fine. For the rest, the plan was to stick to rule #4: one hub, one network, one protocol, one automation system.

\n

Options I considered

\n

As for hubs, I had previously experimented with Raspberry PIs/home servers running OpenHab or Home Assistant. The\nformer was a bit of a configuration nightmare with so many abstract concepts and exotic Java-like DSLs, even though\nit had a nice interface. The latter seemed a bit unreliable and easy to brake at the time (it was around 2019, now\nthings have improved a lot) but most of all I always found the UI very convoluted, and I think that still holds. I\ntried to expose the devices to Google Home too, which worked ok for the most part, but I've never loved the experience\ntoo much.

\n

Network-wise, I tried some Z-Wave devices in the past without much success, but to be frank the unreliability was\nprobably because of the devices themselves and the usb dongle I used. Regardless, Z-Wave devices are quite hard to\nfind here, and are usually quite pricey and complicated to use, so I decided to try someting new.

\n

Final choice

\n

Given that:

\n\n

I decided to give Apple Home + Matter over Thread a go.

\n

Extra lights

\n

I try to avoid smart bulbs if possible since they are not manually controllable without losing the smart part. For\nthis area I would have preferred to use smart relays or plugs with integrated buttons, but the Matter over Thread\nmarket is still in its infancy and in 2+ years of waiting I couldn't find anything reasonably priced or small enough\nfor an in-cord installation. But... Ikea just presented their super cheap new Matter over Thread devices, so I\ndecided to do a bit of experimenting with the\nKajplats\nsmart bulbs. I've heard complaints about reliability and onboarding, but for me the experience was flawless. I'm using\nthe Bilresa smart remote\nto control those bulbs and also trigger additional scenes and actions on double or long press. Bonus point: the\nremote has a magnet on the back that holds perfectly on the metallic corner beads we installed when renovating. They\nmagically stick to the wall!

\n

Climate control

\n

For keeping the condo heating bill in check I'm using some Aqara W600\nMatter over Thread thermostatic valves. They seem to work pretty well, and integrate seamlessly into Apple Home just\nby scanning the Matter QR code.

\n

Access control

\n

Another Aqara Matter over Thread product I'm testing is the U200 Lite.\nI had a bit of trouble getting it to stick properly to the door panel since the handle and lock casing is very thick,\nbut I'm working on a 3d printed base that aligns it properly. For the rest it's working ok!

\n

Deviations from the rules

\n

The main deviation from the rules is the Samsung dual-split AC system: it's smart, but it only connects to the\nSmartThings ecosystem over WiFi, not ideal. The other notable exception is the Ring Intercom: only WiFi, only Ring\necosystem. This brings me to the bridge: I have a small homelab server at home, where I installed Home Assistant for\nthe purpose of bridging these unsupported devices to Apple Home. This has been working ok, with some occasional hiccups\nand limitations.

\n

Things I wasn't able to automate

\n

Of course not all the appliances in the apartment are smart, let alone with Matter support. For the most part that's\nfine, but there are things I would have wanted to automate and couldn't, like the electric water heater. This can be\nsometimes mitigated with simple smart plugs, relays or by \"implanting\" dev boards like ESP32s in the device itself.\nThe third option is becoming increasingly interesting now that ESP32 compatible boards with Thread support are being\nreleased.

\n

Drawbacks of a unified architecture

\n

Trying to rely on a single hub, network and automation system is not easy, and it naturally has some drawbacks. Most\nnotably: being able to find relatively cheap Matter over Thread devices and integrate them in Apple Home in\nliterally less than one minute is an indescribable pleasure, but manufacturers usually incorporate advanced features\nin their devices that go beyond the intrinsic simplicity of what the Matter protocol can describe. For example, the\nAqara smart lock can be configured to auto-open and close when slightly turning the key, but that's only possible if\nyou double-pair the lock with the Aqara app too, something I wasn't able to do with the thermostatic valves. It\ngets even worse when you discover that other more advanced features are only available if pair them to the Aqara hubs.

\n

To sum up: with Matter you get simplicity, reliability and compatibility at the cost of some advanced device\nfeatures. I think it's a reasonable tradeoff, but not all may agree.

\n

Why am I only writing this now?

\n

This smart home has been 2+ years in the making, but the difficult choice of relying on Matter over Thread devices\nhas led to a lot of waiting, and endless web searches for new devices. Matter devices are just starting to gain\ntraction now, but I think this will be beneficial in the long term.

\n

Future plans

\n

I have a lot of plans for new devices and automation that will be possible with new Matter devices and, time\npermitting, with a bit of hardware hacking too. Just to hint a few: smart blind shades\nactuators, in-cord relays with buttons to control lamps...\nI'm currently also working on a custom wired alarm system with Matter compatibility; stay tuned for new articles!

\n

The costs

\n

The SmartCore costed ~ € 670 (shipping and CHF conversion fee included) at the time, it's now listed for € 599. It's\nnot cheap by any means, but it's infinitely expandable and contains all the tools you need for an end-to-end\ninstallation (up to the Apple Home integration). You can achieve similar results by using different DIN-mounted\ndevices for the relays, DALI or KNX controls and bridging to Apple Home (or your favorite smart home system), but\nI'm afraid the costs would be higher. In comparison, an all Philips Hue installation of around 20 lights could cost\nmore than € 400, without physical buttons to activate the lights.

\n

I did already own the HomePod Minis (bought used from a friend for € 50 each), but for completeness: they're\navailable in Europe for around € 100/130. Of course there are plenty of cheaper Matter/Thread compatible hubs like\nthe Aqara M200 (~\n€ 80), the Ikea Dirigera\n(~ € 60) or a simple RaspberryPi + OpenThread. Just keep in mind that the Apple Home integration requires an Apple\nhub to run automations and access your smart home even if you're away from the home LAN. Devices that can act as home\nhubs are: the Apple TV, the HomePod/HomePod Mini or the iPad. If you need to choose, I'd recommend the Apple TV\n4K 3rd gen Wi-Fi + Ethernet, because it's the only thread enabled hub with an Ethernet connection.

\n

The Ikea Kajplats base kit\n(icludes one Bilresa remote) costed € 17, while the Kajplats\n470 lumen bulb costed € 8.95.

\n

The Aqara U200 Lite costed € 89.99 and the Aqara W600 € 49.99.

\n

Regrets and advice

\n

My main regret from the first phase (renovating and wiring) is not preparing soon enough for a KNX or DALI\ninstallation. It probably would have costed a bit more, but now I would have almost infinite expandability, and I\ncould have used the SmartCore for more interesting things on top of lights. If you're planning to renovate\ndestructively enough to redo the electrical, take a moment to consider these wired\nsystems: they're solid, local-first, and future-proof, you won't regret it!

\n

If you're retrofitting an existing installation, consider using the SmartCore or a similar controller for just the\nmain fixtures you want to automate. There are even some smaller multichannel relay modules that fit into derivation\nboxes like the Sonoff 4CHR3.\nYou can install one per room, where it's usually relatively easy to rewire switches and lights from the derivation box.

\n

Final thoughts

\n

Finding good equipment for domestic installations is hard (DALI, KNX, etc.), but that's a one-time thing you do when\nrenovating and then stop thinking about it for years, possibly decades, so it's worth the effort.

\n

As for Matter, I think people sometimes underestimate how uniquely important that is, even though it's still not\nsupported everywhere and the compatible products are still a fraction of the market. Just ask yourself: when was the\nlast time that the industry collectively agreed to co-design a completely new open internet protocol (which Matter\neffectively is, sitting on top of IP) to favor compatibility and break a terrible mess of closed ecosystems?

\n

In conclusion: I couldn't satisfy all my wildest software engineer fantasies, but this system has been working\nperfectly for almost 3 years. I learned so many things about electrical installations, smart home\nsystems, protocols, networks, heck even thermal efficiency in older buildings. This was a blast, and I think the smart\nhome space will become increasingly interesting and fun in the coming years.

\n

I keep learning things every day that I couldn't find anywhere online, so if you have any curiosities or questions feel\nfree to drop me a line on Bluesky!

", "url": "https://umbo.dev/articles/wires-tubes-and-fancy-switches-how-i-built-my-smart-home", "title": "Wires, tubes and fancy switches: how I built my smart home", "summary": "These days smart homes are all about wireless, battery powered devices, cloud connections and walled gardens. When I renovated my apartment I wanted something more solid, privacy-conscious, and long lasting. ", "image": "https://umbo.dev//article-assets/wires-tubes-and-fancy-switches-how-i-built-my-smart-home/cover.webp", "date_modified": "2026-01-30T00:00:00.000Z" } ] }