lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
953 stars 225 forks source link

Feature Request: OLED zur Darstellung der Werte anschließen #276

Closed daja64 closed 1 year ago

daja64 commented 2 years ago

Hallo, ich habe das Problem, das der WR so ungünstig steht. Da ich noch keinen finalen Aufbau habe und den besten Platz auf dem Flachdach suche, muß ich immer wieder sher umständlich den kontakt zum WR herstellen. Er sendet mir aber nur Daten wen er eine genaue Zeit bekommt. Mir wär jetzt geholfen, könnte ich auf einem SSD1306 anzeigen, ob ahoy-dtu noch in meinem Wlan ist oder nicht. Jetzt muß ich immer noch das Notebook noch mit rum schleppen für die anzeige ob ich noch Wlan habe oder nicht und noch das Handy um zusehen ob jetzt Daten vom WR rein kommen. Kann ich die Codeschnipsl für das Oled nicht irgend wo einfügen ?

stefan123t commented 2 years ago

Hallo @daja64 Gute Idee das wäre ähnlich wie die MQTT Anbindung eine Ausgabe / "Visualisierung" von Daten die regelmäßig aktualisiert wird. Sollte also mE in eine eigene Datei und dann von app.c / hmRadio.h aufgerufen werden. Eventuell noch eine Möglichkeit in der Config dies zu de/aktivieren ?

DennisXK commented 2 years ago

Ja gute Idee, man sollte evtl die Möglichkeit haben die Werte die dargestellt werden sollen, auswählen zu können. Man bedenke das das Lcd nicht besonders groß ist und wenn man 3 Wechselrichter an der dtu angebunden hat, die Darstellung durchdacht sein sollte.

stefan123t commented 2 years ago

Oder die einzelnen Kanäle nacheinander durchwechseln dh jedes Mal eine andere Seite anzeigen.

DennisXK commented 2 years ago

Ja, das sowieso. Aber wie willst du 22 Werte von einem HM-600 darstellen. Die meisten Werte benötigt man eh nicht.

stefan123t commented 2 years ago

Haha am besten einen Ticker wie bei den Nachrichten oder an der Börse :)

daja64 commented 2 years ago

Kann mir wer mal sagen, wo ich die entsprechenden Zeilen finde die dann Daten an die serielle Schnittstelle senden ? Mir raucht schon der Kopf von den vielen Codezeilen.

stefan123t commented 2 years ago

Schau mal hier zB

https://github.com/lumapu/ahoy/blob/99c2b9f7a936bad6109a0ab7d8362517dbf15dc0/tools/esp8266/app.cpp#L195

wib100 commented 2 years ago

Ich hab das so gelöst:

daja64 commented 2 years ago

Bitte welches Handy, es geht nicht mit allen. Einige wollen Rootrechte dafür, das fällt für mich flach.

wib100 commented 2 years ago

Bitte welches Handy, es geht nicht mit allen. Einige wollen Rootrechte dafür, das fällt für mich flach.

Dazu brauchst du keine root Rechte (ich hab das mit meinem Samsung S10 gemacht). Sind alles "standard" Sachen die du verwendest. Einfach ausprobieren...

stefan123t commented 2 years ago

@daja64 für den Personal Hotspot brauchst Du keine root-Rechte. Und Dein Handy arbeitet dann als Bridge zwischen ESP und Deinem WLAN Router. Damit kannst Du einfach die Seite unter http://ahoy-dtu/ aufrufen, da beide im selben Netzwerk Segment sein sollten. Nur mit Deinem Handy musst Du Dich irgendwo zwischen ESP und WLAN Router stellen.

wib100 commented 2 years ago

Wenn du einen Hotspot auf deinem Handy erstellst und den ESP so konfigurierst, dass er diesen Hotspot verwendet, spielt das "normale" Haus-WLAN nicht mehr mit. Somit kannst du nur mit dem Handy und dem ESP messen ohne von einem WLAN abhängig zu sein. Die serielle Konsole ist dabei optional. Alternativ kannst du den ESP auch an ein Akkupack hängen wenn du keinen OTG Adapter hast.

gh-fx2 commented 2 years ago

Hallo, ich habe das Problem, das der WR so ungünstig steht. Da ich noch keinen finalen Aufbau habe und den besten Platz auf dem Flachdach suche, muß ich immer wieder sher umständlich den kontakt zum WR herstellen. Er sendet mir aber nur Daten wen er eine genaue Zeit bekommt. Mir wär jetzt geholfen, könnte ich auf einem SSD1306 anzeigen, ob ahoy-dtu noch in meinem Wlan ist oder nicht. Jetzt muß ich immer noch das Notebook noch mit rum schleppen für die anzeige ob ich noch Wlan habe oder nicht und noch das Handy um zusehen ob jetzt Daten vom WR rein kommen. Kann ich die Codeschnipsl für das Oled nicht irgend wo einfügen ?

Hi. Ich habe mir das Nokia-Display 5110 in den Code integriert. Kannst ja mal schauen und deinen SSD1306-Code entsprechend genauso reinbasteln. :)

PS: Eine Trägerplatine habe ich mir auch gefertigt. Nun hab ich eine Anzeige, die ohne weitere Gadgets die aktuelle Leistung anzeigt. (Ob ohne WLAN was geht , weiss ich nicht. Der code will ja unbedingt die ntp-Zeit holen)

https://github.com/gh-fx2/ahoy/blob/nokia5110/tools/pcb-nokia5110/

gandalfred commented 2 years ago

Kann das evtl. jemand für das ssd 1306 Display umsetzen? Tolles Projekt. Danke an alle Beteiligten

daja64 commented 2 years ago

@gh-fx2 Kannst du mir mal erklären wie das Display eingebunden ist, wo diese Einbindung erfolgt? Bin noch Neuling was dieses platformio angeht.

gh-fx2 commented 2 years ago

@daja64: In der aktuellen Version ist das so, dass du in platformio , da wo du 'Build' anwählen kannst, einen weiteren Eintrag findest: esp8266-nokia5110 ( Die anderen Eintraege sind wie gewohnt: esp8266-release, ..debug, ..1m.., esp32, usw... ) Wenn du also diesen Punkt öffnest, dann kannst du da 'Build' anwählen und er kompiliert dir diese Version. Dort findest du auch das passende Upload, Monitor usw... Verbinden musst du die PINs so (ist hardcoded in app.c, Zeile 36 ): RST : D0 ( = 16 ) CE : D1 ( = 5 ) DC : D2 ( = 4 ) DIN : D7 ( = 13, Mosi - damit ist auch der NRF verbunden !) CLK : D5 ( = 14, SCLK - auch mit NRF verbunden!) VCC: auf 3.3V GND: GND Ich habe BL (LIGHT) offen gelassen, damit nicht zu viel Strom verbraucht wird. Zudem habe ich das Gefühl, dass es sich besser liesst, wenn kein BL ist. Bei Bedarf könnte man hier einen Taster einsetzen (bei meiner Version muss der PIN mit GND verbunden sein, damit Backlight an ist).

edit: Am einfachsten ist es unter 'source-control' / Branch / switch to another branch, den */nokia5110 hinzuzufügen. Nicht den Wechsel zu diesem Branch vergessen. Sonst findest du den Zweig esp8266-nokia5110 unterhalb PlatformIO nicht. Falls du Probleme mit dem Einbinden des Branches hast, kannst du auch versuchen den Code als zip zu holen (über den link 3 posts vorher -> Code -> Download als zip). Dann müsstest du darin vermutlich das file 'platformio.ini' anklicken (bin aber nicht sicher, da ich immer nur mit extension gitlens arbeite.)

knickohr commented 2 years ago

Ich möchte da mal ansetzen. Hat das schon jemand für OLED umgesetzt ? Für das Nokia-Display scheint es ja zu existieren. Funktioniert das auch mit dem ESP32 ?

Sorry für die blöden Fragen, aber PlatformIO ist mir irgendwie zu hoch 😞 Steige da nicht richtig durch 😪

gh-fx2 commented 2 years ago

Hab ein weiteres Branch aufgemacht. Mit dieser Version kann statt nokia5110 das OLED (ssd1306) angeschlossen werden. ACHTUNG: Nur die I2C-Version !!! Wie verdrahtet wird, schreibe ich ins README. Upload mach ich erst gleich.

stefan123t commented 2 years ago

@gh-fx2 erstmal Danke für den Beitrafg das sieht schon prima aus. Was ist Deine Vorstellung dazu: Der Code den Du für das Nokia5110 erstellt hast ist eigentlich sehr übersichtlich und wird in app::setup() initialisiert und in app::loop() aufgerufen.

@lumapu wie sollen wir mit dem/den PRs von @gh-fx2 weiter machen ?

Dies sollte m.E. wie in #185 beschrieben über eine Art Ausgabe-Plugin mit einer eigenen Bibliothek z.B. output/textNokia5110.h möglich gemacht werden.

Dann kann man sich individuell entscheiden welche Ausgabe-Routinen / Formate man jeweils ansprechen will:

Und vor allem der Code in der app.cpp wird nicht immer größer und unübersichtlicher :smile:

gh-fx2 commented 2 years ago

@stefan123t: Hi erstmal. Eigentlich habe ich keine Vorstellung. Ich habe einfach 'euren' Code genommen, und etwas erweitert - weil ich ein display haben wollte. Da ich selbst auch fand, dass der code recht gut gekapselt ist, dachte ich mir - stell es zur Verfügung, eventuell möchten andere das auch . Der Zusatz mit dem OLED kam dann wegen dieses Issue hier - und weil der Code fast gleich zur Nokia-version ist. Aus meiner Sicht macht es Sinn den Code auszulagern (zumindest in einen header) um app.cpp zu schonen. Die Pin's sind leider nicht wählbar. Für die Nutzung anderer Pins braucht man extra I2C-Libs (zB brzo), die es wiederum nicht für esp32 gibt. Es macht also kaum Sinn dafür Einstellungen vorzusehen. Zudem schränkt die Nutzung die 'freie Wahl' für die NRF-Belegung ein. (zB sind ja pin 4+5 dann beim esp8266 nicht mehr fürs NRF möglich ... ) Ich vermute, die Display-option ist daher schon beim kompilieren zu treffen.

gh-fx2 commented 2 years ago

hab ich noch vergessen... PR #401 nehmen. Der ist der letzte Stand und müsste auch auf dem esp32 laufen.

knickohr commented 2 years ago

Heißt also das in einer der nächsten DEVs ein Menü drin ist, das man das auswählen kann. Fixe Pins sind OK, allein schon wegen der Einfachheit/Übersichtlichkeit. Soll ja nicht mit anderen Komponenten sich beißen 😉

stefan123t commented 2 years ago

@lumapu ich bin dafür die Änderung von @gh-fx2 in den Code zu mergen. Die Änderung ist relativ gut und übersichtlich und die Refaktorisierung der app.cpp hattest Du m.W. als nächstes vor, dann kannst Du die Code Teile mit auslagern. Sonst müssten wir warten bis wir die app.cpp aufgeräumt haben und gh-fx2 müsste einen neuen PR stellen. @DanielR92 Du wolltest doch auch irgendein Display auf Dein Board packen. Würdest Du den Code ggf. noch reviewen bzw. Deine Einschätzung abgeben ?

lumapu commented 2 years ago

@stefan123t, @gh-fx2 ich war nicht glücklich mit dem PR aus folgenden Gründen:

Ich habe mir die Sourcen gesichert, aber die Änderungen durch den merge rückgängig gemacht.

Wir sollten uns nochmal abstimmen

gh-fx2 commented 2 years ago

... bei C++ bin ich raus. Was da entsehen würde will keiner. Ich hefte mal meinen Versuch bezüglich openDTU an. War ein Versuch - aber nicht weiter verfolgt, da ich nur den esp8266 einsetzen wollte. Die Akquise ist leicht anders (das wisst ihr sicher selbst) und für den Zeitstring musste ich selbst ein sprintf machen. ssd1306.zip

daja64 commented 1 year ago

Super gh-fx2, dank deiner Hilfe bin nun etwas weiter, was die OLED-Anzeige angeht. Ich mußte leider zwangsweise pausieren und melde mich nunmal wieder mit einem Problem zurück. Die Zeit wird auf dem OLED leider eine Stunde zurück angezeigt, warum ? Ich habe mit der Zip-Datei gearbeitet, nur bereitet der c-Code mir immer mal noch Verständnisprobleme.

gh-fx2 commented 1 year ago

Ja... liegt daran, das Sommer/Winterzeit nicht beachtet wird, Du kannst aber mit wenigen Änderungen in die Version umbauen, die ich im pull-request hatte. Ersetze in dataScreen() ganz oben:

  struct tm timeinfo;
  char timeStringBuff[50];

  memset(&timeinfo,0,sizeof(struct tm));
  getLocalTime(&timeinfo, 0);
  strftime(timeStringBuff, sizeof(timeStringBuff), "%y-%m-%d %H:%M:%S", &timeinfo);

durch

  String timeStr = mApp->getDateTimeStr(ts).substring(2,22);

und fast am Ende:

    else
    {
        int w=display.getStringWidth(timeStringBuff,strlen(timeStringBuff),0);
        if ( w>127 )
        {
            String tt=String(timeStringBuff+9);
            w=display.getStringWidth(tt.c_str(),tt.length(),0);
            display.drawString(127-w,49,tt);
        }
        else
            display.drawString(0,49,timeStringBuff);
    }

durch

    else
    {
        int w=display.getStringWidth(timeStr.c_str(),timeStr.length(),0);
        if ( w>127 )
        {
            String tt=timeStr.substring(9,17);
            w=display.getStringWidth(tt.c_str(),tt.length(),0);
            display.drawString(127-w,49,tt);
        }
        else
            display.drawString(0,49,timeStr);
    }
gh-fx2 commented 1 year ago

... ich seh grad, Nun fehlt ja ts (Zeitstempel). Da hatte ich ursprünglich in loop() mUtcTimestamp durchgereicht. Das müsste man eventuell im SSD1306-loop auch vorsehen, oder man schafft ne Möglichkeit, wie dataScreen() diesen Zeitstempel abfragen kann.

daja64 commented 1 year ago

Diese Änderungen sind schon in der zip-Version. Nun bin ich an einem Punkt, wo ich mal ein Übersetzung brauch. was wird hier gemacht Zeile 132 in der app.cpp "display.getStringWidth(timeStr.c_str(),timeStr.length(),0);"

gh-fx2 commented 1 year ago

Hier wird ermittelt, wieviel Pixel der String auf dem oled haben wird. Da nur 128 zur Verfügung stehen, wird bei Bedarf im nächsten if das Datum weggeschnitten - weil nur die Uhrzeit sollte passen. (Mit Datum ist es oft ein paar Pixel zu lang, je nachdem wieviel dicke Zeichen wie etwa die Null). PS: Inzwischen habe ich hier noch diverse Erweiterungen

knickohr commented 1 year ago

Hier ist ein Bug in der Uhrzeit der Displays, hinkt eine Stunde hinterher 😵

@gh-fx2 @lumapu

lumapu commented 1 year ago

Version?

knickohr commented 1 year ago

DEV 50 @lumapu

gh-fx2 commented 1 year ago

Yep. In meinem Code (hier oben bzw. im pull) wird der Zeitstring aus UTC gebildet. Die ist jetzt 1h daneben. In den Pull401-Kommentaren habe ich noch ein paar Zeilen Code hinterlassen mit denen ich die Zeitumstellung realisiert habe. Ist aber ne schlechte Lösung, da sie nur für DE (CST & CEST) gilt.

gandalfred commented 1 year ago

Hi zusammen. Wie bekomme ich die Ssd1306 Option im Code dazucompiliert? Muss ich selber compilieren über visual Studio Code oder gibt es auch fertige bins mit Ssd1306 enabled? Danke für eurer Feedback

knickohr commented 1 year ago

Gar nicht mehr nötig. Nimm die Version 0.5.50 und da das passende Binary.

Anschließen und sich erfreuen.

knickohr commented 1 year ago

Ist es möglich, statt diesen großen fetten off am Tagesende die Yield-Werte beizubehalten ? Also alles was unter dem Strich war und vielleicht das off etwas kleiner als offline zu schreiben ?

was passiert eigentlich bei mehr als 2 Invertern ? Rollieren dann die Werte durch ?

@gh-fx2

gh-fx2 commented 1 year ago

Idee ist gut. Ich werde das offline in der oberen Zeile machen. Bei mehr als 2 gibt es keine Einzelwerte - wäre aber machbar.