Anzeige der Daten auf einem e-Paper Display

Hi Michael,

alles neu macht der Mai – hierzu ein paar Updates von meiner Seite.

Repository

Stattdessen habe ich nun ein eigenes Repository angelegt und mit einer Build-Umgebung auf Basis von PlatformIO ausgestattet. So kannst Du wunderbar mit mehreren Dateien im Editor Deiner Wahl arbeiten. Ich hoffe das klappt auch mit WSL.

https://github.com/hiveeyes/hiveeyes-epaper-display

Abhängigkeiten

Der Code im Repository GitHub - G6EJD/ESP32-e-Paper-Weather-Display: An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground data via their API and then displays the weather ist ja eigentlich eine Bibliothek und wurde nun neben den anderen Abhängigkeiten auch entsprechend eingebunden.

HTTP-Client für Hiveeyes Datenexportschnittstelle

Diese Schnipsel wurden nun auch bereits hinzugefügt, siehe lib/hiveeyes.

Konfigurationsdatei

Die gibt es nun ebenfalls bereits im Repository:

Anleitung

git clone git@github.com:hiveeyes/hiveeyes-epaper-display.git
cd hiveeyes-epaper-display
make

Ich hoffe das hilft Dir ordentlich weiter. Happy hacking!

Viele Grüße,
Andreas.

1 Like

Backlog

Diese beiden Dinge müssten noch erledigt werden, damit das Gesamtsystem bestehend aus “Datenlogger -> DAQ-Backend -> Anzeige-Panel” robuster und wartungsärmer wird.

Wenn Euch weitere Details dazu einfallen, freuen wir uns über entsprechende Rückmeldungen.

Vielen Dank für die super vorarbeit.

Nochmal ein paar Gedanken zur Verbesserung des data export Interface
Bei der swarmAPI würde ich mir noch einen Counter Wünschen. Bei api.openweathermap.org z.B. gibt es bei forecast soetwas.
Mit “&cnt= 10” gibt sie die letzten 10 Datensätze beginnend mit dem neuesten aus.
Das könnte in Kotori noch relativ simpel zu realisieren sein.
Wenn man dieses jetzt noch mit "&from= " und "&to= " wäre es auch möglich, das man auch Daten von vor einem Monat relativ einfach abfragen kann.

Ein Problem welches ich habe ist, das aufgrund der extrem vielen Datensätze pro Tag, sehr viele Datensätze übertragen werden müssen, wenn man die akuellen Daten mit dem vor einem Tag zum selben Zeitpunkt vergleichen will.
Außerdem muß man immer einen relativ großen Zeitraum angeben fals der Sensor-Node mal für einen Zeitraum keine Daten gesendet hat. Man könnte sich zwar nach dem deserialize der .Json swar nur den letzten Datensatz und ersten Datensatz rausziehen, aber die .json ist doch extrem groß.

Das ist wahr.

Stimmt auch, das wäre alles easy zu realisieren.

Hier wird es eben komplizierter.

Genau, da wird der Speicher eines Embedded-Geräts explodieren. Außerdem ist es sehr ineffizient, die Daten erst zu übertragen und dann wieder zu verwerfen.

Wir brauchen für eine DWIM-Implementierung dann eben doch so etwas wie Downsampling. Das hatte ich versucht, in folgendem Ticket zu reflektieren:

Rationale

Bin jetzt Endlich ein wenig weiter. Ist zwar noch recht viel zu machen, aber ich möchte schon mal die ersten ergemisse mit euch teilen, und auch Fragen, ob jemand Ideen und Anregungen für die Anzeige hat.

RSSI und Die Batterieanzeige Funktionieren, Werde sie wohl Links und Rechts vom Beutennamen ohne Werte Anzeigen lassen.
Die 5 Kästchen darunter sind Die inneren Temp Sensoren. Der höchste Wert wird Ausgegeben und das entsprechende Kästchen ausgefüllt gezeichnet. Die Höhe der Kästchen wird von Min nach Max Größer.
Bei dem Graphen ist X, derzeit nur die Anzahl der Datensätze (Aktuell 25). Autoscale auf Y löst momentan noch nicht weit genug auf. Auch werden nicht genug Kommastellen angezeigt.

Werde gleich nochmal versuchen alles auf GIT hochzuladen. Aktuell steht GIT mit mir auf dem Kriegsfuß (SSH Probleme usw.).

Die leeren Flächen sind noch für weitere 2 Beuten gedacht.

3 Likes

Finde das Display ist momentan noch kein imkerliches. Die meteorologischen Daten sind sehr dominant, wenn man es nicht besser wüsste, sieht man eine Wetterstation. Gerade die Windrose ist mega dominant, was mich als Imker überhaupt nicht interessieren würde!

Gibt es nur die auf dem original Display zu sehenden Grafiken? Könnte man so was irgendwie einfach realisierten?

Ich bin da ganz bei Dir.
Die Wetterdaten sind zwar auch recht wichtig. Um z.B. abschätzen zu können ob man vieleicht doch jetzt oder erst später raus sollte.
Natürlich auch “Wetter” um die bessere Hälfte von so einem “nützlichem” Display und einer prominenten Platzierung im Haus zu überzeugen. :sweat_smile:
Habe aber vor das ganze Wetter noch zu stauchen.
Diese rieseige Windrose stört mich auch am meißten, wir sind ja nicht beim Segeln.
Ich schaue mal was die anderen Beispiele für kleinere Displays bei GitHub - G6EJD/ESP32-e-Paper-Weather-Display: An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground and displays the weather zu bieten haben. Leider sind da nicht immer Bilder dabei.
Das neu kleiner zu zeichnen ist sicher eine heiden Arbeit.

Denn in den vorgebauten Funktionen ist leider nicht überall ein einheitliches Offset, was den Zusammenbau der Anzeige doch arg erschwert.

Tendenzen über längeren Zeitraum anzuzeigen ist noch ein riesiger Aufwand, da aufgrund der kurzen Messzyklen extrem viel Datensätze abgefragt werden müßten. Ich hoffe das @Andreas da noch was nachlegen kann. Wenn das Möglich ist könte ich auch versuchen mit dynamischen Aktualisierungszeiten zu arbeiten, wenn z.B. Schwarmalarm droht.

Wollte Mit dem Bild nur zeigen, was möglich wär, um weitere Vorschläge für den Aufbau des ganzen zu bekommen.

Eine Detailansicht über Buttons zu den einzelnen Beuten wird auch noch folgen. Habe da schon mit einem Testcode Deepsleep mit Wakeup über verschiedene Buttons und Auswertung der Aufwachgründe experimentiert. Scheint auf alle Fälle gut zu funktionieren (nicht so wie Pycom).

Richtig. Imkerlich wär es sicherlich schön, noch so etwas wie Varroawetter/Bienenwetter oder das Blühphasen-Monitoring zu bekommen. Kennt da jemand eine API die wir anzapfen könnten?

@wtf warst DU nicht beim Bienenwetter dran? Wie ist da der Stand? Oder gibt es da schon eine API vom DWD?

1 Like

Die Flugprognose veröffenticht der DWD als Tabelle, @thias und @andreas haben sich da schon geschafft, da ist auch eine scraper-Software (‘apicast’) draus entstanden, siehe hier:

Schaut schon mal super aus. Muß also schauen ob ich die HTML Tabelle in in C lesbares Convertieren kann.

Seite würde ich diese Hier probieren.
https://www.dwd.de/DE/leistungen/biene_flug/bienenflug.html
oder noch besser die Regionale “Download/Vergrößerung”
www.dwd.de/ Bienenwetter Hamburg/Flughafen
hoffe nur das sich der Link nicht täglich ändert.
HTML To JSON Converter - BeautifyTools.com gibt das hier zurück.

[
    {
        "Datum": "Mo 01.06.",
        "morgens": "stark",
        "mittags": "stark",
        "abends": "stark"
    },
    {
        "Datum": "Di 02.06.",
        "morgens": "intensiv",
        "mittags": "intensiv",
        "abends": "intensiv"
    },
    {
        "Datum": "Mi 03.06.",
        "morgens": "stark",
        "mittags": "intensiv",
        "abends": "stark"
    }
]

Sollte denke ich machbar sein.

1 Like

Stimmt, danke für die Erinnerung. Das Programm gibts jetzt auch bei PyPI und kommt mit einigen Verbesserungen daher – inkl. HTTP API unter http://apicast.hiveeyes.org/. Mehr darüber gibt es bei:

4 Likes

Habe jetzt http://apicast.hiveeyes.org/ für Arduino auf dem Display erschlossen, aber bisher nur provisorisch Angezeigt. Bin noch am überlegen, ob wirklich alle 3 Tage gebraucht werden und ob Icons das ganze nicht schlanker, übersichtlicher und sprachbarrierefreier machen. als Idee würde ich Waben Zeichnen. Es sind glaube ich 5 Stufen. Also von keine (leere waabe) bis 4 volle Waben etwa so:
image

Aktuelle Anzeige :


Windrose und Iconshabe ich auch schon etwas verkleinert, mache sie aber noch schlanker m/s kommt dann aber nach außen. Verschoben habe ich noch nichts. Wollte mir nicht doppelt Arbeit machen, wenn da noch was zukommt, oder anders aufgeteilt wird.

Man sieht bei der Bienenflugtabelle auch schön, das da was mit drawString(x,y) nicht stimmt (alles Rechtsbündig)

void DrawBeeflightSection(int x, int y) {
  u8g2Fonts.setFont(u8g2_font_helvB08_tf);
  drawString(x, y, "morgens" , RIGHT);
  drawString(x, y+10, beeflight[0].morning, RIGHT);
  drawString(x, y+20, beeflight[1].morning, RIGHT);
  drawString(x, y+30, beeflight[2].morning, RIGHT);
  drawString(x+45, y, "mittags" , RIGHT);
  drawString(x+45, y+10, beeflight[0].noon, RIGHT);
  drawString(x+45, y+20, beeflight[1].noon, RIGHT);
  drawString(x+45, y+30, beeflight[2].noon, RIGHT);
  drawString(x+90, y, "abends" , RIGHT);
  drawString(x+90, y+10, beeflight[0].evening, RIGHT);
  drawString(x+90, y+20, beeflight[1].evening, RIGHT);
  drawString(x+90, y+30, beeflight[2].evening, RIGHT);
}

Einer noch Ideen, was noch rein könnte/muss?
Den Hive Bereich werde ich auch noch an Clemens seinem Beispiel anpassen.

3 Likes

A post was split to a new topic: Rendering beim Grafik-Export von Grafana-panels geht auf swarm nicht

13 posts were merged into an existing topic: Anzeige von PNG-Bitmaps aus Grafana auf einem e-Paper Dispay

A post was merged into an existing topic: Anzeige der Daten auf einem Kiosk-Display mit RaspberryPi und Grafana

Gute Idee! Vielleicht verwenden wir aber auch hier der Einfachheit halber Icons aus dem Bereich Signal-Intensity/-Strength à la:

Oder ebenfalls aus der Wetterdomäne à la:

Vielleicht so etwas?

Je nach Intensität gibt es eine unterschiedliche Anzahl von Strichen.

Die Icons zu zeichnen ist kein Problem.

Was mich an der API evtl. Noch stört ist die plumpe Ausgabe als Text. Wenn ihr das später nach Grafana holen wollt wären ja Uhrzeiten und Stärke 0 bis 4 besser.

1 Like

Das ist wahr. Die letzten Änderungen kümmern sich um eine Verbesserung der Ausgabe. Ich denke, dass es so auch besser ist, die Daten im C/C++ Code auf Icons, Säulen oder dergleichen umzusetzen, um die Intensität darzustellen.

Format "json-machine"

[
    {
        "date": "2020-04-06",
        "morning": 1,
        "noon": 1,
        "evening": 1
    },
    {
        "date": "2020-05-06",
        "morning": 1,
        "noon": 2,
        "evening": 1
    },
    {
        "date": "2020-06-06",
        "morning": 1,
        "noon": 1,
        "evening": 1
    }
]

http://apicast.hiveeyes.org/beeflight/forecast/germany/schleswig-holstein_hamburg/hamburg?format=json-machine

Format "table-markdown"

Die bekannte Ausgabe-Formatierung als Tabelle im Markdown-Format steht nun ebenfalls über die HTTP API zur Verfügung.


Prognose des Bienenfluges in Hamburg (Flughafen)

Datum morgens mittags abends
Do 04.06. gering gering gering
Fr 05.06. gering mittel gering
Sa 06.06. gering gering gering

http://apicast.hiveeyes.org/beeflight/forecast/germany/schleswig-holstein_hamburg/hamburg?format=table-markdown


Auch übersetzt – zumindest die Labels:

Prognose des Bienenfluges in Hamburg (Flughafen)

date morning noon evening
Do 04.06. low low low
Fr 05.06. low medium low
Sa 06.06. low low low

http://apicast.hiveeyes.org/beeflight/forecast/germany/schleswig-holstein_hamburg/hamburg?format=table-markdown&translate=true

A post was merged into an existing topic: Anzeige von PNG-Bitmaps aus Grafana auf einem e-Paper Dispay

Hier mal eine kleine Vorschau. Folgendes ist dabei:

Der Code findet sich bei GitHub - hiveeyes/hiveeyes-epaper-display: Display data from Hiveeyes and Weather Underground on an ESP32 and 4.2" ePaper Display.

2 Likes