Hallo,
Ich habe kein Thema gefunden, in dem eine Funktionalitätsanfrage dazu gestellt wurde, aber ich denke, es wäre gut, den bevorzugten Kommunikationskanal auf globaler Ebene auswählen zu können sowie eine Auswahl zwischen den verschiedenen konfigurierten Kommunikationskanälen, um Nachrichten zu senden.
Tatsächlich habe ich nach der Installation der externen Olvid-Integration eine Dopplung mit Telegram.
Während ich potenziell Nachrichten an die eine oder andere Integration senden möchte.
Zum Beispiel, wenn die Olvid-Integration ausfällt, dass die Benachrichtigung an Telegram gesendet wird und umgekehrt.
Ich weiß, dass der Fall ein bisschen weit hergeholt ist, aber es ist diskussionswürdig
Bereits gedacht und die PR wurde heute Morgen gemerged, sie wird im nächsten Gladys-Update enthalten sein.
Allerdings ist dies eine manuelle Auswahl in den Szenen.
Das ist klar, und mit der Menge an Integrationen, die du uns lieferst, kannst du nicht alle Themen verfolgen.
Und trotzdem versuche ich es
du optimierst das Claude-Paket voll aus
Ja, wir haben Zeit bis zum 19., auch wenn ich hoffe, dass sie diese Grenze beibehalten oder sogar erhöhen.
Chris75
14. August 2026 um 17:40
10
ich habe ein Problem mit der Auswahl des Nachrichtenkanals:
Telegram erscheint zweimal, obwohl ich nur die externe Integration konfiguriert habe?
et wenn ich das erste „Telegram“ auswähle, funktioniert es, aber nicht, wenn ich das zweite auswähle
außerdem, warum werden CallMebot und Nextcloud angezeigt, obwohl ich sie nicht konfiguriert habe?
Will_71
14. August 2026 um 20:08
11
Tatsächlich gibt es drei native Integrationen von CallMeBot, Telegram und Nextcloud Talk, die jedes Mal aktiviert werden. Das werden wir korrigieren.
Für Telegram verwendest du welche interne oder externe Integration?
Chris75
14. August 2026 um 20:17
12
extern: Das sollte man dann bei der Auswahl angeben
mutmut
14. August 2026 um 20:31
13
Kann man nicht nur die konfigurierten und damit aktiven Dienste anzeigen?
Will_71
19. August 2026 um 09:36
14
@pierre-gilles , hier ist der 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.
Danke, das ist gut für mich