🧹 Gladys lightens up: the future of native integrations

[pierre-gilles]

Hello everyone!

Since the arrival of community integrations (installable with one click from the catalog, each isolated in its own container), the ecosystem has literally exploded: over 900 integrations are now available in the store. Thank you to all the developers who publish them

This changes the game for the core of Gladys. A native integration is code that needs to be maintained, tested, and delivered with each version of Gladys, even when a manufacturer’s API changes overnight. A community integration, on the other hand, evolves at its own pace and updates without waiting for a version of Gladys. And if it crashes, Gladys keeps running.

The goal: to remove from the core everything that can be, to keep only what is truly internal to Gladys or truly essential. Here is the complete inventory of native integrations and what will become of them.

What remains in the core

Integration	Why it stays
Matter	The standard for connected homes, a foundation of Gladys
Zigbee2mqtt	The most used protocol by the community
MQTT	The basic building block of DIY: MQTT devices, MQTT scene triggers and actions
Energy Tracking, Thermostat	These are Gladys features, not brand integrations
MCP	The server that allows your AI assistants to control Gladys
Amazon Alexa, Google Home, Enedis, OwnTracks, Artificial Intelligence	Services related to Gladys Plus
Apple HomeKit	Exposes your Gladys devices in Apple’s Home app, like Alexa and Google Home

Deprecated Integrations: A Community Replacement Already Exists

These native integrations already have the « Soon Deprecated » badge and will be removed in a future version of Gladys

I think we’ll soon need to communicate about their removal!

Their replacement is available in the catalog:

Native Integration	Community Replacement
Philips Hue	Philips Hue
TP-Link	TP-Link Kasa (and Tapo for the Tapo range)
Tuya	Tuya
Netatmo	Netatmo
MELCloud	MELCloud (and MELCloud Home for MELCloud Home accounts)
Sonos	Sonos
Z-Wave JS UI	Z-Wave JS UI
Telegram	Telegram
Nextcloud Talk	Nextcloud Talk
Free Mobile	Free Mobile SMS
OpenWeather	OpenWeather, or Open-Meteo / Météo France

How to Migrate Without Losing Anything?

1. Install the community integration from the catalog, configure it, and create your devices.
2. On the page of the old integration, click Migrate on each device and choose its equivalent. Gladys moves the history, updates your scenes and dashboards, then removes the old device.

For messaging (Telegram, Nextcloud Talk, Free Mobile) and weather, there are no devices to migrate: install the new integration, then replace in your scenes the actions that used the old one (for example, « Send an SMS » becomes « Send a message » on the Free Mobile SMS channel).

Next Deprecations: Replacement Available, Feedback Welcome

These integrations already have a community equivalent. Before officially deprecating them, we want to make sure nothing is missing: if you use them, test the replacement and tell us what’s not working.

Native Integration	Community Replacement	Notes
CallMeBot	CallMeBot	Official integration
eWeLink	Sonoff / eWeLink	The native version no longer works since the eWeLink API change of 2023
Broadlink	Broadlink	RM remotes (IR/RF), SP plugs, MP1 power strips, A1 sensors
Tasmota	Tasmota	Via MQTT or HTTP
Xiaomi Home (Xiaomi/Aqara gateways)	Zigbee2mqtt or Matter for Aqara sensors, Xiaomi MIoT for Wi-Fi devices	The native version relies on the developer mode of old gateways, which no longer exists
EcoWatt	RTE éCO2mix, EcoWatt & EcoGaz	Requires a free key from the RTE data portal

To be moved out of the core: we’re looking for volunteers!

These integrations don’t yet have a community equivalent. The official template and the SDK are there to help you get started. Signal yourself in this topic to avoid two people working on the same thing!

Available today:

Integration	Notes
CalDAV	The « Calendar » type already exists. ICS Calendars covers published calendars in .ics format, missing CalDAV synchronization with credentials (Nextcloud, iCloud…)
Nuki	Locks via local MQTT and Nuki web API
Google Cast	mDNS discovery provided by Gladys, voice announcements on speakers
Airplay	Same principle as Google Cast
Node-RED	Launch the Node-RED container with its interface accessible on the local network
EDF Tempo	EDF Tempo Calendar already exists: it lacks feeding the « tempo » tariff calendar used by energy contracts

First, an evolution of community integrations:

Integration	What’s missing	In the meantime
Bluetooth Presence	Access to the Bluetooth adapter from an integration	Nothing changes, the native integration remains in place
LAN Manager	Local network scan provided by Gladys	Presence via your box or router already exists: UniFi, OpenWrt, NetAlertX, Livebox, ASUS, NETGEAR…
Cameras (RTSP)	Live video streaming (community integrations send images, no live stream yet)	go2rtc, ONVIF and Frigate already exist for images
Matterbridge	Now that Gladys external integrations exist, I find that Matterbridge is no longer very useful, to be seen if we don’t want to deprecate this integration

Your turn to speak

• A community integration doesn’t offer everything the native version did? Let us know, that’s exactly what we want to know before removing anything.
• Do you want to port an integration from the « To be moved out of the core » list? Signal yourself in this topic!

Thanks to all

[Prof_Techno]

For the part I was able to test, the LAN Manager, which allows you to detect devices connected to the network, can be easily replaced by the SFR integration. So, we’ll see for the other integrations, depending on the possibilities of each.

[mutmut]

Everything seems very consistent to me.
I would say that removing matterbridge is a bit too much, I will move it to external integration for those who still have things on it, and those who only want Matter instead of external integrations.
I think we should take the same reasoning as for node-red.

[pierre-gilles]

@ProtZ could you migrate Nuki to external integration? If you don’t have a Claude license, we can handle it , but I’d prefer to ask if you want to stay the maintainer of this integration!

[GBoulvin]

Tasmota has been tested and proven

[mutmut]

@Prof_Techno

LAN Manager, which allows you to detect devices connected to the network, can be easily replaced by the SFR integration

What happens when you switch to Free?
In my opinion, everything needs to be redone: scenes, dashboard, etc.

Is it possible to have an external LAN Manager integration that allows you to then choose devices from SFR, Unifi, Orange integrations, etc.?
This would allow for a middle layer that would be used in scenes, etc., and would not depend on a particular box.

[GBoulvin]

I’m happy to handle the integrations to migrate (and maintain them), but I don’t necessarily have the equipment to test them.
For Google Cast, I have a Chromecast, and for AirPlay, an iPad (no idea if that will be enough).
I can migrate Node-RED (testable) and CalDAV (if it’s not too technical).

Nuki and EDF Tempo won’t be testable on my end.

If that’s OK, I’ll get started right away!

[pierre-gilles]

For caldav just contact @bertrandda but the rest is fine, first come first served!

[GBoulvin]

There you go, Airplay and Google Cast are live. Node-RED is in progress.

I’m waiting for responses from @bertrandda (CalDAV) and @ProtZ (NUKI) before I unleash Claude on it

[GBoulvin]

Let’s see if these limits are acceptable, especially for Node-RED:
For Node-RED:

• No USB/serial access or network broadcasting (mDNS, UDP discovery) from flows: Gladys does not provide privileged access to sub-containers.
• MQTT address to change: localhost refers to Node-RED itself. MQTT nodes must target the IP address of the Gladys machine.
• Manual migration: flows are exported from the old editor and imported into the new one, then passwords for configuration nodes must be re-entered.
• Single version (Node-RED 5) instead of a choice between 3, 4, and 5.

For Airplay:

1. AGPL-3.0 License: the AirPlay library (@lox-audioserver/node-airplay-sender, the one used by the built-in service) is under AGPL-3.0 and it is included in the Docker image. I therefore put the project under AGPL-3.0-or-later instead of the Apache-2.0 of the template. Let me know if you want a different approach.
2. Volume of « Play a notification » ignored: Gladys does not transmit this volume to external integrations, only the URL of the voice. The notification is therefore played at the volume of the speaker. To adjust it in a scene, you first need an action « Control a device ».
3. Docker network risk: some AirPlay 2 speakers must recontact the sender to synchronize, which can fail behind the Docker network. A speaker might then be found but remain silent. The planned workaround is to force « AirPlay 1 (RAOP) » in the configuration. This is the point to check first on real hardware.

Google Cast: Volume of announcements: Gladys does not transmit the volume of the « Play a notification » action to external integrations. It is therefore set in the configuration of the integration, and the original volume is restored after the announcement.

[bertrandda]

@GBoulvin

I’m waiting for the responses from @bertrandda (CalDAV) and @ProtZ (NUKI) before I start Claude on it

Hi @GBoulvin, Pierre-Gilles mentioned it to me this morning in private and I immediately launched a Claude plan for CalDAV. If that’s okay with you, I’ll start the implementation to handle this integration.

@GBoulvin

For Airplay:

1. AGPL-3.0 License: the AirPlay library (@lox-audioserver/node-airplay-sender, the one used by the built-in service) is under AGPL-3.0 and it is included in the Docker image. I therefore put the project under AGPL-3.0-or-later instead of the Apache-2.0 from the template. Let me know if you want a different approach.

I don’t know if you’ve seen the lib @lox-audioserver/node-airplay-sender is archived on Github, they have merged with Sonn audio and the new maintained lib is @sonn-audio/node-airplay. It might be worth using that one, what do you think?

[GBoulvin]

@bertrandda

The new maintained library is @sonn-audio/node-airplay. It might be worth using that one, what do you think?

I asked Claude your question and the answer is mixed:

"Yes, I think we should switch to @sonn-audio/node-airplay. But upon examining it, I found a more important issue than the choice of the library: it affects HomePods regardless of the library used.

Why change

• Maintenance: @lox-audioserver/node-airplay-sender is archived, while the new one was published at the end of August and version 0.1.2 dates from September 22.
• License: the new one is under Apache-2.0, like the template, and has no dependencies. The integration could therefore leave the AGPL that I had imposed on it because of the old one.
• Quality: the author says he tested it on a HomePod (OS 27) and a BeoLab 50. It really handles AirPlay 2, automatically choosing the synchronization method that the speaker accepts (PTP or NTP). It also handles the authentication exchange of some old AirPlay 1 receivers that refuse the connection without it.
• A strong argument: its README indicates that recent HomePods and Apple TVs (OS 27) accept an AirPlay 1 session but remain silent. The old library only did a « best-effort » AirPlay 2. On a recent HomePod, the current integration may therefore produce no sound.

What it costs

• The library is young (0.1.x, single author).
• Its interface is low-level: connection, synchronization, audio packets. The reading logic would need to be rewritten, about 250 lines in src/player.js.
• This file is isolated from the rest: discovery, scenes, the widget, and the application tests do not change. Only the et field of the mDNS records would need to be kept in addition.

The underlying problem, which the library does not solve

I checked in Gladys’ code how it creates the container of an integration. It is on a Docker network in bridge mode, with all Linux capabilities removed. No host network mode is possible, neither for the main container nor for a sub-container, and the exposed ports are assigned randomly.

• For HomePods/Apple TVs (PTP): the sender must serve the clock on UDP ports 319/320, and the speaker comes to query it at the address that the sender gives it. This address would be the internal IP of the container (172.x), unreachable from the local network. These devices would therefore probably remain silent.
• For third-party speakers in NTP and AirPlay 1 receivers: it is more favorable, but nothing guarantees it, because the speaker must also recontact the sender.

I had reported it as a limitation; it is actually potentially blocking for HomePods. The real solution would be for Gladys to offer a network option for this type of integration. It would be worth discussing it with the Gladys maintainers."

Maybe keep this solution in mind and wait for it to mature a bit?

And in reality, I haven’t had the opportunity to test it yet, but it may not be possible to switch to external integration as it stands.

[bertrandda]

@GBoulvin

Maybe keep this solution up your sleeve and wait for it to mature a bit?

Yes, I had seen the lib for the « old » internal integration, but you might be right, we can keep an eye on it to use it later. In general, it’s always better to have a maintained lib than an old abandoned one.

@GBoulvin

And in reality, I haven’t had the chance to test it yet, but it might not be possible to switch to external integration as it stands

Given the last sentence you posted from your Claude, yes indeed, I don’t think it’s possible. I’ll try to test it quickly, and I’ll let you know if it works

[bertrandda]

@GBoulvin It doesn’t seem to work, I’ll do more tests on Sunday with a real Homepod

[2026-10-29T21:40:02.135Z] [INFO] [app] Action test_speaker <- ext:ext-gboulvin-gladys-airplay:speaker:faee67b415d7
[2026-10-29T21:40:02.160Z] [INFO] [player] Playing on Speaker (172.16.8.255:7000, AirPlay 2)
/app/node_modules/bplist-parser/bplistParser.js:64
    throw new Error("Invalid binary plist. Expected 'bplist' at offset 0.");
    ^

Error: Invalid binary plist. Expected 'bplist' at offset 0.
    at exports.parseBuffer (/app/node_modules/bplist-parser/bplistParser.js:64:11)
    at Client.processData (/app/node_modules/@lox-audioserver/node-airplay-sender/dist/core/rtsp.js:1501:43)
    at Socket.<anonymous> (/app/node_modules/@lox-audioserver/node-airplay-sender/dist/core/rtsp.js:211:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:569:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:520:3)
    at Readable.push (node:internal/streams/readable:400:5)
    at TCP.onStreamRead (node:internal/stream_base_commons:194:23)