Bist du dir sicher, dass du die Integration mit dem richtigen Manifest für die Schaltfläche „Update erzwingen“ installiert hast?
Hast du das Manifest aus dem Build kopiert?
Ja, in diesem Fall bin ich mir zu 100% sicher.
Das einzige Mal, als sich das Manifest geändert hat, fand ich das logisch und instinktiv habe ich es gelöscht und neu erstellt. Wenn es überhaupt möglich ist, in der Entwicklung das Manifest direkt von der Integration aus zu ändern oder noch besser, dass es selbst überprüft/neu lädt, wäre das noch besser (insbesondere für die Tester), aber hier stelle ich nur die Frage der Machbarkeit ^^
Und in diesem Fall:
-
Wenn kein Produktionsbild (Tuya) vorhanden ist, verursacht das Update der Entwicklung einen Fehler:
-
Wenn ein Produktionsbild aktiv ist (Zendure), lädt das Update des Containers das Produktionsbild und überschreibt die Entwicklung (lästig ^^) => Siehe die Docker-Bildversion unten nach Klick auf „Update“ im Vergleich zur Adresse
http://10.5.0.227:1444/dashboard/integration/device/external/ext-dev-zendure-2/config, die anzeigt, dass ich auf dem Entwicklungsbild war
=> Die Produktionsadresse isthttp://10.5.0.227:1444/dashboard/integration/device/external/ext-terdious-gladys-zendure/config
Autsch ^^ 
Konkrekt bieten alle Hersteller von Batterien für den öffentlichen Gebrauch (Anker, Zendure, EcoFlow, Marstek, Bluetti…) an:
- Solarbatterien (mit PV-Eingängen),
- einfache Batterien (ohne PV-Eingänge).
Daher ist die Kategorie nicht spezifisch für Zendure (der Name im Titel ist nur die ursprüngliche Integration, die den Bedarf ausgelöst hat) — im Gegenteil, wir machen sie wiederverwendbar für alle Speicherbatterien. Der PR konzentrierte sich auf Solarbatterien, aber wir können durchaus beide Fälle abdecken.
Und tatsächlich die Anmerkungen von GPT5.6.
Ich aktualisiere den PR in diesem Sinne.
Zur Information:
Generische Namen (keine Zendure-Begriffe), abgestimmt auf VE/Gladys.
Ladezustand
| Typ | Bedeutung | Einheit |
|---|---|---|
battery-level |
Ladezustand | percent |
Leistungen (momentan, ≥ 0)
| Typ | Bedeutung | Einheit |
|---|---|---|
charge-power |
Leistung, die in die Batterie eintritt | watt / kilowatt |
discharge-power |
Leistung, die aus der Batterie austritt | watt / kilowatt |
solar-input-power |
PV-Eingang | watt / kilowatt |
output-power |
Gesamtleistung zum Haus (PV direkt + Entladung) | watt / kilowatt |
grid-power |
Netzimport | watt / kilowatt |
off-grid-power |
Ausgang außerhalb des Netzes (Notstrom) | watt / kilowatt |
Energie (kumulierte Zähler) + Zustand
| Typ | Bedeutung | Einheit |
|---|---|---|
charge-energy |
Gesamtenergie, die geladen wurde | kilowatt-hour |
discharge-energy |
Gesamtenergie, die entladen wurde | kilowatt-hour |
solar-energy |
Gesamt-Solarenergie | kilowatt-hour |
output-energy |
Gesamtenergie, die dem Haus zugeführt wurde | kilowatt-hour |
grid-energy |
Gesamtenergie, die importiert wurde | kilowatt-hour |
off-grid-energy |
Gesamtenergie, die außerhalb des Netzes ausgegeben wurde | kilowatt-hour |
available-energy |
Aktuell verfügbare Energie (momentan) | kilowatt-hour |
→ UNITS_BY_CATEGORY['battery-storage'] = [PERCENT, WATT, KILOWATT, WATT_HOUR, KILOWATT_HOUR], Standard nach Typ: percent (level), watt (Leistungen), kilowatt-hour (Energie) — was den Fallback-Punkt des Reviewers löst. Und Kategorie zu isSensorCategory hinzugefügt.
- Integration-Store mit dem neuen Manifest-Format aktualisiert, also kannst du loslegen @Terdious, wenn du Tuya oder Zendure veröffentlichen möchtest
- SDK auf v0.5.0 aktualisiert ( Changelogs )
- JS-Template mit dem SDK v0.5.0 aktualisiert
- Gladys in #2665 aktualisiert mit allen neuesten Funktionen und einem Fix für den „Update erzwingen“-Button
Zögere nicht, wenn du Fragen hast
Kleine Neuerung, um nicht eine Stunde zwischen jedem Durchlauf des Integrations-Store warten zu müssen, habe ich ein kleines npx-Tool erstellt, um lokal zu validieren (oder deinen KI-Agenten die Validierung durchführen zu lassen), ob eine Integration die Validierungsregeln besteht:
npx github:GladysAssistant/integration-store
Mehr dazu im README des Stores.
Ich aktualisiere die JS-Vorlage.
@Terdious, fehlt dir noch etwas für Zendure, Tuya, Netatmo, Shelly oder andere Integrationen?
Mein Ziel ist es, eine erste V1 nächste Woche zu veröffentlichen. Die Idee ist natürlich nicht, alle Fälle von Anfang an abzudecken, sondern eine solide Basis zu haben, auf der wir iterieren können. Wenn wir bereits einige Integrationen zu diesem Zeitpunkt anbieten können, wäre das wirklich großartig! 
« Wir » denken, dass ja !! Zumindest für die V1 ohne Zweifel ^^ Vielen Dank !!
Natürlich bin ich mir dessen bewusst, es wäre ohnehin unmöglich, alle aktuellen und zukünftigen Anforderungen ohne Iteration zu bestimmen ^^
Ich denke, dass für eine V1 alles, was bereits vorgeschlagen wurde, ausreicht! Der Beweis, ich bekomme praktisch alles zum Laufen!!
Hör mal, ich bin auf SDK 0.5.0, und es funktioniert!!^^
Nun, es gab einige Änderungen in der Zwischenzeit, also gehe ich davon aus, dass es auf unserer Seite lag. UDP funktioniert auf 6 von 10 Geräten und die anderen müssen manuell hinzugefügt werden. Und das war bereits bei der Tuya Core-Integration der Fall, also sind wir gut!!
Edit: Okay, das war ich, jetzt übergebe ich das Wort an Claude 
Das ist ja mal schlau, das gibt mir wieder Arbeit 
:
JA, ich habe das SDK 0.5.0 vollständig gelesen (über deinen Fork, in meinem Bereich) — und es ist enorm: PG hat fast alles, was wir besprochen haben, industrialisiert. Drei Game-Changer, die unsere Roadmap direkt betreffen:
| Neuheit SDK 0.5.0 | Was es bewirkt | Löst |
|---|---|---|
publishTransports() + DEVICE_TRANSPORTS + Manifest transports:["local","cloud"] |
Lokal/Cloud/Nicht erreichbar-Badge pro Gerät (Aufkleber) vom Core gerendert; und wenn beide Kanäle deklariert sind, zeigt der Core einen Standard-Toggle « Lokale Verbindung bevorzugen » als reservierten Schlüssel GLADYS_PREFER_LOCAL an |
#8 + unser Punkt 3 (unser benutzerdefiniertes local_mode wird standardmäßig!) — das ist genau das, was wir PG argumentiert haben |
publishDiscoveredDevices führt nun ein UPSERT der Parameter eines bereits erstellten Geräts (IP DHCP ändert sich, Cloud→Lokal…) ohne Name/Merkmale zu berühren; eine Strukturänderung zeigt die Schaltfläche « Aktualisieren » an |
Keine Notwendigkeit, zu löschen/neu zu erstellen | C (das Fehlen von « update params ») + der DHCP-Churn |
Manifest actions + onAction(key, cb) mit dem Beispiel detect_protocol (manuell eingegebene IP → Protokollerkennung, timeout_seconds bis zu 120 s) |
Aktionsschaltfläche mit angezeigtem Ergebnis | #7 (Geräte, die nicht vom UDP erkannt werden: manuelle IP + Erkennung) |
Bonus verfügbar: onGetImage/publishCameraImage (Kameras/Klingeln), OAuth2 (onOAuthAuthorizeUrl/onOAuthCallback, Netatmo-Stil), Sub-Container (getContainers/startContainer + onHardwareUpdated), setConnectionStatus (Anwendungsverbindungsstatus).
Was das für uns bedeutet (groß, aber im guten Sinne)
Wir sollten auf das Standardmodell migrieren:
- unsere benutzerdefinierte Konfiguration
local_modedurchtransports:["local","cloud"]+ Lesen vonGLADYS_PREFER_LOCALersetzen (mein Modell « toggle live » von vorhin lässt sich direkt daran anschließen); publishTransportsbei jedem Poll aufrufen, um das lokale/Cloud/nicht erreichbare Badge anzuzeigen (und unseren Circuit-Breaker →unreachable);- die Aktion
detect_protocolfür nicht gescannte Geräte hinzufügen; - von der Upsert der Parameter profitieren: Unser Re-Scan beim Toggle aktualisiert jetzt wirklich die bestehenden Geräte (inklusive IP) → wir können den Workaround
resolveDevice/mergeParams langfristig entfernen.
ABER das hängt davon ab, was der Core-Zweig, den du ausführst, tatsächlich implementiert (Transports, GLADYS_PREFER_LOCAL, onAction, Upsert). Bevor wir migrieren, möchte ich deinen Core lesen.
Ausgezeichnet !! 
Ich wäre sehr neugierig auf dein Feedback zu Netatmo und Frigate danach
Netatmo sollte abgedeckt sein, es gibt eine ganze OAuth-Verwaltung.
Frigate wird ebenfalls verwaltet, mit einer Verwaltung von Subcontainern.
@ProtZ ich denke, die Nuki-Integration könnte eine externe Integration werden
@cicoub13 Gleiches gilt für TP-Link!
@bertrandda mal sehen, was wir für Airplay und Google Cast machen
Für alle, die die externen Integrationen testen möchten, hier ein Docker-Build (nur amd64):
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2
Das Image wird automatisch mit allen Entwicklungen aktualisiert, die ich mache
Die Dokumentation ist auf dem neuesten Stand!
Auf Französisch:
Auf Englisch:
Bravo für die ganze Arbeit an dieser Architektur, die viele Welten freischaltet
Es gibt nur ein Detail, das mich stört 
Früher wurde eine Integration, die von jemandem entwickelt wurde, in Gladys integriert und andere Entwickler oder du @pierre-gilles konnten kommen, um einen Fix oder eine Weiterentwicklung vorzunehmen, wenn der Hauptentwickler keine Zeit hatte oder nicht mehr antwortete.
In der Zukunft, mit diesen externen Integrationen, was passiert, wenn eine Integration nicht mehr gewartet wird? Wird sie unbrauchbar? Muss man ein Fork machen und die Leute manuell migrieren lassen?
Und eine Bonusfrage? Wie entscheidet man, ob eine Integration extern oder intern sein soll?
Ja, man kann sich in diesem Fall durchaus einen Fork vorstellen. Und wenn eine Integration sehr weit verbreitet ist und eine echte Nachfrage nach einer vereinfachten Migration besteht, können wir einen Migrationsprozess in Betracht ziehen, um die Benutzer zu unterstützen.
Die Idee ist auch, dass die Community eine veraltete Integration leicht übernehmen kann: Da alles offen und vom Kern entkoppelt ist, liegt die Wartung nicht mehr allein bei mir.
Abgesehen von wirklich „universellen“ Integrationen (Matter, Zigbee, MQTT…), finde ich, dass fast alles, was extern sein kann, es auch sein sollte.
Was mich am meisten an diesem neuen System überrascht, ist, wie sehr die Benutzererfahrung mit einer nativen Integration identisch ist. Mit Fable 5 haben wir es geschafft, eine Erfahrung zu schaffen, bei der es für den Benutzer kaum einen Unterschied zwischen einer internen und einer externen Integration gibt.
Andererseits ist der Unterschied für das Projekt enorm: Beiträge können parallel erstellt werden, ohne meine Zeit in Anspruch zu nehmen, und die Erfahrung ist zwischen den Integrationen standardisiert.
Ehrlich gesagt, würde es mich nicht überraschen, wenn wir in den kommenden Monaten dank dieses Ansatzes auf mehrere hundert Integrationen kommen würden.
OK, danke für die Antworten.
Ich habe etwas Angst vor der Qualität der externen Integrationen und damit vor dem Nutzererlebnis in Bezug auf Gladys. Eine der Stärken von Gladys ist ihre Stabilität.
Auch wenn die Installation durch Verweisen auf ein externes Repo erfolgt (und die Docker-Container gesichert sind, um die Gladys-Instanz nicht zu beeinflussen), werden die Nutzer hierher kommen und sagen, Gladys funktioniert nicht.
HA hat ein System zur Bewertung von Integrationen eingerichtet, um die Nutzer über deren Qualität zu informieren. Gehen wir auch in diese Richtung?
Das ist eine berechtigte Sorge, und man muss hier tatsächlich wachsam sein. Aber heute haben wir eher das gegenteilige Problem: den Mangel an Integrationen 
Seit Beginn der v4 ist das wahrscheinlich der häufigste Kritikpunkt: Viele Nutzer würden gerne Gladys verwenden, aber ihre Geräte werden einfach nicht unterstützt.
Langfristig, wenn wir es schaffen, Hunderte von externen Integrationen zu haben, denke ich, dass wir tatsächlich Mechanismen einführen müssen, um den Nutzern bei der Auswahl zu helfen: Bewertungen, Kommentare, Wartungsindikatoren, Anzahl der Nutzer, zuletzt veröffentlichte Version usw.
Aber lasst uns nicht das Pferd vor die Karre spannen 
Die Priorität heute ist es, ein viel breiteres Integrations-Ökosystem zu haben. Dann können wir die notwendigen Tools aufbauen, um eine gute Gesamtqualität zu erhalten.
Okay, ich bin mit den Integrationen vom Typ „Kommunikation“ (z. B. Telegram) weitergekommen, und das ist in der SDK v0.6.0 verfügbar.
Ich habe gerade die Telegram-Integration mit Fable in einem Rutsch portiert, und es funktioniert perfekt.
Ich finde sogar, dass die Erfahrung besser ist als mit der Integration, die wir in Gladys haben
Das GitHub-Repo:
Könnte man einen Build für ARM v8 haben?