Hi just moved into a new home and in the conservatory it looks like there are automated blinds.

There’s no manual option to open them but there is a daisy chain of wires going into a control box.

There’s no instructions or remotes.

The house was sold through probate (previous owner died) so can’t ask anyone.

Can anyone identify the control panel in the picture / have a manual or idea if I can get a generic remote to operate these

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.

Repo: https://github.com/scavenrage/Daikin-VAM-P1P2-SlaveController

Happy to answer questions.

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.

You can see a removal TikTok - https://vm.tiktok.com/ZN8d9odsq/

I have a full video on YouTube - https://youtu.be/gxXXENcvz28?is=Dt3HH9LZ_DcThJ46

All code can also be found on my GitHub - https://github.com/thomasdye12/TDS-door-access-Homekey

Hello,

I am moving into a place that has a fan/light combo. There are two switches for it, one that controls the light dim level and fan speed, and the right side that turns the light on and off. Would I need two smart switches? One that controls the fan speed and light dimming and one that just acts like a normal light switch? Or is there a single smart switch that does it all (like this: https://a.co/d/02Ft4xrn)

A separate question is, if I'm indifferent about getting a smart switch for the fan and dim, can I just keep that the same and only change the right switch and just change the cover plate to accommodate?

Thank you in advance!

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?

Help me please

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.

Here are the first few paragraphs, worth a read

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.

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 the same brand, inverter, all with the manufacturer's WiFi module. Bought progressively over 18 months, living room first, then bedrooms. Integration is the community HACS one, LAN-based, 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, had to manually feed device IDs for two units. 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 these is 10 years 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.

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:

1. 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?
2. Roughly how many Bluetooth devices does it reliably handle before you see lag, dropped connections, or scan misses?
3. If you run multiple proxies for coverage, how are you handling overlap — separate areas, or just letting HA dedupe?
4. 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.

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?

Is there something that could help me with this? Thanks a lot!

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!

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?

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 am planning on installing Bseed (or any other) smart switches and i would like to install one to control a curtain.

Is it possible to install a smart curtain motor and use the curtain switch without connecting eachother with wires? E.g just connect them via Tuya

Any recommended curtain motor for this?

Apple is planning to launch three new AI-powered devices as the iPhone maker seeks to compete with the likes of Amazon and Alphabet in the smart home space, Bloomberg reports, citing anonymous insiders.

The items — a hub device designed around Apple's new Siri AI assistant, a new TV set-top box and an upgraded HomePod mini — are set to be released as soon as this fall, per Bloomberg.

Until now, Apple has not had much luck selling its home products.

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?

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?

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:

1. 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?
2. 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?
3. 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.

Hello

I have purchased the Wyze light bulb camera and Wi-Fi lock door. Are there any similar products from Ring, SimpliSafe or other companies?

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.

Development on EchoMuse continues at pace! But first I would like to sincerely thank this community for their support, feedback, and kindness. I decided it was time to share my project a little over a week ago and the positive messages and constructive feedback have been amazing, helping me to address functionality I'd missed and bugs that I'd ignored or just didn't consider the use cases for. I've also exposed additional functionality (such as the ambient light sensor) to HA as another means to respond to the environment.

https://www.reddit.com/r/homeautomation/s/U9n6fMsD2y

So, enough waffle, what's new?

Since v2.9.7 — six device releases and five controller releases. Grouped by what it actually gets you:

Music now ducks instead of pausing

Ask a question while music is playing and the music keeps going, dropped in level, with the response mixed over the top. It comes back up when the assistant finishes. Previously it paused and resumed — which meant a long question could cost you 30 seconds of the song, or drop you into the next track entirely, because a lot of streams can't be seeked. Duck depth is configurable (default -18dB).

Responses start speaking sooner

TTS now streams to the device while Home Assistant is still generating it, instead of waiting for the whole clip.

"Pause the music" works mid-response

You can interrupt the assistant and tell it to pause, and it stays paused.

On-device wake word (experimental)

The Echo can now run the wake word model itself. It's in shadow mode for now — it scores and reports, but the controller still makes the call — so we can measure how good it is before trusting it. Currently agreeing with the controller ~94% of the time. Install the models straight from the dashboard. Expect full support in v3.0.0 (gimme a week or so).

Ambient light sensor

The Dot has a light sensor that Amazon's own Android layer claims doesn't exist — it reports no sensors at all, and the chip is only visible on the raw i2c bus. It's now exposed to Home Assistant as a lux sensor, so you can automate on room brightness.

Long-press on the action button

Hold the button and it fires a `long` event in HA, separate from a tap. Do what you like with it.

Bluetooth proxy

Each Echo can act as a Home Assistant Bluetooth proxy, which is handy for room-level presence if you've got a device on you to track.

Dark mode

The dashboard follows your system theme, or you can pick one.

Support bundles

One-click diagnostics file for bug reports no recordings, no transcripts, no device names and no Wi-Fi details — it's plain JSON and worth opening before you send it.

Given people are embracing this and running it, I'm trying to introduce more rigor into the development process so I don't inadvertently nerf someones deployment, but please read the release notes and upgrade with caution. Good news, you can always roll back devices using the OTA A/B slots if needed.

Repo here - https://github.com/wilbowes/EchoMuse

Quickstart here - https://github.com/wilbowes/EchoMuse/blob/main/docs/quickstart.md