Ok, ich habe den PR von Gladys mit 3 Änderungen aktualisiert:
1. Banner „Ihr Gerät ist nicht in der Liste?“ — es hebt nun Matter und die externen Integrationen der Community hervor: „jeder kann eine erstellen und sie im Store veröffentlichen, dann erscheint sie in dieser Liste“,
2. Ankündigung der Deprecation von Tuya, MELCloud, Telegram und Netatmo — ich habe beide gemacht, damit es keine Missverständnisse gibt:
- ein rotes Badge „Bald veraltet“ auf ihrer Katalogkarte (Flag
deprecatedin den JSON-Dateien der Integrationen, gerendert inIntegrationTags); - eine Warnung oben auf der Seite jeder der vier Integrationen (geteilter Bestandteil
DeprecationWarning): „wird bald zugunsten einer äquivalenten externen Integration veraltet sein… beide Versionen werden während des Übergangs im Katalog koexistieren — Sie können diese weiterhin für den Moment verwenden“.
3. Authentifizierungsfehler beim Neustart (close code 4000) — Diagnose bestätigt, und es war sogar schlimmer: ohne die Umgebungsvariable JWT_SECRET wird das Geheimnis bei jedem Boot von Gladys neu generiert, und da start() den bestehenden Container mit dem in seiner Umgebung eingefrorenen JWT-Token neu startet (signiert mit dem alten Geheimnis), schlingerte die Integration in der Ablehnung ohne sich jemals zu reparieren. Zwei Korrekturen:
- der Supervisor signiert nun die JWT-Integrationen mit seinem eigenen Geheimnis, einmal generiert und als Variable (
EXTERNAL_INTEGRATION_JWT_SECRET) persistiert — es überlebt Neustarts und Wiederherstellungen aus Backups, in Übereinstimmung mit den Containern, die er validiert; - Selbstreparatur in
start(): Bevor ein bestehender Container neu gestartet wird, prüftverifyContainerTokenden Token seiner Umgebung (Signatur mit dem aktuellen Geheimnis + guter Dienst + gutetoken_version); wenn er abgelaufen ist, wird der Container mit einem frischen Token neu erstellt, anstatt sinnlos neu gestartet zu werden. Das repariert auch beim nächsten Boot die Container, die vor diesem Fix erstellt wurden.
