Hola,
No he encontrado un tema donde solicitar esta funcionalidad, pero creo que sería bueno poder elegir el canal de comunicación preferido a nivel global, así como elegir entre los diferentes canales de comunicación configurados para enviar los mensajes.
De hecho, después de instalar la integración externa Olvid, tengo un duplicado con Telegram.
Mientras que potencialmente querría enviar mensajes a una u otra integración.
Por ejemplo, si la integración Olvid falla, que la notificación se envíe a Telegram y viceversa.
Sé que el caso es un poco exagerado, pero es algo a debatir
Ya se pensó y la PR se fusionó esta mañana, estará en la próxima actualización de Gladys.
Sin embargo, es una elección que hay que hacer manualmente en las escenas
Está claro, y con la cantidad de integraciones que nos sacas, no puedes seguir todos los temas
optimizas al máximo el paquete claude
Sí, tenemos hasta el 19, aunque espero que mantengan este límite o lo aumenten.
tengo un problema con la selección del canal de envío de mensajes:
y si elijo el primer « Telegram » funciona, pero no si elijo el segundo.
De hecho, hay 3 integraciones nativas de CallMeBot, Telegram y Nextcloud Talk que se activan cada vez. Lo corregiremos.
externa: entonces habría que especificar eso en la elección
mutmut
14 Agosto, 2026 20:31
13
¿No es posible mostrar solo los servicios configurados y, por lo tanto, activos?
@pierre-gilles , aquí tienes la PR
master ← William-De71:fix/message-service-selector-configured-only
ouvert 09:34AM - 19 Aug 26 UTC
### Description
The "send message" scene action offered CallMeBot, Telegram a… nd Nextcloud Talk even when the user had never configured them, and showed a duplicate Telegram entry next to the external Telegram integration.
getMessageServices() only checked that a service was loaded and exposed message.sendToUser. That proves nothing about configuration: a core service whose start() throws a ServiceNotConfiguredError stays RUNNING, stays in the stateManager and keeps its sendToUser method.
Filter on the isUsed() hook instead, the convention getUsage() already relies on. External integrations are kept as-is (installed means configured, and a proxied service exposes no hook), and a core service without the hook is kept too, as there is nothing to check it against.
Telegram had no isUsed() hook: add one, based on TELEGRAM_API_KEY, exactly like start() does. CallMeBot and Nextcloud Talk already had theirs.
Also disambiguate the selector labels: a native service and an external integration can display the very same name, so append "built-in integration" / "external integration" when two channels would otherwise be identical.
<img width="594" height="248" alt="image" src="https://github.com/user-attachments/assets/08a7fbd6-921b-407c-858b-c1d5b60d6b87" />
## Forum
Reported at https://community.gladysassistant.com/t/choix-canal-communication/10549
### Checklist
- [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
## Summary by CodeRabbit
* **New Features**
* Message service selectors now distinguish external integrations from built-in services, including when names overlap.
* Unavailable services are clearly indicated while remaining selectable where applicable.
* Added German, English, and French translations for service type labels.
* **Bug Fixes**
* Service discovery now excludes unconfigured or invalid built-in messaging services while retaining valid integrations.
* Telegram availability now reflects whether an API token is configured.
* **Documentation**
* Updated API examples to include service type information.
Gracias, está bien para mí
