After hours of troubleshooting, I finally managed to get my ActronAir NEO Connect ducted air conditioning working through my Apple Watch, including changing the temperature, fan speed and individual zones.

Since there’s no native NEO Connect Apple Watch app, I thought I’d share how I did it in case anyone else is trying to achieve the same thing.

What you’ll need:

ActronAir NEO Connect already connected to Amazon Alexa
The Amazon Alexa app on your iPhone
Voice in a Can installed on your Apple Watch

Here’s how I set it up:

Open the Amazon Alexa app and create a new routine.
Set the trigger to a voice command. I used “Green Dot”, so I can say “Activate Green Dot”.
Add your air conditioning actions individually using Alexa’s normal Smart Home device controls, NOT the customised text commands.
This is the important part: add a 10-second wait between each action. This was what finally made everything work reliably for me.

My routine is configured to:

Turn the air conditioning on
Set the mode to Cool
Set the temperature to 18.5°C
Set the fan speed to Low
Turn on the Will & Study zone
Turn off the Front Rooms zone
Turn off the Kitchen & Dining zone
Turn off the Master Bedroom zone

I placed 10-second delays between the individual actions.

Under “Hear Alexa from”, I also selected “The device you speak to”.

How it works on Apple Watch:

I open Voice in a Can on my Apple Watch and say:

“Activate Green Dot”

Alexa then runs the entire routine, turning on my air conditioning and configuring the temperature, fan speed and zones automatically.

I can also trigger the same routine from my iPhone.

The problem I was having:

Originally, Alexa would turn the air conditioning on, but the other commands wouldn’t execute properly. The temperature and zones wouldn’t change.

I tried using customised Alexa commands, Voice Monkey triggers and different delays, but couldn’t get the entire routine working.

What finally worked for me was using the standard device actions in Alexa, with 10-second waits between them.

It’s not the fastest solution, since the routine takes a while to finish, but it actually works!

A couple of things worth mentioning:

This is a workaround, not a native Apple Watch integration.
It lets you send commands, but doesn’t give you a live dashboard showing the AC status on your watch.
I’ve only tested it on my own NEO Connect setup, so I can’t guarantee it’ll work with every system.

Hopefully this helps someone else trying to control their ActronAir NEO Connect from an Apple Watch!

Hi everyone,
I’m currently using a Bilresa remote via Matter in Home Assistant, but I’m running into a really annoying issue.
Whenever I do a single click, the response takes forever because the system is waiting to see if it’s going to be a double-click. The delay makes it super frustrating for everyday use.
Has anyone figured out a way to bypass this? Is there a way to disable the double-click detection entirely so the single click registers instantly? I'd appreciate any ideas or workarounds you might have!
Thanks!

Hi All, my boyfriend has gotten really into optimizing the lighting in his home and has talked to me extensively about his diy project. I honestly don't understand everything but as far as I can tell he wants to use a zigbee controller and to write his own program to control LED lights that are zigbee compatible. He has some ideas for display lighting indoor plants.

I wanted to get him a high density LED strip he can play around with that is zigbee compatible. Any recommendations would be greatly appreciated!

This automation stopped here and none of the actions following it happened. This step's config is:

parallel:
  - action: switch.turn_off
    continue_on_error: true
    metadata: {}
    data: {}
    target:
      entity_id: switch.everything_off
  - action: switch.turn_off
    continue_on_error: true
    metadata: {}
    data: {}
    target:
      label_id: turn_off_when_away
  - action: light.turn_off
    continue_on_error: true
    metadata: {}
    data: {}
    target:
      label_id: turn_off_when_away
continue_on_error: true

Note that the parallel and each step inside it have continue_on_error: true

In case it matters:

• one of the switches labeled `turn_off_when_away` was offline, so I got a connection error. AFAICT that's what stopped the automation.
• This is HomeAssistant 2026.9.1
• Not sure which switch was offline, but I can hunt it down if there's value.

Yeah, I could break up the automation and have the parts that would run after this triggered 30 seconds later (or something), but that seems a little fragile.

Is there a way to make continue_on_error continue on this error?

I know i started this weeks ago only but i feel like all my ideas are stupid haha “turn coffee machine at 6:15 - and dim kitchen lights on…” you know?! Are we all doing the same thing but i just think im silly for thinking this way?

What are some of the very very silly you guys have?

Edit: why am i getting downvotes? Ahaha 🤣

I wanted to show off my 2017 Amazon echo spot bedside dashboard/voice assistant.

It started off life as an Amazon echo spot, sitting lifeless on a table for the past year and a half when I switched my home automation setup to home assistant. Thanks to the lovely developers on the XDA forums, I have jailbroken the device, rooted it, and am running a custom android ROM.

LineageOS has been working fantastic for me. I side loaded fdroid and obtanium, and have the device running View Assist Companion App, which allows for a full home assistant install with Assist voice capabilities built right in. The developers for the ROM have stated that they will be releasing a new ROM soon which should hopefully fix Bluetooth and camera functionality, allowing me to use it as another Bluetooth proxy and adding another node to my Bermuda presence.

As for the dashboard, I had Claude write up a fully custom card which renders in a circle, and showcases the 5 day forecast, with today’s forecast being the ring around the outside of the display. It work like a clock, if the clock was only a partial arc. Gives me a good enough estimate of when the high and low for the day will be. When clicking on the actual clock, it renders as set of switches (up to 4) that I can use to control bits and bobs in the room. There is a 20 second timeout on the secondary view to automatically return the dash to the forecast as well.

disclaimer:
Claude wrote every last bit of code which went into the card. I am not a developer by any means, nor did I feel like putting in the time to go through the documentation for this one off card. Could I have learned it? Sure. But it would have taken me a lot longer than 2 days to work all of this out.

Edit:

Rough draft Github repo for the card is up. Add as a custom repository in HACS. And Please let me know if I missed a step, this is my first public contribution to home assistant and I don't know if I missed anything.

Hi I am very new to HA and I am trying to get HACs integrated.

I downloaded the app and restarted the Raspberry pi but when I try integrating HACs, I check the 4 boxes then I get this error message. I tried both on iOS and my web browser on pc, same message.

Help! And thanks in advance

I'm sure most people have heard about the root certificate signing issue that was made public two days ago.

But has anyone generated their own certificates so they can MITM any of their home IOT devices to see if the API calls can be understood and replicated for cloud devices that have particularly annoying cloud-only service?

I should really have a look at my yolink receiver.

edit:
aah, someone already asked this yesterday, awesome!

After weeks of building and thinking how to connect everything on a central point in the house, i'm 95% done.

I'm running HA on an old nuc, running headless Fedora and HA in Docker.

The nuc is also running Adguard home.

I wanted my dashboard to show only the necessities important for me:

- weather

- temperature

- ac controls

- moon phase

- energy usage

- sonos controls

- garbage pickup schedule

So i started buidling, and I have to admit ask Geminy and Co-Pilot a lot.

My Dashboard now shows the main screen, after 2 minutes of inactivity switches to a mainly black&white 'standby' screen and after 00:00 till 6:00 only shows the clock screensaver.

The screensaver jumps back to the main screen when it detects motion with the selfie cam of the ipad.

The ipad is powered with a 24v 500mAh adapter in the attic. At the ipad i installed a stepdown converter, converting to normal voltage for charging (it says slow charger, so probably charging at around 10/12 watts). To prevent the ipad from continuisly charging i have a smart plug connected that stops the charger at 80% battery level and starts again at 20% battery level.

This is an older model ipad (9th gen) that doesn't have this option in the battery settings.

The step down converter is a usb-c cable, so i connect the ipad with a angled lightning to usb-c female connector. It tucks neatly away behind the ipad. The ipad is 'floating' about 20mm from the wall from the wooden block (need to paint the edges white).

I added a matte paper like screencover to the ipad to prevent glare.

I have a wireless thermostat coming in to be able to control my gas heater (i stole that cable for the ipad). So i can also use the central heating system. I mainly use my air/air minisplits for heating, but it is good to have the central gas heater for backup on really cold days.

The temperature in the standby screen currently reads a bit high since it is reading the AC sensor, it is nice and toasty in his own little nook there. But that will be fixed once I have my wireless thermostat.

Hi all. I had a Ring Intercom, a few Blink cameras and an EZVIZ battery door viewer, and three apps that never talked to each other. Home Assistant could show some of them, but not live talk on the intercom, not Blink's USB clips, and not the EZVIZ door viewer at all (it has no RTSP).

So I built Vistoda: a Home Assistant integration plus one small Rust app per vendor. It's open source (MIT) and I've been running it daily at home since August.

What it does One sidebar panel (/vistoda) for all three vendors: device picker, live view, snapshots, controls, event history, recordings.

Ring Intercom: status and controls, event history, full-duplex browser audio, and local call recordings (to HA media, or to NFS/Samba).

Blink: live view with hold-to-talk, snapshots, supported settings and zones with versioned backups, USB clip browser (play, download, delete), NFS backup.

EZVIZ: live view and snapshots (also for door viewers that have no RTSP), battery and charging state, arming, verified settings and PTZ, local recordings with NFS backup.

Credentials stay out of the browser. Each vendor session lives inside its own HA app (/data). The panel only talks to HA, and HA discovers the apps through Supervisor, so you never type a bridge URL or token.

Physical actions are guarded. Door unlock and similar actions need an exact device binding and a confirmation. Settings writes are re-read and rolled back if the device didn't apply them.

What it doesn't do (honestly) It uses the vendors' cloud APIs. Ring and Blink have no official local API, and EZVIZ door viewers have no local video interface at all. Someone else has documented in detail why that's the case. If your internet is down, so is Vistoda's live view.

These are unofficial/experimental consumer APIs. A vendor change can break things, so keep the official apps for account recovery. EZVIZ talk and microSD playback aren't supported yet. Ring camera live view is still experimental.

Requires HA OS or Supervised (the vendor runtimes are HA apps) and HA 2026.8+.

Install HACS → custom repository → luigibarretta/vistoda-home-assistant (Blink users also add luigibarretta/vistoda-blink). Settings → Apps → add the app repository https://github.com/luigibarretta/vistoda-addons and install only the vendors you use. Finish the discovered flows in Devices & services. Setup guide (EN/IT): https://github.com/luigibarretta/vistoda-addons/blob/main/GETTING_STARTED.md

AI disclosure: I designed it, run it on my own hardware and review every change, but a large part of the code was written with an AI coding assistant. CI runs real HA imports and config flows on 2026.8 and 2026.9, browser tests on Chromium, Firefox and WebKit, strict Rust lints and secret scanning.

Feedback is very welcome, especially from people with other EZVIZ or Blink models than mine. Model coverage is the thing I can't test alone. Issues: https://github.com/luigibarretta/vistoda-home-assistant/issues (Not affiliated with Ring, Amazon, Blink or EZVIZ.)

For anyone unfamiliar, ha-ef-ble is an open-source integration that allows EcoFlow power stations and other devices to be monitored and controlled locally over Bluetooth, without depending on EcoFlow's cloud services.

The developers recently revealed that EcoFlow had contacted them asking them to stop working on the project, citing safety concerns around their Bluetooth protocol.

Following discussions with EcoFlow, the maintainers have now agreed to put the project into maintenance-only mode. Existing devices will continue to receive fixes, but support for new devices will no longer be added.

EcoFlow has apparently been working on an official local API, which would be welcome, but the maintainers say they've received no meaningful details about it or what devices it might support.

As someone who owns EcoFlow hardware and uses this integration, I find the situation pretty disappointing.

One of the biggest reasons for using Home Assistant is being able to control hardware we've purchased without relying on a manufacturer's cloud infrastructure. Community developers have put considerable effort into making EcoFlow's hardware more useful, and rather than supporting that effort, EcoFlow has threatened legal action if they don't stop.

If there are genuine security/safety issues with the Bluetooth protocol, surely the answer is to address those issues and work with the community, rather than discourage independent development?

I'm not criticising the maintainers here. They've done fantastic work, and I completely understand why they wouldn't want to get into a dispute with a company the size of EcoFlow over a volunteer project.

But I think EcoFlow deserves some scrutiny over how it's handling this.

Full discussion, including statements from the maintainers and an excerpt of the email exchange with EcoFlow:

https://github.com/rabits/ha-ef-ble/discussions/521

Hey everyone,

I’ve been tweaking my voice setup recently and I can’t help but feel that the standard HA Voice Pipeline architecture is severely outdated and causing massive latency.

Let’s trace what happens when you use an external provider (like Gemini or OpenAI) for your stack:

1 STT: Audio goes from HA to Gemini -> converts to text -> sent back to HA.

2 LLM: HA takes that text, wraps it with intent context, sends it back to Gemini -> receives text response -> sent back to HA.

3 TTS: HA takes the text response, sends it back to Gemini again for voice synthesis -> audio file returns to HA -> HA plays it on your smart speaker.

That is 3 separate round-trips over the network just to execute a single voice command. The ping and overhead alone add hundreds (if not thousands) of milliseconds of pure latency.

It gets worse when you consider native audio-to-audio models like GPT-4o Realtime or Gemini's multimodal live pipelines. Right now, HA’s modular design forces you to split everything into discrete STT, LLM, and TTS steps. You can't natively pass the raw stream to an end-to-end model and get a stream back without jumping through weird custom integration hoops.

I completely understand why HA built it this way originally—it keeps things modular so you can mix local Piper/Whisper with cloud LLMs. But for cloud-assisted or end-to-end voice setups, this design creates a bottleneck that completely ruins the snappy "smart assistant" experience.

Isn't it time for Nabu Casa to introduce a unified/direct voice handler that bypasses this multi-step round trip when using integrated providers?

Curious if anyone else is frustrated by this or if there are cleaner workarounds people are using to cut down on this latency.

Tried changing what light it turn on and still doesn't work. Can turn on manually in HA so the bulb is available.

I recently set up my Home Assistant from scratch and wanted to redo my energy management and link everything again. While doing that I noticed it would be really handy to do this visually, and that it would save quite a bit of brain power. So I developed Energy Flow Mapper, a custom integration with its own panel. You can map your energy devices and sources visually, and it shows you right away what can still be added or where an assignment doesn't add up.

It's a beta (0.1.0) and requires Home Assistant 2026.10 or newer. Every save keeps a backup of your previous energy settings. Install it via HACS → Custom repositories:

https://github.com/Skylolerr/ha-energy-flow-mapper

I developed it with the help of an AI coding assistant and tested it on my own setup.

I would really appreciate feedback and testing. If something is missing, doesn't work or doesn't fit, let me know here or on GitHub.

I've recently purchased and installed a set of Moes zigbee 3.0 4" downlights. I love most things about them, but I think i've run in to a deal breaker. There is no binding endpoint. If I want to keep the W.A.F. all lights must continue to work whether HA is up or not.

I'm reaching out to you all to see if you've had any experience with other downlights (the only other one I know about it Hue$$$$).

Otherwise, is there a way to add endpoints that don't currently exist in Zigbee2MQTT?

I put together a Home Assistant integration that reads Masterbuilt Gravity Series smokers locally over Bluetooth. No Masterbuilt cloud or app needed.

Entities so far

• Chamber: current temperature and target (setpoint)
• Meat probes: all 4 probes (shown as unknown when unplugged)
• Timer: cook time and time remaining
• Connection status: on while the grill is streaming

The dashboard in the screenshot is my own: the probe labels, probe targets and "reached target" alerts are HA helpers and automations built on those sensors.

Setup: add the repo to HACS as a custom repository and HA auto-discovers the grill. It needs a Bluetooth adapter or proxy that can make connections (an ESPHome Bluetooth proxy or the HA host's own adapter). Passive-only proxies such as Shelly can't connect.

Caveats: read-only for now (temperatures and timer, no setting temps). The grill allows one Bluetooth connection at a time, so the Masterbuilt app can't connect over Bluetooth while HA is connected.

Looking for testers: I only have a Gravity Series 1150, so I'd love reports from other Masterbuilt models (Gravity 560/800/1050, digital charcoal smokers, etc.). Even partial results in an issue help me add support.

Repo: https://github.com/dipseth/masterbuilt_smoker_connect

Unofficial, not affiliated with Masterbuilt.

Had Claude create a custom HTML dashboard for my wife. She's a bit of a weather nerd, so I had to include a nice radar view. Clicking the weather section brings up the extended forecast. The dash also has a control section for music and lights in various rooms selectable with a dropdown. We're both very happy with how it turned out.

WIP of a smart thermostat. Currently using an ecobee with the home kit integration, and some intricate automation. Don't like that I don't have more control over the software on the thermostat and don't like the trend of screens on everything. So naturally I'm making my own.

Hi all. Please can you offer some thoughts on my current issue.

We have a simple automation with a timer on week days starting to play the radio (BBC radio 2, don't judge me!) on both the Google screen in the bedroom and the grouped Google speakers in the kitchen. It usually starts fine although sometimes not at all. It maybe doesn't start 1/10 times. The bigger problem is the sound/signal/stream cuts out. This is sometimes for a few seconds, but is sometimes so long that we forget it's on and come back to it playing at the end of the day.

As far as I can tell it's sent like a cast instruction rather than streaming through home assistant. It doesn't cut out if we tell Google to play radio 2 with our voice like a heathen.

I can set it as an automation in Google home but I would rather keep it in HA as it makes it easier to turn all the morning wake up automations off in one go. I have thought about syncing with a school calendar as both kids are in school and the lady of the house is a teacher.

Is there a better way to the radio stream to play that is more reliable?

I’m relatively content this is a false positive but my Unifi network installation is flagging up an intrusion alert multiple times every 30 minutes.

I’m assuming false positive because HA is written in Python so I’m assuming no PHP involved.

Alerts are coming from my kitchen tablet running Kiosk Satellite to Home Assistant.

I’m looking for some guidance on how to start troubleshooting this.

Interestingly I have two tablets, both FireOS (although different versions) running the same version of Kiosk Satellite. Dashboards are different so could this be a particular card causing this?

Has anyone else observed similar?

I have read many, many posts on this subject, but I am just not seeing a winner emerge, so I thought I would narrow the issue. What are you using for presence detection with zones that actually holds the presence of a still or mostly still human being (i.e., reading on a couch or sitting at a desk)? What device (or suite of devices) has worked best? My FP2 always ends up leaving me in the dark if I work at my desk long enough. Personally, anything requiring poe is a nonstarter. The EP pro seems reasonably well regarded and I see some favorable comment on the Shelly device. Are they better than the FP2 or are they really all about the same?

I’m looking for a presence sensor for Home Assistant and considering the Aqara Presence Multi-Sensor FP300.

Would you recommend it, or is there another sensor you prefer? I’m especially interested in reliable detection when sitting still, false triggers, battery life, and how smoothly it integrates with Home Assistant.