For the longest time, I’ve resisted the urge to make my home smart, because I’ve always heard how difficult it was and how it made no sense unless you owned your home. The examples I’d seen were not at all that impressive either. I’ve visited supposed “smart” homes that involved shouting “Okay Google, turn on the lights” when entering, and having my lights be dependent on someone else’s servers being up,1 as well as having a device listening to every word I say, simply didn’t appeal to me.

Finally, in 2026, I decided that I was sick of manually controlling my lights. Why should I have to use my phone as a flashlight after turning off the bedroom lights every night? Why should I have to turn on the lights when I am working in the middle of the day and a storm comes? Surely, there must be a better way…

Thus, I did some research and quickly learned that most of the supposed difficulties were overblown. With less than a $200 investment and a day’s work, I was able to control all my lights at will, with lights automagically turning on depending on my presence, the availability of sunlight, and whether I’ve decided to sleep. Instead of having to ask Google or find the light switch, I can simply walk into a room, and if it’s dark, the lights just turn on.

And naturally, it’s more than just lights that could be automated. With a bit more investment, I’ve managed to automate fans, air purifiers, and perhaps created the world’s first offline smart bed. But let’s not get ahead of ourselves and instead start with the lights.

My requirements

Let me clearly enumerate my requirements for my smart home:

  1. The entire system must function locally and not depend on anything outside the home, including any cloud services. This is so that the system works regardless of any cloud outage, and my data doesn’t get uploaded to the cloud, i.e. someone else’s computer.
  2. Controls are automated as much as possible. In my mind, voice commands are no less annoying than flipping switches.
  3. Full programmability of automations. I am a software developer and will never be happy with a few pre-programmed automations in an app that don’t do exactly what I want them to do.
  4. No vendor lock-in. Everything should communicate using open standards so that I am not forced to buy parts from a specific brand, which could then jack up prices or cease to exist down the line.
  5. No opening walls. I live in an apartment, so I am not going to tear down the walls, nor redo the wiring of switches, or anything like that.

Furthermore, the following traits are desired:

  1. Cheap, affordable components;
  2. Extensibility, as I plan to continuously improve my home over the next few years; and
  3. Low maintenance burden, so no fiddling with parts more than once a quarter, e.g. for battery replacements. Ideally, it just keeps working indefinitely without intervention.

The first automation that I definitely want the system to be able to handle is:

When a room is occupied, and the outdoor sunlight intensity is below a threshold, the lights turn on. Otherwise, the lights turn off.

The controller

To build a smart home, there has to be something controlling all the devices. There really is only one good option here, and that’s Home Assistant, which is free and open source. It’s also highly interoperable, allowing basically any brand of hardware or any communication protocol to be used together through various “integrations.” It also happens to be the most popular option, so using it was a no-brainer.

There are several ways of running Home Assistant, such as buying dedicated hardware that comes with Home Assistant Operating System (henceforth HAOS) preinstalled, or installing HAOS on a single-board computer like a Raspberry Pi, or installing it in a container or virtual machine on an existing system. If you are following along, please feel free to choose whichever option you find is the easiest.

In my case, since I already have a Linux home server, I decided I might as well use that instead of getting a separate machine to worry about, so I only had to decide whether to install Home Assistant as a container or use an HAOS VM. Since container installs can’t use Home Assistant Apps, and several common integration for communication protocols require apps, I decided to go with a VM for my sanity.

I simply downloaded the qcow2 image for HAOS and configured it with virt-install, following the instructions. It was a very painless process. For the VM, I went with 2 GiB of RAM, as I have some apps that need the RAM, which we’ll discuss in a future post. For the basic use cases here, 1 GiB is plenty.

I also decided to put HAOS and anything related to it on a separate VLAN at home, reachable over Wi-Fi on a separate SSID. This adds some degree of isolation for the smart home stuff from various other things at home, serving as a defence-in-depth measure. If your networking hardware at home doesn’t support this, or you don’t know how to do this, then note that it’s optional. Also, if you have random IoT appliances that communicate with the cloud over Wi-Fi, you should put them in a different VLAN2 from Home Assistant and everything else, since these sketchy devices are unlikely to be secure and also don’t need to directly communicate with Home Assistant.

Hardware requirements

We then need to decide what kind of hardware is required to accomplish the desired automations. We’ll start with just the automatic lights, though I would end up getting a lot more than this for additional features down the line.

To automate lights based on human presence and outdoor sunlight intensity, we definitely need:

  • human presence sensors;
  • light intensity sensors; and
  • some mechanism to control the lights.

There are two common ways to control the lights—smart bulbs and smart switches. As installing smart switches would require a bunch of electrical work, and perhaps running additional wires in the walls if the switches only had access to the live wire and not the neutral,3 while light bulbs are designed to be easily swappable, I decided to go with smart bulbs.

Smart bulbs also have the advantage of allowing the colour to be adjusted. There are two common types of smart bulbs:

  • Correlated Colour Temperature (CCT), which can only emit white light, but at different colour temperatures; and
  • Red Green Blue (RGB), which can emit any colour in the RGB colour space. Usually, RGB bulbs also come with CCT capabilities.

Naturally, CCT bulbs are cheaper than RGB. Since I don’t really want crazy colour effects, I decided to just go with CCT.

Also note that for some smart bulbs with both CCT and RGB, the maximum brightness in RGB mode is laughably low compared to CCT. Make sure you check the reviews.

Communication protocols

Since we refuse to use the cloud, we’ll need a different mechanism for Home Assistant to talk to our hardware. We’ll focus on physical layer protocols, since higher-level protocols can usually be handled in software.

The following wireless physical layer protocols exist:

  • Wi-Fi: the common home wireless network standard. While Wi-Fi is readily available, it isn’t suited for low-power devices due to its battery requirements.4 Note that we only care about devices that support talking to Home Assistant directly over Wi-Fi and not via the cloud. As such, if you are using a separate VLAN, the devices will need to connect to the dedicated SSID. Also note that most cheap devices only support 2.4 GHz, not 5 GHz or 6 GHz.
  • Zigbee: an older low-power wireless mesh network standard with shorter range and much lower speed than Wi-Fi, also running over the 2.4 GHz band.
  • Thread: a newer low-power wireless mesh network standard like Zigbee, also running on 2.4 GHz, but uses IPv6 as the transport layer on top, instead of a custom protocol like Zigbee.
  • Z-Wave: a low-power mesh network similar to Zigbee, but uses the 900 MHz band, which gives it a longer range while avoiding interference on the potentially congested 2.4 GHz band.
  • Bluetooth: a low-power, non-mesh network, also running over 2.4 GHz, commonly used for things like wireless headphones.

You might also hear about the term “Matter,” which is actually an application layer protocol running on top of IPv6. It can use either Wi-Fi or Thread as transport. When you hear “Matter-over-Thread,” it means Matter is used over the Thread physical layer.

At this point, you might find this all confusing, as I certainly did when I first did the research, but here are the important things to know:

  1. Wi-Fi is not suitable for anything battery-powered, unless you like charging it frequently;
  2. Mesh networks like Zigbee, Thread, and Z-Wave can have their ranges extended by repeaters, while you are going to have a hard time with Bluetooth due to range limits;
  3. Any device on the network that’s plugged into AC power can act as a repeater for mesh networks, e.g. smart bulbs or smart plugs;
  4. You can buy a lot of Zigbee devices for really cheap on AliExpress, including sensors, bulbs, and smart plugs;
  5. Thread is the standard that everyone seems to be moving to, e.g. IKEA discontinued their entire Zigbee smart home line and replaced it with Matter-over-Thread;
  6. Z-Wave devices are quite expensive, but some people swear by them due to greater stability and range, most likely because they live in places where 2.4 GHz is saturated; and
  7. I have not personally experienced any connectivity issues with a properly designed Zigbee or Thread network.

I ultimately decided to get hardware that supports both Zigbee and Thread, so that I can benefit from cheap AliExpress sensors and also newer hardware in the future. Note that if you want to run both, you should get hardware with two separate radios, not one of those “multiprotocol” ones that attempt to multiplex Zigbee and Thread on the same radio, which have stability issues.

There are quite a few dual-radio devices, but I ultimately went with the SLZB-MR3U, because it has nice software and is also PoE-powered, so I can put it anywhere with just Ethernet and simply use VLANs on my switch to get it to talk to the HAOS VM. There are also USB-powered versions, but that would require annoying USB passthrough logic for the VM and limit where I can put it, due to USB range limits. I bought the SLZB-MR3U on AliExpress for US$48.44. The cheaper SLZB-MR1U probably would have also worked, but the MR3U had better hardware for only a few dollars more.

Also note that on the Home Assistant side, there are two implementations of Zigbee: ZHA and Zigbee2MQTT. Zigbee2MQTT is the newer option and supports more devices, so I decided to use that.

Hardware choices

Now that we know what kinds of hardware we want and which communication protocols to use, we can shop for the hardware, starting with the lights.

For the human presence sensors, I found these really cheap mmWave motion sensors on AliExpress, going for less than US$5 each, while also coming with temperature, humidity, and luminance sensors. While it doesn’t say on AliExpress, the devices identify as HOBEIAN ZG-204ZV, and you can see more details on the Zigbee2MQTT information page. Basically, you want something like this listing with the “Type 3 for Z2M” “colour,” but you can get it for much cheaper as an AliExpress bundle deal. Just make sure it says Zigbee2MQTT and have temperature and humidity as well, since those will come in handy later. These also require two standard AAA batteries each.

Note that while these motion sensors come with luminance sensing (at least, if you choose to not cheap out), I chose to not exercise the feature. This is because I wanted the lights to turn on while I am in the room if it gets dark, and off when it’s no longer dark, and I don’t want it to see the lights being on as a reason to turn off the lights, which would be annoying.

For the outdoor light sensor, I decided to get the Zigbee2MQTT version of this sensor, which identifies as the HOBEIAN ZG-106Z. It’s cheap and seems fairly accurate based on my testing, easily detecting brightness drops due to cloud cover and rain. It should ideally be taped facing outside on a window, as far from any indoor lights as possible.

For the light bulbs, I decided that I wanted to get something better than the generic stuff on AliExpress, ideally a model that I can get more of down the line. This is because not all smart bulbs emit the exact same colour even when set to the exact same CCT setting, and the difference in colour is going to bother me. I also wanted something with a high colour rendering index (CRI), so that colours would look better. It’s known that low CRI lights can make food look unappetizing, and that’s something I wanted to avoid.

I ultimately decided to get a bunch of IKEA Kajplats5 “smart white” light bulbs, with different brightness based on where I intend to deploy them. I expect this product line to be around for years, and they supposedly have >90 CRI, which is considered good. Note that the RGB and CCT (“smart white”) versions look almost the same, except that the bulb on the box of the RGB version is red, blue, and green, while the CCT version is blue and yellow. Don’t accidentally buy the wrong one!

Also note that IKEA sells Kajplats “starter kits,” each of which comes with a Bilresa6 smart button for much cheaper than buying them separately. You probably want a bunch of those buttons to send commands to Home Assistant. And don’t bother with IKEA’s Dirigera7 hub since we have the SLZB-MR3U already, which performs the same function, but better.

So I bought a few of the 450-lumen variant for desk lamps, the 1100-lumen variant for general room-wide illumination, and 1600-lumen variants for places where I want to see a lot of detail, like the kitchen and bathroom. Replacing all the light bulbs at home set me back around CA$100 or so.

I also grabbed a few AliExpress Zigbee smart bulbs to act as repeaters to extend my Zigbee mesh, since I get connectivity drops to my Zigbee sensors after going through multiple walls otherwise. I deployed them in obscure places that rarely get turned on to avoid the colours clashing. In retrospect, it might have been smarter to get smart plugs or force a few Kajplats bulbs into Zigbee fallback mode instead, since the colours would match perfectly.

For Thread, with all the IKEA Kajplats bulbs spread around my home, the signal is excellent everywhere.

For the AAA batteries in the sensors, I decided to get rechargeable batteries. While they have smaller capacity compared to the single-use ones, I felt that it’s better to not have to go out and buy more batteries, then worry about disposing of the dead ones. Eneloop is commonly regarded as the best rechargable AAA battery brand, and they are also available from IKEA under the name Ladda8. So I simply got a bunch of Ladda batteries and Stenkol9 chargers for my sensors when I got the smart bulbs.

Note that the cheap AliExpress sensors are not designed with NiMH rechargeable batteries in mind, so the battery percentage reported is often wildly off. A full charge shows up as around “50%” and drops to “5%” after 6 weeks, but I’ve had sensors operating on “5%” for over 4 months and still going strong. I expect these NiMH batteries to require recharging no more than twice a year.

Setting up the radios

Setting up the SLZB-MR3U was as easy as screwing in the antennæ, plugging in the PoE, and navigating to the IP address assigned via DHCP. If you are using something else, please check the manufacturer’s documentation.

Note that the port on my switch is configured for the Home Assistant VLAN, and my server is connected to the same switch via a trunk port. The HA VLAN is added to the same Ethernet bridge as the HAOS VM, allowing Home Assistant to talk directly to the SLZB-MR3U, but nothing else. All inbound connections are blocked via the firewall also, except via nginx reverse proxy. Note that if you don’t know how to do this, you can always run it on the same network as everything else at home.

For the SLZB-MR3U, I configured the Silicon Labs EFR32MG24 chip to run in “Thread to remote OTBR” mode, and the Texas Instruments CC2674P10 to run in Zigbee Coordinator mode. While I could have configured it the other way around, I’ve heard that the TI chip is more stable for Zigbee and the Silicon Labs one is better for Thread, and I’ve not had any issues with this setup.

Note that I am using “Thread to remote OTBR” mode as opposed to the new, experimental “Thread+OTBR running on device” mode. This runs the OpenThread Border Router (OTBR) in the HAOS VM, which is the traditional setup. The experimental setup is supposed to reduce latency issues when Home Assistant is talking to the radio over Wi-Fi, but since we are using Ethernet, that’s moot. So I am sticking with the more mature option.

Once configured, you can follow SMLight’s instructions to set up Thread. In essence, you just:

  1. In Home Assistant, go to Settings → Device & services, which should bring you to the list of integrations;
  2. Add the Matter integration in Home Assistant, with the official Matter Server Supervisor app;
  3. Install the OpenThread Border Router app;
  4. Go to the configuration tab for the OpenThread Border Router app;
  5. If using USB to connect the dongle, select the SLZB USB serial port, otherwise if you are using Ethernet, select an arbitrary /dev/tty* device, then put in [IP of SLZB]:6638 into the “Network Device” field, filling in the IP and change the port if you changed it in the SLZB configuration;
  6. Set baudrate to 460800 and hardware flow control to off;
  7. Save the settings;
  8. Go back to the “Info” tab and start the OpenThread Border Router, then set it to start on boot; and
  9. Go back to the list of integrations. You should see the “Thread” and “OpenThread Border Router” integrations autodetected. Add them. If you don’t, try adding them manually.

For Zigbee, you can follow the instructions of the Home Assistant Zigbee2MQTT app. In essence:

  1. Install the Mosquitto broker app;
  2. Add the https://github.com/zigbee2mqtt/hassio-zigbee2mqtt repository to the app store;
  3. Install the Zigbee2MQTT app;
  4. In the Zigbee2MQTT app configuration, open up the serial panel;
  5. If using network transport, set port to tcp://[IP of SLZB]:7638, filling in the IP and change the TCP port if you changed it in the SLZB configuration;
  6. Set adapter to zstack;
  7. Set baudrate to 115200;
  8. Save configuration changes; and
  9. Go back to the “Info” tab and start Zigbee2MQTT, and set it to start on boot. For good measure, set Zigbee2MQTT to show in sidebar, since you’ll need to navigate to it a lot.

Adding the IKEA Kajplats smart bulbs

Pairing Matter-over-Thread devices is quite annoying and requires Bluetooth and the Home Assistant app. On Android, you will also need to have the Google Home app installed, though you don’t actually need to open it.

The first time you do this, you will need to go into the app, then Settings → Companion app → Troubleshooting → Sync Thread Credentials.

Once synced, we can begin adding a Matter-over-Thread device:

  1. Enable Bluetooth if you haven’t done so already.
  2. Ensure you are connected to the same Wi-Fi network on your phone as Home Assistant, especially if you have it on a separate VLAN.
  3. In the Home Assistant app, go to Settings → Devices & Services → Devices.
  4. Select “+ Add device,” then “Add Matter device”.
  5. Select “No, it’s new”.
  6. Scan the QR code on the Matter device, in this case, the IKEA Kajplats smart bulb.
  7. Power on the Matter device. In this case, screw it into a light socket. If the device is brand new, it should be in pairing mode already. Otherwise, you’ll need to reset it. In the case of the Kajplats bulb, powering it off for 10 seconds, then power cycling it 6 times in quick succession should do the trick.
  8. Continue the pairing process on your phone. It should manage to connect to the device, generate Matter credentials, and connect the device to Home Assistant.

At this point, the smart bulb should show up as a device in Home Assistant, and you should be able to turn the light on and off from the device page.

If it doesn’t work, I am not sure what to say since the pairing process is notoriously opaque. I guess neither Google nor Apple wants users to see scary debug details… Try double checking Bluetooth and Wi-Fi, and make sure the Home Assistant app is connecting directly to the server without going through a proxy. You may need to configure the app to use an internal URL when connected to the SSID with Home Assistant to accomplish this.

Adding the Zigbee sensors

Pairing Zigbee devices is a lot simpler. Simply click the big “Permit join” button in Zigbee2MQTT, then put the Zigbee device into pairing mode, and it should join automatically.

For the ZG-106Z light sensor, it came with a battery already, so I just had to remove the plastic piece that prevented contact, then push the reset button, which is in a hole, with a pin that came with the device for a few seconds.

For the ZG-204ZV motion sensors, I put in two Ladda AAA batteries, then pushed the reset button for a few seconds with the provided pin, until the indicator lights turn on.

In either case, the device quickly showed up in Zigbee2MQTT and also Home Assistant.

Colour temperature automation

Now that we have the sensors and smart bulbs, it’s time to make them do smart things. The first thing I wanted to do is make sure the bulbs all sync up with the correct colour temperatures befitting the time of day—that is, the colour temperature should look like sunlight (≈ 5500 K) during the day, be warmer (≈ 3200 K) at night, and even warmer (≈ 2700 K) when it is time to sleep.

This is relatively easy to accomplish with the Adaptive Lighting integration for Home Assistant, which needs to be installed through the Home Assistant Community Store (HACS). If you haven’t installed HACS, follow its installation instructions. Then, add the Adaptive Lighting HACS repository.

Once that’s installed, go to the integrations page in Home Assistant and add a new integration for Adaptive Lighting. You want to create a new instance to start with. If you have multiple types of bulbs, you may want to create an instance for each with slightly different parameters to make the colour temperatures match better, as they often produce slightly different colours despite having the same CCT setting.

In my case, I added all the Kajplats bulbs into one Adaptive Lighting instance, then set min_color_temp to 3200, max_color_temp to 5500, and sleep_color_temp to 2700 to match my desired temperatures. I am not using dimming, so I set min_brightness, max_brightness, and sleep_brightness to 100%.

Adaptive Lighting will then adjust the colour temperature based on the time of day and your local sunrise and sunset times. Since I live in Toronto and sunset is way too early in the winter, I set min_sunset_time to 19:00:00 in the advanced settings to make it pretend the sun never sets before 7 p.m.

The sleep mode will need to be triggered separately through an automation.

Sleep mode automation

Let’s start simple by creating a time-based automation to turn on Adaptive Lighting’s “sleep mode” and make the colour temperature even warmer when bedtime calls.

In Home Assistant, go to Settings → Automations & scenes → + Create automation and create a new empty automation.

Let’s say we want to turn on “sleep mode” at midnight. You should add a new trigger and find the “Time” option. Once selected, you can enter a fixed time. In this case, we want 00:00:00, and don’t select any days of the week to run it every day. Then, add an action, search for the “sleep mode” entity under your Adaptive Lighting instance, then select “Turn on switch.” You can now save the automation and name it something like “Bedtime,” and the lights will automatically become warmer at midnight.

You should also create a similar automation to turn off “sleep mode,” say at sunrise. You can repeat the same process, but use the “Sunrise” trigger and “Turn off switch” action instead.

Light automation based on occupancy

For lights, I wrote the following Home Assistant automation blueprint for occupancy-based lighting:

blueprint:
  name: Occupancy and Lux Light
  author: quantum
  description: Turns a light on based on presence and outdoor light brightness.
  source_url: https://dl.quantum2.xyz/home-assistant/occupancy_and_lux_light.yaml
  domain: automation
  input:
    occupancy:
      name: Occupancy sensor
      selector:
        entity:
          filter:
            - domain: binary_sensor
              device_class: occupancy
    illuminance:
      name: Illuminance sensor
      selector:
        entity:
          filter:
            - domain: sensor
              device_class: illuminance
    disable:
      name: Disable boolean (optional)
      default:
      selector:
        entity:
          filter:
            - integration: input_boolean
    brightness:
      name: Brightness level
      description: The brightness threshold below which the light activates.
      selector:
        number:
          min: 0
          max: 5000
          unit_of_measurement: lux
      default: 1000
    no_motion_wait:
      name: Wait time
      description: Time to leave the light on after last motion is detected.
      default: 120
      selector:
        number:
          min: 0
          max: 3600
          unit_of_measurement: seconds
    adaptive_lighting:
      name: Adaptive lighting instance
      description: The instance of adaptive lighting to control the temperatures.
      selector:
        entity:
          filter:
            - integration: adaptive_lighting
    light:
      name: Lights
      description: The light(s) to control.
      selector:
        entity:
          multiple: true
          filter:
            - domain: light
trigger_variables:
  disable: !input disable
variables:
  disable: !input disable
triggers:
  - trigger: template
    value_template: '{{ is_state(disable, "off") }}'
  - trigger: state
    entity_id: !input occupancy
    from: 'off'
    to: 'on'
  - trigger: numeric_state
    entity_id: !input illuminance
    below: !input brightness
conditions:
  - condition: state
    entity_id: !input occupancy
    state:
      - 'on'
  - condition: numeric_state
    entity_id: !input illuminance
    below: !input brightness
  - '{{ disable == none or is_state(disable, "off") }}'
actions:
  - alias: Turn on lights
    action: adaptive_lighting.apply
    metadata: {}
    data:
      entity_id: !input adaptive_lighting
      lights: !input light
      turn_on_lights: true
      transition: '0'
  - alias: Wait until there is no motion from device
    wait_for_trigger:
      trigger: state
      entity_id: !input occupancy
      from: 'on'
      to: 'off'
  - alias: "Wait the number of seconds that has been set"
    delay: !input no_motion_wait
  - alias: Turn off the light
    action: light.turn_off
    target:
      entity_id: !input light
mode: restart
max_exceeded: silent

Open your Home Assistant instance and show the blueprint import dialog with this blueprint pre-filled.

You can also manually import the blueprint by going to Settings → Automations & scenes → Blueprints → Import blueprint, then entering the URL https://dl.quantum2.xyz/home-assistant/occupancy_and_lux_light.yaml.

Once you have imported the blueprint, you should see a new automation blueprint called “Occupancy and Lux Light” under Settings → Automations & scenes → + Create automation. Create one of those and select the motion sensor as “occupancy sensor,” the sunlight sensor as “illuminance sensor,” a brightness level below which the light turns on, how long to leave the light on after motion is no longer detected, the instance of Adaptive Lighting that controls the light, and the exact lights to control. Save the automation.

If all goes well, then when you trip the motion sensor, the linked light should turn on, provided that it’s sufficiently dark outside. If you want it to always trigger, max out the brightness level.

Tip: the motion sensor can see everything in front and to the side that’s not blocked by a wall, up to around 4 m away. You should install it in such a way that it doesn’t see anything outside of the room it’s monitoring.

Living room light automations

I spend a lot of time in the living room in front of my computer, where I don’t necessarily move a lot, so using the motion sensor would result in very flaky light behaviour. Instead, I decided that the lights in my living room would be on whenever I am not sleeping.

So essentially, the lights should only be on in the living room when it’s dark outside (say, below 1500 lx), I am home, and I haven’t declared myself to be sleeping.

To determine whether you are home, you can use Home Assistant’s zones feature to declare a circle of a certain radius around your home’s GPS coordinates. The Home Assistant companion app can report whether you are in the zone periodically to the server. You can add yourself as a person in Home Assistant and declare that the device with the app belongs to you, after which Home Assistant will know you are home. Repeat this for everyone living there, and Home Assistant can easily track whether anyone is home. If this sounds complicated or is too flaky for your tastes, you can also just have the lights always turn on regardless of whether anyone is home by ignoring this aspect.

To determine whether I am sleeping, I decided to use an “input boolean” in Home Assistant, which is just a custom switch that I can toggle from automations. It’s effectively storing one bit of data. I will later show how to program a button to toggle this, but you can also just add the switch to any dashboard in Home Assistant and flip it manually from the app.

I’ve decided to use a pair of automations to keep things simpler, with one automation running to turn on the lights when the following conditions are simultaneously true:

  • Outdoor illuminance is below 1500 lx;
  • Occupancy is detected at home; and
  • The input boolean “Sleeping” is off.

The other automation turns the lights off when any of the conditions become false. It is possible to bundle all these into one automation, but I just haven’t bothered.

Note that having multiple triggers in Home Assistant means that any trigger will run the automation, so implementing the automation to turn on the lights requires setting the automation conditions instead to those mentioned above. Triggers are still needed to tell Home Assistant when to evaluate the conditions, and the following triggers are required:

  • Outdoor illuminance changes below 1500 lx;
  • Occupancy detected at home; or
  • The input boolean “Sleeping” changes to off.

For turning on the lights, I find it best to use the “Adaptive Lighting: apply” action on the desired bulbs to sync the settings. Remember to set turn_on_lights and adapt_color, and pass the correct instance of Adaptive Lighting to entity_id.

For the automation to turn off the lights, we can simply use triggers as it’s a disjunction. So the following triggers should be set:

  • Outdoor illuminance changes above 1500 lx for 10 minutes;
  • Occupancy cleared at home; or
  • The input boolean “Sleeping” changes to on.

Note that to avoid lights flickering when the sensor hovers around 1500 lx, we require the outdoor illuminance to be above the threshold for 10 minutes.

Obviously, feel free to adjust the values and perhaps even the logic here. The key advantage of Home Assistant is that it’s fully programmable, and you might as well take advantage of that flexibility.

Sleep button

Ideally, when I go to bed, I wouldn’t need to take out my phone just to tell the system that I intend to sleep. Instead, I wanted a physical button installed next to my bed that I could press for this purpose.

For the button, I decided to use a cheap Bilresa button that came with the Kajplats starter kits. They pair just the same as the Kajplats bulbs, except you enter pairing mode by opening the cover and holding down the hidden middle button until the LED inside starts blinking.

For setting up the automation against the button, I am using this blueprint, which gives the button a much nicer UI to work with:

Open your Home Assistant instance and show the blueprint import dialog with this blueprint pre-filled.

Create a new automation for the button. In my case, I select the button device and “button (1)” and “button (2)” entities, then define the actions as follows:

  • Button 1 (the big circle) single press turns on the lights in the bedroom only, overriding brightness to 20%;
  • Button 1 double press turns off the input boolean for sleeping; and
  • Button 2 (the small circle) single press turns on the input boolean for sleeping, then explicitly turns off all lights at home one by one.

Basically, I can press button 2 to turn off all the lights from the comfort of my bed, and if I need to find something in my bedroom, I can press button 1, then button 2 to when I am done. If I decide to abort my sleep attempt, I can just double tap button 1.

Remember, if you are using my occupancy automation for bedroom lights, you should set the sleeping input boolean as the “disable boolean” for that automation, unless you want the lights to randomly turn on while sleeping.

Something is required to reset the sleeping input boolean to false every morning. I have it set to motion in the bathroom after sunrise, but you can set it to more suitable things for your use case.

Conclusion

I have to say, it’s rather liberating to never have to think about turning on and off the lights ever again. No more finding light switches, no more flashlights, and no yelling at devices—the lights just automagically turn on when I enter a room and turn off after I leave. It’s definitely worth the $200 investment and a few hours’ worth of work.

In fact, I’ve become rather spoiled by this. When I stayed at a hotel recently, it took me a hot minute to realize why the bathroom lights don’t turn on when I enter. Then, every night, I’d lie down in bed and reach out for the sleep button, only to curse, crawl out of bed, turn on the bedside lamp, spend minutes turning off all the individual lights in the room, crawl back into bed, and turn off the bedside lamp. What a chore…

Next time, we shall explore all the other automations that could be done with Home Assistant and additional hardware. Stay tuned for automations against fans, air purifiers, and even doors, rain detection, fake infrared remotes, and what might just be the world’s first cloud-free smart bed.

Notes

  1. I’m sure you’ve all heard about horror stories of smart devices not working every time there’s a major outage at a cloud service provider, perhaps famously when an AWS us-east-1 outage rendered some people unable to sleep. That is absolutely not something I want in my life. ↩

  2. If you have very fast upload speeds, you also need to worry about these devices being used for DDoS attacks. Ideally, you should throttle the egress to 10 Mbps or lower. ↩

  3. Remember, a dumb switch only needs to break the circuit, and for safety reasons, this is usually done by breaking the live AC wire. Powering a smart switch would require a neutral wire to complete the circuit inside the switch, which may require a neutral wire to be run, breaking the “no opening walls” requirement. While there are battery-powered smart switches, they are undesirable due to the maintenance burden. ↩

  4. Yes, Wi-Fi is used on battery-powered devices like phones all the time, but these are devices that get charged every day or two, not less than once per quarter. ↩

  5. I always find IKEA names really funny once you know what they mean in Swedish. For example, “kajplats” means a berth, i.e. a place for a vessel to moor alongside a quay or wharf. A more literal translation is “quay-place” and it sounds surprisingly similar to that in English. Goes to show how Swedish is related to English. Still, not sure what this has to do with light bulbs… ↩

  6. “Bilresa” means car trip. “Bil” is a clipping of “automobile.” “Resa” derives from an old Germanic root meaning travel; compare German Reise. Not sure what this has to do with buttons either. ↩

  7. “Dirigera” means “to direct,” which makes sense for a smart home hub, I guess. ↩

  8. “Ladda” means to load or to charge, which makes sense for a battery. It comes from the proto-Germanic root *hlaþaną, whence English “to lade.” So it’s not a direct cognate of “load” in English. ↩

  9. “Stenkol” means “black coal,” or literally “stone coal.” I am not sure what this has to do with chargers. ↩