Two Years of Home Assistant in a Kolkata Flat: The Numbers
Key numbers
- 1,767
- entity states tracked across the flat at any given moment
- 52
- active automations running in the system
- 12
- rooms with full smart home coverage
- 0
- cloud subscriptions required for lights, fans, and automations to work
This flat in Kolkata has been running Home Assistant since 2024. Twelve rooms, fifty-two automations, one thousand seven hundred and sixty-seven entity states tracked in real time. No cloud subscription required for any of it to work. What follows is an operational record — the numbers, what broke, what we learned, and what we would do differently. None of the figures in this article are estimates. Each one comes from a running system or a documented technical finding.
The numbers, two years in
The homepage of this site publishes four live numbers: 1,767 devices, 52 automations, 12 rooms, and a start date of 2024. These are not marketing estimates. They come from a real Home Assistant installation that has been running continuously in a Kolkata flat. Here is what each number actually means.
What 1,767 entity states means in practice
Home Assistant counts entity states, not physical devices in the way you might count them when shopping. A single Aqara presence sensor might expose five distinct entity states to Home Assistant: occupancy detected (a boolean), illuminance reading (in lux), temperature (in °C), battery level (a percentage), and link quality (signal strength). A smart switch with energy monitoring might expose three: on/off state, real-time power draw in watts, and the timestamp of the last state change. When we say 1,767 entities across 12 rooms, we mean 1,767 pieces of live state that the system tracks, queries, and acts on simultaneously. A flat of this size — 12 rooms with presence sensing in every room, smart switches at every switch point, media players, a weather integration, virtual helpers for tracking household modes, and custom hardware on several sensor boards — generates entity counts in this range. The number is not unusual for a well-instrumented flat; it is what complete coverage actually looks like.
52 automations: a breakdown by type
The count of 52 active automations has been stable for several months. In the first six months of 2024, the count grew quickly — adding automations in Home Assistant is easy, and the temptation to automate every observable pattern is strong. The count peaked higher, then fell as we removed automations that fired too frequently, interfered with each other, or solved problems we stopped caring about. The 52 that remain break into rough categories. Presence-triggered automations are the largest group: a room light or fan that turns on when the room becomes occupied, and off after a configurable delay once it empties. Schedule-based automations cover things that have fixed times: the geyser switching on thirty minutes before a typical morning shower, the corridor night-light dimming after midnight. Conditional automations are where the real power is: if it is past 22:00 and the bedroom presence sensor shows occupancy and the television state is off, set the bedroom lights to ten percent brightness. Scene automations tie a single button press or voice command to a coordinated state across multiple rooms — a movie mode that dims every room except the one with the screen, or a morning mode that gradually raises the living room lights starting at six. None of these automation types is exotic or specific to advanced users. They represent what two years of iteration converges on as genuinely useful.
Twelve rooms: what full coverage requires
Twelve rooms with full smart home coverage means that every room has, at minimum, controllable lights and presence sensing. The rooms include three bedrooms, one study, a hall, a drawing room, a kitchen, a dining area, two bathrooms, and a terrace. The bathroom installations required specific attention to sensor placement — the LD2410 millimetre-wave radar can detect the movement of water vapour from a shower and register it as motion if aimed poorly. The correct placement aims the sensor along the length of the bathroom, away from the shower zone, at a height that catches a seated or standing person rather than the steam zone near the ceiling. The terrace has a weather station integration rather than indoor sensors, feeding external temperature, humidity, and light readings into automations that adjust interior climate responses during the day.
The software stack that runs the flat
Three layers handle all the automation: Home Assistant as the central server and automation engine, ESPHome for any custom hardware connected over Wi-Fi, and a Zigbee coordinator managing the wireless mesh of switches and sensors. The three layers interact cleanly because they are all open standards with well-documented APIs. Replacing any one layer does not require replacing the others.
Home Assistant: the automation core
Home Assistant is an open-source home automation platform that runs on local hardware — a small single-board computer or dedicated server sitting inside the flat. It stores all event history locally, executes every automation locally, and does not require an internet connection to operate. This is the most important property of the whole setup. The internet goes down — as it does regularly in Kolkata, for Jio maintenance, BSNL faults, or monsoon-season infrastructure issues — and every automation continues to execute exactly as configured. The hub was never interrupted by a network outage because it does not depend on one. Power returns after a cut and the system resumes from its last known state. Home Assistant has been running continuously in this flat since 2024 with no gap in operation attributable to its own software.
ESPHome: firmware for custom sensor hardware
ESPHome is a framework for writing firmware for ESP-based microcontrollers and connecting them to Home Assistant. It takes a YAML configuration file describing the hardware — which sensors are connected, on which pins, with what update intervals — and compiles it to firmware that runs on the device and reports back to Home Assistant over Wi-Fi. Every sensor reading appears as a Home Assistant entity automatically; there is no manual integration to write. ESPHome is how we run custom sensor hardware in this flat, including RoomGuardian V2 prototypes that we developed alongside the commercial product. Each prototype communicates with Home Assistant over the local network and contributes its sensor readings to the same automation engine as every other device.
Zigbee: the mesh protocol for switches and sensors
Zigbee is a low-power wireless protocol designed for mesh networking in homes and buildings. Its key property for an Indian flat with RCC construction is that mains-powered Zigbee devices — smart switches, smart plugs — act as relay nodes that retransmit signals from other devices. Every smart switch installed in the flat is also a Zigbee router for the devices around it. A battery-powered presence sensor in an outer room does not need to reach the coordinator directly; it routes its signal through whichever mains-powered switch is nearest. In a flat with smart switches at every switch point across 12 rooms, the Zigbee mesh is dense. Signal reaches every room through multiple possible hop paths, which means the mesh degrades gracefully even if a single switch loses power or develops a fault.
Local-first means no single point of external failure
The architecture of this setup has no mandatory cloud dependency. The Zigbee coordinator connects to Home Assistant over USB or network. ESPHome devices talk to Home Assistant over local Wi-Fi. Automations run in Home Assistant. All state is stored on the local hardware. The home router provides local network access — which is always available even when the internet uplink fails. The only feature that requires internet access is remote control from outside the flat, which is available through an optional subscription to Nabu Casa, the company that maintains Home Assistant. Every other function — lights, fans, presence sensing, scheduled automations, scene triggers, energy monitoring — runs on the hardware in the flat and does not leave the local network.
ESPHome 2026.6.2: why we pinned it and how we learned to
ESPHome releases roughly monthly. Most releases are additive — new device support, bug fixes, performance improvements. Occasionally a release changes a foundational layer in a way that breaks builds for specific hardware configurations. ESPHome 2026.7.x was one of those releases for our setup.
What changed in 2026.7.x
ESPHome 2026.7.x changed the toolchain management for the ESP-IDF build system, moving it off PlatformIO and onto a directly managed ESP-IDF installation. For most ESP32 variants — the ESP32-S2, ESP32-S3, the classic ESP32 — this was a clean upgrade with no visible effect on compiled firmware. For the ESP32-C6 using the Zigbee build path, the change broke compilation. The Zigbee stack on the C6 uses the ESP-IDF Zigbee libraries, and the specific way 2026.7.x restructured the ESP-IDF layer conflicted with the Zigbee build configuration in our bench firmware. The bench firmware file `roomguardian-c6-final.yaml` — which we use to validate Zigbee behaviour on the ESP32-C6 module — would not compile against ESPHome 2026.7.x.
Why 2026.6.2 is the pinned version
ESPHome 2026.6.2 is the last version that compiles the C6 Zigbee bench firmware cleanly. Every custom device in the flat and every RoomGuardian V2 prototype compiles against this version without modification. OTA updates flash reliably. Sensor readings arrive in Home Assistant correctly. The pin means we control when we take a major ESPHome version change, rather than accepting the ESPHome release schedule as the update cadence for production hardware. In a home environment where the sensors are monitoring real rooms where people live and sleep, a build failure at two in the morning because a framework update changed the toolchain is not acceptable. The pin is the correct response.
The staged update process we now follow
After the 2026.7.x incident — which we caught before it affected any production device, because we update a test device first — we formalised a staged update process for ESPHome upgrades. Step one: compile the new version against the full device configuration list and check for any build errors before flashing anything. Step two: flash a single test device that is not critical to any essential function. Step three: run the test device for 24 hours and verify that all its entities report correctly in Home Assistant with expected values and update frequencies. Step four: if the test passes, roll out to the rest of the fleet one room at a time over the following week. This process adds a week to every ESPHome update cycle. It has prevented one confirmed fleet-wide build failure and is worth the delay.
The broader lesson: dependency management in a production home
A home automation system that has been running for two years is a production system in the meaningful sense — it is something that people depend on daily, and failures have a real cost in inconvenience and time. The same engineering discipline that applies to production software deployments applies here. Pin your dependencies. Test updates before applying them to the fleet. Keep a rollback path. The habit of treating home automation firmware like software that needs dependency management rather than consumer electronics that self-updates may feel excessive for a home, but after one incident where a framework update breaks production hardware, the overhead of that discipline looks very different.
The Zigbee endpoint limit on the ESP32-C6
The ESP32-C6 is a single-chip module from Espressif that includes both a 2.4 GHz Wi-Fi radio and a 2.4 GHz 802.15.4 radio capable of running Zigbee. GrihaTEK uses the ESP32-C6 as the main processor in RoomGuardian V2. The product firmware runs Wi-Fi exclusively; but to test the C6 Zigbee capability and validate it for potential future use, we built bench firmware — `roomguardian-c6-final.yaml` compiled against ESPHome 2026.6.2.
What we found: two endpoints join, four fail
A Zigbee endpoint is a logical application instance within a single physical Zigbee device. A sensor might expose all its measurements on a single endpoint in multiple attribute clusters, or split them across multiple endpoints for organisational or interoperability reasons. Our bench firmware experiments tested how many endpoints the ESP32-C6 could successfully join to a Zigbee coordinator. The finding was consistent and reproducible: when the C6 board exposes two endpoints, both join the Zigbee coordinator immediately and without error. When we attempted to use four endpoints, the join process failed consistently. The device could not join the coordinator. The limit sits at two endpoints on the C6 hardware and firmware configuration we tested. This constraint is not documented in Espressif's ESP32-C6 reference manual or the ESPHome documentation for Zigbee on the C6.
How the bench firmware was designed around it
The bench firmware `roomguardian-c6-final.yaml` uses exactly two endpoints. EP1 carries all the sensor attribute clusters: temperature, humidity, barometric pressure (from the BME280), ambient light in lux (from the VEML7700), and the two mmWave distance channels move_cm and still_cm (from the LD2410). EP4 carries the PIR cluster from the AM312 passive infrared sensor. The endpoint numbers reach 4, but the count of endpoints used is 2. This arrangement was not accidental — it was the result of empirical testing that established the two-endpoint limit, followed by a deliberate design decision to place all sensor clusters on EP1 and keep EP4 for the PIR as a clean separation between continuous monitoring sensors and discrete motion events. The count is 2; the design works within the constraint.
Diagnosing Zigbee join failures: the endpoint count question
If you are building firmware for the ESP32-C6 using its Zigbee radio and a device is failing to join a coordinator, the endpoint count is the first variable to test. The symptom — device visible to the coordinator but failing to complete the join handshake — can look identical to a range problem, a coordinator pairing timeout, or a channel conflict. The diagnostic is to reduce the endpoint count to two and retry. If the join succeeds, the root cause was the endpoint count. If it still fails with two endpoints, the problem is elsewhere. This diagnosis is fast and eliminates an entire failure category before investigating the others.
What this does and does not affect in the product
The two-endpoint limit affects only the bench Zigbee firmware on the ESP32-C6. The RoomGuardian V2 product firmware runs Wi-Fi exclusively and does not use the 802.15.4 radio at all. Customers installing RoomGuardian V2 in their homes will connect it to their Home Assistant instance over Wi-Fi using the ESPHome integration. The Zigbee endpoint limit is a constraint for future hardware development — specifically any future version of RoomGuardian that might use the C6 Zigbee radio in a product context — not a constraint on the current Wi-Fi-based product.
What the sensors measure in each room
The sensor layer in a room determines what the automation engine knows about that room. Better sensors enable better automations. The core sensor set in this flat comes from four components, three of which are carried on the RoomGuardian V2 prototype boards we have been running in select rooms. Here is what each sensor contributes.
BME280: temperature, humidity, and barometric pressure
The BME280 is a combined environmental sensor from Bosch Sensortec, connecting over I2C and providing temperature, relative humidity, and barometric pressure from a single small package. In Kolkata, all three readings are useful. Temperature readings drive climate control responses — triggering the air conditioner when a room temperature crosses a threshold in summer, adjusting fan speed based on the ambient temperature in spring and autumn when a full AC cycle is unnecessary. Relative humidity is the most operationally important reading in a Kolkata flat. The city's pre-monsoon period (April to early June) and the monsoon itself (June to September) push indoor humidity above 70% RH for months at a time. The automation responds to room humidity as a factor in presence comfort: when a room is occupied and humidity is high and the temperature is within the range where cooling alone without dehumidification is insufficient, a different response is appropriate. Barometric pressure readings — less common in home automation setups but genuinely useful — show measurable drops before major rain events in Kolkata. A five-hectopascal pressure drop over six hours, combined with high humidity, is a reliable early indicator of incoming heavy rain, which the system can act on by closing motorised blinds or adjusting ventilation settings.
VEML7700: ambient light in lux
The VEML7700 is a high-accuracy ambient light sensor from Vishay Semiconductors, reporting illuminance in lux over I2C. The range covers from near-dark conditions up to bright outdoor levels, which makes it useful throughout a day without saturation. In a smart home context, the lux reading allows lighting automations to respond to actual light conditions in the room rather than time of day alone. A room with a westward window in Kolkata gets substantial afternoon sunlight until late in the day in summer; triggering the room light at 17:30 based purely on clock time ignores the fact that the room may already be well-lit by natural light. The VEML7700 reading provides the actual illuminance level, and the automation adjusts accordingly: light below a threshold triggers the supplemental lighting; light above it does not. The sensor also enables gradual transition scenes — setting indoor lighting to a level that maintains a consistent perceived brightness as natural light fades through the evening rather than jumping between two states.
LD2410: 24 GHz millimetre-wave presence detection
The LD2410 is a 24 GHz frequency-modulated continuous wave radar module from Hi-Link Electronic. It detects presence by measuring the Doppler shift and return signal from objects in its field of view. Unlike passive infrared sensors, which detect rapid changes in infrared emission from warm bodies, the LD2410 detects stationary presence — a person sitting still at a desk, lying in bed, or reading in a chair. The distinction is critical for home automation. An automation that turns off the bedroom light when the PIR sensor reports no motion will turn off the light while someone is lying in bed reading. The LD2410 keeps the light on because it can see the person even when they are not moving. The sensor reports two distinct channels: move_cm, the distance to the nearest movement target, and still_cm, the distance to the nearest stationary presence target. Both channels are available as separate entities in Home Assistant through the ESPHome integration, which allows automations to distinguish between someone entering a room (movement) and someone settled in a room (stationary). The sensitivity and detection zone can be configured through registers that ESPHome exposes as configuration entities, allowing adjustment for specific room geometries and ceiling heights.
PIR AM312: motion trigger for fast response
The AM312 is a passive infrared motion sensor in a compact TO-18 metal package, drawing minimal current and providing a simple binary output when infrared motion is detected. PIR sensors respond faster than radar to entering a room — the AM312 fires within milliseconds of a person crossing its field of view. In this flat, the PIR serves as the fast trigger for initial lighting response. When someone enters a dark room, the AM312 fires and the light comes on before the LD2410 has completed its first full radar sweep. The LD2410 then takes over as the presence hold signal — keeping the light on while the person is in the room, including when they are stationary. This dual-sensor architecture combines the best properties of both: fast response from PIR on entry, accurate stationary presence from radar on hold. Relying on PIR alone creates the well-known problem of lights going off while someone is seated and still. Relying on radar alone creates a perceptible delay at room entry. The combination eliminates both problems.
What the board does not measure — and why
RoomGuardian V2 does not include an air quality sensor, a CO2 sensor, a VOC (volatile organic compound) sensor, or a microphone. These are the sensors most commonly requested after people learn what the board does carry. The omissions are not permanent decisions; they are the result of the current fabrication cycle. Each additional sensor category requires hardware validation against the PCB layout, component sourcing verification, and firmware testing — a cycle that takes time. The sensors currently on the board are the ones that have been through that full cycle: component selection, layout review, BOM confirmation, and firmware verification on the fabricated board. Air quality monitoring in a Kolkata flat is genuinely valuable — indoor dust, cooking combustion products, and monsoon-season mould are all real concerns — and the current approach for customers who need it is to run standalone air quality hardware alongside the RoomGuardian board rather than waiting for an integrated solution. A standalone CO2 or PM2.5 sensor from a credible manufacturer integrates into Home Assistant over Zigbee or serial connection and adds its readings to the same automation engine as everything else.
India-specific challenges that no product documentation covers
The majority of documentation for Home Assistant, ESPHome, Zigbee, and smart home hardware in general is written for European or North American markets. Indian construction, electrical standards, power infrastructure, and climate create a different operating environment. Here are the constraints that have mattered most in two years of running this system.
The neutral wire in older Indian buildings
Smart switches require a neutral wire at the switch box to power their internal electronics while the controlled circuit is open. In standard Indian domestic wiring from before approximately 2010, switch boxes were typically wired with only two conductors: a switched live wire going to the fixture and an earth conductor. No neutral wire reached the switch box because no standards required it. European wiring regulations mandated neutral wires at switch locations decades earlier, which is why smart home hardware designed for European markets assumes neutral availability. In a Kolkata flat built before 2000 — and many desirable buildings in South Kolkata, Central Kolkata, and older housing in Jadavpur, Behala, and Bhowanipore fall into this category — checking the switch box before ordering any smart switch hardware is essential. The options when neutral is absent are: running a new neutral conductor from the nearest point in the circuit (which typically means opening the wall at one or two points), or using a no-neutral smart switch that borrows a small current from the load circuit for its own power. No-neutral switches work but have limitations: some cannot dim loads below a certain threshold, some have compatibility constraints with LED bulbs, and some produce a faint hum under certain conditions. We check the neutral wire status at every switch box during the initial site visit, before quoting.
How the system behaves through power cuts
Load shedding and unplanned power outages are a background condition of life in Kolkata and its surrounding areas. Some localities — parts of Howrah, parts of Barasat, peri-urban areas on the city's edges — still experience scheduled load shedding. Even in central Kolkata with relatively stable supply, brief outages from grid switching, high-demand periods, or monsoon-season infrastructure stress are common. The correct behaviour for a smart switch through a power cut is to restore exactly its previous state when power returns. A switch that was on before the cut should come on when power returns. A switch that was off should stay off. This sounds obvious but is not universal in smart home hardware — some devices return to a fixed default state (all on) on power restoration, which is actively worse than no smart home at all if it turns on lights or fans at 3am. Every switch in this flat is configured to restore last state. The Home Assistant hub runs on a UPS — a standard 600 VA unit — which keeps it alive through cuts of up to two to three hours. The hub therefore has continuous state awareness through most outages, and when devices come back online after a cut, they report their restored state cleanly.
Zigbee signal through RCC construction
Reinforced concrete is the standard construction material for Indian urban residential buildings. Concrete with embedded steel reinforcement attenuates 2.4 GHz radio signals noticeably. The Zigbee coordinator placed in a central room of a 12-room flat cannot rely on line-of-sight or even single-wall penetration to every end device. The Zigbee mesh design compensates for this by using the mains-powered smart switches as relay nodes. Every switch in the flat — and with 12 rooms fully covered there are many — acts as a Zigbee router that relays signals from devices around it. The effective range between adjacent nodes can be short in an RCC building, sometimes just across a room to the next switch, but the density of relay points means that the hop count from the coordinator to any end device is low. A battery-powered presence sensor in a far bedroom might route through two or three switches to reach the coordinator, but each hop is a short, well-established link. The mesh is resilient: if one switch goes offline, signals reroute through alternatives. Planning the mesh before installation means identifying which switch positions will serve as the critical relay points for the sensors in each room, and ensuring those switches are among the first to be installed and added to the network.
Device selection for local control in an Indian market
The Indian smart home market includes a wide range of devices at varying price points, but not all of them expose local control. A significant portion of devices sold in India operate through proprietary cloud platforms: a command from your phone goes to the manufacturer's server in another city or country, which relays the command to the device in your home. These devices appear in Home Assistant only through cloud integrations that require internet access. When the cloud is unreachable — for any reason — the devices are unreachable. Selecting devices for a local-first setup requires filtering specifically for local control capability: devices with Zigbee protocols that work with a local coordinator, devices with Matter firmware that communicate locally over the home network, or ESP-based devices running custom ESPHome firmware. This filtering eliminates many otherwise reasonably priced Indian-marketed devices that have no local control path. The selection discipline required at purchase time is what makes the local-first promise hold over time.
Kolkata climate and sensor calibration
Kolkata's climate is a specific operating environment for sensors that measure temperature, humidity, and light. Summer (March to May) brings high temperatures and rising humidity. The monsoon (June to September) brings sustained high humidity — often above 80% RH indoors in rooms with inadequate air exchange — and lower temperatures. Winter (November to January) brings moderate cold and very low humidity. Smart home automations that respond to climate conditions need to be calibrated against this seasonal profile, not against a temperate European default. Humidity thresholds that make sense in a dry climate would trigger constantly in a Kolkata monsoon; thresholds calibrated for Kolkata might never trigger in a city with lower ambient humidity. The same applies to temperature setpoints, lighting compensation curves, and any automation that uses environmental readings. Two years of seasonal data from the BME280 and VEML7700 sensors in this flat has informed these calibrations over multiple seasonal cycles.
What broke and what we changed because of it
No home automation system runs for two years without failures. The failures in this flat were specific, diagnosable, and each produced a concrete change to how the system is managed. Here are the most significant ones.
ESPHome 2026.7.x: the build that broke the C6 Zigbee firmware
This is covered in detail in the ESPHome section above, but the operational consequence belongs here too. The 2026.7.x ESPHome release broke the compilation of the bench Zigbee firmware for the ESP32-C6. We caught the failure on a test device before it affected any production device. The change it forced was not just pinning the version — it was formalising the entire update process with a staged rollout and a 24-hour validation period. Before the incident, ESPHome updates were applied across all devices when they appeared. After it, there is a test device, a validation period, and an explicit decision before any update reaches the rest of the fleet. The cost of the change is time. The benefit is that the next breaking ESPHome release — and there will be one, for some future platform or configuration — will again be caught on the test device first.
LD2410 false positives from ceiling fan movement
The LD2410 millimetre-wave radar in the bedroom had a specific false-positive pattern: when the ceiling fan ran at high speed, the radar occasionally detected the rotating blades as movement and kept the room logged as occupied after the person left. The symptom was lights remaining on in a room that had been empty for fifteen minutes. The root cause was radar sensitivity settings calibrated for person-sized targets returning movement detection on the faster, closer, and more regular target presented by a fan running at three or four metres away. The fix was adjusting the LD2410 sensitivity and gate thresholds through the configuration registers exposed by ESPHome, reducing the sensitivity at close range where the fan sits while maintaining detection at distances where a person would be. The LD2410 allows fine-grained sensitivity adjustment across multiple distance gates — a capability that exists specifically to handle this kind of environmental interference. After adjustment, the false-positive rate dropped to zero across four weeks of monitoring.
Automation interference: the fourteen automations we deleted
At peak, the automation count was higher than the current 52. The extras were removed because they created interference — situations where two or more automations acted on the same entity at overlapping times with conflicting intentions. A common pattern: automation A turned off the drawing room light when the presence sensor reported empty. Automation B turned on the drawing room light as part of an evening scene that ran at 19:00. Automation C set the evening scene in response to a presence detection event in the hall. The result was that entering the hall after 19:00 triggered the evening scene, which turned on the drawing room light, even when the drawing room itself had been deliberately switched off. The fix required both deleting the redundant automations and introducing a cleaner ordering principle: scene automations check occupancy before executing, and explicitly switched-off states have higher priority than scene defaults. The fourteen removed automations were not wrong individually; they were wrong in combination. Two years of operating the system has produced a set of 52 that interact predictably.
What a hub UPS prevents and what it does not
The Home Assistant hub runs on a 600 VA UPS that keeps it alive through power cuts of two to three hours. This covers the majority of brief outages in this area of Kolkata. During these cuts, the hub continues tracking presence, running scheduled automations, and maintaining state for every device that has a UPS or internal power reserve. What the UPS does not cover: extended outages beyond its capacity, which have occurred twice in two years during severe monsoon events when the power was off for more than three hours. During these extended outages, the hub shuts down cleanly when the UPS battery depletes and comes back up cleanly when power returns. Devices restore to their last state. Automations resume. The gap in automation coverage during the outage is real but not consequential for a flat where people are awake and present during the event.
What we would do differently starting from zero today
Two years of operating a system teaches lessons that are difficult to convey abstractly. The three below are the ones that would most change a fresh installation.
Map the Zigbee mesh before ordering any hardware
The correct starting point for a smart home installation in a Kolkata flat is not a product list — it is a floor plan with wall materials marked and switch positions noted. In an RCC building, the Zigbee coordinator placement and the relay path from the coordinator to every sensor should be planned before purchasing anything. The coordinator goes in a central location; the mains-powered switches in adjacent rooms become relay nodes for battery-powered sensors in those rooms and further ones. Two of this flat's outer rooms required an extra relay node — a smart plug placed in a corridor junction — because the direct path from the coordinator had too much wall attenuation. If the mesh had been mapped on paper before installation, the relay node location would have been obvious and the plug would have been included in the initial order. Instead it was an additional purchase after the first week of running the system.
Start with presence sensing in every room before adding any switches
The first devices installed in this flat were smart switches in the kitchen. Controllable lights and fans. Useful, but the value was limited to remote control and scheduled switching. The second installation phase added presence sensing to the master bedroom, alongside smart switches. The difference in utility was immediate and significant. A room that knows whether it is occupied responds to people rather than to clocks and manual commands. Looking back, the right sequencing would have been: install a presence sensor in every room first, running alongside the existing dumb switches, and observe the occupancy patterns for four to six weeks before installing any smart switches. The presence data would have informed exactly which automations were worth building — which rooms had the most complex occupancy patterns, which transitions happened most frequently, which schedules were most predictable. The switches could then be targeted at the high-value rooms rather than installed uniformly and then discovered to have inconsistent value.
Pin ESPHome from day one and treat home automation firmware like production software
We did not pin the ESPHome version when the system was first set up. Updates were applied when ESPHome prompted. The 2026.7.x incident, which broke the C6 Zigbee bench firmware build, was caught on a test device and did not affect any production device — but only because by that point we had a test device and were running staged updates. If it had occurred in the first year, before the staged update process was in place, it would have affected every custom device simultaneously. A home automation system that has been running for more than a few months is a production system in the meaningful sense. It is something that people depend on for daily comfort and function. The same engineering discipline that applies to production server deployments — pinned dependencies, staged rollouts, explicit change management — applies here. The overhead is low and the benefit is that breaking changes are caught before they reach production.
What this means if you want it in your own flat
A 12-room installation like this is the result of two years of gradual build-up. It is not a one-week project. But the architecture scales in both directions: smaller installations work on the same stack and the same principles, and the hub cost is fixed regardless of how many rooms are connected.
A single hub serves the whole flat from day one
The Home Assistant hub handles the entire flat from the first day it is installed. Adding rooms means adding devices — switches, sensors — to a network that is already running, not starting over or buying additional hubs. This matters because it means the per-room cost of expansion is only the cost of the hardware for that room, not hardware plus hub. Many customers install one room first — the master bedroom plus the geyser is a common starting combination — and add rooms over months as the value of the first installation becomes clear. The hub cost amortises across however many rooms are eventually covered.
The fastest path to a cost estimate is the estimator
Understanding the cost for a specific flat in Kolkata requires knowing the room count, the device density, and whether neutral wires are present at the switch boxes. The estimator on this site takes you through a room-by-room selection: choose the rooms you want covered, select the sensors and switches for each, and the estimate is generated immediately with itemised pricing. No account creation, no form to fill, no call required before you have numbers. If the estimate raises questions about specific rooms or specific devices, the contact form on the homepage connects directly to us.
Local-first in practice: what happens when things go wrong
The most common concern we hear from people considering a smart home installation is about reliability — specifically, what happens when the internet is down, when the app stops working, or when the manufacturer discontinues the product. The answer for a local-first installation is that none of those events affects the home's operation. The internet is down: every automation runs as scheduled. The app has a bug in an update: the home keeps working because the app is optional for local control — the automations run without it. The manufacturer of a specific switch discontinues their cloud platform: the switch continues to work because it runs on Zigbee or local firmware that does not use the manufacturer's cloud. What we have found in two years is that the failures that actually affect the system are local failures: a firmware build that breaks a device, a sensor calibration that needs adjustment, an automation that needs to be refined. These are all diagnosable and fixable on hardware inside the flat. They are not invisible failures in a cloud somewhere that you have no access to.
Common questions after the first consultation
Two consistent questions come up after people understand the local-first architecture. The first: is there a monthly fee? No. The only optional subscription is Nabu Casa for remote access from outside the flat, which is not required for local operation. The hub draws approximately 5 watts of continuous power — under fifty rupees per month on a typical Kolkata electricity tariff. The second: can I move the system when I change flats? Most hardware can move. Smart switches unscrew and reinstall. The hub moves wherever you go. Sensors use adhesive mounts. A full flat move takes approximately half a day. Cable work — neutral wire runs that were done at installation — does not move, but that is a small fraction of the total installation cost. We quote moves on request.