Dieses ist doch auch schon mal genial, behalte ich auf alle fälle im Hinterkopf.
So könnte man sogar Graphen einbinden und diese bequem in Grafana anpassen.
Width und height lassen sich auch schon gleich beim Rendern anpassen. Nur habe ich noch nicht rausgefunden, ob und wie die Farbpalette angepasst werden könnte. &color_type= und &depth= scheinen bei den ersten Versuchen jedenfalls nicht beachtet zu werden.
Das könnte man aber sicherlich auch noch auf dem Node beim Importieren richten.
Wie immer in der Pycom Welt wird es etwas komplizierter.
Ich habe jetzt mal die von @Andreas genannten Lib´s durchprobiert.
Die Treiber von Dominik Kapusta(ayoy) unterstützt leider nur das 1.54" Waveshare zwei Farben Display.
Sie funktioniert zwar in dem Bereich von 200x200 Pix aber sobald ich mehr will gibt es Chaos.
Die Treiber von mcaser funktionieren bei mir gar nicht, sie sind auch für einen ESP32 geschrieben ich habe versucht diese für einen Pycom anzupassen, aber das Display will absolut nichts anzeigen. Außerdem sind der 4.2 Treiber doch extrem eingeschränkt. Kein Text keine Linien oder dergleichen.
Den Treiber für das 7,5 habe ich mir aber noch nicht angeschaut.
Werde aber wie es aussieht bei den Treiber selbst Hand anlegen müssen. 
Ich sträube mich immer noch, einen Raspi für ein eInk Display zu nehmen. Da schaut die Welt jedoch anscheinend etwas rosiger aus: Das Display lief dort auf Anhieb ohne Probleme.
Ein schneller Zufallsfund. Tolles Projekt, exzellentes Layout. Befor wir selber lange rumdoktern, könnten wir das ggf. 1:1 verwenden und einfach anpassen bzw. erweitern?
Leider nicht ganz, habe das 4in2 s/w und nicht das 4.2b. Grund: Es kann Teilaktualisierungen und ist auch sonst 3-4 mal schneller.
Ich bin aber schon so einiges weiter: Habe aus mehreren Treibern mal einen zusammengebastelt. Läuft aktuell doch noch etwas arg langsam, aber ich kann schon praktisch alles machen, was ich will.
Eine volle Aktualisierung braucht aber noch extreme 30-40 Sec…
Bin mal gespannt, ob ich dort noch was rauskitzeln kann. Es liegt wohl hauptsächlich daran, das ich als Basis den 3 Farben Treiber genommen und ihn auch nicht in der Firmware eingefroren habe.
Der Stromverbrauch ist aber schon genial: Es verbraucht praktisch nur bei der Aktualisierung 10mA Strom. Ansonsten liegt er bei schlanken 10-50uA. Die Lesbarkeit ist auch bei extremen Bedingungen Top.
Ich werde auf alle Fälle mal am Treiber für Pycom noch ein wenig weiter machen, und auch mal mit einem kleinerem Display probieren. Diese Displays sind, bis auf die vielen Pins die sie belegen, auch sicher am Bienenstand selbst interessant.
@Andreas: Dein Zufallsfund schaut fast zu schön aus, um wahr zu sein. Ich werde wohl parallel auch mal einen ESP32 Arduino aus der Bastelkiste rauskramen.
A post was merged into an existing topic: Erschließung der HTTP-Datenexportschnittstelle via Arduino
Dachte, die kann man komplett vom Strom abkoppeln und der Inhalt bleibt immer noch stehen und lesbar? Oder ist das der Verbrauch des Microcontrollers?
Ja, das Display bleibt auch ohne Strom über Monate (Jahre?) sichtbar.
Dieser Stromverbrauch ist im Sleep Modus des Displays. Das heißt die Spannungsversorgung + Datenleitungen und pullups liegen an und man kann jederzeit wieder eine neue Übertragung/Aktualisierung starten. Der Node kann dabei wach sein und sich mit anderen Dingen beschäftigen. Die 10 -50uA gönnt sich bestimmt der Displaycontroler.
Deep Sleep Display + Node habe ich noch nicht getestet. Laut Datenblatt sind das glaube ich dann 5uA fürs Display.
Bin jetzt am Wochenende entlich mal ein Stückchen weiter gekommen.
Das Display funktioniert mit Arduino-C auf einem ESP32 echt flott (1-2sek).
Die Abfrage und Anzeige der Daten von openweathermap.org läuft auch einwandfrei.
Wahnsinn, was der Python-Treiber vs. C da an Geschwindigkeit macht!
8 posts were merged into an existing topic: Erschließung der HTTP-Datenexportschnittstelle via Arduino
Drüben bei Erschließung der HTTP-Datenexportschnittstelle via Arduino haben wir einen Ausflug gemacht, wie die HTTP-Datenexportschnittstelle von Arduino for ESP32 aus angesprochen werden kann, um eine Anpassung auf Basis von 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 realisieren.
Während der o.g. Arbeiten habe ich bei Erschließung der HTTP-Datenexportschnittstelle via Arduino gemerkt, dass es ungünstig ist, dass die ds18b20 vor der Übertragung zu swarm.hiveeyes.org nicht gemapt werden.
Gerade, wenn ich mehrere Sensor-Beuten mit dem Display überwachen möchte, muß ich alle ID’s überall übertragen. Es graut mir schon davor, wenn mal ein DS18b20 ausgetauscht werden muß.
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.
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!
