Using Codex + Home Assistant to build an adaptive office comfort mode

[zemismart (official)]

Hi everyone,

I wanted to share a real-world Home Assistant experiment that I have been running in my office.

The goal is simple: when I am in the office, the room should automatically keep a comfortable light and temperature level. I prefer natural light first, and I do not like the AC making the room too cold. In practice that means:

• use presence detection to decide whether the office comfort mode should be active
• use light level and curtain position before turning on lights
• keep the office temperature around 26 C
• turn things down when I leave the office
• keep manual switches available, because I still want a local fallback

The interesting part is that I am not only using Home Assistant automations. I am using Codex on my M1 Pro as a natural-language operating and debugging layer on top of Home Assistant.

My current setup

• Home Assistant as the local control layer
• Codex running on my Mac / M1 Pro
• Zemismart MT25B curtain motor
• screen display switch for manual control and status
• two human presence sensors
• one temperature and humidity sensor
• light level sensors
• light switches and AC exposed in Home Assistant

Here is the office dashboard I use while tuning the behavior:

The dashboard gives me one place to see:

• temperature and humidity
• desk-side and window-side illuminance
• two presence sensors
• AC mode and target temperature
• light switch groups
• curtain controls
• quick office modes

How the comfort logic works

The automation is built around a feedback loop rather than a single scene.

1. Presence activates comfort mode

When either presence sensor detects that I am in the office, the room is allowed to adjust itself. This is important because I do not want the office reacting in the same way when nobody is inside.

2. Home Assistant reads the real room state

Before making changes, I check the values in Home Assistant:

• current temperature
• humidity
• illuminance near my seat
• illuminance near the window
• current AC mode and setpoint
• light switch state
• curtain position

3. Natural light comes first

My preference is not to turn on lights immediately. If there is enough daylight, the system should use the curtain motor first. If the seat area is still too dark after curtain adjustment, then the lights can be used.

4. Cooling should be gentle

I originally found the office getting too cold. So the comfort target is closer to 26 C instead of a colder cooling preset. That made the office feel much more comfortable during normal work.

5. Away mode reduces unnecessary control

When I am away, the office can turn off lights and reduce or stop active cooling. This keeps the automation from wasting energy.

How I operate it with Codex

The practical workflow looks like this:

Step 1: I open the Home Assistant office dashboard

I start by checking the actual room state in Home Assistant. I look at the temperature, humidity, lux, presence sensors, AC setpoint, lights and curtain position.

Step 2: I describe the comfort problem to Codex

Instead of manually thinking through every entity each time, I tell Codex what I feel in natural language. For example:

I feel cold. Keep my office around 26 C.

or:

Use natural light first. Do not turn on the lights unless the seat area is still too dark.

or:

When I am not in the office, turn off the lights and stop active cooling.

Step 3: Codex checks the Home Assistant state

Codex helps me inspect the current HA entities and compare them with what the dashboard shows. This is useful because the biggest problems are often not the automation idea itself, but small mismatches:

• the wrong switch entity is shown on the dashboard
• a sensor is not updating as frequently as expected
• the AC entity reports an unexpected value
• a light or curtain control is available in HA but not placed where I can use it quickly

Step 4: I tune the behavior in small steps

I do not try to build the perfect automation in one pass. I tune one behavior at a time:

• first make presence detection reliable
• then make the dashboard show the right sensor values
• then set the AC target around 26 C
• then adjust curtain positions for natural light
• then decide when lights should turn on
• then add a simple away behavior

Step 5: I verify it in the actual room

After each change, I look at the HA dashboard and also judge the room physically. If the room still feels cold, I change the target. If the desk is too bright or too dark, I adjust the curtain/light behavior.

That feedback loop is the part I like most. Codex makes it faster to iterate, but Home Assistant remains the actual local control system.

Curtain control

The curtain motor is important because it lets the system change the room before using artificial light. In my setup, the curtain can be opened, stopped, closed, or moved to a target position from the dashboard.

Why I find this useful

For me, this setup is useful because it combines three things:

1. Home Assistant gives reliable local control.
2. Sensors provide real room context.
3. Codex helps me operate, debug and refine the logic conversationally.

It feels different from a fixed automation because I can say what I want in human terms, check what Home Assistant is actually seeing, and then adjust the logic quickly.

What I am still improving

• better illuminance thresholds for different times of day
• better handling when a sensor does not update frequently
• a cleaner way to express comfort rules as reusable scenes
• better fallback behavior when one device is unavailable
• avoiding too many rapid device commands

I am curious how others are building similar adaptive comfort modes in Home Assistant.

Do you prefer doing this with pure YAML automations, Node-RED, templates, Assist/voice, or an external AI agent connected to Home Assistant?

[zemismart (official)]

I want to add a little more implementation detail, because the first post was more of a project overview.

The most important design choice is that Codex is not directly controlling random devices by itself. Home Assistant is still the local execution layer. Codex helps me inspect state, reason about the comfort goal, and tune the rules. The actual device control still goes through Home Assistant entities, services and dashboards.

My current comfort logic is roughly like this:

office_comfort_mode:
  trigger:
    - presence_sensor_1 == on
    - presence_sensor_2 == on

  conditions:
    - room == office
    - someone_present == true

  logic:
    - read:
        - office_temperature
        - office_humidity
        - seat_lux
        - window_lux
        - curtain_position
        - ac_mode
        - light_switches

    - daylight_first:
        if seat_lux < comfortable_lux:
          adjust_curtain_position_first
        if seat_lux_still_low:
          turn_on_selected_lights

    - temperature:
        if office_temperature > target_temperature:
          set_ac_cooling_target: 26 C
        if office_temperature <= target_temperature:
          avoid_overcooling

    - away:
        if no_presence_for_a_while:
          turn_off_lights
          reduce_or_stop_active_cooling

The actual thresholds are still being tuned, but the current direction is:

• temperature target: around 26 C, because colder settings felt uncomfortable
• lighting preference: use daylight and curtain position first
• presence: either of the two presence sensors can keep office mode active
• away behavior: wait a little before turning things off, to avoid reacting too aggressively
• device safety: avoid sending repeated commands too frequently

One practical lesson: the hard part is not only writing the automation. It is making sure the dashboard shows the correct entities, the sensors are updating as expected, and the manual fallback still works. Codex is useful for that daily debugging loop.

My longer-term idea is to express this as a more structured local rule layer:

user intent -> Codex / AI assistant -> Home Assistant state check -> safe HA service call -> local device execution

So the AI layer can help with reasoning and tuning, but the home still has a local, inspectable control path.

I am curious about the community's opinion on this:

Would you trust an AI assistant to help adjust Home Assistant automations if all real device execution stays local, visible, and reversible inside Home Assistant?