u/Rude-News-8416

I will start with two of mine at opposite ends of the spectrum.

The first is extremely simple. When I put my smartwatch on its charger in the evening, the house knows I am winding down. The lighting shifts to evening tones. The shades close. The whole house mode flips to sleep-ready. It is one of my least technically impressive automations and one of my most loved. The trigger is dumb. The effect is everything.

The second is more involved. The shades in my main living space are managed by an automation I call "Do Not Cook the Fish". It has four template sensors and two state triggers. It tracks LUX levels going up and down, the TV being turned on or off, and whether any windows are opened or closed. The west-facing dining room windows take full afternoon sun, which both bakes the room and causes a lot of glare.

The automation closes the shades when LUX crosses a sustained threshold, or faster when the LUX spikes high enough to be painful (cloud-and-sun afternoons in Loja are dramatic). It does not fully close the shades when a window is open, so if someone closes the window it re-evaluates and adjusts. Same for the TV. Turning it on triggers a lower LUX threshold because glare on a screen is more annoying than direct sun on a face. And the shades open all the way at the start of sunset, because the sunset over the Andes is the actual reason we live in this house and no automation gets to hide it.

The bedtime one is extremely simple but satisfying. The shades automation is more complex and impressive. Both earn their place because they make the house feel like it is paying attention.

What is yours?

Most privacy conversations on this sub frame the issue as a Fourth Amendment question. Search and seizure, probable cause, the warrant requirement. That framing is mostly wrong, or at least mostly incomplete. The doctrine that actually decides what's protected and what isn't, in almost every smart home, cloud account, and digital service case, is the third-party doctrine. It's older than most of the technology it's applied to, and it's the load-bearing wall in the house-of-cards we all live in.

The case is Smith v. Maryland, 1979. The court held that a person has no reasonable expectation of privacy in information they voluntarily share with a third party. The facts were narrow at the time. Smith had called a victim from his home phone, and the police had the phone company install a pen register to record the numbers he dialed, without a warrant. The court said the numbers weren't private because Smith had handed them to the phone company by the act of dialing. The phone company was the third party. He'd voluntarily shared. No warrant required.

I spent eighteen years working traffic homicide cases in Florida, and the doctrine quietly decided more of those cases than the Fourth Amendment did. Cell tower data, cloud backups, app records, smart device logs. The framework that determined whether I needed a warrant or just a subpoena was almost always third-party doctrine, layered with the Stored Communications Act, not the Fourth Amendment in any direct sense. The Fourth Amendment governs the house. Smith governs the cloud.

The doctrine has been eroding, slowly. Carpenter v. United States, 2018, was the first real crack. The court held that historical cell site location information, the records of which towers a phone connected to over time, is sensitive enough that the government needs a warrant to get it, even though the data sits with the carrier. The reasoning was that the information is so revealing and so involuntarily generated (you don't really "choose" to ping cell towers) that the old logic of Smith doesn't fit. But Carpenter was narrow. It carved out cell site location, not everything else. Cloud email, cloud photos, smart speaker logs, Ring footage, thermostat history, search history, all of it still lives substantially in Smith's world, modified by the SCA, which gives weaker protection than a warrant.

Where smart home data lands depends on where it sits. Data on a hub in your closet, on a drive in your house, on a camera that never reaches the internet, that's "papers and effects" inside the home and gets the full Fourth Amendment treatment. Data on a manufacturer's server, even data you generated, is third-party doctrine territory. The same camera, the same recording, the same motion event. Where it lives decides which framework applies, which standard the government has to meet, and whether you'll ever know they asked.

So the practical takeaway, if you're trying to build a private digital life, is that the doctrine is the thing to pay attention to. Not the Fourth Amendment, which is sturdier than people think but covers less than people think. The third-party doctrine is the one that decides what's protected, and it's built on the premise that you already gave it away.

Once you share information with a third party, the law mostly stops treating it as yours. That's not a future risk, it's the current rule. Be deliberate about what you hand over, to whom, and under what architecture. The default architecture of consumer tech is to route everything through someone else's server, which is the architecture the doctrine was designed for. Local-first, end-to-end encrypted, or off the wire entirely are the postures that keep your data on the side of the Fourth Amendment instead of Smith. You can't unshare what you've voluntarily given away.

I've come around to a fairly specific one, and I'm curious where everyone else lands.

Mine is that a smart home should be invisible. The lights come on at sunset, the shades move with the sun, the door announces a visitor before the bell rings. None of that requires me to pick up my phone or open an app or ask a voice assistant for permission. The phone is for when something is wrong, not for running the house.

The test I keep coming back to is whether someone who has never been in my home can use it without instructions. My mother-in-law walks in, hits the switch on the wall, the light comes on. A guest stays for a weekend and never knows there's a system running. The dumb functionality of every switch and every control is preserved, because the moment the smart layer disables the dumb layer, you've built something fragile that breaks for anyone who isn't you.

The other piece is that everything runs locally. Home Assistant on hardware in a closet. No cloud round-trips for the things that matter. If the internet drops, the house still works. If a manufacturer shuts down their servers next year, nothing in my home becomes a brick.

I think a lot of what gets sold as smart home is really just remote-control-by-phone, and the planning question never gets asked. People buy the gadget first and then try to make it fit. I went the other way, planned the system before I bought anything, and the result is a home that mostly disappears.

So what's yours? Where do you draw the line on cloud versus local, on app versus invisible, on the dumb switch staying or going?

I've made a few small esp32 and esp8266 sensors in the past, but nothing on this scale, so I'm a little excited and frightened at the same time.

Working on a vehicle presence and telemetry project for my 1976 Land Cruiser. The vehicle is fully analog (no OBD-II, no factory ECU) and I am adding sensors and reporting back to a Home Assistant install at home. I live in Loja Ecuador and my home is on the Eastern ridge of the Loja valley with a clear view of about 2/3 of the city. So I think LoRa is my obvious choice.

Requirements:

- LoRa radio for telemetry back to home. 915 MHz band (Ecuador). I will run a receiver at home, likely an ESP32 with LoRa as a gateway.

- GPS module for position reporting. Periodic position updates while parked (deep sleep with timed wake), continuous position every 30 seconds while the engine is running.

- BME280 for cabin temperature, humidity, and barometric pressure.

- MPU6050 for inclinometer and impact-wake tamper detection.

- Deep sleep with wake sources: ignition on (optocoupler from the HEI distributor), door open (factory door pin circuit), MPU6050 motion interrupt, and a timer for periodic GPS check-ins.

- Powered from the vehicle's 12V battery via a buck converter. Constant 5V so the tamper detection runs while parked.

- Piezo buzzer for status feedback.

My current candidate is the LILYGO T-Beam since it integrates the ESP32, LoRa SX1276, and a NEO-6M GPS on one board. But before I order:

1. Is the T-Beam still the right choice in 2026, or is there a newer board that does this better and is well supported? I have seen the Heltec V3 mentioned for Meshtastic and the RAK4631 for low-power LoRa work.
2. Anyone running a LoRa-based vehicle tracker with deep sleep that wakes on impact? Specifically interested in whether the wake-on-MPU6050 path is reliable when the device has been asleep for hours.
3. For the home-side receiver, what is the cleanest way to get LoRa data into Home Assistant? Raw LoRa to MQTT via a gateway ESP32, Meshtastic, or LoRaWAN through ChirpStack? I was thinking MQTT. I want this fully local (no cloud).

Happy to share more about the project if useful. I'm in the idea/planning phase, so no decisions made yet.

I've made a few small esp32 and esp8266 sensors in the past, but nothing on this scale, so I'm a little excited and frightened at the same time.

Working on a vehicle presence and telemetry project for my 1976 Land Cruiser. The vehicle is fully analog (no OBD-II, no factory ECU) and I am adding sensors and reporting back to a Home Assistant install at home. I live in Loja Ecuador and my home is on the Eastern ridge of the Loja valley with a clear view of about 2/3 of the city. So I think LoRa is my obvious choice.

Requirements:

- LoRa radio for telemetry back to home. 915 MHz band (Ecuador). I will run a receiver at home, likely an ESP32 with LoRa as a gateway.

- GPS module for position reporting. Periodic position updates while parked (deep sleep with timed wake), continuous position every 30 seconds while the engine is running.

- BME280 for cabin temperature, humidity, and barometric pressure.

- MPU6050 for inclinometer and impact-wake tamper detection.

- Deep sleep with wake sources: ignition on (optocoupler from the HEI distributor), door open (factory door pin circuit), MPU6050 motion interrupt, and a timer for periodic GPS check-ins.

- Powered from the vehicle's 12V battery via a buck converter. Constant 5V so the tamper detection runs while parked.

- Piezo buzzer for status feedback.

My current candidate is the LILYGO T-Beam since it integrates the ESP32, LoRa SX1276, and a NEO-6M GPS on one board. But before I order:

1. Is the T-Beam still the right choice in 2026, or is there a newer board that does this better and is well supported? I have seen the Heltec V3 mentioned for Meshtastic and the RAK4631 for low-power LoRa work.

2. Anyone running a LoRa-based vehicle tracker with deep sleep that wakes on impact? Specifically interested in whether the wake-on-MPU6050 path is reliable when the device has been asleep for hours.

3. For the home-side receiver, what is the cleanest way to get LoRa data into Home Assistant? Raw LoRa to MQTT via a gateway ESP32, Meshtastic, or LoRaWAN through ChirpStack? I was thinking MQTT. I want this fully local (no cloud).

Happy to share more about the project if useful. I'm in the idea/planning phase, so no decisions made yet.

I am a slow adopter when it comes to smart home hardware. The companies below have earned permanent spots in my Home Assistant setup over several years of use. When I need a new sensor, camera, switch, or coordinator, I default to one of these without researching alternatives. That is the time-saving payoff of brand loyalty.

But it might also be making me miss something better. So: change my mind.

**Third Reality (sensors, smart plugs)**

When I need a sensor and they make it, I buy theirs without checking alternatives. Strict Zigbee 3.0 compliance, AA batteries instead of CR2032 in most sensors, OTA firmware through HA. They are good Zigbee mesh citizens, which matters when your mesh has devices from five other brands on it.

**Reolink (cameras and NVR)**

PoE cameras paired with their NVR means my video never goes to anyone's cloud. The native HA integration is genuinely good: doorbell events fire in real-time, snapshots come from the camera's API and not a buffered stream, AI detection events are granular enough to build real automations on. Worth knowing they support ONVIF and RTSP if you want to bypass their integration entirely.

**SMLight (Zigbee and Thread coordinators)**

Network-attached coordinators instead of USB sticks. The SLZB-06 line sits on Ethernet, can be PoE-powered, and lives wherever the mesh needs it. Devices that were finicky on USB coordinators tend to behave when you switch.

**Zooz (Z-Wave coordinators and devices)**

The workhorse of Z-Wave. Their 800-series coordinators support Z-Wave Long Range, which extends reliable range to several hundred feet through obstacles. Their switches and sensors are ETL certified, well documented, reasonably priced. Not flashy. Just consistently works.

**Inovelli (smart switches)**

Premium pick for smart switches. The RGBW notification bar turns the switch into an ambient information display: pulse red when the security system is armed, blue if rain is forecast, countdown for the laundry cycle. Outstanding customer support, often direct from company leadership. Worth the price for switches that matter.

**Shelly (invisible relays and miniature devices)**

Tiny relays that fit behind a traditional wall switch or inside the appliance you already own. They turn dumb devices smart without replacing them. Multi-protocol, local-first, MQTT to HA out of the box. The form factor is the magic. Anywhere a full smart switch will not fit, Shelly probably will.

Who is missing? What have you been using long enough to vouch for? Occasionally, it is a good idea to take a look around. This slow adopter is willing to be convinced.

The standard way to add conditions to a device in HA is to include them in an automation. The automation has a trigger, a condition block, and an action. The conditions are checked when the automation fires, and only then. If the conditions are not met, the action is skipped.

This works for most situations. It fails when the rules are vital enough that a sloppy script, a voice command, or a stray tap on a dashboard can ignore them. These manual overrides walk right past your safeguards and leave your hardware in a state it was never meant to handle.

I was presented with this particular problem with my Motion Blinds. If a shade is closed on an open window, the Loja breeze catches the shade like a kite, damaging it instantly.

The solution is to stop treating safety like an afterthought and start treating it like a filter. A guarded entity acts as a suspicious middleman standing in between the command and the device. No matter where the command comes from, a voice assistant, a dashboard tap, or an automation, it has to clear the guard first. The guard inspects the request and either grants passage, edits the instruction to keep things safe, or drops the command entirely.

I will use my motorized shades as the primary example because the failure is so easy to visualize. But this same blueprint works for door locks, smart appliances, and thermostats. It applies to any device where you want to put a set of hard rules in front of the "execute" button.

The shade case is simple. If a window is open and a strong gust comes in, a partially closed shade can catch the wind and damages the fabric or the motor. The shade should not be allowed to go below its safety limit while the window is open. That rule has to hold whether the command came from the dashboard, a voice assistant, or an automation.

The implementation is a template cover that wraps the real cover. Hide the real entity from your dashboard and your voice assistant. Expose only the wrapper.

Below is the version I run for my living room shades. The real entity is `cover.living_shades`. The window sensors are the two window contacts. The disable toggle is an input_boolean for manual override. The wrapped entity I expose is `cover.living_shades_guarded`. My safety limit is 62, but you set whatever number works for your shades.

template:
  - cover:
      - name: "Living Shades Guarded"
        unique_id: "living_shades_guarded"
        device_class: shade
        state: "{{ states('cover.living_shades') }}"
        position: "{{ state_attr('cover.living_shades', 'current_position') }}"
        availability: "{{ has_value('cover.living_shades') }}"
        open_cover:
          - if:
              - condition: state
                entity_id: input_boolean.disable_living_room_shades
                state: 'on'
            then:
              - action: script.do_nothing
            else:
              - action: cover.open_cover
                target:
                  entity_id: cover.living_shades
        close_cover:
          - if:
              - condition: state
                entity_id: input_boolean.disable_living_room_shades
                state: 'on'
            then:
              - action: script.do_nothing
            else:
              - if:
                  - condition: template
                    value_template: >-
                      {{ not is_state('binary_sensor.window_living_room_left_contact', 'off')
                      or not is_state('binary_sensor.window_living_room_right_contact', 'off') }}
                then:
                  - action: cover.set_cover_position
                    target:
                      entity_id: cover.living_shades
                    data:
                      position: 62
                else:
                  - action: cover.close_cover
                    target:
                      entity_id: cover.living_shades
        set_cover_position:
          - if:
              - condition: state
                entity_id: input_boolean.disable_living_room_shades
                state: 'on'
            then:
              - action: script.do_nothing
            else:
              - if:
                  - condition: template
                    value_template: >-
                      {{ (not is_state('binary_sensor.window_living_room_left_contact', 'off')
                      or not is_state('binary_sensor.window_living_room_right_contact', 'off'))
                      and position | int(100) < 62 }}
                then:
                  - action: cover.set_cover_position
                    target:
                      entity_id: cover.living_shades
                    data:
                      position: 62
                  else:
                    - action: cover.set_cover_position
                      target:
                        entity_id: cover.living_shades
                      data:
                        position: "{{ position }}"
        stop_cover:
          - action: cover.stop_cover
            target:
              entity_id: cover.living_shades

`script.do_nothing` is a one-line script with an empty sequence. It exists so the disable toggle has somewhere to send commands when you want the wrapped cover to ignore everything.

What the wrapper does:

`open_cover` opens the real cover unless the disable is on. Wind cannot damage a blind that is going up.

`close_cover` checks the windows. If either is open, it sets the position to the safety limit instead of fully closing. If both windows are closed, it closes the shade normally.

`set_cover_position` is the safety-critical handler. If the windows are open and the requested position is below the safety limit, it clamps to the safety limit. Otherwise it passes the requested position through.

`stop_cover` always passes through. A stop is never unsafe.

The conditions live on the entity. Every command path has to go through them. There is no race condition, no watchdog automation racing the wind, no path that bypasses the safety check.

The same wrapper structure works for almost any entity in HA where you want a layer of protection between the dashboard and the device. A door lock you do not want HA to unlock when nobody is home. A smart plug for a space heater that should refuse to turn on if there is nobody in the room. Hide the real entity. Expose the wrapper. Put your conditions on the entity, not in a watchdog automation.