Ich habe es gerade versucht, aber die Widgets funktionieren nicht.
In den Logs sieht man nichts Besonderes, aber es werden die Stationen und die Preise korrekt abgerufen.
Hast du die Widgets richtig konfiguriert?
Kannst du einen Screenshot deiner Konfiguration machen, bitte, und eventuell die sensiblen Elemente ausblenden?
Bist du auf der Integration bei 2.0.5?
Ist Gladys bei 5.1.1?
Bei mir gibt es keine Probleme mit den Widgets
Für die Versionen ist alles gut.
Für die Konfigurationseinrichtung, willst du die Integration oder das Widget?
Für die Konfiguration gibt es nichts Besonderes, also würde ich sagen, ja, ich habe sie richtig konfiguriert.
Alles 
Damit ich es auf meiner Entwicklungsinstanz reproduzieren kann 
Bearbeitung: Falls sensible Informationen, bitte privat schicken
Es funktioniert, aber es war nötig, die Integration zu deinstallieren und neu zu installieren.
Ok, notiert. Ich schicke es heute Nachmittag an Claude, um zu sehen, ob er einen Bug findet
Danke
ich habe drei Häuser erstellt und finde ‹ Mein Haus in Gladys ›, ich sollte die drei finden …
Vorschau der nahegelegenen Stationen schlägt fehl …
Ich habe gelöscht und dann neu erstellt, aufgrund der Versionsstufe…
Hier ist die Rückmeldung von Claude :
- « Die Widget-Daten sind nicht verfügbar »
Ursache (im Gladys-Code überprüft): Der Kern wartet 15 s auf die Bestätigung von widget.get (WIDGET_GET_TIMEOUT_MS). Danach löscht die Frontend-Komponente (ExternalWidgetBox.jsx):
den bereits angezeigten Inhalt, zeigt « Daten nicht verfügbar » ohne weitere Details an, plant keinen erneuten Versuch → die Karte bleibt tot, bis das Dashboard neu geladen wird (daher die Neuinstallation).Auf einem kalten Container überschreitet man leicht 15 s: 2 Karten, die gleichzeitig ziehen, die konzentrische Suche (1 Anfrage pro Ring, jedes mit 15 s Timeout), die Geocodierung der Postleitzahl, die Stationsnamen (2 weitere Datensätze).
Korrektur:
getWidgetContent hat sein eigenes Timeout von 9 s; danach gibt es eine Karte « Open-Data-Fluss wird gelesen… » mit einem TTL von 15 s zurück, während der echte Pull weiterläuft und den Cache füllt → die Karte füllt sich beim nächsten Pull von selbst. Ein echter Fehler bleibt ein Fehler (der Kern zeigt ihn dem Benutzer an): Nur das fehlende ACK war stumm. stationStore.search teilt sein Versprechen im Flug: 2 Karten = 1 Suche statt 2.
- Die Rundungen
Das ist Gladys, nicht die Integration, und an zwei Stellen:
Kachel mit einer Zahl → formatNumber mit maximumFractionDigits: 2 Kachel, die mit einem Gerät verknüpft ist → DeviceFeatureValueText → Math.round(v * 10) / 10 → 1 DezimalstelleDas ist der zweite Fall auf deinem Screenshot: 1,699 wird im Widget zu 1,7, auf der Geräteseite bleibt es 1,699.
Korrektur: Alle Preiskacheln senden nun von uns formatierten Text (1,699), in der vom Kern gesendeten Sprache. Abgewogen: Die Karte « Meine Station » verliert die Live-Verbindung zum Gerät — aber notifyWidgetsChanged zwingt den Kern bereits, die Karte nach jedem Durchlauf zu entfernen, der einen Preis bewegt.
Falls gewünscht, kann man melden: DeviceFeatureValueText, das auf 1 Dezimalstelle rundet, ist fragwürdig für jeden präzisen Sensor.
3. Mehrere HäuserDer Kern kann dynamische Optionen eines Selects nur für Geräte auflösen (SELECT_SOURCES = [‹ devices ›]) — kein Manifest kann Häuser auflisten.
Korrektur:
house.js speichert nun alle lokalisierten Häuser (es speicherte nur eines). Neues Konfigurationsfeld « Welches Haus » (freier Text, optional): Name wird ohne Groß-/Kleinschreibung und Akzente verglichen, leer = das erste lokalisierte. Der Button « Stationsvorschau » zeigt das verwendete Haus + die Liste der von Gladys bekannten Häuser an, um zu wissen, was man eingeben soll. Nur die Namen, niemals die Koordinaten.
Alles sollte in Version 2.0.6 behoben sein, die gerade veröffentlicht wurde
Heute Abend scheint alles in Ordnung zu sein, Haus für Haus.
Einfach sind sie in den Einstellungen zugänglich und es gäbe keine Möglichkeit, eine Listenbereich zu erstellen?.. OK, das ist Komfort.
Für mich ist es im Prinzip alles gut… bravo.
Nach dieser Testphase gehe ich zurück zu den Kraftstoffen, die ich normalerweise verwende.
Normalerweise gehe ich zu dieser Tankstelle, aber sie verkaufen nur SP98:
• TotalEnergies - 104/106 AV MEDERIC - Noisy-le-Grand (1,6 km) — Diesel: 2,250 EUR/L, SP98: nicht verfügbar, E10 (SP95-E10): nicht verfügbar…
Danke
Es ist in der nächsten Version (2.0.7) behoben:
Du hattest recht: Deine Tankstelle verkauft SP98. Sie zeigte „nicht verkauft“ an, weil ein Datenloch vorlag, das die Integration falsch gelesen hat. Das ist behoben und auf
claude/quirky-hypatia-59syh1gepusht.Was passiert ist
- Gestern sagte die nationale Datei „SP98 seit dem 21/09 vorübergehend nicht verfügbar“.
- Heute gibt der Datenstrom nichts mehr für SP98 an: weder Preis noch Lieferengpass. Die Tankstelle hat wahrscheinlich ihren Lieferengpass aufgehoben, ohne den Preis wieder einzustellen.
- Die Integration las dieses „nichts“ als „nicht verkauft“.
Korrektur
- Wenn der Datenstrom nichts über einen Kraftstoff angibt, schaut die Integration jetzt in die Preishistorie der letzten 30 Tage (öffentliche Daten
prix-des-carburants-j-1).- Wenn die Tankstelle in diesem Zeitraum einen Preis für diesen Kraftstoff angezeigt hat, wird er als „nicht verfügbar“ statt „nicht verkauft“ markiert.
- Eine „endgültige“ Lieferengpassmeldung der Tankstelle wird nie in Frage gestellt.
- Wenn die Historie nicht antwortet, passiert nichts: Es wird das belassen, was der Datenstrom sagt.
- Die Antwort wird 6 Stunden lang im Speicher gehalten, also keine zusätzlichen Anfragen bei jedem Aktualisieren.
- Code in src/countries/franceRecent.js, eingebunden in src/countries/france.js.
Überprüft an deiner Tankstelle (93160009)
- Vorher: SP98 nicht verkauft.
- Nachher: SP98 nicht verfügbar. Gleiches gilt für E10, das aktuell wirklich nicht verfügbar ist.
- Alle Tests sind bestanden (4 neue), ebenso wie der Lint und das Format. Die Dokumentation FR/EN und
CLAUDE.mdsind aktuell.Zu beachten
- Auf dem Gerät wird der Text „Nicht verfügbar“ angezeigt, ohne Datum, weil der Datenstrom in diesem Fall keins angibt.
- Sobald die Tankstelle den SP98-Preis wieder anzeigt, wird er normal angezeigt.
Danke für diese neue Version mit Widgets/Auslösern: Das Widget „die günstigsten“ und der Auslöser „die günstigste Tankstelle hat sich geändert“ sind gerade jetzt wirklich sehr nützlich
Frage: Könnte man die Anzeige der Tankstellennamen je nach verfügbarem Platz auf dem verwendeten Bildschirm anpassen?
Am PC
Am Handy:
Okay, ich denke, die beste Lösung wäre, dass Gladys die aktuelle Bildschirmbreite sendet und der Text sich entsprechend Option 3 anpasst. Aber ich verstehe, dass das eine Anforderung auf Kernel-Ebene ist.
Was Option 1 betrifft: Wenn ich das richtig verstehe, würde das bedeuten, ein Dashboard für PC und ein anderes für Mobilgeräte zu erstellen? Für mich ist das zu „aufwändig“ und das gefällt mir nicht!
Daher würde ich vorschlagen, dass wir in der Zwischenzeit einen Parameter für Option 3 hinzufügen: die Möglichkeit, die Anzahl der anzuzeigenden Zeichen einzustellen, denn das würde jedem ermöglichen, es an seine Bildschirme anzupassen (ich habe auf meinen PC-/Tablet-/Mobilgeräte-Bildschirmen noch Platz).