Der Bug ist behoben 
Ich habe gleichzeitig einen weiteren Bug gefunden, also wenn man die Adresse aktualisiert, wird stattdessen ein neues Gerät erstellt, anstatt das bestehende zu aktualisieren
Claude kümmert sich darum
Ich werde eine Release machen, sobald diese 2 Bugs behoben sind
Kann man den „Ort“ des Gladys-Hauses nicht abrufen?
Okay, wenn man zwei hat, wie würde das funktionieren? → man wählt den Ort über einen Selektor aus
de meinerseits habe ich auch zwei Orte, die ich im Auge behalten muss?
Genau das ist der Gedanke, den ich vor ein paar Minuten hatte
Ich werde Claude bitten, einen Button hinzuzufügen, um den Ort direkt in Gladys abzurufen und die Koordinaten zu injizieren
Und dann mehrere Orte erstellen zu können, mit einem Selektor in der Konfiguration
Bearbeitung: Wenn diese Integration gut abgeschlossen ist, kann ich dasselbe für Pollen, Luftqualität und UV-Index tun, was für jeden eine spezifische Integration wäre
Für den Teil der Abfrage der Koordinaten direkt in Gladys hat die KI Folgendes geantwortet:
1 & 2. Abfrage des Standorts des Gladys-Hauses — unmöglich, und es gibt keine Umgehungsmöglichkeit
Ich habe den Kern von Gladys geklont, um zu überprüfen, anstatt zu vermuten. Das Haus hat tatsächlich Koordinaten (server/models/house.js: latitude/longitude), aber nichts davon wird einem Integrationscontainer ausgesetzt:
Die Host-API der Integrationen (/api/integration/v1/*) hat genau 21 Routen (server/api/routes.js) — keine davon betrifft das Haus. getConfig() gibt nur die Konfiguration der Integration selbst zurück.
GET /api/v1/house ist authenticated: true, also ein JWT-Benutzer: session.validateAccessToken erfordert audience: 'user', während ein Integrations-Token audience: 'integration' trägt. Das Middleware sagt dies explizit — die beiden Öffentlichkeiten kreuzen sich nie.
Umgehungsweg über getDevices(): Die Antwort enthält tatsächlich room, aber getStandardDeviceIncludes() verschachtelt das Haus nicht — der Raum trägt nur eine house_id, ohne Koordinaten.
Der angeforderte Button würde also einen PR im Kern benötigen (eine GET-Route /api/integration/v1/house + eine SDK-Methode). Ich habe nichts auf dieser Seite implementiert, und ich habe die Feststellung in CLAUDE.md festgehalten, damit dies nicht erneut erlernt wird.
Ich weiß nicht, ob @pierre-gilles die Änderung direkt im Kern vornehmen kann
Für den Teil der Erstellung mehrerer Orte werde ich heute Abend testen und wahrscheinlich eine 2.0.0 pushen, wenn die Tests erfolgreich sind.
Ich hatte einen Bug in Version 2.0.0-test, den ich in 2.0.1-test behoben habe.
Allerdings habe ich keine Dropdown-Liste mehr zur Auswahl der Orte, die ich in 2.0.1-test hatte.
Ich habe auch keinen Token mehr und das nächste Zurücksetzen ist um 00:00 Uhr, also mache ich später weiter
Ich werde ab Version 1.2.0 mit der Version 2 und der Verwaltung mehrerer Standorte weitermachen 
Ich hatte ein paar kleine Probleme, als ich Claude mit der ersten Version der v2 arbeiten ließ 
Ich halte euch auf dem Laufenden, wenn sie veröffentlicht wird 
Die V2 ist verfügbar mit der Verwaltung mehrerer Orte 
Ich konnte nicht jeden Ort anzeigen lassen, also habe ich mein Bestes gegeben, wie im Screenshot:
Hier ist der Grund, den claude angegeben hat:
Warum ein Ort pro Zeile unmöglich ist
Der Zeilenumbruch wird gesendet — ein echter \n — und man sieht ihn in den Container-Logs. Es ist der Konfigurationsbildschirm von Gladys, der ihn „frisst“, aus drei kumulativen Gründen:
ActionsCard.jsxrendert die Antwort als<div class="alert alert-success">{getLocalizedText(...)}</div>: ein Text-Child von React. Jegliche Markierung wird entkommen, daher sind weder<br>noch<pre>möglich.- In HTML ist ein
\nim Text ein Leerzeichen, es sei denn, das CSS sagtwhite-space: pre-wrap. Weder das CSS von Gladys noch das.alertvon Tabler setzen es (das einzigepre-wrapim gesamten Frontend der externen Integrationen befindet sich auf der LOGS-Seite). - Die Unicode-Trennzeichen U+2028 / U+2029, die die CSS-Spezifikation als erzwungene Zeilenumbrüche beschreibt, wurden in Chromium gemessen: Sie werden ebenfalls zusammengefasst.
Überprüft am Tag v4.84.4 und auf master. Es gibt also nichts anderes zu senden: Der Fix ist eine CSS-Regel in einer Zeile im Kern von Gladys, nicht etwas, das diese Integration liefern kann. Daher das „•“, das jeden Eintrag eröffnet: Es ist das, was die Liste lesbar hält, wenn alles auf einer Zeile zusammengedrückt wird — eine nackte Nummer geht zwischen einer Postleitzahl und zwei Koordinaten verloren, ein „•“ kann nicht in einer Adresse auftauchen.
Ich habe 2 Feature-Anfragen erstellt, um die Integration zu verbessern :
Dumme Frage, aber warum holst du nicht den Standort des Hauses, den Gladys bereits kennt?
Soweit ich weiß, haben wir ihr ihren Standort angegeben, also sollte Gladys bereits die Breiten- und Längengrade des Hauses haben, oder?
Ah, ich habe gesehen, dass das nach meinem Fehler gesagt wurde, weil ich nicht alles gelesen habe ^^’
Ich bin bei 4.85 und der Zeilenumbruch wird nicht gemacht
Ich habe es gerade mit der Version 2.0.0 von Vigieau und Gladys 4.85 noch einmal getestet und alles funktioniert sowohl auf meinem Gladys-Dev- als auch auf meinem Gladys-Prod-System.
Kannst du es im privaten Modus testen, um sicherzugehen, dass es nicht am Cache liegt?
Ja, du hast recht, das war ein Cache-Problem, danke!
Alles läuft bei mir, danke @prohand !!!
Die neue Version 2.0.1 enthält die von Gladys bekannten Häuser:
Bald verfügbar nach dieser Nachricht
Version 3 ist verfügbar mit Widgets, Auslösern und Aktionen