DEV Community: Philipp Schweizer

Your SD Card Dies Silently – Monitor NVMe SSD Health in Home Assistant

Philipp Schweizer — Tue, 28 Jul 2026 15:24:21 +0000

A microSD card dies silently: it works - until suddenly it doesn't, usually without any warning. That's exactly why switching to an NVMe SSD on the Raspberry Pi 5 isn't just faster, but also safer. An NVMe drive reveals its health through SMART - wear, temperature, data written, errors. In this guide I'll show you how to pull those values straight into Home Assistant and get an automatic warning before your SSD gives out. And because there wasn't a simple solution for this yet, I built a small Home Assistant add-on that does exactly that - one click, and the sensors show up on their own.

In short: On your Raspberry Pi 5 running Home Assistant OS you install the free "NVMe SMART Monitor" add-on from the raspberry.tips repository. It reads your NVMe SSD's SMART values (wear, temperature, data written, spare, errors) and adds them automatically as sensors in Home Assistant via MQTT discovery. A single automation then warns you before the SSD fails.

What is SMART on an NVMe SSD?

SMART (Self-Monitoring, Analysis and Reporting Technology) is a self-monitoring system built into modern SSDs. Over the NVMe protocol the drive reports metrics such as wear (percentage_used), the data already written (TBW), the available spare, the temperature and error counters. Unlike a microSD card, which offers practically no readable health data, on an NVMe you can see the wear coming and react in time.

The key points

SD cards fail without warning, NVMe SSDs don't: via SMART you see wear, spare and TBW - and can swap in time.
Our Home Assistant add-on reads the SMART values and creates the sensors automatically via MQTT discovery - no YAML fiddling.
You get a device with ~10 sensors (wear, temperature, TBW, spare, errors ...) plus a problem sensor for automations.
Requirements: Home Assistant OS with an NVMe SSD and the Mosquitto broker add-on.

Requirements

Home Assistant OS (HAOS) on a Raspberry Pi 5 with an NVMe SSD (the common case). Our guide Set up the Raspberry Pi 5 without an SD card shows how to get HAOS onto the NVMe. The add-on also runs on x86 HA servers with an NVMe.
The official "Mosquitto broker" add-on - the sensor data travels over it (MQTT).

💡 No NVMe on your Pi yet?

Then the switch from the SD card pays off twice - more speed and the health monitoring shown here. Which NVMe SSD and which M.2 HAT suit your Pi 5 is covered in our buying guide. And how to flash HAOS onto the NVMe without any SD card at all is laid out step by step in our tutorial.

Step 1: Install the MQTT broker

The add-on reports the SMART values to Home Assistant over MQTT, so you need an MQTT broker. In Home Assistant go to Settings → Add-ons (the add-on store), search for "Mosquitto broker", install it and start it. Home Assistant then sets up the MQTT integration automatically.

Install and start the official Mosquitto broker add-on.

Step 2: Add the raspberry.tips repository

Now we add the add-on repository. In Settings → Add-ons click the ⋮ → Repositories menu in the top right and enter this URL:

https://github.com/raspberry-tips/ha-addon-nvme-smart

Add the raspberry.tips repository by URL.

After adding it, a new section "raspberry.tips Home Assistant Add-ons" with the NVMe SMART Monitor appears in the store.

The "NVMe SMART Monitor" shows up in the raspberry.tips section of the store.

Step 3: Install and start the add-on

Open the NVMe SMART Monitor and click Install. The container is built locally (takes 2-4 minutes).

Install the add-on - the container is built locally (2-4 min).

Then start the add-on. I recommend enabling "Start on boot" and "Watchdog" so the monitoring always runs. The default options (device /dev/nvme0, interval 300 s, warning thresholds) work for most people - you'll find them on the Configuration tab.

Start the add-on - I recommend enabling "Start on boot" and "Watchdog".

To check that everything runs, look at the Log tab: you should see lines like MQTT broker found, Device detected: ... and State published: ....

In the log: broker found, device detected, values published.

💡 How it works behind the scenes: The add-on reads your SSD's health values via nvme smart-log, converts them (e.g. temperature to °C, TBW to GB) and publishes them through MQTT discovery. Home Assistant detects the sensors automatically - you don't have to configure anything by hand.

The sensors in Home Assistant

A few seconds after starting, a new device appears under Settings → Devices & Services in the MQTT integration - named after your SSD model (an Intenso in my case). Click it and you'll see all the health sensors at a glance.

The "NVMe SSD" device with all its health sensors - created automatically.

These are the most important values and how to read them:

Sensor	Meaning / warning sign
NVMe wear (`percentage_used`)	The lifespan bar. 0% = as new, 100% = calculated end of life. Rises slowly over years.
NVMe spare (`available_spare`)	Spare blocks. If it drops toward the threshold (often 10%), a swap is due.
NVMe data written (TBW)	Total data written - comparable to the manufacturer's endurance (TBW rating).
NVMe temperature	Operating temperature. If it stays above 70 °C, add cooling.
NVMe media errors	Should always be 0. If it rises, that's a serious warning sign.
NVMe problem	Binary sensor: "on" as soon as a critical state occurs or a warning threshold is crossed - ideal for automations.

🌡️ NVMe too hot? A low-profile heatsink helps

If the temperature sensor stays high (rule of thumb: above 70 °C), a small M.2 heatsink is worth it. Important inside a Pi 5 case: keep it as flat as possible, otherwise the lid won't close - measure the free height above the SSD first.

TBW: how long will my SSD last?

The "NVMe data written" sensor shows the amount of data written so far. Compare it with your SSD's TBW rating (Terabytes Written, listed in the datasheet). My Intenso Premium 250 GB, for example, is rated at 150 TBW - and after several weeks of continuous HAOS operation just 56 GB written and 0% wear showed on the clock. Extrapolated, an SSD like that lasts, at 20 GB of writes per day, a calculated 20+ years. Together with the wear percentage you get two independent views of the remaining life - something an SD card simply can't give you.

Step 4: Dashboard with a wear gauge

Now let's make the values visible. Open your dashboard, go to Edit → Add card → Manual and paste this card. The add-on assigns fixed entity IDs (e.g. sensor.nvme_percentage_used), so the YAML works by copy-paste - if you see different IDs, you'll find them on the device page:

type: grid
columns: 2
cards:
  - type: gauge
    entity: sensor.nvme_percentage_used
    name: Wear
    min: 0
    max: 100
    needle: true
    severity: {green: 0, yellow: 70, red: 90}
  - type: gauge
    entity: sensor.nvme_temperature
    name: Temperature
    min: 20
    max: 80
    needle: true
    severity: {green: 0, yellow: 60, red: 70}
  - type: gauge
    entity: sensor.nvme_available_spare
    name: Spare
    min: 0
    max: 100
  - type: entity
    entity: sensor.nvme_data_written
    name: Written (TBW)

Dashboard with a wear gauge and all the NVMe sensors.

Step 5: Automatic alert

Here's the real payoff: get notified automatically the moment something is wrong. For that we use the problem sensor. Go to Settings → Automations & Scenes → Create automation → Edit in YAML and paste:

alias: NVMe SSD warning
triggers:
  - trigger: state
    entity_id: binary_sensor.nvme_problem
    to: "on"
actions:
  - action: notify.notify
    data:
      title: "⚠️ NVMe SSD warning"
      message: >-
        The NVMe reports a problem - wear {{ states('sensor.nvme_percentage_used') }} %,
        temp {{ states('sensor.nvme_temperature') }} °C, spare {{ states('sensor.nvme_available_spare') }} %.
mode: single

Create a new automation from scratch - the alert uses the problem sensor.

From now on you get a push message on your phone as soon as your SSD turns critical - long before data loss is a risk.

Limits & honest notes

SMART is not a crystal ball: it mostly sees gradual wear coming (spare, TBW, percentage_used). Sudden total electronic failures can't always be predicted, even by SMART - a backup stays mandatory.
Cheap DRAM-less SSDs sometimes don't report every field cleanly (e.g. power_on_hours stays at 0). That's normal and not a defect.
microSD cards on consumer models offer practically no readable SMART - which is exactly why the NVMe is so superior here.

Conclusion

With a few clicks you now monitor the health of the SSD your smart home runs on - and get warned before it turns critical. The add-on is open source on GitHub and works with any NVMe SSD. If you're coming from an SD card, you now have a safety net that simply didn't exist before. For matching hardware tips, see our NVMe buying guide.

Frequently asked questions about NVMe monitoring in Home Assistant

Can you monitor an SSD's health in Home Assistant?

Yes. Through the NVMe SSD's SMART values you can read out wear, temperature, data written and errors. With the raspberry.tips "NVMe SMART Monitor" add-on these values appear automatically as sensors in Home Assistant via MQTT discovery.

Does this work with an SD card too?

Usually not. Consumer microSD cards offer no readable SMART monitoring - they mostly fail without warning. That's a major advantage of an NVMe SSD on the Raspberry Pi 5.

Does the add-on work with any NVMe SSD?

Yes. The add-on reads the model and the SMART values live from the drive - it isn't tied to a specific brand. Cheap DRAM-less SSDs, however, occasionally don't report individual fields.

Do I need an MQTT broker?

Yes, the add-on publishes the values over MQTT. Just install and start the official "Mosquitto broker" add-on; the NVMe SMART Monitor then picks up the credentials automatically.

This article was originally published on raspberry.tips.

Connect Home Assistant to AI: Set Up an MCP Server for Claude, ChatGPT & Gemini

Philipp Schweizer — Sun, 05 Jul 2026 15:36:58 +0000

What is the Home Assistant MCP server?

The MCP server (Model Context Protocol) is an interface that lets AIs like Claude, ChatGPT, or Gemini talk directly to your Home Assistant. Instead of writing YAML yourself, you give the AI access to entities, automations, and dashboards - it handles the code. Runs as a free app/add-on on Home Assistant OS, community project (homeassistant-ai/ha-mcp).

Inhaltsverzeichnis

What you need
Official vs. unofficial MCP server
Step 1: Install the MCP server as an app/add-on
Step 2: Set up remote access
Step 3: Connect the MCP server to your AI
Best-practice guidance for the AI
Security: MCP access alongside a hardened Cloudflare setup
Optional and potentially dangerous: letting the AI edit YAML configuration
What you can actually build with this
Troubleshooting

Home Assistant can do almost anything - which is exactly why so many beginners struggle to build their own automations, design dashboards, or debug errors. Until now, you were entirely on your own: learning YAML, understanding templates, digging through forums. Anyone who wants to set up a Home Assistant MCP server instead hands that work off to an AI.

An MCP server changes that fundamentally. You connect Home Assistant directly to an AI of your choice - Claude, ChatGPT, or Gemini - and simply describe in plain language what you need: "Build me a sensor that shows today's rainfall" or "Fix the automation in the kids' room, the lights aren't dimming correctly anymore." The AI finds the right entities itself, writes the code, and sets it up in Home Assistant.

In this article I'll show you how to set up the MCP server on your Raspberry Pi, connect it to Claude, ChatGPT, and Gemini - including desktop and smartphone access - and how to secure the whole thing properly, even if your Home Assistant already runs behind Cloudflare Access with a client certificate.

What you need

Home Assistant OS or Supervised on a Raspberry Pi (apps/add-ons require the Supervisor - installation doesn't work on Home Assistant Container/Core)
Access to the App Store (Settings → Apps - since Home Assistant 2026.2 the former "Add-ons" are called this; on older versions it's still Settings → Add-ons → Add-on Store)
For access from cloud AIs (Claude, ChatGPT): a way out to the internet - Nabu Casa, an existing reverse proxy, or your own Cloudflare Tunnel
At least one account with Claude, ChatGPT, or Google Gemini

If you haven't set up remote access yet, I cover that step by step in my article Set Up Cloudflare Tunnel on the Raspberry Pi - no port forwarding needed, including mTLS hardening.

Official vs. unofficial MCP server

Home Assistant has shipped its own official MCP server since version 2025.2. It's quick to set up, but can do far less than the community solution ha-mcp, which this article is about. Before you install anything, you should know the difference:

Feature	Official MCP server	Unofficial (ha-mcp)
Entity access	Only Assist-exposed entities	Every entity in the system
Create/edit automations, scripts, scenes	No	Yes
Build/edit dashboards	No	Yes
Debug automations from traces, read history/logs	No	Yes
Manage helpers, areas, zones, labels, groups	No	Yes
Backups, apps/add-ons, HACS, device/entity registry	No	Yes
Setup effort	Low	Medium

Just want to use your AI as a somewhat better voice assistant ("turn on the living room light")? The official server is enough. But if you want an AI to build automations, dashboards, or sensors for you, there's no way around the unofficial solution - only that one gives you full access.

Step 1: Install the MCP server as an app/add-on

The project is called "Home Assistant MCP Server" (repository homeassistant-ai/ha-mcp, officially "The Unofficial and Awesome Home Assistant MCP Server"):

Go to Settings → Apps → App Store (or Add-ons → Add-on Store on older HA versions)
Via the three dots in the top right → Repositories, add the URL https://github.com/homeassistant-ai/ha-mcp
Reload the page, install "Home Assistant MCP Server", and start it

Then open the app's Logs tab. It shows your ready-to-use MCP server URL, already secured with a 128-bit random path, for example:

🔐 MCP Server URL: http://<ha-ip>:9583/private_zctpwlX7ZkIAr7oqdfLPxw

You'll need this URL for step 3. You don't need to create a token or password yourself - the app authenticates automatically via the Home Assistant Supervisor, and the random path in the URL is the actual security measure.

In the app's settings (config tab, or its own Tool Settings web UI via "Open Web UI"), I recommend:

Tool Search (enable_tool_search): Disabled by default - leave it that way. For Claude in Sonnet or Opus mode, definitely leave it disabled, because its built-in tool search otherwise conflicts with ha-mcp's. Only worth enabling for Claude Haiku or other models without their own tool search, or if your client caps the number of tools (e.g. at 100).
Tool Security Policies (enable_tool_security_policies): Optionally enable this if you want manual approval via the app's web UI for critical actions (locks, alarm systems, writing automations).
Read Only Mode (read_only_mode): Handy for the first test run or shared installations - switches off every write-capable tool completely.
Backup Hint (backup_hint): Leave it at normal - the AI will then automatically suggest a backup before irreversible changes.
You can disable or pin individual tools in the web UI if you don't need them or consider them too dangerous.

Part 1 is done - on your home network you can already talk to the app directly via the local URL (e.g. with VS Code, Cursor, or other HTTP-capable MCP clients).

Step 2: Set up remote access

For cloud AIs like Claude or ChatGPT to reach your MCP server, you need a publicly reachable, HTTPS-secured URL. There are two ways to get there:

Option A: Webhook Proxy app (easiest if you already use Nabu Casa or a reverse proxy)

The "Webhook Proxy for HA MCP" app (same repository) routes MCP traffic through your existing Home Assistant access - Nabu Casa, Cloudflare Tunnel, DuckDNS, or any other reverse proxy that already points at port 8123. You don't need an additional hostname or a second tunnel for this:

The MCP Server app from step 1 must already be running
Install and start "Webhook Proxy for HA MCP" from the same App Store

If you don't use Nabu Casa (e.g. with your own Cloudflare Tunnel), your public Home Assistant URL needs to be entered explicitly in the Webhook Proxy app's settings - with Nabu Casa, the app detects this automatically

Restart Home Assistant (do a full restart in the settings, top right)
Copy the finished remote URL from the Webhook Proxy app's Logs tab, e.g.:

MCP Server URL (remote): https://<your-external-url>/api/webhook/mcp_7eacf143b0f5d31269417ae3304ee534

The app finds your MCP Server app automatically. If you use Nabu Casa, your external URL is also detected automatically; without Nabu Casa, you enter it manually as shown in step 3. Either way, the webhook path (/api/webhook/mcp_...) stays stable across restarts, because the ID is stored locally.

Option B: Your own Cloudflared tunnel (if you don't have remote access yet)

Alternatively, use a dedicated tunnel just for the MCP server, as described in our Cloudflare Tunnel article (Part A). In the Cloudflared app configuration:

additional_hosts:
  - hostname: ha-mcp.yourdomain.com
    service: http://localhost:9583

If localhost doesn't work from inside the Cloudflared container (its own Docker container), use the MCP Server app's container hostname instead, which you'll find on its Info page (e.g. b37de126-ha-mcp).

⚠️ Important Cloudflare trap: Cloudflare's "Block AI Training Bots" feature blocks AI clients by default - even when browser access to the same URL works fine. Under Security → Bots, set the "Block AI training bots" option to "do not block", or you won't be able to connect with any AI at all.

Did you set up the country restriction (DE/AT/CH) from the Cloudflare Tunnel article? That same rule blocks Claude and ChatGPT too - both connect from the US. Either add Anthropic's stable IP range 160.79.104.0/21 as an exception to the rule, or scope the country rule to your main hostname only and leave the MCP hostname untouched.

Step 3: Connect the MCP server to your AI

Now for the actual connection. How easy this is - and how far you'll get - differs quite a bit between Claude, ChatGPT, and Gemini:

AI	Minimum plan	Setup location	Desktop/Mobile
Claude	Free (1 connector), otherwise Pro/Max	claude.ai (web), Custom Connector	Syncs automatically to the desktop app and iOS/Android
ChatGPT	Plus	Settings → Connectors → Developer Mode	Manual, no known auto-sync
Gemini	Free (CLI)	Gemini CLI only, settings.json	No path via the regular Gemini app

Connecting Claude Desktop

Route 1 - Web Connector (recommended, web + desktop + smartphone in one step):

Log in at claude.ai, go to Customize → Connectors (Customize - Claude)
Add a custom connector using the plus icon (+), and name it, e.g., "Home Assistant"

Enter your remote URL from step 2 and save
For read-only tools you can set "always allow"; for write/delete tools I'd leave confirmation prompts on

The convenient part: once the connector is set up on claude.ai, it's automatically available in the Claude Desktop app and the Claude apps for iOS and Android too - no extra configuration needed.

Watch out: if you've set up block rules in Cloudflare (I've blocked a lot of countries, for example), you naturally need to allow Claude's IP addresses. I've put a skip rule for Claude at position 1, which causes all other block rules to be skipped:

((ip.src in {160.79.104.0/21}) or (ip.src in {2607:6bc0::/48})) and http.host eq "homeassistant.your-domain.com"

That's it: once the MCP connection via the Claude connector is up, you can interact with your Home Assistant through Claude from anywhere in the world:

Route 2 - Claude Desktop only, purely local (no remote access needed): Claude Desktop only talks to local MCP servers over stdio, not via a URL. Using the small helper program mcp-proxy (via uvx, which only needs the uv tool), you build the bridge yourself.

uv/uvx needs to be installed on the machine running Claude Desktop. Do that in a terminal with:

winget install --id=astral-sh.uv -e

Your Claude Desktop config needs to be extended with the following. Depending on what's already in your config, the JSON needs to be merged in accordingly - feel free to ask your AI assistant for help if you're unsure. As the streamablehttp target, enter the URL from step 1. Important: Claude should be fully quit first (also close its icon in the system tray):

{
  "mcpServers": {
    "home-assistant": {
      "command": "uvx",
      "args": ["mcp-proxy", "--transport", "streamablehttp", "http://homeassistant.local:9583/private_Odhrwersdgh234"]
    }
  }
}

This goes into claude_desktop_config.json. Advantage: works entirely on your home network, no remote access from step 2 needed - but only on that one computer, without mobile sync. You'll find the file under "%APPDATA%\Claude" (Windows). Claude Desktop needs to be fully restarted once.

Then the connection is ready to go in Claude Desktop too:

Connecting Claude Code to Home Assistant

For Claude Code, one command within a session is enough. Insert the URL from step 1:

claude mcp add-json home-assistant '{
  "url": "your-mcp-server-url",
  "type": "http"
}'

Claude Code needs to be restarted once.

Connecting ChatGPT

In ChatGPT, go to Settings → Connectors → Advanced and enable Developer Mode (available from the Plus plan)
Under Connectors, click Create and enter your remote URL from step 2
ChatGPT then walks you through an OAuth authorization flow

The difference to Claude: ChatGPT requires a genuine OAuth 2.1 flow for authorization - it doesn't accept simple bearer tokens or API keys for connectors. That makes setup a bit more involved, but it's also the more robust security model overall.

Connecting Gemini (CLI only)

Here's the honest limitation: there's currently no way to connect an MCP server through the regular Gemini app or web interface. It only works via the Gemini CLI, a command-line tool for developers:

{
  "mcpServers": {
    "home-assistant": {
      "url": "your-mcp-server-url"
    }
  }
}

This configuration goes into the Gemini CLI's settings.json. You don't need to add a bearer token separately here - the random path in the URL itself is the authentication. For the mass market, this is currently the least practical of the three routes - but if you already work with the CLI, you get the same full tool access.

Best-practice guidance for the AI

Earlier versions of ha-mcp required a separate download of an "Agent Skills" package that you had to upload manually as a ZIP into Claude. Current versions ship this best-practice guidance directly through a built-in, always-active tool called ha_get_skill_guide - the AI calls it itself whenever needed to learn how to correctly set up helpers, utility meters, or template sensors, for example. A manual skills import is generally no longer necessary; still, check the project's current documentation if your client shows different instructions.

Security: MCP access alongside a hardened Cloudflare setup

Many of you already protect Home Assistant with Cloudflare Access and a client certificate (mTLS) - rightly so, it's one of the most secure ways to make a smart home reachable on the internet. There's a catch here, though, that none of the existing guides on this topic address:

Cloud AI connectors cannot present client certificates. Both Claude and ChatGPT call your server not from your device, but from the provider's own cloud infrastructure. A client certificate is tied to a private key that only your device holds - the AI providers logically can't send it along. OpenAI confirms this for ChatGPT explicitly in its own documentation: custom connectors can present neither their own API keys nor customer-provided mTLS certificates.

The simple fix if you use the Webhook Proxy app (Option A)

If you use the Webhook Proxy app from step 2 (Option A) for remote access, MCP traffic runs over /api/webhook/... on the same hostname as your Home Assistant interface - so you don't need a second hostname at all. Instead, it's enough to exempt this one path from the mTLS requirement. If you copied the WAF rule from our Cloudflare Tunnel article, just extend it with this exception:

(http.host eq "homeassistant.your-domain.com" and not cf.tls_client_auth.cert_verified and not starts_with(http.request.uri.path, "/api/webhook/"))

The /api/webhook/ path itself stays secure regardless, because the webhook carries its own random ID in the path - that ID is the authentication for this one endpoint, with no certificate needed. Your Home Assistant interface stays fully mTLS-protected, while the AI still gets in through the same hostname. No second hostname, no extra IP allowlisting required.

Alternative if you use a dedicated MCP hostname (Option B)

If you instead run a separate Cloudflared tunnel just for the MCP server (step 2, Option B) with its own hostname like ha-mcp.yourdomain.com, there's no shared hostname you could relieve via a path exception. Here, the separate security layers still make sense - the random path in the URL (see step 1) is the first line of defense, and you can additionally restrict via a Cloudflare firewall rule to Anthropic's stable outbound IP range, as shown in the "Connecting Claude Desktop" section above. IP allowlisting is less worthwhile for ChatGPT, since OpenAI changes its egress ranges more frequently - but ChatGPT requires that mandatory OAuth 2.1 flow mentioned earlier anyway, which inherently offers stronger security than a plain URL with a secret.

Outlook: official tunnel solutions with no public exposure at all

Both Anthropic ("MCP Tunnels", currently a research preview with a waitlist) and OpenAI ("Secure MCP Tunnel", an open tunnel-client on GitHub) are working on a mechanism where a small agent at your home establishes an outbound connection to the AI cloud - your MCP server would then no longer need any public port at all. For security-conscious users, that's the cleanest solution in the medium term, though it's currently either still gated (Claude) or geared more toward business use (OpenAI).

Optional and potentially dangerous: letting the AI edit YAML configuration

This step is completely optional. Some Home Assistant features - REST template sensors, for instance - can only be set up via configuration.yaml, not through the UI. The tools for this (ha_config_set_yaml, file read/write access) are marked as beta features and require an additional companion component. Enable it via the "Advanced settings" of the Tool Settings web UI (a beta master toggle plus individual sub-toggles) - check the project's current documentation for details, since these beta features can still change.

Before you enable this: make a backup. Then make another one. An AI that edits your configuration.yaml and accidentally discards half its content can take down your entire system. Only enable this feature if you understand what you're granting access to, and if you already run regular backups anyway.

What you can actually build with this

New sensors: "Create a sensor that shows today's rainfall from my weather station" - the AI finds the right source entity, sets up a utility meter helper, and configures it correctly.
Dashboard elements: new badges, cards, or entire dashboard sections on request, without writing a single line of card YAML yourself.
Fixing/adjusting automations: "The automation in the kids' room stops dimming correctly after 9pm" - the AI finds the right automation, analyzes traces, explains the proposed fix, and applies it once you confirm. If you'd rather understand the basics of triggers, conditions, and actions yourself first, our Home Assistant automations beginner's guide covers that.

Keep in mind: the AI can also suggest broken or nonsensical code. Especially for automations with real-world consequences (heating, safety functions), review the suggested code before letting it run permanently.

Troubleshooting

Problem	Solution
AI client can't connect via Cloudflare, but browser access works fine	Check this first, before you lose yourself in WAF rules: it's almost always "Block AI Training Bots" in Cloudflare (Security → Bots). Set it to "do not block". Also check whether a country WAF rule is blocking US traffic.
"Apps" or "Add-ons" missing from the menu	Only available with Home Assistant OS (not on Core/Container without the Supervisor). Since 2026.2 the menu item is called "Apps" instead of "Add-ons".
Tool is known, but the call fails with "Unknown tool"	After changing tool settings (Tool Search, Read Only Mode, enabled/disabled tools), your AI client keeps caching the old tool list. Restarting the app/Home Assistant isn't enough - disconnect and reconnect the connector in the client (e.g. re-add the connector in ChatGPT, fully close and reopen Claude Desktop).
Connector can't find the MCP server	With the Webhook Proxy app: did you restart Home Assistant after installing it? Without a restart, the connection stays inactive.
Can't create the ChatGPT connector	Check whether Developer Mode is enabled and your plan (Plus or higher) supports it.
MCP connection over the mTLS hostname fails	Expected behavior with client certificate enforcement. Use the Webhook Proxy app with the `/api/webhook/` exception in the WAF rule (see the security section) or a separate hostname without mTLS.

Do I need HACS for the Home Assistant MCP server?

No, you install the base app/add-on directly through the App Store via the repository URL (github.com/homeassistant-ai/ha-mcp). An additional companion component is only needed if you want to use the optional, beta-labeled YAML/file-access tools.

Does the MCP server also work entirely locally, without a cloud AI?

Yes. With a local AI like Ollama or LM Studio, or with Claude Desktop via the local stdio bridge (mcp-proxy), all processing stays on your own network - with no remote access from step 2 needed at all.

Is it safe to give an AI full access to Home Assistant?

With some precautions, yes. Disable dangerous individual tools via the Tool Settings web UI, use Read Only Mode or Tool Security Policies for approvals where needed, and never share your MCP server URL with anyone - the random path inside it acts like a password.

Which AI works best for Home Assistant MCP?

Claude currently offers the simplest setup, since a connector configured once syncs automatically to the desktop and smartphone apps. ChatGPT works well too, but requires a manual OAuth flow and at least the Plus plan. Gemini is currently only usable via the CLI.

Dieser Artikel erschien zuerst auf raspberry.tips.

[Beta Testers Wanted] Help me launch this Raspberry Pi IP Scanner for Android

Philipp Schweizer — Tue, 28 Apr 2026 14:43:24 +0000

🚀 Beta Testers Wanted: Raspberry Pi IP Scanner for Android

Hi everyone! I’m currently in the final stages of launching a dedicated Raspberry Pi IP Scanner App for Android. To officially release it on the Google Play Store, I need to complete a closed beta with at least 20 testers for 14 days.

If you have an Android device and use Raspberry Pis, I would love your help!

👉 Join the Beta here: https://play.google.com/apps/testing/tips.raspberry.rpi_app

Why this app?

Anyone running a Raspberry Pi in their home network knows the problem: What is the Pi's IP address right now? The DHCP server assigns a different one at every restart, and searching the router interface is tedious.

That's exactly why I built this app - a tool specifically developed for the Pi ecosystem.

Key Features

IP Scanner: Scans your network and automatically identifies Raspberry Pis using MAC address prefixes and mDNS.
One-Tap Access: Open your Pi's web interface or start an SSH session (integrates with Termius/JuiceSSH) directly from the scan results.
Built-in Tools: Includes the GPIO Pinout, WPA Supplicant Generator, and Electronics Calculators from raspberry.tips.

How you can help

Join the beta via the link above.
Install the app and run a quick scan.
(Optional) Let me know if it correctly identified your Pi models!

The source code is open source: github.com/raspberry-tips/rpi-app

Thanks for helping me get this tool into the hands of the community!

Original article and more details: raspberry.tips

Dieser Artikel erschien zuerst auf raspberry.tips.

Raspberry Pi IP Scanner App – Find Your Pi on the Network Instantly

Philipp Schweizer — Sat, 25 Apr 2026 14:03:45 +0000

Anyone running a Raspberry Pi in their home network knows the problem: What is the Pi's IP address right now? DHCP assigns a new one after every restart, and digging through the router interface gets old fast.

That's exactly why we built the raspberry.tips App for Android — an IP scanner built specifically for Raspberry Pi, combined with all the tools from the website, right on your phone.

What the App Does

The app has three main sections:

IP Scanner — scans your local Wi-Fi and automatically detects all Raspberry Pis
My Devices — saved devices at a glance, with one-tap browser and SSH access
Tools — all raspberry.tips web tools (GPIO Pinout, WPA Supplicant Generator, Electronics Calculator, and more) directly in the app

How the IP Scanner Works

The scanner combines multiple techniques to reliably find Pis even in busy networks:

mDNS Discovery — detects devices via Bonjour/Avahi instantly; if your Pi is reachable as raspberrypi.local or pi.local, it shows up within seconds
MAC Address Recognition — the app knows all Raspberry Pi Foundation and Raspberry Pi Trading Ltd MAC prefixes and automatically marks matching devices as confirmed Pis
Port Scan — all 254 hosts in the subnet are scanned in parallel for SSH (22), HTTP (80, 8080), and HTTPS (443)
Reverse DNS — hostnames are resolved via PTR lookup so you see what your Pi calls itself

Results are split into three categories:

Category	Description
Raspberry Pis	Confirmed via MAC address or hostname
Possible Pis	Characteristics match (e.g. SSH open, MAC unresolved)
Other Devices	All other network participants with open ports

From the results, you can open the device in the browser or launch an SSH session directly. For SSH, the app hands off to a compatible app like Termius or JuiceSSH.

Save and Manage Devices

Found Pis can be saved with a tap on the bookmark icon. In the My Devices tab you'll see IP address, hostname, and last scan date — and you can rename devices, so 192.168.1.42 becomes Media Center Pi or Pi-hole.

Integrated Tools

The Tools tab puts all raspberry.tips web tools in one place without opening a browser:

GPIO Pinout – pin assignments for all Raspberry Pi models
WPA Supplicant Generator – create Wi-Fi configs for headless setup
Docker Compose Generator – build Docker Compose configurations
Electronics Calculator – LED resistors, voltage dividers, color codes
SD Card Calculator – estimate SD card lifespan
Power Supply Calculator – determine wattage requirements
Subnet Calculator – calculate IP addresses and networks

Download

The app is currently available as a direct APK download. You'll need to allow installation from unknown sources once in your Android settings (Apps > Unknown Sources or Security > Install unknown apps).

➡️ Download APK

A Google Play Store release is coming soon.

Note: The Raspberry Pi must be on the same Wi-Fi network as your Android device for the scanner to work. An iOS version is not yet available but is planned.

The source code is open on GitHub: github.com/raspberry-tips/rpi-app

Feedback, bug reports, and feature requests are welcome in the comments!