How to Control Loxone from Home Assistant Using Its Built-In HTTP API
If you’ve spent any time in the Home Assistant community forums searching for “Loxone integration,” you’ve probably come across a graveyard of half-finished custom components, outdated HACS add-ons, and threads that trail off without a real answer. It’s frustrating — because Loxone is excellent hardware with a capable local API, and Home Assistant is the most flexible automation platform out there. They should work together cleanly.
Here’s the thing nobody seems to say plainly: they already do. You don’t need a custom integration, a third-party plugin, or the Loxone Link to get Home Assistant calling Loxone. Loxone has a built-in HTTP API. Home Assistant has a built-in rest_command integration. Point one at the other, add basic authentication, and you’re done.
I’m running this exact setup in my showroom in Cherry Hill — Home Assistant orchestrating automations that trigger Loxone lighting moods, scenes, and virtual inputs, all locally, no cloud in the loop. This post walks through exactly how it works, including the part that trips most people up: finding the right UUID for your Loxone inputs.
Before I get into it: here are two resources worth calling out that helped me get here The LoxWiki Home Assistant integration guide by Krzysztof Kajkowski laid out the general approach clearly, and a Home Assistant Community thread by gigatexel on sending data from HA to Loxone was useful for thinking through the Virtual Input pattern. Both are worth bookmarking.
I also want to acknowledge that PyLoxone exists — it’s a HACS custom component that provides a richer, bidirectional Loxone integration with entity discovery and a proper HA integration framework. If you’re a capable DIYer running your own Home Assistant instance, it’s worth evaluating.
That said, I don’t use PyLoxone for client installations, and the reason is straightforward: chain of responsibility. When I build a system for a client, I own the outcome. HACS components are community-maintained — PyLoxone is well-built and actively developed, but I can’t guarantee it’ll continue to work through every Home Assistant update, every Loxone firmware revision, or every breaking change in either platform’s API. The rest_command approach I’m describing here uses a native HA integration against a documented Loxone API. It has far fewer moving parts, which means far fewer things that can break at 2am when a client’s automation stops working. For professional installations, simple and auditable beats feature-rich and opaque.
Why Loxone’s HTTP API Is the Simplest Integration Path for Home Assistant
Loxone’s Miniserver exposes a local REST API that requires nothing more than an HTTP GET request with basic authentication. No tokens, no OAuth dance, no websocket handshake. Note that If your Home Assistant instance can reach your Loxone Miniserver on the local network — and it can, because they’re both on your LAN — you can control Loxone from HA with a few lines of YAML.
One caveat to this: Loxone’s own documentation flags HTTP Basic Authentication as intended for debugging, testing, and locked-down local networks — and that’s exactly the context we’re using it in here. For a production client installation, I use token-based authentication, which is Loxone’s recommended approach and meaningfully more secure. That’s a later post. This one is about getting the proof of concept working cleanly on a local network, and Basic Auth is fine for that purpose.
The URL structure follows a predictable pattern:
http://{loxone-ip}/jdev/sps/io/{UUID}/{command}
Where {UUID} is the unique identifier for a specific virtual input or output in your Loxone config, and {command} is what you want to do to it. The two commands you’ll use most are pulse (for momentary triggers) and on or off (for stateful switches).
For example, to trigger a lighting mood via a virtual input I’ve called “Night Lights” in my Loxone config:
curl -u loxone-user:loxone-password http://{showroom-loxone-ip}/jdev/sps/io/207da04a-02a2-f404-ffff4ebbfd8d0b74/pulse
That’s it. A single GET request, authenticated with basic auth, and Loxone executes whatever logic is wired to that virtual input. Home Assistant can send that request on a schedule, in response to a sensor state, as part of a multi-step automation, or from a webhook triggered by a wall-mounted kiosk. The flexibility lives in Home Assistant; the reliability lives in Loxone.
This is also a genuinely private architecture. Nothing goes to the cloud. Your automation data doesn’t pass through Loxone’s servers or Amazon’s or Google’s. It’s a local HTTP call between two devices sitting on your home network. That matters more than most people realize — and it’s a baseline expectation for every system I install.
How to Find Loxone Virtual Input UUIDs Without Guessing
This is the step where most tutorials wave their hands and say “find the UUID in Loxone Config.” That’s technically accurate but not particularly helpful, especially if you’re newer to Loxone and the graphical interface feels like a circuit diagram that you need to carefully trace through.
Here’s the method I use, and it’s much faster.
Your .Loxone project file is just XML. Open it in any text editor — Sublime Text, VS Code, or Notepad++. The file is typically named after your project and lives wherever you saved it from Loxone Config.
Once it’s open, hit Ctrl+F (or Cmd+F on Mac) and search for the friendly name you gave the input in Loxone Config. If you named your virtual input “Party Door Trigger,” search for exactly that. You’ll land directly on the XML element for that input.
Here’s what that element looks like:
<C Type="VirtualIn" IName="VI4" V="175"
U="207df13e-02eb-874a-ffff4ebbfd8d0b74"
Title="Party Door Trigger">
<Co K="Q" U="207df13e-02eb-8748-00ffa5ec5f9bd939"/>
<Co K="Qm" U="207df13e-02eb-8749-01ffa5ec5f9bd939"/>
</C>
The UUID you want is the U attribute on the parent <C> element — the one with Type="VirtualIn" and your input’s Title. In this case: 207df13e-02eb-874a-ffff4ebbfd8d0b74.
Do not use the U values from the child <Co> elements. Those are connector UUIDs for the input’s output ports within Loxone’s internal logic — they won’t work in the HTTP API URL.
Take that UUID, drop it into the URL pattern, add your command, and you have a working endpoint. Name it something human-readable in your HA config so you remember what it does six months from now.
Setting Up Loxone REST Commands in Home Assistant’s configuration.yaml
Once you have your UUIDs, the Home Assistant side is straightforward. The rest_command integration lets you define named HTTP calls in configuration.yaml that you can then trigger from automations, scripts, or the HA dashboard.
Here’s the structure I use for my showroom setup:
rest_command:
loxone_night_light_trigger:
url: "http://{showroom-loxone-ip}/jdev/sps/io/207da04a-02a2-f404-ffff4ebbfd8d0b74/pulse"
method: "get"
authentication: "basic"
username: "loxone-user"
password: !secret loxone_password
loxone_party_lights_trigger:
url: "http://{showroom-loxone-ip}/jdev/sps/io/207d988e-013f-c1d7-ffff4ebbfd8d0b74/pulse"
method: "get"
authentication: "basic"
username: "loxone-user"
password: !secret loxone_password
loxone_enable_party_door:
url: "http://{showroom-loxone-ip}/jdev/sps/io/207df13e-02eb-874a-ffff4ebbfd8d0b74/on"
method: "get"
authentication: "basic"
username: "loxone-user"
password: !secret loxone_password
loxone_disable_party_door:
url: "http://{showroom-loxone-ip}/jdev/sps/io/207df13e-02eb-874a-ffff4ebbfd8d0b74/off"
method: "get"
authentication: "basic"
username: "loxone-user"
password: !secret loxone_password
A few things worth noting here.
Pulse vs. on/off produce different actions. The night light and party lights use /pulse because they activate a Loxone mood or scene — a momentary trigger that fires the logic and exits. The party door enable/disable uses /on and /off because it’s controlling a stateful virtual input that needs to hold its value. Getting this wrong won’t break anything dramatically, but a /pulse on a stateful input may not behave the way you expect.
Store your password in secrets.yaml. The !secret loxone_password reference pulls the value from a separate secrets.yaml file that sits in your HA config directory. That file should never be committed to version control or shared. Create a dedicated Loxone user with limited permissions specifically for HA — don’t use your admin credentials here.
Use descriptive command names. loxone_night_light_trigger is clear. loxone_cmd_3 is not. You’ll thank yourself when you’re debugging an automation at 11pm.
Triggering Loxone REST Commands from Home Assistant Automations
With your rest_command entries defined and HA restarted (or the config reloaded), calling Loxone from an automation is a single action:
actions:
- action: rest_command.loxone_night_light_trigger
metadata: {}
data: {}
That’s the whole thing. From here, you can set it up with any trigger Home Assistant supports — a contact sensor changing state, a time pattern, a person arriving home, a webhook from an external system. The Loxone side doesn’t care where the call originated; it just executes the virtual input logic.
In my showroom, I use this to chain automations across both systems. When someone rings the doorbell affixed just outside the showroom, Home Assistant detects the event and switches the kiosk display to the demo interface, opens the curtain covering the glass on the door, and then calls Loxone to trigger the appropriate lighting mood — all in a coordinated sequence, none of it touching the internet. More coming in a future post!
This is the kind of integration that takes an afternoon to set up properly and then runs invisibly for years. That reliability is exactly why I use both systems together: Home Assistant handles event detection, conditional logic, and cross-system orchestration; Loxone handles the low-level hardware control and the lighting scenes it does exceptionally well.
Ready to Build a Smart Home You Actually Own?
Stop fighting with forums and YouTube tutorials. Get expert 1-on-1 guidance to set up your privacy-first Home Assistant system the right way, with proper security hardening, automation design, and troubleshooting confidence.
What This Integration Actually Looks Like Running in a Real Home
This is not a theoretical setup — it’s what’s running in the Serenity Smart Homes showroom right now. Home Assistant and Loxone are coordinating across lighting, motorized window coverings, a kiosk display, and a person-detection camera, all without a single cloud dependency.
For homeowners, that translates to a system that keeps working when your internet goes down, doesn’t depend on a manufacturer’s server staying online, and doesn’t send your automation patterns to anyone. Learn more about why cloud-dependent smart homes are a liability →
For people who’ve already invested in Loxone — typically because they built new construction or did a serious renovation — this integration means you’re not locked into Loxone’s ecosystem for every part of your smart home. You can add Zigbee sensors, Thread devices, or third-party cameras through Home Assistant and still have them trigger your Loxone scenes natively. The two platforms complement each other well when they’re set up to communicate directly.
The integration I’ve described here covers the most common use case: Home Assistant calling Loxone. If you also want Loxone triggering automations in Home Assistant — say, a Loxone button press firing an HA scene or sending a notification — that’s handled through Loxone’s Virtual HTTP Output pointed at HA’s webhook endpoint, and I’ll cover that in a follow-up post.
Setting up a Home Assistant and Loxone integration from scratch is one of those things that looks complicated from the outside and turns out to be refreshingly simple once you know where to look. The .Loxone file gives you the UUIDs. The rest_command integration handles the HTTP calls. Basic auth handles the security. Everything stays local.
If you’re looking at this and thinking “I want this in my home, but I’d rather someone who’s already done it handle the setup” — that’s exactly what a Serenity consultation is for. We’ll talk through what you have, what you want it to do, and how to get there without the trial and error. Click here to book a smart home consultation to learn more.
