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

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

lame
Beiträge: 70
Registriert: 15.02.2019, 10:01
Hat sich bedankt: 5 Mal

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

Beitrag von lame » 17.06.2019, 19:41

Gelegenheitsbastler hat geschrieben:
17.06.2019, 17:50
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.
Viele Grüße
Lars

TomMajor
Beiträge: 355
Registriert: 30.08.2017, 23:25
Kontaktdaten:

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

Beitrag von TomMajor » 17.06.2019, 23:25

Gelegenheitsbastler hat geschrieben:
17.06.2019, 17:50
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.
Viele Grüße,
Tom

TomMajor
Beiträge: 355
Registriert: 30.08.2017, 23:25
Kontaktdaten:

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

Beitrag von TomMajor » 17.06.2019, 23:39

papa hat geschrieben:
16.06.2019, 19:33
Hm - komisch. Kannst Du das Schlafenlegen mal ganz abschalten.
ok wie versprochen hier noch die Messung mit Idle
stayAwake_Idle.png
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.
Viele Grüße,
Tom

jp112sdl
Beiträge: 2901
Registriert: 20.11.2016, 20:01
Danksagung erhalten: 6 Mal
Kontaktdaten:

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

Beitrag von jp112sdl » 18.06.2019, 06:41

Moin.
TomMajor hat geschrieben:
17.06.2019, 23:39
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

VG,
Jérôme

lame
Beiträge: 70
Registriert: 15.02.2019, 10:01
Hat sich bedankt: 5 Mal

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

Beitrag von lame » 18.06.2019, 07:00

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

jp112sdl
Beiträge: 2901
Registriert: 20.11.2016, 20:01
Danksagung erhalten: 6 Mal
Kontaktdaten:

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

Beitrag von jp112sdl » 18.06.2019, 07:05

lame hat geschrieben:
18.06.2019, 07:00
...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)

VG,
Jérôme

TomMajor
Beiträge: 355
Registriert: 30.08.2017, 23:25
Kontaktdaten:

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

Beitrag von TomMajor » 18.06.2019, 11:24

jp112sdl hat geschrieben:
18.06.2019, 06:41
Moin.
TomMajor hat geschrieben:
17.06.2019, 23:39
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 8) , heute komme ich wahrsch. nicht dazu, aber die nächsten Tage probiere ich das aus und gebe Rückmeldung.
Viele Grüße,
Tom

TomMajor
Beiträge: 355
Registriert: 30.08.2017, 23:25
Kontaktdaten:

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

Beitrag von TomMajor » 22.06.2019, 18:45

jp112sdl hat geschrieben:
18.06.2019, 06:41
Moin.
TomMajor hat geschrieben:
17.06.2019, 23:39
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?
.
ScreenShot 91 SDR# v1.0.0.1700 - RTL-SDR (USB).png
Viele Grüße,
Tom

jp112sdl
Beiträge: 2901
Registriert: 20.11.2016, 20:01
Danksagung erhalten: 6 Mal
Kontaktdaten:

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

Beitrag von jp112sdl » 22.06.2019, 20:21

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.

VG,
Jérôme

stan23
Beiträge: 560
Registriert: 13.12.2016, 21:14
Wohnort: Altmühltal
Hat sich bedankt: 2 Mal
Danksagung erhalten: 2 Mal
Kontaktdaten:

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

Beitrag von stan23 » 22.06.2019, 22:43

Vielleicht noch ein Debug-Print in 237 falls waiting den Wert ändert.
Viele Grüße
Marco

RaspberryMatic
~60 Geräte (HM, HmIP, HMW, HBW, AskSin)

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“