TECHNOACTIVE

Loxone Integrations · From Our Own Installs

What actually workswith Loxone.

Not a list of what the datasheets claim. These are integrations we have built and handed over in real properties, written up with the limitations included — what works, what does not, and what happens when the internet drops. We are starting with the Shelly range and adding a brand at a time.

Ask about your device020 8191 2479
How to read the verdicts
Native in Loxone
A Loxone device, or one Loxone supports itself. Nothing in between to break.
Works properly
A third party, connected locally on a documented interface. Reliable, and ours to maintain.
Needs a bridge
An extra box or piece of software in the middle. It works, and it is one more thing to keep alive.
Events only
The two systems can tell each other something happened. No data, no picture, no control.
Not worth it
Possible on paper. We would fit something else and tell you why.

Why this page exists

The honest answer is almost always yes, but not like that.

Ask whether a device works with Loxone and you get either a sales answer or a forum thread from 2019 in German. Both leave out the part you need: how the connection is actually made, what it stops being able to do, and who owns it when a firmware update breaks it. So we write down what we find on our own jobs.

The Integrations

Written up one at a time,as we do them.

The list begins with the Shelly range, split by product because the verdict is not the same across it — the meters are the best thing Shelly makes, and the dimmers need the most care. Open any entry for the limitations.

Lighting & power

Shelly relays and input modules

Works properly

The honest answer to "we forgot the cable". A Shelly behind an existing switch or in a ceiling rose gives Loxone a circuit it was never wired to reach — no chasing walls, no lifting floors.

How it is connected. Loxone virtual outputs send HTTP commands to the device on the local network, and the Shelly pushes its own state and its button presses straight back into Loxone virtual inputs. On larger jobs we drop the polling and use MQTT instead.

What it does and does not do

What works

  • Loxone switches the circuit with a virtual output: /relay/0?turn=on on a Gen 1 device, /rpc/Switch.Set?id=0&on=true on the Plus, Pro and Gen 3 range
  • State comes back rather than being assumed — Gen 1 action URLs, or a Gen 2 webhook on switch.on and input.toggle_on, calling the Miniserver on /dev/sps/io/
  • Gen 2 webhooks substitute live values into the URL, so a reading can be pushed into a Loxone virtual input as a number instead of being polled for
  • A webhook can carry its own condition and a time window, so the device itself decides whether the event is worth telling Loxone about
  • An existing wall switch on the SW terminal becomes a Loxone input, so the old plate keeps working and can run scenes without being replaced
  • The input-only models do the same job with no load attached — a retro toggle, a doorbell push, a boiler contact, a garden gate button
  • The PM models meter their own circuit, so the load appears in Loxone as a live figure alongside the switching
  • On bigger jobs MQTT replaces all of it, and the last-will message on shellies/<id>/online tells Loxone the moment a device drops off the network

What it cannot do

  • Loxone does not know these devices exist. Nothing appears in the device tree, there is no bus diagnostics, and Loxone support will not help you debug one
  • Put a password on a Gen 2 or Gen 3 device and its HTTP interface moves to SHA-256 digest authentication, which a Loxone virtual output cannot answer. Either the devices sit on their own isolated network with authentication off, or you drive them over MQTT, which is exempt
  • Twenty webhooks per device is the ceiling — ten on the battery models — with five URLs each. Ample, right up until somebody tries to bring everything across
  • It rides on the WiFi. An access point reboot or a channel change can interrupt lighting control that a Tree cable would have ignored completely
  • Send commands without reading state back and Loxone will confidently show a light as on when somebody has switched it off at the wall
  • Failure is silent unless you build for it. We poll /shelly, which stays reachable even with authentication enabled, so a device that stops answering raises a fault instead of being discovered six months later
  • The API changed between generations. A Gen 1 configuration does not transfer to a Plus or Gen 3 device without being rewritten
  • Most of the range needs a neutral at the switch position and somewhere accessible to sit, and it is still work on a live circuit that belongs to an electrician
  • Every device is built by hand in Config. Twenty undocumented Shellys in a loft is a liability for whoever comes next, so ours are labelled, addressed and written down

With no internet. Completely unaffected, set up properly: a reserved address, and every command travelling between the Miniserver and the device across your own network. Turning MQTT on switches Allterco's cloud service off altogether on the Gen 1 range, which is exactly what we want. There is no TLS on Shelly's MQTT either, so the broker and the devices stay on our network and never cross the internet.

Our take

Installed by us

In a house being wired now, Tree wins every time — one cable, self-identifying devices, real diagnostics. A Shelly is the right answer to a specific problem: a circuit the cable cannot reach, an outbuilding, a listed ceiling nobody is allowed to chase, or an extra light that appeared after first fix. It is a good repair, not a strategy, and we will tell you which one you are buying.

Why the network underneath mattersHow we wire a Loxone house properlyShelly's own API documentation
Energy

Shelly energy meters

Works properly

The best value in the whole Shelly range, and the entry we would defend hardest. Clamp one round the incoming supply and Loxone finally knows what the house is doing.

How it is connected. A Loxone virtual HTTP input reads the power figures out of the meter's JSON status — /rpc/EM.GetStatus for total_act_power and the per-phase values on the Pro range, the emeter endpoints on the older 3EM.

What it does and does not do

What works

  • Whole-house load, per phase, arriving in Loxone as a live number it can make decisions with
  • Individual circuits metered on their own clamp, which is how you find out that the pool pump or the immersion is the real bill
  • Load management becomes possible: hold back the EV charger or the immersion when the incoming load is already near the main fuse
  • A clamp on the solar circuit tells Loxone what is being generated, so a surplus can be spent on the cylinder or the car instead of exported for pennies
  • The meter can also push rather than wait to be asked: set an over-power or under-power threshold and it calls Loxone the moment a circuit crosses it, which is faster than any polling interval
  • A long-run record kept by Loxone statistics rather than a manufacturer app, so the history is yours and survives the device

What it cannot do

  • A polled value is only as fresh as its interval. Fine for load and billing, not intended for anything that needs instant reaction
  • Clamp meters are indicative, not a settlement-grade revenue meter, and the accuracy depends on the clamp being on cleanly and the right way round
  • It measures. It does not switch anything, so the control still has to exist somewhere else
  • Installing it means working inside a live consumer unit, which is our work rather than a homeowner project

With no internet. Entirely local. The meter and the Miniserver talk to each other on your network, and the statistics keep being recorded whether the internet exists or not.

Our take

Installed by us

If somebody wants one integration to start with, this is it. A few hundred pounds of metering turns Loxone from something that switches things on into something that makes decisions with real numbers — and it is the piece almost nobody thinks to ask for.

Electrical work and consumer units
Lighting & power

Shelly dimmers

Works properly

Connected exactly as easily as the relays. The difficulty is never the integration — it is what happens between the dimmer and the LED driver.

How it is connected. The same local HTTP or MQTT link as the relays, with the level carried in the command — /light/0?turn=on&brightness=50, or a relative dim up and down in steps.

What it does and does not do

What works

  • Loxone sets brightness as a percentage, so a Shelly circuit joins scenes and daylight-linked lighting alongside Tree dimmers
  • A minimum brightness can be set on the device, which is how you stop a fitting dropping out or flickering at the bottom of its range
  • A retrofit room gets proper dimming with no cable back to the board, which is the whole reason to consider one
  • The existing switch can still be wired in, so the wall plate keeps working for anyone who ignores the app
  • It will run in two-wire mode where there is no neutral at the switch, which is often the only reason the room can be dimmed at all

What it cannot do

  • It has to be calibrated against the actual fitting before it behaves, and the calibration has to be run again if the lamps are ever changed
  • LED compatibility is the real risk. Minimum load, driver quality and edge behaviour cause flicker, buzz and a range that stops well above zero
  • We test the actual lamp and the actual driver before committing to it, because no datasheet will tell you how the pair behaves together
  • Two-wire mode is the fussiest of all and often needs a bypass, so it is the first thing we test rather than the thing we promise
  • Dimming curves differ from Loxone Tree dimmers, so a Shelly circuit and a Tree circuit both set to 30% will not necessarily match in the same room
  • It is a mains dimmer, not a driver, so anything on a constant-current or DALI driver is a different job entirely

With no internet. Local, like the rest of the range, provided it is commissioned onto your own network rather than left talking to the cloud.

Our take

Installed by us

Where cable exists, dim on Tree or through a proper DALI driver and the result is better in every measurable way. Where it does not, a Shelly dimmer with a lamp we have actually tested is a genuinely good outcome — and we would rather sell you three tested fittings than a dimmer that hums.

Lighting design and electrical

The Ways In

Every integration is one ofa handful of connections.

Which one a device can offer decides how quickly it reacts, how much of it survives a firmware update, and how obvious it is when something has stopped working. It is also why we still run cable wherever cable can go.

01

Tree and Air

Loxone's own two-wire bus and its wireless equivalent. Native, self-identifying, diagnosed by Loxone itself, and nothing in the middle to translate.

02

Wired contacts

Digital inputs and relay outputs. Unglamorous, and the most reliable link there is — an alarm panel, a recorder, a gate controller, a boiler demand.

03

Modbus

How serious equipment talks: inverters, batteries, heat pumps, energy meters, ventilation units. Registers rather than an app, so it survives firmware fashion.

04

KNX and DALI

For buildings already committed to those standards, and for addressable lighting drivers where each fitting has to be spoken to individually.

05

RS232 and RS485

Projectors, screens, AV matrices and older plant. Not fashionable, still the only way into a lot of good hardware.

06

HTTP virtual in and out

Commands sent as URLs, and values read back out of a JSON status. This is how most network devices end up connected, the Shelly range included.

07

MQTT

The grown-up option once there are more than a handful of devices: one broker, status and command topics, and offline detection built in.

08

HomeKit and Matter

The route out rather than in. It lets Apple Home and voice assistants see the system, without either becoming responsible for running it.

Commissioning

A third-party deviceis only as good as its setup.

Most integrations that fail were never broken — they were left on factory settings, on a floating address, talking to a cloud service, with nobody watching whether they were still alive. Every device we connect goes through the same six steps before we hand it over.

  1. 01

    Reserved address

    A fixed lease on the router, so a device cannot move and take the configuration with it.

  2. 02

    Cloud switched off

    It answers to the Miniserver on your network, not to a server in another country.

  3. 03

    Authentication decided

    Either a password and a protocol that can carry it, or no password and its own isolated network. Never a password and a link that cannot answer one.

  4. 04

    Firmware recorded

    The version we tested is the version we leave on it, written into the handover notes.

  5. 05

    Heartbeat added

    Loxone checks the device is still there and raises a fault the moment it stops answering.

  6. 06

    Labelled both ends

    Named in Config, named on the device, and on the schedule for whoever comes next.

The Small Print, Up Front

Four things installerstend not to mention.

01

"Works with" on a box means almost nothing

It can mean a certified, self-identifying device, or it can mean somebody once got it to respond to a URL. Both are printed the same way. The question worth asking is what breaks when the manufacturer changes their API, and who fixes it.

02

Cloud integrations are borrowed, not owned

Anything that routes through a manufacturer cloud works until that company changes its terms, its pricing, or its mind. We use them where the alternative is nothing, we say so, and we keep them off the critical path — heating, lighting and security stay local.

03

A device on WiFi is not a device on a bus

A wireless device does the same job right up to the moment an access point reboots, a channel changes or a firmware update reorders its API. A cabled bus device is boring by comparison, and boring is the entire point in a house you have to live in. Where cable can still be run, we run cable.

04

We would rather tell you no

Every entry here includes what the integration cannot do, because that is the part that generates the phone call two years later. If something on this page turns out to be wrong, or a firmware update changes it, we correct the page.

How the Loxone system itself worksHow a whole system responds together

Got something you want to keep?

Tell us what is already in the house and we will tell you honestly whether it belongs in the system, needs a bridge, or is better replaced. If we have not tried it, we will say that too.

Ask us about a device020 8191 2479