Grafana-Grafiken mit Raspberry Pi 4 auf 2 Monitoren und Browser autostart / fullscreen

@clemens das keine .map Dateien existieren ist jetzt nix schlimmes und auch irrelevant. Hast meine Version auch probiert?

Hallo Hannes,

Vielen Dank für Deine Demo. Ich kann beobachten, dass die Ressource von Grafana scheinbar drei mal geladen wird.

Das trägt noch ein wenig auf, daher ist die gefühlte Ladezeit leider nicht ganz so snappy. Ist es möglich, dass da unter der Haube noch ein Problem besteht?

Viele Grüße,
Andreas.

Hallo Andreas,

das kommt davon das ich Preloaden versuche, was aber nicht wirklich funktioniert. Ich kann die Preloader entfernen. “Snappy” wird es aber nie sein, weil ich immer eine aktuelle Version des IFrames generiere und nicht so wie die andere Demo alles auf einmal reinlade. Dafür ist meine Version immer aktuell. Die Frage ist was hier gewollt ist.

Cheers
Hannes

Ja, das hatte mir Lars auch schon geschrieben. Er hat weiter nichts gefunden und schreibt:

Habe mich jetzt nochmal über 1 Std lang wundgetestet und kann meinerseits einfach keinen der beschriebenen Fehler reproduzieren.
Einzig Chrome und Chromium (linux und mac) im incognito Modus geben mir
"If you’re seeing this Grafana has failed to load its application files

  1. This could be caused by your reverse proxy settings.
  2. If you host grafana under subpath make sure your grafana.ini root_url setting includes subpath
  3. If you have a local dev build make sure you build frontend using: yarn start, yarn start:hot, or yarn build
  4. Sometimes restarting grafana-server can help"

weiter

Auffällig ist dann noch, das heute morgen das Laden der einzelnen iframes ziemlich zügig ist im Vergleich zu gestern Abend. Habt ihr zwischenzeitlich was neu gestartet?

Afaik hat aber niemand was gemacht oder gab es einen (automatischen) restart in der Nacht?

Demo von Hannes

Ja, wahrscheinlich ist es besser, diesen Teil zu entfernen, wenn er ohnehin nicht funktioniert. Dann wird auch diese Variante schneller laden.

Seitenblicke

Bei Versuchsaufbau "Autonome Zelle" #1 & #2: Solar-Feinstaub-Wetter-Vergleichsding, Autonome Zelle #3: Bodentemperaturen mit CubeCell, DS18B20, Solar & LoRa oder anderswo funktionieren die eingebetteten Grafana Panels einwandfrei, nicht?

Proof

Mit einem ganz einfachen iframe HTML code.

<iframe src="https://weather.hiveeyes.org/grafana/d-solo/az3htccab01/3-cubecell-bodentemperaturen?orgId=1&refresh=5m&panelId=35&from=now-24h&to=now" width="100%" height="250" frameborder="0"></iframe>

Bei Hiveeyes - Kotori DAQ funktionieren die eingebetteten Panels derzeit auch nicht. Ich habe dort jeoch noch nicht nach der Ursache geschaut, vielleicht erlangen wir dadurch irgendwelche weiteren Erkenntnisse in dem Bereich.

Grafana Upgrade?

Wir können noch versuchen, auf einer parallelen URL Grafana 7 oder 8 zur Verfügung zu stellen. Vielleicht klappt es damit besser. Grafana 6 hat ja nun doch schon ein paar Jahre auf dem Buckel, in denen sich die Browser ordentlich weiterentwickelt haben.

Matthias hat nochmal die RasPis vor Ort beobachtet und das geschickt:

Ich sehe da aber keine eindeutige Systematik.

Hannes, danke für deine Version!

Ja, hatte ich auch verwendet, ähliches Verhalten wie die von Lars: Im “normalen” Browser geöffnet funktioniert es, über das Skript nicht.

Wenn wir die Dinger 1x laden und dann die nächsten 12 bis 24 Stunden anzeigen wäre das schon ganz gut. Wir zeigen aktuell 14 Tage an, da wird es nicht auffallen wenn ein paar “live” Stunden fehlen und die Rechner müssen nicht ständig im Netz sein – ich weiß nicht wie stabil das vor Ort ist.

Vielleicht habe ich den Übeltäter gefunden, aber noch keine Lösung! Das spezifizierte user profile / path scheint mit unseren Problemen zusammen zu hängen. Ich gebe beim Start von Chromium mit --user-data-dir=/tmp/browser2 einen Profil-Path an, hier der ganze Aufruf:

@chromium-browser --disable-infobars --app=https://beedao.zku-berlin.org/hive.html#yy --user-data-dir=/tmp/browser2 --window-position=1281,0 --kiosk --noerrdialogs --disable-session-crashed-bubble

Ohne den Parameter --user-data-dir scheint es besser zu gehen und die Seiten werden geladen!! Ich brauche aber laut Autostart mehrere Chromium-Fenster positionieren - Allgemeine Software - Deutsches Raspberry Pi Forum diesen Parameter zwingend, da ich nur damit zwei Browserfenster in zwei unterschiedlichen Monitoren aufmachen kann.

Was ich jetzt (ohne Erfolg) versucht habe:

  • /tmp/browser2 auf 777 gesetzt
  • statt des Pfads oben den default vorhande user angegeben (nur testweise, produktiv brauche ich ja zwei)
    --user-data-dir=/home/pi/.config/chromium/Default
  • die config / den Inhalt von --user-data-dir=/home/pi/.config/chromium/Default nach /tmp/browser2 kopiert, um ggf. vorhandene andere defailt-Einstellungen zu verwenden
  • das Verzeichnis /tmp/browser2 ist da und wurde automatisch angelegt und es stehen auch Dinge drin, mangelnde Rechte, meine ich, sollten es nicht sein.

Irgendwie scheint es als ob der Browser was (temporär) runterladen will und das nicht kann. Allerdings funktionierte das Skript ja mit https://www.documenta.de/ und https://www.zku-berlin.org/ als URLs, nur nicht mit unseren ollen Grafana-Panels.

Hier noch wie ich aktuell teste ich rufe über die bash die eine Skriptzeile auf und schaue dann was auf dem Raspi passiert

pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --user-data-dir=/tmp/browser1  --kiosk
[10783:10783:0615/120117.215616:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is 
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --user-data-dir=/home/pi/.config/chromium/Default  --kiosk
[10987:10987:0615/120210.277398:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is 
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk
Opening in existing browser session.
pi@raspberrypi:~ $ [11140:11140:0100/000000.081315:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is

Das macht dann natürlich sinn, habe jetzt eine andere Version hochgeladen:

https://btree.at/swarm/embed.html

Die sollte im Prinzip auch alle iFrames am Anfang laden.

Per view-source:https://beedao.zku-berlin.org/hive.html#02 sieht man jedoch, dass das iframe anders geladen wird. Irgendwie scheint JavaScript involviert zu sein.

<div class="slide" data-src="https://swarm.hiveeyes.org/grafana/d-solo/cx_KOvH7k/documenta-stockubersicht-and-bienenwetter?orgId=2&from=now-14d&to=now&var-beekeeper=hiveeyes_beecoin&var-measurement=documenta_hive_##HIVE##_sensors&var-COMMON_CDC_NAME=Schauenburg-Elgershausen&var-COMMON_MOSMIX_NAME=SCHAUENBURG-ELGERSH.&var-STATION=Schauenburg-Elgershausen&panelId=23">
<iframe src="" width="100%" height="100%" frameborder="0" loading="lazy"></iframe>
</div>

Dazu kommt, dass scheinbar alle Panels auf einer einzigen Seite untergebracht wurden. Das bedeutet wohl, dass jeweils alles geladen wird, obwohl Ihr doch anstrebt, auf dedizierten Monitoren nur einzelne Panels vollflächig anzuzeigen?

Ich weiß nicht, wozu Ihr bei diesem Anwendungsfall die Einbettungsgeschichte überhaupt braucht? Warum nicht einfach folgendes machen?

# URL definieren.
export URL_HIVE02_PANEL23="https://swarm.hiveeyes.org/grafana/d-solo/cx_KOvH7k/documenta-stockubersicht-and-bienenwetter?orgId=2&from=now-14d&to=now&var-beekeeper=hiveeyes_beecoin&var-measurement=documenta_hive_02_sensors&var-COMMON_CDC_NAME=Schauenburg-Elgershausen&var-COMMON_MOSMIX_NAME=SCHAUENBURG-ELGERSH.&var-STATION=Schauenburg-Elgershausen&panelId=23"

# Browser öffnen.
chromium-browser "$URL_HIVE02_PANEL23" lalala

Hi Andreas, wie gerade telefonisch angeteasert: Könntest du mal schauen, ob auf dem Mac in der Konsole das einen Unterschied macht

chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk

vs.

chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --user-data-dir=/tmp/browser1 --kiosk

Auf dem RasPi funktioniert ersteres, zweites mit --user-data-dir nicht!

Ich habe es gerade mit dem RasPi 1x im Autostart getestet und ich bekomme ohne path-Angabe

Loading & initializing dashboard

mit user-path passiert – wie bei der Version von Lars – nix.

Im Browser über die Adresszeile aufgerufen funktioniert es!

Glaube es problem ist, dass Grafana irgendwo in den LocalStorage schreiben möchte, das aber nicht erlaubt ist und Grafana hat keinen schönen “catch” call um das abzufangen.

Jup, könnte mir gut Vorstellen das des der Übeltäter ist. Wenn window.localStorage nicht existiert wird er einen Fehler werfen.

Edit1: Flags in Chromium habe ich nur gefunden für disablen von LocalStorage aber es gibt diese Flag hier --mojo-local-storage “Use a Mojo-based LocalStorage implementation.”, aber keine Ahnung a) was das ist und b) ob sowas helfen könnte.

Edit2: Problem ist anscheinend auch bekannt: Support anonymous access with cookies/localstorage is disabled · Issue #15884 · grafana/grafana · GitHub

2 Likes

Servus Hannes,

Das ist ein sehr guter Fund. Ich denke auch dass das die Ursache ist. Die Diskussion dazu bei Grafana geht bei Storage: Improve local storage error handling · Issue #40434 · grafana/grafana · GitHub ff. weiter. Scheinbar ist das Problem aber in Grafana 8 immer noch vorhanden, daher würde uns ein Upgrade also nichts bringen.

@clemens: Eine Möglichkeit wäre, zu Firefox rüberzuwechseln?

Viele Grüße,
Andreas.

Was mich wundert, dass es ja funktioniert, wenn ich es “normal” im Browser aufrufe, oder über chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk da funktioniert es ja, nur nicht mit einem spezifizierten --user-data-dir=/tmp/browser1

Das würde ja bedeuten, dass der default user LocalStorage allocaten kann, ein anderer aber nicht. Nun ist die Frage warum nicht? Braucht er besondere Rechte, wo kann man das einstellen … oder ist es “nur” ein bug?

Du könntest versuchen den standard user dir path zu kopieren für den zweiten browser, könnte mir vorstellen er erstellt die sql dateien nicht.

Edit: Default Locations: User Data Directory

Edit2: Und ja scheint ein Bug zu sein puppeteer was auch chromium benützt hat auch das problem LocalStorage is missing in userdataDir when using headless mode · Issue #5612 · puppeteer/puppeteer · GitHub

1 Like

Oder versuche doch einmal, das Profil-Verzeichnis im gleichen Hauptverzeichnis wie “vanilla” unterzubringen, also unterhalb von ~/.config [1]. Ich könnte mir vorstellen, dass irgendwo bei Chrome, oder durch Linux, fortschrittliche Sandbox Funktionalitäten realisiert sind, die einen entsprechenden Zugriff nicht beliebig erlauben. Vielleicht gerade eben unter /tmp nicht.

Muss aber auch nicht sein, auch das sind nur Vermutungen.


  1. Chromium Docs - User Data Directory ↩︎

Laut chrome://version/ in der Adresszeile von Chromium eingegeben ist der Profile Path /home/pi/.config/chromium/Default selbst wenn ich den explizit spezifiziere via:

chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk --user-data-dir=/home/pi/.config/chromium/Default

funktioniert es nicht,

Wenn ich statt dessen --user-data-dir=/home/pi/.config/chromium/ verwende (ohne Default) geht es??! Mit --user-data-dir=/home/pi/.config/chromium2/ oder --user-data-dir=/home/pi/.config/chromium/browser1 geht es wieder nicht! --mojo-local-storage brachte nichts.

Agrrr!

[edit] ich hatte gestern schon den Inhalt von /home/pi/.config/chromium/Default nach /tmp/browser1/ kopiert, was nichts brachte. Nun – mit der Erkenntnis von oben nochmal

den Inhalt von

  • /home/pi/.config/chromium/ (ohne Default) nach
    /tmp/browser1/

kopiert, und es funktioniert! Boah! Jetzt wäre nur noch schön zu wissen, ob es eine config-Opton ist die gezwickt hat oder tatsächlich eine Datei, die nicht angelegt werden konnte / durfte.

[edit2] Das Verzeichnis Default ist nicht das user dir, sondern laut Chromium Docs - User Data Directory

  1. The user data directory is the parent of the profile directory.

Dazu gibt es ein ticket: Grafana embeds not working in Chromium/Chrome incognito window · Issue #33610 · grafana/grafana · GitHub

Fein! Andere [1] verwenden ganz einfach ein jeweils neu angelegtes temporäres Verzeichnis als Profilverzeichnis.

--user-data-dir=$(mktemp -d)

So wäre es eigentlich am besten, damit muss a) nichts vorbereitet werden (Profil umkopieren WTF!?) und b) kann auch nix schlimmes kaputtgehen, wenn es beim nächsten Mal ohnehin wieder neu erzeugt wird.


  1. Open google chrome (all users installation) in kiosk mode from terminal - Stack Overflow ↩︎

1 Like

Ne, mit einem leeren funtioniert es ja nicht, momentan tuts nur wenn ich die Sachen von /home/pi/.config/chromium/ ins neu angelegt Verzeichnis kopiere,