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

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

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

Unstaging changes

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

alias gunstage='git restore --staged .'

Discarding changes

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

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

Git log

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

alias gl='git log --oneline'

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

alias gll='git log'

Working with multiple remotes

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

# When you want to make sure you don't introduce merge commits
alias gpu='git pull upstream main --ff-only'

# When merge commits are fine
alias gpu!='git pull upstream main'

# If you prefer rebasing on the latest upstream main
alias gpureb='git pull --rebase upstream main'

# When you want to reset your fork branch to the last upstream commit
alias gru='git fetch upstream && git reset --hard upstream/main'

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 branch, no matter how old is the commit where I currently am, and then just gru to the latest upstream changes.

Stash management

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

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

Quick amending

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

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

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

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

Getting the current branch name

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

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

Progressing with merges and rebases

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

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

while grcont continues a rebase process:

alias grcont='git rebase --continue'

Saving work in progress

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 quite easily, and it's hard to guess which is the one you're looking for without going through diffs etc.) here's a sub-second WIP committer alias:

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

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

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 pre-push hook:

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

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 commit from the git log output and then git rebase -i <sha>^ (note the ^ at the end), marking the WIP commit for editing in the list:

edit XXXXXXX [WIP] Edit me before pushing
pick XXXXXXX Other commits
...

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

Grab 'em all

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

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 literature and social media for both fun and educational purposes where the negative aspects are –rightfully– highlighted, I think there's a positive side no one ever talks about. So pack up a bit of open-mindedness and let's see how some of these characteristics can be used at the developer's advantage and how even famous libraries use them in creative ways.

Representing empty values

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

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

• return; statements with no value,
• non-existent object properties (obj.undeclaredProp),
• uninitialized variable declarations (let emptyVar;),
• and as "empty" return value of many standard library methods (see Array.prototype.find() for example).

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

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

let preferredLayout: string | null | undefined;

preferredLayout = await loadPreferredLayout();

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

const Component = ({prop = 'defaultValue'}) => { ... };

// If you pass `null` here, `defaultValue` will not be used
<Component prop={condition ? 'value' : undefined} /> 

Loose equality

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

// !== null would exclude undefined
if (varThatMightBeEmpty != null) {
}

// This is even more concise, but you may not be able to use it if
// you have to take into account non-nullish but falsy values, like empty strings
if (varThatMightBeEmpty) {
}

Arrays are objects

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

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

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

'01-02-2025'.match(/(?<day>\d{1,2})-(?<month>\d{1,2})-(?<year>\d{2,4})/);

// ['01-02-2025', '01', '02', '2025', index: 0, input: '01-02-2025', groups: {day: '01', month: '02', year: '2025'}]

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

The in operator and for...in loop

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

// This passes even if options = { someOption: undefined }
if ('someOption' in options) { ... }

// This does not
if (options.someOption) { ... }

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

if (('someOption' satisfies keyof typeof options) in options) { ... }

// Or if you have direct access options' type

if (('someOption' satisfies keyof Options) in options) { ... }

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

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

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

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

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

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

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

Generators and async generators

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

import { Effect } from 'effect';

const addServiceCharge = (amount: number) => amount + 1;
const applyDiscount = (
    total: number,
    discountRate: number,
): Effect.Effect<number, Error> =>
    discountRate === 0
        ? Effect.fail(new Error('Discount rate cannot be zero'))
        : Effect.succeed(total - (total * discountRate) / 100);
const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100));
const fetchDiscountRate = Effect.promise(() => Promise.resolve(5));

// This is automagically typed to Effect.Effect<string, Error, never>
//                                                |       |      |
//                                             return  errors  services
const program = Effect.gen(function* () {
   const transactionAmount = yield* fetchTransactionAmount;
   const discountRate = yield* fetchDiscountRate;
   const discountedAmount = yield* applyDiscount(
       transactionAmount,
       discountRate,
   );
   const finalAmount = addServiceCharge(discountedAmount);
   return `Final amount to charge: ${finalAmount}`;
});

Effect.runPromise(program).then(console.log);

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

Somewhat unreadable, but absolutely beautiful ✨

Labels

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

let i, j;

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

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

<script>
	export let title;
	export let person;

	// This will update `document.title` whenever
	// the `title` prop changes
	$: document.title = title;

	$: {
		console.log(`multiple statements can be combined`);
		console.log(`the current title is ${title}`);
	}

	// This will update `name` when 'person' changes
	$: ({ name } = person);
</script>

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

Directive prologues

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

'use strict';

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

'use server';
'use client';

Spread operator

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 for example.

To conclude

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

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

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:

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

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

The instinctive reaction of my webdev-y brain was:

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

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

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:

https://github.com/jurassiscripts/velociraptor

To get started, install it with deno install:

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

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

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

and run the start command

vr start

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.

More script options

Use objects to superpower your scripts:

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

Compact deno run

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

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

Env variables

Use env to pass env variables to the scripts

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

Deno cli options

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

scripts:
  start:
    cmd: server.ts
    allow:
      - net
      - read
    tsconfig: tsconfig.json
    imap: importmap.json

allow: # Global options
  - write

Compound scripts

A list of commands is executed in series

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

and parallel commands are supported as well

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

Bonus

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

Check out the documentation in the repo for more details.

Hope you'll find it useful! 🙌

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.

It all started when

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

The ground rules

This is more or less what I wanted to accomplish:

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

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

The essential part

Options I considered

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

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

Final choice

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

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

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

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

Lights programming

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

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

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

The non-essential part

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

Options I considered

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

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

Final choice

Given that:

• I've been a fan of Matter (formerly Connected Home Over IP) from the early days,
• I've read many good things about Thread being a better version of Zigbee,
• I've been an Apple user for quite some time and enjoy the simplicity of the Home app and ecosystem,
• I had a couple of HomePod Minis lying around, which are also Thread border routers,

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

Extra lights

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

Climate control

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

Access control

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

Deviations from the rules

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

Things I wasn't able to automate

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

Drawbacks of a unified architecture

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

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

Why am I only writing this now?

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

Future plans

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

The costs

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

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

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

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

Regrets and advice

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

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

Final thoughts

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

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

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

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