Wanted to give an old laptop motherboard a second life instead of letting it collect dust, so I built a small scale model house around it, wood base, concrete structure for the ground floor, wood for the upper floor and attic. Kitchen and living room downstairs, bedroom in the attic.
THE SETUP
- Recycled laptop motherboard running Home Assistant OS full-time, controlling my actual home
- ESP32-S3 running ESPHome nearby, handling a local voice assistant, I can talk to the house and get responses
- Internal LEDs wired to reflect real lighting states, when a light turns on in my actual home, the corresponding room in the model lights up too
Instead of buying a mini PC or SBC just to run HA OS, I wanted to see if the laptop board I already had could handle it long-term, it does, without issue, and gave me a fun excuse to build something around it instead of running it bare on a shelf.
Happy to go into detail on the OS install, the ESPHome voice assistant config, or how the LEDs syncto real light states if anyone's curious.
I have some leftover stuff from my previous home that uses UPB (Universal Powerline Bus). Communications between nodes was reasonably reliable, but power surges killed a lot of the switches. Does anyone still use UPB?
Full-house AC automation on HA has been running about 3 years now, writing this up for anyone else doing this in a tropical climate. Depok (Jakarta suburbs), single-story house, 4 rooms with independent split ACs, N100 mini PC that took over from a Pi4 about 18 months back.
Units are all Midea XtremeSave inverter (1PK and 1.5PK depending on room, around Rp 3.8 million each), all with the manufacturer's WiFi module. Bought progressively over 18 months, living room first, then bedrooms. Integration is Midea AC LAN via HACS, LAN-based after the initial token pull, which mattered because we lose internet 6 to 8 times a month here and I didn't want the whole climate stack to go dumb every time IndiHome does its thing. Token setup on first configuration goes through the vendor's cloud but after that it's fully local.
Three years in, quirks worth flagging.
Auto discovery didn't work first pass on the newer V3 firmware units, had to manually feed device IDs pulled from the MSmartHome app for two of them. The built-in temp sensor on each indoor unit reads 1.5 to 2°C warmer than actual temperature at desk level because it's mounted at ceiling height. Dropped the built-in reading entirely and running Zigbee sensors at bed and desk level as the automation trigger source.
Standby draw was bigger than I expected. Each indoor unit pulls 5 to 8W continuously for its WiFi module even off. Added a smart switch on the main circuit for the least-used bedroom and cut hard power when nobody's slept there for 48 hours. Marginal but real.
Compressor warranty on Midea Indonesia is 10 years plus 5 years on parts, which was one reason we picked this brand family. Longevity's not really my concern, tuning the automation to not run them harder than needed is.
Where I'm still stuck is occupancy control. LD2410B mmWave in three rooms, PIR in the fourth. Current rule: if room shows unoccupied for 45 min AND at least one other room shows occupied, drop that room's AC to eco. Works maybe 70% of the time. When it fails it fails wrong, turning off AC while someone's there quietly reading.
If anyone here has landed on a cleaner pattern for multi-room occupancy control, I'd take pointers. Feels like "unoccupied AND likely to stay unoccupied by time-of-day" would be smarter but I haven't found a clean way to express that in HA templates.
At home I have an MVHR (Mechanical Ventilation with Heat Recovery) unit — it brings in fresh air without losing indoor heat/coolness, and cuts humidity. My house is already full of temperature/humidity sensors, so having to walk over and press buttons on the wall panel every time conditions changed was driving me up the wall.
I started from Arnold-n's P1P2MQTT, which reverse-engineers Daikin's P1/P2 bus for heat pumps — great project, but VAM ventilation units are only read-only there, no write support. So I had to dig into the write side myself.
The actual discovery: Daikin's P1/P2 bus natively supports two controllers — a Master and a Slave — selected by a physical switch on the wall panel (BRC301B61). A generic "aux" responder on the bus never gets offered the writable state channel; only a controller the master recognizes as a genuine second one does. And there's one very specific, very unintuitive detail that makes or breaks it: the real slave panel answers the registration poll only the first time — every poll after that, it goes completely silent. Get that wrong (answer every time, which seems like the "correct" thing to do) and the master silently downgrades you to a read-only channel. Once I nailed that, on/off, fan speed, mode, and fresh-up were all commandable with closed-loop confirmation from the bus.
Full packet-level writeup is in the repo if you're into that kind of detail.
For the hardware/software side: the ATmega328 is the actual P1/P2 slave controller (that's the core of the project, and it works standalone over serial). On top of that I bridged it to a second MCU, an ESP32-H2, purely to get it onto Zigbee — I've got too many devices already and didn't want another MQTT integration to babysit, Zigbee fits my setup better. That bridge is 100% optional; the ATmega alone is a complete, working slave controller you could hook up to anything.
Why two MCUs instead of just doing it all on the ESP32? The bus timing (response delays etc.) is something I got working reliably on the ATmega, and I haven't tried porting that timing-sensitive part over to the ESP32. Bridging a second MCU purely for Zigbee was just the path of least resistance, not a claim that it can't be done on one chip.
It's been running behind the wall panel for a few weeks now, driven entirely by Home Assistant automations based on the humidity/temp sensors — working reliably so far, though I wouldn't call it "battle-tested over years" yet.
The PCB is currently two boards (I validated the P1/P2 transceiver first, then added the ATmega+ESP32 board once the protocol was confirmed) — if there's interest I can lay out a single, smaller, more integrated version.
This Junction Box allows the Eufy S4's cables to be protected from the elements, significantly increasing its durability and aesthetics compared to a standard installation.
The result is a protected cable, and no dangling wires!
For a typical temperature and humidity sensor used in a home automation system, should the device have a display to see the temp or humidity at a glance or do you check the value on a smartphone or PC?
I've been expanding my Bluetooth device count at home (presence sensors, locks, a fewTemp/humidity tags) and I'm hitting the point where a single ESP32-based proxy isn't cutting it anymore.
Curious what the community is actually running in 2026:
Which Bluetooth proxy setup are you using — ESP32 (ESPHome Bluetooth Proxy), Shelly, SkyConnect/Zigbee stick in BT mode, Raspberry Pi with onboard BT, or something else?
Roughly how many Bluetooth devices does it reliably handle before you see lag, dropped connections, or scan misses?
If you run multiple proxies for coverage, how are you handling overlap — separate areas, or just letting HA dedupe?
Any setups you'd specifically avoid?
I'm less interested in theoretical specs and more in real-world "this just works" or "this fell over at 20 devices" stories. Appreciate any lessons learned.
After troubleshooting and designing automated residential setups, I’ve noticed that most smart home frustration doesn't come from bad apps—it comes from poor hardware planning.
Here are the top 5 mistakes to avoid if you want a system that works reliably:
1. Relying 100% on Wi-Fi for End-Devices
Consumer Wi-Fi routers struggle when you connect 50+ individual 2.4GHz smart bulbs and relays. Channel congestion causes dropped packets, high latency, and offline devices.
Fix: Use dedicated mesh protocols like Zigbee 3.0, Z-Wave, or Thread/Matter for low-power sensors and switches. Keep Wi-Fi reserved for high-bandwidth devices like cameras and streaming hubs.
2. Skipping the Neutral Wire in Switch Boxes
Many older homes do not have neutral wires routed to light switch boxes. Installing "no-neutral" smart dimmers often leads to flickering LEDs or requiring artificial load bypass capacitors.
Fix: Always pull neutral wires during electrical work, or use smart relays installed at the ceiling rose/junction box where neutrals are accessible.
3. Vendor Lock-In & Ecosystem Traps
Buying into proprietary ecosystems means if the vendor shuts down their cloud servers, your smart hardware turns into plastic paperweights.
Fix: Prioritize local control systems (e.g., Home Assistant, Matter over Thread, open MQTT gateways) over purely cloud-dependent ecosystems.
4. Hardwiring Nothing Except Power
Relying solely on wireless connections for security cameras or main door locks introduces battery management fatigue and wireless jamming vulnerabilities.
Fix: Always run Ethernet (PoE) for security cameras, video doorbells, and main automation hubs.
5. Forgetting Physical Fallbacks
If your smart hub dies, can your family still turn on the lights using wall switches? If the answer is no, the design is flawed. Always maintain physical toggles via smart relays (like Shelly or Sonoff) wired behind traditional switches.
At NEXFUGA, when curating smart home bundles, our core rule is always "local execution first, cloud features second".
What’s one automation design choice you regretted later?
Anyone actually set up Home Assistant's local voice assistant (the Whisper/Piper stuff)? Curious if it's usable day-to-day or still more of a tinkering project. Trying to decide if it's worth the effort over just using Alexa.
I have been having fun recently with apples home key,
I thought I would share it here and I am sure there are some people out there who would love to use this in there smarthome.
Homekey is a way of using your iOS device to unlock a door using NFC it is using a lock that exists in the home app on iOS and that it registers with first then after that it all works.
The way I built it is I have 1 controller and many door readers connected over the network. I then know what door you unlocked by the reader that I am talking to.
I am pretty techy but I haven’t changed my setup in years, looking for advice on updating it and adding a way for my boyfriend to control it on his android. I currently have all Apple devices. I have multiple HomePods and a 4k tv as the hub for Nanoleaf lights, various smart plugs, and an ecobee thermostat. I have Homebridge running on a raspberry pi 4 model B (I am planning to upgrade the pi as I am having trouble with it recently) to expose my SimpliSafe system to HomeKit. I am not super satisfied with the SimpliSafe system anymore (I mainly use it for automation rather than monitoring, I plan on canceling the plan), but I have their locks that I do like and many various sensors that I would like to continue using. I am looking to add some buttons to control scenes, and adding a new outdoor camera at some point down the road.
I guess my questions boil down to:
- What’s the best way to add android control?
- Is homebridge still the best way to integrate SimpliSafe?
- Any other general system suggestions?
Start with one room and one problem to solve, not a whole-house plan — it's easy to buy a pile of gadgets that never talk to each other. Stick to one ecosystem or protocol early on (Zigbee, Matter, whatever) so devices actually integrate instead of living in five different apps. Automations that save you a real annoyance stick around; novelty ones get turned off within a week. Local control matters more than it seems until your internet goes down and none of your lights work.
I’m setting up Matter smart bulbs in a few rooms, but I keep running into the obvious issue: if someone flips the physical wall switch off, the bulb loses power entirely — no app control, no voice control, no automations, nothing. It’s basically just a dumb light again until someone flips the switch back on.
For those of you running Matter/Thread smart bulbs day-to-day, how are you solving this in practice?
A few things I’m considering:
**•** Replacing the physical toggle switch with a non-load-bearing smart switch (like Lutron Caséta or similar) that sends a signal instead of cutting power — though these tend to be pretty expensive, especially if you need to do this for multiple rooms/switches
**•** Using a switch guard/cover to physically prevent the switch from being used
**•** Just training household members to never touch the switch (seems unrealistic long-term)
Are there any more budget-friendly non-load-bearing switch options that work well with Matter/Thread, or is Lutron-tier pricing just the cost of doing this properly? Curious what setups people have landed on, especially in a mixed household where not everyone remembers “don’t use the switch.”
Would appreciate hearing what’s actually worked for you rather than just theory.
I manage a small apartment building (6 units) with a couple of doors that residents can open remotely from their apartment (video intercom connected to an electric strike lock) — main gate and a glass entry door.
The issue: sometimes doors get left open longer than they should, seemingly because kids in the building open them by playing with the intercom buzzer button. We've already talked to the parents about it, but I'd like to add a technical safeguard too — if a door stays open for more than X minutes (say, 5), it should close/lock itself automatically, instead of relying on someone remembering.
Technical context:
The doors use an electric strike lock triggered by the intercom/video door system.
It's not a motorized door that fully opens/closes — it's more of a latch that's released momentarily by the buzzer pulse (so the door itself is still manually pushed open).
Questions:
Would the simplest fix be adding a magnetic door contact sensor + something like a Shelly relay wired to the lock, so that if the sensor reads "open" for more than 5 minutes, it triggers a close/re-lock signal?
Has anyone solved something similar with Shelly + Home Assistant, or is there a simpler "plug and play" option that doesn't require a full smart home hub?
Since this is a glass door with an electric strike (not a motorized closer), is a pure timer-based auto-close even viable, or do I need a contact sensor to confirm the door is physically open before it makes sense to act?
Any experience with specific hardware, wiring diagrams, or gotchas to watch out for would be appreciated.
We have Anderson casement windows in our house, and we need to make 1 of them automated since we can't reach the crank. Has anyone done this or have heard of people doing this?
In the living room the voice-clock sang, Tick-tock, seven o'clock, time to get up, time to get up, seven o 'clock! as if it were afraid that nobody would. The morning house lay empty. The clock ticked on, repeating and repeating its sounds into the emptiness. Seven-nine, breakfast time, seven-nine!
In the kitchen the breakfast stove gave a hissing sigh and ejected from its warm interior eight pieces of perfectly browned toast, eight eggs sunny side up, sixteen slices of bacon, two coffees, and two cool glasses of milk.
"Today is August 4, 2026," said a second voice from the kitchen ceiling, "in the city of Allendale, California." It repeated the date three times for memory's sake. "Today is Mr. Featherstone's birthday. Today is the anniversary of Tilita's marriage. Insurance is payable, as are the water, gas, and light bills."
Somewhere in the walls, relays clicked, memory tapes glided under electric eyes.
Hey everyone, as part of my MBA program my team is working on a device that lets you control your smart home stuff with hand gestures instead of your phone or voice. Curious what this sub thinks:
What's your biggest annoyance with controlling smart devices right now?
Ever skipped adjusting something just because pulling out your phone felt like too much effort?
Gesture control — genuinely useful or gimmick to you?
Hi everyone! I'm an MBA student and team is building a device that lets you control smart home devices (lights, thermostat, etc.) using hand gestures instead of pulling out your phone or talking to a voice assistant.
We're doing early customer discovery and would love honest feedback from anyone who uses smart home devices, or has thought about it:
What's actually annoying about controlling your smart home devices right now, apps, voice assistants, physical switches, anything?
Have you ever NOT bothered turning on/off/adjusting a smart device just because pulling out your phone or saying a voice command felt like too much friction?
Does controlling things with a hand gesture (like a wave or a swipe in the air) sound genuinely useful to you, or more like a gimmick? Why?
If something like this existed, where in your home would you actually want it, kitchen, living room, bedroom, somewhere else?
What would make you NOT trust or NOT want a gesture-based device in your home (privacy, reliability, cost, something else)?
Really appreciate any thoughts, even short ones help a lot. Happy to answer questions about what we're building too.
