HB-Dis-EP-42BW - 4.2" ePaper Display

[lame]

Da klinke ich mich jetzt noch mal ein, denn das verstehe ich nicht.
Du schickst also nicht den ganzen Kram (Dein Beispiel "tempOut" und "humOut") direkt an das Display, sondern schreibst in Deinem Beispiel das, was übertragen werden soll in "line3". Du überträgst dann im Endeffekt unter anderem "line3". Oder schreibst Du das wirklich in eine SV hinein? Falls ja, wie geht das?

Code: Alles auswählen

string line3 = "/3 '@p03@t09@p45" # tempOut # "@p78" # humOut # "'";

Dann sähe der Befehl irgendwie in dieser Art aus?

Code: Alles auswählen

string displayCmd = "DISPLAY-ID  /1  ' " # line3 # " '

Passt, so mach ich das auch.
Ich packe für vier Zeilen Daten (3x Text/Temp/Humi +1x Text/Uhrzeit) in einen Variable (hier line3) und übertrage diese an das Display.
Dabei nutze ich an so vielen Stellen wie möglich (Wochentage/Zimmernamen) die festen Texte aus der Hardware Konfiguration.
Ich übertrage alle 30 Minuten und liege wohl bei 8-10% mehr DC als ohne Display.

[TomMajor]

Da klinke ich mich jetzt noch mal ein, denn das verstehe ich nicht.
Du schickst also nicht den ganzen Kram (Dein Beispiel "tempOut" und "humOut") direkt an das Display, sondern schreibst in Deinem Beispiel das, was übertragen werden soll in "line3". Du überträgst dann im Endeffekt unter anderem "line3". Oder schreibst Du das wirklich in eine SV hinein? Falls ja, wie geht das?

Genau, ich schreibe alle Zeilen in eine SV, getrennt durch \t, beim nächsten mal werden alle Zeilen aus der SV mittels foreach verglichen und nur die geänderten Zeilen landen im "pool" der zur Übertragung ans ePaper ansteht.

[TomMajor]

Hm - komisch. Kannst Du das Schlafenlegen mal ganz abschalten.

ok wie versprochen hier noch die Messung mit Idle

wie zu erwarten nur ein Burst, alles Bestens.
Habe dann spaßeshalber nochmal stayAwake von 500ms auf 250ms verkleinert, aber das bringt wieder 10 Bursts statt 8, so als ob die 500ms schon zufälligerweise? eine Art Optimum für das ePaper bezüglich Bursts darstellen.

Die Lösung wäre m.E. das ePaper nach dem ersten Telegramm nicht in den Sleep sondern Idle zu schicken, mit einem Timeout, und erst z.B. nach dem eigentlichen Display Refresh wieder das Sleep.
Bin aber nicht sicher wie dafür die konkrete Umsetzung aussehen müsste, entweder müsste ich bei Gelegenheit das Konzept des Multi-Message Empfangs im sketch/Lib untersuchen oder vielleicht gibt es da einen Tipp von papa oder Jerome wie man vorübergehend Idle statt Sleep haben kann.

[jp112sdl]

Moin.

Die Lösung wäre m.E. das ePaper nach dem ersten Telegramm nicht in den Sleep sondern Idle zu schicken,

Ich vermute, es reicht, statt <Sleep> einfach gar nichts zu machen.

Ungetestet beim Frühstückskaffee, probier es mal damit:
https://github.com/jp112sdl/HB-Dis-EP-4 ... P-42BW.ino

ansonsten kannst du unter Zeile 656 ja noch ein else hal.activity.savePower<Idle<>>(hal); einbauen

[lame]

...mal ne blöde Frage,
Burst‘s werden doch von der Zentrale verschickt um Geräte „aufzuwecken“, richtig?

[jp112sdl]

...mal ne blöde Frage,
Burst‘s werden doch von der Zentrale verschickt um Geräte „aufzuwecken“, richtig?

Allgemein richtig - können aber auch von einem Peer verschickt werden (z.B. verknüpfte Fernbedienungstaste mit einem Batterieaktor)

[TomMajor]

Moin.

Die Lösung wäre m.E. das ePaper nach dem ersten Telegramm nicht in den Sleep sondern Idle zu schicken,

Ich vermute, es reicht, statt <Sleep> einfach gar nichts zu machen.

Ungetestet beim Frühstückskaffee, probier es mal damit:
https://github.com/jp112sdl/HB-Dis-EP-4 ... P-42BW.ino

ansonsten kannst du unter Zeile 656 ja noch ein else hal.activity.savePower<Idle<>>(hal); einbauen

Danke dir Jerome , heute komme ich wahrsch. nicht dazu, aber die nächsten Tage probiere ich das aus und gebe Rückmeldung.

[TomMajor]

Moin.

Die Lösung wäre m.E. das ePaper nach dem ersten Telegramm nicht in den Sleep sondern Idle zu schicken,

Ich vermute, es reicht, statt <Sleep> einfach gar nichts zu machen.

Ungetestet beim Frühstückskaffee, probier es mal damit:
https://github.com/jp112sdl/HB-Dis-EP-4 ... P-42BW.ino

ansonsten kannst du unter Zeile 656 ja noch ein else hal.activity.savePower<Idle<>>(hal); einbauen

@Jerome
Hmm, deine Codeänderung sah gut und logisch für mich aus, leider funktioniert sie nicht und ich habe gerade keine Idee warum das so ist.
Das ist die Stelle bei mir beim HAL

Code: Alles auswählen

#ifdef BATTERY_MODE
    if (hal.battery.critical()) {
      hal.activity.sleepForever(hal);
    }
    // VAR1
    //if (ePaper.isWaiting() == false) {
    //  hal.activity.savePower<Sleep<>>(hal);
    //}
    // VAR2
    hal.activity.savePower<Idle<>>(hal);

Im SDR Bild unten sind die Messages für die gleichen Texte zum Testen wie weiter oben gepostet.

Der untere Teil mit den vielen Bursts ist die VAR1
Das funktioniert überhaupt nicht, das Display macht dann auch kein Update für den Text.

Darüber ist nochmal als Gegencheck VAR2, also immer im Idle halten, funktioniert bestens.

Ich habe VAR1 auch noch mit dem else <Idle> probiert, das macht überhaupt keinen Unterschied.
Irgendwie scheint der call zu ePaper.isWaiting() alles kaputt zu machen, hast du noch eine Idee?
.

[jp112sdl]

Was passiert denn bei

Code: Alles auswählen

#ifdef BATTERY_MODE
    if (hal.battery.critical()) {
      hal.activity.sleepForever(hal);
    }
    // VAR1
    if (ePaper.isWaiting() == false) {
    //  hal.activity.savePower<Sleep<>>(hal);
    }
    // VAR2
    hal.activity.savePower<Idle<>>(hal);
    

Also nur ePaper.isWaiting() aufrufen, ohne jegliche Aktion und beim savePower<Idle<>> bleiben.

Evtl auch mal Debug einbauen, ob isWaiting() tatsächlich true wird. Vielleicht vor Zeile 241.

Ansonsten bin ich da auch etwas ratlos.

[stan23]

Vielleicht noch ein Debug-Print in 237 falls waiting den Wert ändert.