Deshalb werden ja bei Hiverize/Fipy die ID’s nur in user_settings.json gespeichert und nicht übertragen.
In den Daten tauchen nur t_i_1 bis 5 und t_o auf.
@didilamken stimmt, von dort kenne ich das ja auch so.
@clemens, @all wo wir schon bei den Temperatursensoren und deren Anzeige sind.
Macht es Sinn, einen Median der inneren DS1820 zu bilden und auch die Abweichung der letzten Stunde auszugeben(Schwarmalarm?)?
Eine Auflistung aller Sensoren macht das ganze finde ich recht unübersichtlich, gerade wenn man mehrere Beuten anzeigen möchte.
Man könnte auch über der Zahl dann noch noch einen Pfeil zeichnen, der anzeigt, ob sie eher links,rechts oder Mittig sitzen.
Hi Michael,
I hear you. Ja, wir sollten das gerade in diesem Kontext auch unbedingt so gestalten wie hier:
@tonke hat ebensolche Wünsche und wir haben während der letzten Releases bereits daran gearbeitet, entsprechende Funktionalität nicht “out-of-band” zu realisieren, sondern die Möglichkeit zu schaffen, die Telemetriefeldnamen bereits in den entsprechenden Konfigurationsabschnitten der Sensoren selbst definieren zu können.
Viele Grüße,
Andreas.
1 Like
Hmm, Median / Mittelwert würde ich nicht machen, das sagt dann nix mehr aus. Ich würde mir einfach den mittleren nehmen und dessen Daten anzeigen, die anderen verwerfen. Oder man nimmt den Maximalwert von allen. Schwarm wäre so ab 35,8 °C
Ist es für die Messdatenauswertung wichtig zu wissen, dass der BME280 am I2C-Bus0 mit der Adresse 0x77 betrieben wird? Oder ist das nur unnötiger Datenballast?
@MKO: Ich habe das o.g. Repository nach GitHub - hiveeyes/ESP32-e-Paper-Display: Display data from Weather Underground and Hiveeyes on an ESP32 and 2.9", 4.2" or 7.5" ePaper Display geforked und einen Branch “hiveeyes” angelegt. Vielen Dank schon im Voraus fürs Bestücken mit unseren Errungenschaften aus Erschließung der HTTP-Datenexportschnittstelle via Arduino und dem weiteren Entwicklungsverlauf!
Das liegt daran, das die Terkin Firmware nach oben offen ausgelegt ist. Theoretisch kann man beliebig viele BME280 anschließen. Praktisch wird das aber wieder durch die BME begrenzt, die nur auf 2 Adressen eingestellt werden können. Beim i2C verhält sich das ähnlich es sind auch auf dem FiPy zwei möglich.
Testweise Angeschlossen hatte ich schon 2 x BME, 10 DS18b20 und 2 x HX711, welches einen vollen Sensor-Betrieb von 2 Beuten mit nur einem Fipy + bedeuten würde.
Theoretisch geht noch einiges mehr. I2C Multiplexer + B Kanäle der ADC (beim HX711 wohl lieber nicht) z.B.
Man braucht also nicht mehr lange Programmieren, wenn man neue Ideen hat. Anschließen Konfig Ändern und fertig.
1 Like
David aka G6EJD hat dazu auch einige YT-Videos ins Netz gestellt:
https://www.youtube.com/results?search_query=G6EJD+e-paper
Hast du das s/w-Display oder ein dreifarbiges? Du hattest hier irgendwo mal ein Foto mit einem 3-farbigen Display gepostet, daher die Frage! Gerade für die Graphen fände ich die dritte Farbe prima!
Könnte das framework von David / G6EJD auch drei Farben?
Ich habe derzeit nur das Schwarz Weiße 4.2 von Waveshare. Der Grund ist hauptsachlich eine kurze Aktualisierungszeit und die möglichkeit von Partial Update. Anstatt Farbe kann es aber auch aber auch Graustufen.
Ein 3 Farben Display braucht doppelt so viel Speicher/rechenzeit im ESP , doppelt so viel Zeit/Daten per SPI und gut 3Mal so lange zum Aktualisieren.
Und aktive Zeit ist leider auch Batterieverbrauch, welche sich auch durch häufigeres Laden/Batteriewechsel bemerkbar machen würde. Derzeit hoffe ich, das wir bei ca. 200 - 300 Tagen Laufzeit mit einer Akku Ladung landen.
Die verwendete Libary fur die Displays GitHub - ZinggJM/GxEPD2: Arduino Display Library for SPI E-Paper Displays kann aber auch 3 Fabige Displays.
Eine Kurze Aktualiesierunszeit und Datenübertragung zum Display ist für mich aber aktuell fast wichtiger als Farbe, da ich auch ein paar Buttons mit Interupt einbauen möchte.
Von der Idee her: Ich möchte ich eine Kurzform der wichtigsten Daten des Wetters und meherer Beuten in der Standartansicht anzeigen lassen, die dann auch per Wakeup über einen Button-interupt umgeschaltet werden können, um eine größere Ansicht der einzelnen Beuten zu erhalten.
Also ein Button zum manuellen Aktualiesieren (=Reset) und je einen weiteren für die Detailansicht der einzelnen Beuten.
Der relativ günstige Preis für diese größe des E-Papers (ca 35€ m. Controler und Versand aus DE) hat aber auch eine Rolle gespielt.
Mit einem Waveshare 15823 e-Paper ESP32 Driver Board
ca15€ + Solo-Display ohne Controler für ca. 22€ hätte man auch noch eine minimal kostengünstigere Variante, ohne groß Kabelsalat und Löten.
War mir nicht klar, dass der Unterschied so heftig ist. Selbst bei einem kleinen 3-Farben Display dauer es fast eine halbe Minute (Video ab 7:42):
Hier, mit em großen Display, dauert es unglaubliche 55 Sekunden bis das neue Bild aufgebaut ist: (ab 12:58)
Hier im Vergleich ein 2-Faben Display mit ca. 4 Sekunden update-Zeit (ab 14:48)
Ja der ist echt heftig. Der Treiber macht aber schon extrem viel aus.
Das im Video gezeigte Flackern braucht das Display, um Leinenhaft ausgedruckt, die Elektrische Ladung in den einzelnen Bildpunkten anzugleichen. Wenn dieses nicht oder nicht intensiv genug gemacht wird bleiben Teil-Ladungen von der letzten Anzeige erhalten. Die sich dann als Schatten bemerkbar machen.
Ein 3 Farbiges e-Paper sind theoretisch 2 eigenständige Anzeigen in einem. Diese werden nicht parallel sondern nacheinander Aktualisiert. Daher dauert es mindestens doppelt so lange.
Eine reale Chance später auch Farbe ins Spiel zu bekommen haben wir allerdings dennoch. Von der verwendete Display Libary meine ich eine evtl. kompatible für “normale” Displays gesehen zu haben. Der Nachteil wär dann aber, das man an eine feste Spannungquelle gebunden wär, oder ständig aufladen müsste.
Also eher was für den Schreibtisch oder ein Regal mit Steckdose, wo ein zusätzliches Stromkabel nicht stört.
Ich will es frei an der Wand im Flur/Gaderobe hängen, oder auch Mal einem interessierten Besucher in die Hand geben.
Ein komplettes Aktualisieren inkl. Hochfahren, Wlan, Zeitsync, 2x API-OpenWeathermap, 1x Http-Hiveeye , Datenaufbereitung und Displayanzeige dauert Aktuell übrigens ab Reset 5-6 Sekunden. Was ich zugegeben recht Flott finde, für das was getan wird und das Flackern von nicht einmal einer Sec. Zeigt einem dann auch noch zusätzlich, das das die Daten Frisch sind.
Gestern bin ich leider nur minimal weiter gekommen. Das Auslesen der Json stoppt jetzt nach dem letzten Datensatz und ich bin mit einem Configfile für Hiveeyes angefangen.
Auf GitHub - hiveeyes/hiveeyes-epaper-display: Display data from Hiveeyes and Weather Underground on an ESP32 and 4.2" ePaper Display werde ich es leider erst am Wochenende Mergen können. Die geforderte Verzeichnisstruktur von der Arduino-IDE und die des Forks unterscheiden sich schon extrem. Werde wohl auf CodeBlocks oder Visual Studio Code oder WSL inkl. Makefile umbauen müssen.
1 Like
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.
- Improve telemetry field name mapping · Issue #76 · hiveeyes/terkin-datalogger · GitHub
- Improve data export interface · Issue #32 · daq-tools/kotori · GitHub
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. 
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