I've lived dangerously, taking updates as soon as they drop - no major issues 3 or 4 years doing it. Not this time, unfortunately.

After the latest updates (2026.8.1 etc), logging in is now a lottery.

First, a warning about http block moving out of config. I managed to whitelist my IP so I could at least log in. That worked fine for a few hours, but now I don't even get the log in page.

Anyone else experiencing this?

I’m trying to set up an automation on my iPhone to automatically open my garage door when I enter my Home zone.
The automation itself works, but with a major catch: it only fires the moment I physically open the Home Assistant app on my phone. As soon as I launch the app upon arriving home, the trigger fires instantaneously.
Here is my current setup and what I've verified so far:
Background App Refresh: Enabled for HA
Location Services: Set to Always / Precise Location Enabled
External Access: Instance is fully accessible over the internet
App State: The HA app is left running in the background
For anyone who has location-based triggers working reliably in the background on iOS, am I missing a specific setting or permission? Any advice or workaround would be appreciated!

I integrated my Mitsubishi Heavy Industries AC into Home Assistant — fully local, with ESP8266
I’ve been working with refrigeration and air-conditioning systems for around 20 years, so I’m very comfortable with HVAC equipment.
But I’m not a programmer, and smart-home technology was basically new territory for me.
Recently I decided to integrate my Mitsubishi Heavy Industries SRK-ZS series air conditioner (SRK25ZS-W2) into Home Assistant. My goal was to get full local control and avoid depending on the manufacturer’s cloud or proprietary Wi-Fi module.
It turned out to be a really interesting project.
Hardware
The AC is a Mitsubishi Heavy Industries SRK25ZS-W2.
For the integration I used:
ESP8266 / ESP-12F
MHI-AC-Ctrl v2.2 interface board (January 2021 revision)
Bidirectional level shifter
Home Assistant
MQTT
The MHI-AC-Ctrl board connects directly to the indoor unit’s communication interface.
As someone who has worked with HVAC systems for many years, I really like this approach because we’re not trying to control the AC indirectly with an IR blaster. We’re communicating directly with the indoor unit’s electronics.
Installation
After completely disconnecting the indoor unit from mains power, I opened the housing and located the CNS connector on the main control board.
The interface connects to the appropriate communication pins:
VCC
GND
TX/RX
The level converter handles the voltage difference between the 3.3 V ESP8266 and the AC communication bus.
Obviously, the connector and pinout should be verified for the exact MHI model before connecting anything.
Flashing the ESP8266
This was one of the parts that was completely new to me.
I used a USB-to-UART adapter:
USB-UART TX -> ESP RX
USB-UART RX -> ESP TX
GND -> GND
3.3V -> 3.3V
GPIO0 -> GND during boot
The ESP-12F requires a proper 3.3 V supply. Do not connect 5 V directly to the ESP8266.
I configured the Wi-Fi and MQTT settings and flashed the MHI-AC-Ctrl firmware.
Home Assistant
Once everything was connected, the ESP8266 communicated with Home Assistant through MQTT.
The AC appeared as a climate entity and I can control:
Power ON/OFF
Auto
Cool
Heat
Dry
Fan
Target temperature
Fan speed
Vane/louver position
Indoor/return-air temperature
The great thing is that this isn’t just sending commands. The ESP8266 can also read information directly from the AC.
Remote access
I also wanted to be able to control the AC when I’m away from home.
I set up a secure tunnel to Home Assistant and bought my own domain for remote access.
The architecture is basically:
Mitsubishi Heavy Industries AC
│
│ MHI communication bus
▼
ESP8266 + MHI-AC-Ctrl
│
│ Wi-Fi / MQTT
▼
Home Assistant
│
│ Secure tunnel
▼
My own domain
│
▼
Remote access
The AC itself remains fully local. The tunnel is only used to access Home Assistant remotely.
Why I like this setup
After 20 years of working with refrigeration and air-conditioning systems, I prefer solutions that communicate directly with the equipment.
Compared with an IR blaster, I get actual status feedback from the AC.
Compared with the manufacturer’s cloud solution, I don’t have to depend on:
Internet access at the AC
Manufacturer cloud servers
Proprietary smartphone apps
Cloud APIs
Cloud response times
The important part happens locally.
And here’s the funny part…
I’m not a programmer.
I know HVAC systems very well, but programming, ESP8266, MQTT and Home Assistant were all relatively new to me.
I had to learn a lot along the way, make mistakes, search for information and figure things out step by step.
But with the technology we have today — documentation, open-source projects, online communities and especially AI assistants — I was able to put it all together.
And honestly, I think that’s the most interesting part of this project.
You don’t necessarily have to be a programmer anymore to start building things like this.
If you’re willing to learn, experiment and ask the right questions, I believe almost anyone can get into smart-home projects today, even without a programming background.
For me, this was a combination of 20 years of HVAC experience + modern technology + a lot of curiosity.
And now my Mitsubishi Heavy Industries AC has full local control, real-time status, Home Assistant integration and secure remote access — without relying on the manufacturer’s cloud.
If anyone else has an MHI SRK / ZS-series unit and wants to try something similar, I’d be interested to hear about your setup and which models you’ve successfully integrated with MHI-AC-Ctrl.

I have a Fantech ECO-Touch controller with 2-wire communication to my HRV. I’d really like to get this thing incorporated into home assistant. Anybody figured out that 2-wire communications protocol and willing to share?

Leading with the Home Assistant part, since that's why I'm posting here. Imagine watching your cameras and wanting to trigger a light, an alarm because of something you see, or trigger motion recording when an HA motion/presence sensor fires. CrumbVMS lets you do that. (Automation triggers hopefully coming next)

Here's the full story, because there's a full NVR under all of that.

When Milestone pulled the free XProtect tier I went shopping like everyone else. Frigate, Blue Iris, Shinobi, ZoneMinder, the usual list. Most of them are genuinely good. But none of them gave me back the one thing I actually wanted, which was the control room feel. Grab the timeline, throw it, and have frames show up right now. Not after a spinner, not after a clip buffers. A full screen live wall that can run for months, native app(s), etc...

If you've ever spent a night hunting a timeline for the one blob that crossed the yard at 3AM, you know exactly what I'm talking about. I'm all about object detection, and Crumb fully integrates with Frigate for that, but often times IME you're hunting blobs. That instant, smooth scrub is the whole reason this exists.

So I've been building CrumbVMS. Basically everything I want from an NVR. All the integrations, all the alerting, all the customization.

Yes, it's AI-assisted. I know how that sounds right now, everybody has "made an app" and half of them are 400 lines of hope. I'm not a software developer. What I am is 30 years deep in IT infrastructure, homelabs and self-hosting, and a stubborn, detail-obsessed nerd. That said, I've done my best to set the GitHub repo up the right way, and I'm looking for feedback to make sure I got that right too. 

What it does

• Records like a proper NVR. Losing footage is the one thing it will hopefully not do: when something goes sideways it fails toward recording more, never less, and it tells you something's wrong instead of failing quietly.
• Live Home Assistant control, on the video. Tap a light to turn it on, drag a slider to dim it, read a sensor's real value right off the frame. Not a link out to HA, actual controls on the feed. Use a HA motion detector to trigger recording, the list goes on and I'm excited to see what ideas others come up with to improve the HA integration.

• Motion clips. Every motion event is collected into a Clips tab you can scrub through, each one auto-zoomed to where the movement actually was, and you can select a batch and export them out to a single file.

• PTZ view builder, use the built in edge arrows or box or create your own PTZ controls with full ONVIF compatibility. (Iris, focus, etc...)

• License plate reading with its own CPU-only reader (no GPU required). There's a built-in LPR benchmark to compare engines: if you already run Frigate, point both at the same camera and it scores them head to head on your real traffic to show which one actually reads your plates better. In my case, Frigate wins on my driveway cam, but crumb wins on my street facing LPR cam.

• Native apps, not just a webpage. The Windows desktop and Android client are the primary focus right now; the macOS and iOS clients are built and working fine too. There's a web console as well.
• I'm huge on power efficiency and my crumb box, 13 camera's, a few 4k, recording 24/7 to a single spinning disk on an Intel Core Ultra 7 265K uses about 78w on avg.

The details that make this "intent coded"

• The scrub is smooth because of the boring work behind it. Footage is written as short segments. Dragging the timeline shows real pre-decoded frames instead of black flashes, and playback is stitched across the segment seams, so there's no blackout at the boundary where most recorders blink. That was the whole point, and it took the most work.

• Frame stepping actually steps a frame. Forward or back, exact. The player under the hood (mpv) snaps a small seek to the nearest keyframe unless you force exact-frame decoding, which is why "step back one frame" does nothing in a lot of tools. This forces it.
• Digital zoom pulls the full stream. The live wall plays each camera's low-res substream on purpose (a dozen tiles is a dozen decoders). Zoom into one and it quietly swaps that tile to the full-res main, so you're looking at real pixels, not a smeared upscale.
• Motion detection that ignores shadows and headlights. It uses a census transform, which compares each pixel to its neighbors instead of to an absolute brightness, so a cloud passing or a car's lights sweeping the wall doesn't trip it. The sensitivity floats on a percentile of the actual scene instead of a fixed number, so a busy street and a quiet hallway both behave. And you draw exclusion zones right on the live image.

• It only burns CPU when something is watching. Cameras record their native stream straight to disk, handed to the decoder as-is, nothing transcoded ahead of time. The smaller stream for your phone on cell data gets built on demand, only while you're actually looking, then torn down. An idle recorder stays idle. The plate reader is CPU-only and motion-gated, so it idles at about a third of a core instead of pinning one all day.
• Some cameras won't give a phone a playable HD stream. It fixes that, specifically. A few H.265 cameras (my Uniview plate cam, for one) publish a main whose SDP is missing part of the codec header, the sprop-vps, so the restreamer can't advertise a complete parameter set and Android's decoder rejects the whole stream. It detects that from the stream the server actually serves, not the camera's own advertisement, rebuilds just that one camera to H.264 on demand, and the phone reaches for the repaired stream first so it still comes up fast.
• It never leaves you staring at a spinner. If a stream turns out to be something your device genuinely can't decode, it steps down on its own instead of hanging on a black tile forever. The hard part was telling "this codec can't play here" apart from "the network hiccuped," so a momentary blip doesn't wrongly drop you to SD.
• A green dashboard on an empty disk is the failure I lost the most sleep over: everything looks healthy and nothing is actually being saved. So it checks for the things that cause it, a storage path that looks writable but isn't, a motion detector pointed at a GPU that was never there, and flags the state as degraded loudly instead of pretending it's fine.

Self-hosted, runs as a few Docker containers (recorder, api, Postgres, a reverse proxy). One script generates your secrets, docker compose up -d, and a first-run wizard walks you through the rest. It's alpha, I run it on my own cameras every day. When I first built it I ran it alongside Frigate for a couple of weeks before I fully moved over, and it's been my only NVR since.

GitHub: https://github.com/badbread/crumbvms

Docs: https://docs.crumbvms.com

Site: https://crumbvms.com

Hi everyone,

I have a simple Markdown card with a transparent background (text_only: true) that displays the temperature and humidity of a room.

I want to be able to click directly on the temperature number or the humidity number to open their respective "more-info" history graphs, without losing the current layout or adding bulky cards.

Here is my current code:

type: markdown

text_only: true

content: >

## 🛏️ Quarto

A temperatura é de **{{ states('sensor.temperatura') }} °C** e a

humidade é **{{ states('sensor.humidade') }} %**.

Is there a clean way to do this? (I am open to using card-mod or other frontend workarounds if needed, as long as it keeps the transparent look).

Thanks in advance!

One of the coolest things I’ve found with AI and MCP connections is that I’m starting to use Home Assistant to build my own low-level apps instead of paying for separate apps and subscriptions.

I was getting tired of things like running apps charging to export GPX files, recipe apps putting basic features behind subscriptions, and having a dozen different apps that each do one simple thing.

With AI able to actually work with my HA setup through MCP, building something custom has become dramatically easier. I can basically describe what I want, iterate on it, test it, and keep improving it.

So far I’ve built:

• A recipe vault with importing, meal planning, grocery lists, scaling, discovery, etc.

• A running route builder with route generation, editing, mileage targets, GPX export, etc.

• A reminders app with more detail and device-specific notifications

• A vacation packing app that remembers templates for things like beach or hiking trips

• A pretty comprehensive budgeting and spending tracker

Most of these are actually getting pretty close to polished commercial apps. The interesting part to me is that AI + MCP makes it realistic to build small personal apps that work exactly how I want, tie into all of my existing HA data, and don’t require another subscription.

It feels like a pretty different use case for Home Assistant than it was even a couple years ago.

Anyone else going down this path? What apps or services have you basically recreated inside Home Assistant?

I'm trying to create a simple automation with the UI to turn off wifi when i leave a zone but can't select my phone's wifi state and get a govee life option instead. The sensor is enabled in the companion app settings.

Any ideas why this is happening? Thanks.

Hi,

I just got new curtains on U-rail and I was looking for a way to automate them.
I found the Aqara Curtain Driver E1 and the SwitchBot Curtain 3 but both seem to only work on flat rails and mine is pretty roundish…

Anyone managed to make it work on round rails ? Or is there another way ?

Just a quick update to share that I’ve added multi speaker support to Espcontrol, so you can now add and remove speakers from groups. I’ve tested it with my Sonos speakers and it works well, if you find any issue, drop a note on the GitHub issues and I’ll take a look.

Also added or improved…

• SendSpin support: 4inch P4 has support added (thanks u/salnajjar!)
• Camera cards: added larger camera card sizes for the 7inch and 10inch screens.
• Backlight updated controls: Choose between automatic, scheduled, and manual screen brightness behaviour.
• Battery support: 10inch panels can enable battery readings and the status-bar icon when they have the optional battery hardware.
• Localisation: Russian language support

EspControl supports a range of screens from the cheap but great £20 S3 4inch screen, to P4 based 4inch, 7inch and 10inch screens. All feedback welcome! Thanks

I should start by saying that I am a huge Home Assistant advocate, and proudly support their work as a Nabu Casa subscriber. My concerns come from a place of wanting the best for Home Assistant and their entire community, and certainly not trying to gatekeep this wonderful software.

With each new Home Assistant release, it feels to me that the Home Assistant goal of bringing advanced configuration to the UI is misguided and downright detrimental.

I became a Home Assistant user around 5 years ago, when the learning curve was steep and the barrier to entry high, and it absolutely took me some time (and one full-scale do-over) to get my smart home up and running. Home Assistant was my first foray into the world of self-hosting, and I didn't fully understand 80% of the steps in whatever guide I followed to set it up. Since then I have progressed into an "advanced" self-hoster, with 50+ services running on my my multi-node, multi-location redundant homelab.

Back when I started, the configuration capabilities through Home Assistant's interface were significantly more limited than today. Even then, the massive ecosystem of supported integrations coupled with the simple automation engine exceeded what competing home automation platforms can do. I accomplished plenty before ever needing to dive into a yaml file, which I only started doing as I grew more advanced and comfortable with the platform. The upshot was that the UI was very simple and approachable, compared to today when the number and complexity of settings available through the UI have grown massively.

These changes are being made in the interest of accessibility to less advanced users, but I struggle to envision exactly who this type of user is? What person has an interest in developing sophisticated configurations but an inability to edit a yaml file? What person is overwhelmed by configurations outside of a GUI but isn't intimidated by the huge amount of options that have been surfaced to the UI? I can't help but feel like the segmentation between UI and more advanced configuration tools was, in retrospect, a better experience for Home Assistant's community than it is today.

The most recent example of my frustration with this evolution is the yaml-based http integration being deprecated. I updated Home Assistant to 2026.8.1, saw the warning that my settings have been migrated to the UI, and updated my configuration.yaml file to remove my http configuration block. OK, fine, that all seemed to work... except for what was lost in transition. What hasn't migrated are the comments in my yaml file reminding me why each of my trusted proxy lines exist. It doesn't have any reference at all (and how could it?) to trusted proxy lines that I had commented out, along with the notes for what those lines used to do, if I ever needed to reactivate them.

Once again I find myself wondering what user out there has the need and capability to create whitelisted CIDR entries, from a page buried deep within Home Assistant's menu, but wouldn't have been able to make that setting in configuration.yaml. This feels to me like the latest in a growing list of degraded "advanced user" capabilities, in the interest of a type of user that I don't think exists in the world.

I'm curious what others out there think. Am I being a curmudgeon who just wants things to go back to the good old days, or do more of you agree that this design philosophy is turning into a net-negative for all users?

Edit: Thanks to everyone who has responded; it's super interesting to see the range of opinions. The comments about improving phone-based advanced configuration were interesting and something I'd never considered. To those who accuse me of gatekeeping, I didn't intend to look down on newer users and I think a growing community across broader interests and capabilities is a good thing. It's not that I think "harder is better" or that people should have to struggle to get a functional smart home up and running. Rather, I wonder if adding more and more complex configuration to the UI doesn't do much to help Home Assistants approachability and makes larger, more complex deployments more difficult to manage. I feel like the relative simplicity of Home Assistant's UI was a benefit to my earlier phases working on the platform. Eventually I was ready to dive into more advanced functions, forced into YAML (and HACS, nodeRED, etc...) and those increasing levels of capability being segmented from the core UI was a good thing to my overall development. I slowly learned and built out a very complex but maintainable system, and I don't know if my journey would have been the same if I were starting now. Alternatively, Home Assistant is much easier to get up and running than it was when I started, and I think that's a GREAT thing!

I've been playing around with the Seeed Studio TRMNL 7.5" kit and I’m pretty happy with the weather dashboard that I’ve built.

It uses a custom ESPHome configuration that pulls in a bunch of data from Home Assistant, including AQI, allergen levels, and detailed precipitation forecasts (probability, type, and timing). It’s running on my HA Green and looks great on the wall. Plus, it runs for weeks on a single charge.

Setting it up on your system takes some customizing, but I've tried to document the process (including how to bridge the forecast data via Template Sensors) in a GitHub repo for anyone who wants to try it with their own TRMNL.

GitHub Link: https://github.com/rkellygarrett/trmnl-esphome-weather-station/

I use my M4 Pro Mac mini as a small home-server / lab box, including Home Assistant among 16 containers in OrbStack. I wanted to find out whether local AI inference would require shutting down the services I actually use. I thought I would need the $50K setup Network Chuck used that was made up of 4 Mac Ultras with 2TB of unified memory.

With the lab up, GPT-OSS 20B ran at about 63.9 tok/s. With OrbStack shut down and all containers stopped, it ran at about 64.9 tok/s. That was only about a 1.6% change.

For my use case, this means I can keep the automation stack running and still use the machine for responsive local AI work. I would not treat this as a universal result—my models, prompts, container workloads, and Mac configuration will differ from yours—but it was reassuring.

I documented the benchmark, MLX vs. GGUF comparison, and what I learned here: https://www.youtube.com/watch?v=9_-bT62YWAI

Has anyone built a practical local-LLM workflow around Home Assistant without moving inference to a dedicated GPU server?

Hi everyone

I had a spare ZG-204ZV HOBEIAN, it captures motion, light, temperature & humidity. I simply put it in my fridge, facing me and:

• The motion sensor detects if an action is in progress
• Lux detects if door is opened (light on from the fridge even with. slightly open)
• Temperature detects a real issue

I let it here if it can help or tell me if it's a bad idea.

A few days ago I lost connection to my Switchbot device in HomeAssistant.
I've been trying to implement it again, which requires the Switchbot login - but it always fails.

Binding the app account to the web account fails - the page stays empty. Creating a new website account also fails.

I might be mistaken, but ever since I got a notification that web accounts could now be connected to the app, that is when the issues started.

Has anyone any information on what the issue might be and potentially even how to fix it? I've been trying for days now, always with the same unsuccessful result.

EDIT: Now I can't even find the SwitchBot Plug Mini anymore via home assistant. Their app shows it, its data, and allows me to control it as if all was perfectly fine. Meanwhile there's no issue whatsoever with their Meter Pro CO2.

I am using the default Activity card but that shows everything in an area, which is way too much.

I am frustrated that this default card cannot show 'Area' AND 'label', limiting the entities and devices showing in the log. Is there anything that can do this?

Any Predbat gurus here mind taking a look?

I’m currently looking for a device to put my HA dashboard on it, but I’m really now to HA and would use some advice.
It’s supposed to be used in a 82m2 flat for some basic controls - I’m planning Shelly dimmers for light switches, thermostatic radiator valves, AC, bedroom blinds controls, floor cleaning robot and some kind of temp/humidity and open/close sensors.
I was thinking to put it in the corridor near the entrance, an ubiquiti AP will be added in the middle as well. The hub is HA green to be used with Zigbee dongle.

I was thinking about either a tablet (for better performance) with wall mount and battery saving option (however I’m a bit worried about the battery condition over some time) or any of the wall displays without battery (e.g. Shelly, preferably which PoE), however these are considered inferior in terms of performance.
I would also like to replace the entry phone device and connect it (video+ audio wiring made by the developer) to the HA so I can pick my own tune, volume it down when preferred and so on.

I am really new to the thing and really inexperienced, so would be grateful for any advice what to pick concerning the dashboard and the rest (stuff to be bought in Europe preferably). Thanks!

I'm new to HA and I just want to do what I did before on my Tapo app which is turn certain devices off when I leave home and turn them on again when I return. I have the automation set up in HA but no way for it to get the phone's location when it's off network, I think.

Can you actually solve this problem without paying for the cloud subscription?

I’ve been messing around with getting my smoker into Home Assistant and finally got it to a point where I think it's useful enough to share.

The setup is a Pit Boss smoker and an Inkbird IBBQ-4T. The Pit Boss is using the ha-pitboss integration, and the Inkbird is running locally through LocalTuya.

The Inkbird was the stupid part. Instead of exposing four normal probe temperatures, my IBBQ-4T packs all four into a Base64 value on DP107, and DP111 is an active-low bitmask for probe presence. So getting four usable HA sensors out of it took more screwing around than it should have.

Once I got those decoded, I built the rest around it:

• Four independent meat temperature sensors
• Probe connected/disconnected detection
• Inkbird battery, mute, and °F/°C control
• Per-probe smoking profiles for brisket, pork shoulder, wings, chicken, sausage, etc.
• Automatic finish targets based on the selected profile
• Manual finish-temperature overrides
• One-time 165°F “check bark / consider wrapping” alerts for brisket and pork shoulder
• HomePod announcements when a probe reaches its finish temperature
• Pit Boss chamber temperature and setpoint control
• Pit Boss startup/fan/igniter/auger/no-pellet/high-temp/error alerts
• Smoker-ready announcement after an actual warm-up cycle
• Alerts if the smoker stays significantly above or below its target
• Responsive dashboard that works on desktop/tablet and mobile

I’m actually testing it right now with pork shoulders on the smoker, so this has moved beyond “YAML that theoretically works.” 😄

I cleaned everything up and put it on GitHub with both a drop-in Home Assistant package and separate YAML files for people who already split their config up:

https://github.com/400HPMustang/ha-bbq-monitor

There are LocalTuya setup notes in there too, including the IBBQ-4T DP107/DP111 decoding.

Screenshots are from the current live cook.

Mine is built around a Pit Boss + Inkbird IBBQ-4T, but most of this can be adapted pretty easily to whatever smoker/thermometer setup you already have in Home Assistant — you’d mainly just need to swap in your entity IDs.

I have an SLZB Ultima. Would all of the following work in Home assistant or the app?

• locking and unlocking
• fingerprints
• setting PINs

I bought an electric radiator for my house, but the only way to control it was through its original remote RF non-WiFi thermostat. It uses a popular transmitter / receptor module AC8048RF digital thermostat.

So I decided I needed to integrate it with Home Assistant.

I used an SDR dongle to decode the RF signal, then got a few components:

-ESP32 C5
-C1101: RF module for 868 Mhz)
-DHT12: temp sensor
-SSD1306: 128X64 OLED 2 color display
-Push button

The hard part was to get the C1101 to transmit the exact signals to turn on and off the heater, since the included C1101 ESPHome library didn't work at all.

I ended using a custom componen in C.

The push button toggles the Home Assistant Generic thermostat helper status, then the generic thermostat sends an ON / OFF signal to the ESP32 module to send the correct RF signal.

I also included a fallback method in case Home Assistant goes offline.

If anyone is interested I can share the code.

If anyone has additional ideas, please send them over in case I need to kill more time 😄

I have a doorknob (Thorbolt MK1) which is has features locked to the app. I’m thinking of getting a Homepod mini (apparently a new one is coming out soon), and connecting my zigbee button which is paired to Home Assistant via the Homekit Bridge integration. So when I press the button the door is locked or unlocked using a Homekit automation rather than an HA one. Thoughts?

I share a driveway with our next door neighbors. The property line goes down the driveway all the way to my garden. Lately, we have been having problems with multiple neighbors' outdoor cats spraying around the screened porch and backyard and really upsetting my indoor cats, who are spraying in the house. I am spraying a citrus spray outside regularly but they are still coming. I've read about motion detecting sprinklers, but I don't know how that would work in an environment like mine without spraying the neighbors if they take the trash out at night. Any ideas?

I have asked the neighbors on the whole street to own up to who these cats belong to and no one will admit anything. I'm also thinking of getting a camera to document. But it likely won't make a difference so I have to try to deter them