Damals habe ich keine Doku zum OLED gefunden, ist hier jetzt auch ein anderes, aber vielleicht hilft es weiter:
As for IIC communication, it is necessary to move the resistor on R4 to R3, and R5 is soldered with 0 ohm resistor.
Vielleicht sind 4k7 auf allen Positionen zu viel …
Guten Morgen, da brat mir doch einer einen Storch. Plötzlich läuft das zweite Display - ohne Flackern. Fehleranalyse hat ergeben, wird der Laptop vom Netz getrennt und erreicht einen gewissen Ladestand, reicht die Betriebsspannung nicht mehr für das große Display.
Der Tag startet nicht nur sonnig, sondern auch sehr erfolgreich. Sketch modifiziert, onboard Display am Heltec ausgeschaltet und nur das externe im Betrieb. 
Danke Clemens!!!
Das externe display läuft jetzt mit HW oder SW im constructor? Falls SW, stelle im code den debug level einmal auf 4 ein und schaue welche round trip time dann im Seriellen Monitor angezeigt wir. Wenns, wie bei mir mit dem onboard, 600 ms sind wird es vermutlich nichts mit einer präzisen, sprich kontinuierlich schnellen Messung während des Abfüllens und wir müssen schauen, wie und auf welche HW Pina wir umstellen können.
Ja, es läuft mit SW im constructor.
Wo genau stelle ich den debug level ein?
Einfach den Kommentar-Syntax // rausnehmen, ggf. zu 4 ändern wenn du den master branch hast.
So, anbei der Auszug aus dem SerMon
Reicht Dir das, oder brauchst Du mehr Infos?
Leider, wie befürchtet, zu langsam, dein code braucht mit SW-Ansprache über die U8g2
Dauer 515
also 515 ms, etwas besser als die bei mir gemessenen 630 ms mit SW und onboard OLED, aber lange nicht im Bereich der 180 ms, die wir mit dem alten board oder mit der HW-Initialisierung bei der V3 und onboard OLED haben, siehe Kann ich auch das Heltec "WiFi Kit 32" in der neuen Version V3 verwenden? - #39 by clemens
Das Problem ist, der Honig läuft kontinuierlich aus dem Hahn und der HaniMandl regelt nur wenn er einen Messwert hat. Bei einer halben Sekunde kann schon einiges an Honig im Glas sein bevor der Servo die Möglichkeit hat zu reagieren. “Normal” misst der HaniMandl 5x in der Sekunde, deiner nur 2x in der Sekunde. Das wird vermutlich auf die Genauigkeit gehen. Wir sollten also auch hier nochmal ran …
Danke, Clemens. Das heißt, noch einmal am Code schrauben und optimieren. Ich bin gespannt, was sich hier rausholen lässt…
In der Zwischenzeit werde ich das gleiche Projekt auf Basis ESP32 WROOM aufbauen.
Momentan ist es bei mir etwas eng da zeitnah weiter zu schauen, könntest du versuchen rauszufinden wie man beim ESP32 / Heltec andere pins als die default eingestellten als Hardware-I2C-pins verwenden kann? So weit ich weiß ist das beim ESP möglich. Ich habe nur kurz geteste einfach andere beim U8g2-contructor anzugeben, das funktionierte aber nicht, entweder gehen die von mir verwendeten pins nicht / sind schon anders belegt, oder man muss allgemein I2C anders (vor der U8g2) initialisieren, damit es klappt (denke das ist dann die Lösung).
Wenn du nichts umlöten möchtest, ggf. auch gleich SPI nehmen, siehe Großes OLED-Display am HaniMandl anschließen - #3
Und wenn du dein auf I2C umgelötetes Display mit dem WROOM verwendest sollte SW keine Probleme machen, die habe ich bisher nur beim S3 gesehen.
Hallo Clemens, ich werde mal schauen, ob ich in Punkto I2C eine PIN-basierte Lösung finde. Alternativ werde ich die SPI Variante umsetzen. Diese lässt sich ja relativ einfach auf der bestehenden I2C Lösung aufsetzen. Muss dann nur das Display wieder zurücksetzen.
Ich lass von mir hören 
Ich habe jetzt eine Reihe von GPIO Kombinationen durchprobiert und bin dem Ziel leider nicht näher gekommen. Die 512 ms ließen sich nicht unterbieten, da der Konstruktor HW nicht funktionierte. Möglicherweise liegt es an der internen Architektur des Boards oder ich habe vlt. noch eine Kombination übersehen.
Anyway. Bei näherer Betrachtung des Heltec Boards ist mir dann aufgefallen, dass die GPIOs 17 und 18 nicht ganz verschwunden sind. Diese sind durchaus noch erreichbar, nämlich auf der Unterseite des Boards. Über Kabel habe ich die beiden GPIOs abgegriffen und siehe da, beide Displays arbeiten synchron bei sehr guter Performance. Auch wenn das nicht die Wunschlösung war, so kann ich erst einmal mit diesem Workaround ganz gut leben.
Hmm, Dauer 21 verstehe ich nicht, bei mir waren das um die 180 ms, ggf. weil noch keine Waage dranhängt?!
Hier wird beschrieben wie man die default pins via Wire ändert, falls du nochmal versuchen möchtest:
Hallo Clemens, das Problem lässt sich leider nicht darüber lösen, da ESP32 aufgrund der fehlenden WIRE_INTERFACES_COUNT-Definition keinen zweiten HW Constructor unterstützt. Wenn ich die Diskussionen um dieses Thema richtige verstehe, müsste man die U8G2 Library platformspezifisch anpassen.
siehe auch hier: https://github.com/olikraus/u8g2/issues/961
Danke für die Vorarbeit, so weit bin ich noch nicht gekommen. Allerdings ist das oben geschilderte Problem nicht 1:1 unseres, dort wird versucht über die zweite hardware-I2C-Schnittstelle ein zweites Display anzuschließen. Und auch dafür gäbe es hier einen workaround: pin remapping for second I2C interface · Issue #779 · olikraus/u8g2 · GitHub allerdings mit Modifikation der U8g2 lib in den files U8g2lib.h und U8x8lib.cpp.
Wenn ich dein Szenario richtig im Kopf habe, möchtest du die erste hardware-I2C-Schnittstelle gar nicht mehr nutzen, sondern wir könnten “einfach” bei der esten HW I2C die Pins “umbiegen”.
Falls ich nichts überlesen habe wäre die Pin-Änderung aber nur im constructor nötig – oder hast du noch was anderes gefunden? – und das hatten wir ja schon versucht!
Hilft uns das noch weiter? https://github.com/olikraus/u8g2/issues/942#issuecomment-558820183
After trying any possibly correct constructor and double-checking every pin and parameter I found that adding a
delaybefore callingu8g2.begin()solved the issue for me.
Magst du das mal probieren?
Vielleicht bringen jene Updates Besserung, enthalten in ESP32 Arduino 2.0.7?
Release ESP32 Arduino 2.0.7 based on ESP-IDF 4.4.4 · espressif/arduino-esp32 · GitHub
– me-no-dev released this 38 minutes ago
Bitte das heltec_wifi_kit_32_v3 und das heltec_wifi_lora_32_V3 nicht in einen Topf werfen, sind unterschiedliche boards wie schon in Version 1/2!
