ESP8266-DevKitC WROOM-02D interner Pullup an RX?

International Deutsch
1

Hallo zusammen,
Ich habe ein ESP8266-DevKitC mit einem WROOM-02D Modul, mit dem ich gerne meine Heizungs Steuerung auslesen möchte,

Bauanleitungen und Software gibts ja passend. Die Zusatzhardware sieht auch simpel aus.

Allein, es klappt nicht. :frowning:

Wenn ich den RX nicht mit dem Sensor verbinde, schaltet der Phototransistor (SFH 309 FH) brauchbare Signale zwischen 3.3 und ~0V. Sobald ich aber den RX verkable, kann der PT den Signal Eingang nicht mehr schalten. Im besten Fall bekomme ich ein LOW von 3.1V, also nur noch 0.2V Signal.

Das sieht für mich so aus, als ob an dem Anschluss ein relativ niederohmiger PullUp sitzt und der kleine Phototransistor nicht genug Verstärkung hat, um das sauber auf ein LOW zu ziehen.

Ich habe es auch schon ganz ohne den üblichen 10K (externen) PullUp versucht, dann ist das Signal marginal besser.

  • Ist das Modul nur verkonfiguriert? Es gibt ja gefühlt eine Zillion Möglichkeiten, die Pins zu konfigurieren.
  • Kollidiere ich mit der auf dem Modul befindlichen UART/USB Schaltung, die ja grundsätzlich den gleichen UART benutzt?
  • Kann ich einen Verstärker Transistor zusätzlich verbauen, der das Signal wieder sauber auf Low zieht? Gibt's für so etwas ein Beispiel?

Ich habe schon ein paar Hinweise gelesen, dass es mit dem "Wemos D1 pro" Board ähnliche Probleme gibt und das verwendet das gleiche Modul.

Leider geben die Datenblätter zum Modul und zum DevKit in dieser Richtung überhaupt nicht aus.

2

Warum nimmst du nicht andere Pins für deine Anwendung.
Hier findest du Informationen zu den einzelnen Pins, auch dass der RX auf HIGH gezogen wird.

1 Like
3

Das verlinkte Beispiel sieht nach ESPhome aus. Damit arbeitet hier kaum einer. Da wäre das ESPhome-Forum wahrscheinlich der bessere Anlaufpunkt.

Gruß Tommy

4

Ja genau. ESPhome. Danke für den Link. Ich werde es auf jeden Fall dort auch versuchen.

Soweit ich das aus der Doku verstanden habe, wird in der Anwendung fix und exklusiv der UART0 verwendet, weil das Timing mit UART1 nicht sauber genug ist, um mit der Anlage zu sprechen.

Ich muss also irgendwie mit den RX/TX Anschlüssen klar kommen - oder ich habe ein unpassendes Modul.

Aber unabhängig von der verwendeten Software könnte das Hardware "feature" ja auch in anderen Schaltungen problematisch und dafür auch schon irgendwie gelöst sein. Deshalb die Frage in diesem Forum.

Was also machen, wenn ausweichen auf andere Pins oder andere UARTs keine Option ist? Bekommt man den RX trotzdem irgendwie nutzbar?

Es ist in erster Linie eine Hardware/Schaltungs Frage.

5

An den RX und TX Ausgängen hängen gerne auch mal LEDs. Ich kenne Dein Board nicht, aber wenn Du mich fragst wäre für dein Projekt ein ESP32 Board besser geeignet. Das hat zwei Hardware getriebene UARTs verbaut. Dann kannst Du den UART0 ganz normal für Uploads und auch für debug/Trace Ausgaben verwenden. Das hab ich gerade so ähnlich gelöst als ich Probleme mit einem HLK-LD2410 Sensor hatte und schließlich den D1-mini durch einen ESP32 D1-mini ersetzt hab. Es war schon beim initialen Upload per USB lästig die ganze Schaltung abzustöpseln und außerdem hat der D1-mini ab und zu die Ohren angelegt und neu gebootet, ich nehme an er kam nicht mehr nach.

Der zweite UART des EPS32 hängt auf GPIO16 / GPIO17 und die beiden GPIOs sind in der Regel komplett frei verwendbar, haben also keine LEDs oder ähnliches dranhängen.

So wie ich das sehe, kannst Du den zu verwendenen UART per Konfiguration auswählen. Schau mal diese external Component für esphome an.

6

Jaaa, diesen Plan-B mit einem ESP32 hatte ich mir sogar schon vorher überlegt und gleich ESP32-C6-DevKitC-1 mitbestellt.

Nun stellte sich aber heraus, dass die C6 Variante zwar "das aktuelle Modell" und gut 12 Monate auf dem Markt ist, aber scheinbar noch keine Arduino Platform dafür verfügbar ist. Genau die "OptoLink" Komponente die ich verwenden will, setzt aber exklusiv auf die Arduino API und läuft nicht mit der ESP-IDF, die ich für ESPhome normalerweise alternativ verwenden könnte.

Ich habe leider keinen lokalen Laden, in dem ich mal schnell Ersatz holen kann. Ich muss bestellen und schicken lassen. Was Versandkosten und/oder Mindestbestellmengen aufruft und ich wieder im Vorfeld schlecht abschätzen kann, ob das neue Board dann wirklich besser funktioniert.

Der Käfer fällt vorerst also aus, wenn ich mit ESPhome weitermachen will, was eigentlich außerordentlich praktisch wäre, weil ich das ja genau in Home Assistant einbinden will und das quasi die "natürliche" Umgebung dafür ist.

Es gäbe dort sogar vorgesehene Konfigurationen, um UART0 auf alternative Pins zu legen (UART0_SWAP). Dummerweise interessiert sich die Applikation aber dafür nicht und macht nur die Standard Konfiguration. Wie der Autor selbst schreibt,

aus Gründen der Vereinfachung hardkodiert, denn an den UART Parametern darf ohnehin nichts verändert werden.

Aus einer einfachen 5-Komponenten Schaltung mit fertigem Programm "für jeden billigen Arduino Chip" entwickelt sich ein hässliches Monster aus schlampigem Chip Design und freihändiger Programmierung unter Vernachlässigung der vorgesehenen Design-Richtlinien.

Leider beides jenseits meiner eigenen Fähigkeiten, also kann ich kaum aktiv an der Verbesserung mitwirken. Sich zu beschweren, dass die freiwillige Leistung anderer nicht meinen Vorstellungen entspricht, ist ja auch keine gute Option.

Ich werde nun einen Plan-D überlegen, auf ESPhome vorerst vielleicht verzichten und die Kommunikation über MQTT versuchen. Ich glaube, dafür Programmbeispiele gesehen zu haben.

Wenn nicht, dann eben warten, bis sich der eine oder andere aktuelle Stolperstein durch die Arbeit fleißiger Heinzelmännchen erledigt.

Aber wenn jemand trotzdem einen Schaltungs-Vorschlag hat, wie ich den hochohmigen Phototransistor Schaltkreis dazu bringen kann, den niederohmigen RX zu schalten, würde ich noch ein paar Kleinkomponenten ins Rennen werfen und den Eingang einfach auf Low zwingen. :smiling_imp:

Wenn es klemmt, probier's mit Gewalt. Wenn es dann kaputt geht, hätte es sowieso ersetzt werden müssen.

7

ESP8266_DEVKITS_20190902.pdf (527,3 KB)

Vielleicht hilft das Schematik.

8

Also laut https://www.cnx-software.com/2023/11/03/esp32-arduino-core-3-0-esp32-c6-esp32-h2/?amp=1 soll das ESP32-C6 ab ESP32-Core 3.0 unterstützt werden.

9

Ja und die Version ist aktuell im Status "Alpha-3". Kann sich also noch ein paar Monate hin ziehen.
[Arduino ESP32 Core Project Roadmap · GitHub](Roadmap 3.0.0)

10

Hmmm, hast du da nicht dasselbe Problem?
Der Plan D heißt ja nur, dass die erfassten Daten statt über die esphome Schnittstelle nun als MQTT Telegramm über den Mosquito Broker zu Home-Assistant gesendet werden.

Aber genau dort, wo du die Daten abgreifen möchtest, also am UART klemmt es doch weiterhin, oder sehe ich das falsch?

OK ein klassischer Fehlkauf, das passiert halt mal. Irgendwann in ein paar Jahren wird der sicherlich auch für Arduino gehen.

BTW es gibt auch noch andere Lieferanten außer mouser. Einen ESP32-nodeMCU oder einen ESP32 D1-Mini bekommst du z.B. auch bei komputer.de Am besten darauf achten dass ein CP2104 USB Treiber verbaut ist, mit den CH340 Bausteinen hatte ich schon Probleme.

Das Leben ist kein Ponyhof, manchmal läuft es halt nicht auf Anhieb. Auf jeden Fall lernst du was dabei.

Zu deiner YAML Konfiguration bzw. SW kann ich nichts sagen, die hast du noch nicht gepostet. Mein Rat bezüglich der problematischen RX/TX Ports ist halt auf den ESP32 auszuweichen, oder alternativ deine verwendete Komponente zu forken und den entsprechenden Teil zu ändern. Viel helfen kann ich dabei nicht, ich bin selber noch am forschen wie man einen "Custom Sensor" baut, bzw. die neuerdings empfohlene "external Component". Jedenfalls hab ich esphome erstmal lokal installiert, denn in der homeassistant Umgebung liegt ja alles versteckt irgendwo in einem nicht zugänglichen docker-Container oder so. Das ist vielleicht Super um einfach per Konfiguration fertige Komponenten/Sensoren zu generieren und upzudaten, aber um tiefer einzusteigen für mich nicht praktikabel. Auf der lokalen Installation kann ich jedenfalls sehr gut erkennen was denn genau aus dem YAML File nach dem Generieren für ein main.cpp herauspurzelt und welche Libs angezogen werden. Aber es dauert halt. Es gibt Vorgaben wie man SPI usw. verwendet, oder welche externen Libs angezogen werden können. Da muss ich mich durchwühlen.

11

Mir ist noch was aufgefallen.

Frage1:
Wie sieht eigentlich deine Schaltung aus, ein D1-Mini + PT + IR-LED ?

Frage2:
Wie sieht deine Spannungsversorgung aus?
Also wie hast du gemessen?

a) USB-Kabel angeschlossen, die FW geflashed und dann gemessen, oder
b) USB-Kabel angeschlossen, die FW geflashed, USB-Kabel abgezogen, das Board mit 3.3V versorgt und dann gemessen

Der Hintergrund ist, dass ja der USB Chip auch genau am besagten UART hängt, und somit ja auch einen negativen Einfluss haben könnte.

12

Antwort 1:
Ich habe die Schaltung von dieser Seite: https://deploy-preview-2737--esphome.netlify.app/components/optolink

Allerdings heißt mein Chip nicht "D1-Mini" sondern "ESP8266-DevKitC-02D-F", weil der Lieferant, der in der Lage war, den speziellen PT zu liefern (Mouser), eben den im Programm hat. Nach dem Motto "ist das Original Referenz Modell von Espressif, sollte eigentlich passen". Da ist auch ein CP2104N Chip verbaut.

Antwort 2:
Das Board hängt mit dem on-board USB Anschluss normal am USB Netzteil. So sollte es später auch betrieben werden. Ist auch nicht so leicht, in den Keller, dort wo das eingesetzt werden soll, 3,3v hinzubekommen. Eine Steckdose mit Netzteil ist schon einfacher.

Am Arbeitsplatz kann ich das schwer testen, weil ich dazu die direkte Kommunikation mit dem Gerät und den dort verbauten optischen Komponenten brauche. Kann ich nicht simulieren.

Das mit dem "forken und einfach ändern" hört sich leichter an, als es ist. Ich bin kein Native-Linux, der in Shell Commands denken kann, meine c++ Kenntnisse sind eher rudimentär und bis man das Zeug nicht nur geforkt gelesen, verstanden und gefixt, sondern auch wieder zu einem Ganzen zusammengeschraubt hat, ist die Lernkurve schon etwas steil. Das war eigentlich als "niederschwelliger Einstieg in die Materie" gedacht, in der Hoffnung, dass ich das mit 60 auch noch hin bekomme.

Wenn ich auf das ESPhome und die "Optolonk" Komponente verzichte, kann ich vermutlich "normal" den UART0_SWAP definieren. Ich könnte auch die ESP-IDF Plattform verwenden, die meinen C6 unterstützt. Die Basis-Bibliothek für die Geräte Konfiguration, auf die sich auch "Optolink" stützt ist "VitoWIFI". Ich müsste ein paar Stufen tiefer ansetzen und die Bibliothek selbst ansteuern, aber die sollte sowohl unter ESP-IDF als auch unter Arduino laufen. Das ganze WLAN Gedöns, MQTT, und das Auslesen über Home Assistant ... muss ich dann natürlich alles selber machen. Aber dafür wird's ja hoffentlich Samples geben.

Mit dem YAML für das ESPhome ist nicht viel angefangen. Das sind nur ein paar Zeilen Standard und sollten bei Default Belegung funktionieren. Alternative Einstellungen haben alle nicht funktioniert und ich will das Forum hier damit auch nicht voll spammen.

Im Grunde die Beispiel Konfiguration aus oben verlinkter Seite.
Der "uart" Teil wurde völlig ignoriert, obwohl das Debug Log im Bootvorgang klar bestätigt hat, dass die Kinfiguration gültig ist und auch umgesetzt wurde.
2024-02-04_11-03

Nach der Beschreibung des Komponenten Entwickers auch nicht überraschend, wenn er IN der Komponente das noch einmal explizit und hardkodiert neu konfiguriert. :roll_eyes:

Die unter optolink vorgesehene PIN Einstellung beschwert sich, dass es kein ESP32 ist, deshalb wieder auskommentiert. Eigentlich hat das IN der Komponene gar nichts verloren, MUSS aber beispielsweise bei einer ESP32 Konfiguration sogar enthalten sein.

esphome:
  name: esphome-web-fcaf73
  friendly_name: heizung

esp8266:
  board: esp_wroom_02

uart:
  tx_pin: 15
  rx_pin: 13
  baud_rate: 4800
  data_bits: 8
  parity: even
  stop_bits: 2

# Enable logging
logger:
  hardware_uart: UART1
  baud_rate: 0
  level: DEBUG

external_components:
  - source: github://pr#4453
    components: [ optolink ]
    
optolink:
  protocol: P300
  # tx_pin: GPIO15
  # rx_pin: GPIO13
  device_info: Gerätekennung # dient zur Identifizierung der Vitotronic
  state: Status
  logger: enable             # wenn später alles rund läuft, wieder entfernen
13

Ich denke mal, dass es an deinem speziellen Board liegt, ehrlich gesagt hab ich das noch nie gesehen. Du müsstest mal versuchen von deinem speziellen Board einen Schaltplan zu finden. Das sieht nämlich komisch aus, da ist ein Mäuseklavier, mit dem man irgendwas mit dem UART einstellen kann. Ich kann mir vorstellen, dass der Wemos D1-Mini besser mit der Beschaltung klarkommt, damit sind auch alle Beispiele angegeben.

Also ein Versuch wäre es wert, wenn du dir einen D1-mini kaufst, wie gesagt es gibt andere Quellen als mouser. Ich hab auch schon bei "A. und die 40 Räuber" bestellt und die Boards haben genauso gut funktioniert, wie von Reichelt oder mouser.

Dein YAML Code zeigt aber nicht alles, die sensor: wifi: und api: Teile hast du weggelassen richtig?
Aus meiner Sicht sollte der UART ausgeschalten sein, d.h. ich würde den UART Teil weglassen und den Logger ausschalten, also ungefähr so:

# Enable logging
logger:
  hardware_uart: UART0
  baud_rate: 0 
  level: DEBUG

external_components:
  - source: github://pr#4453
    components: [ optolink ]

optolink:
  protocol: P300             # P300 oder KW
  #logger: enable             # wenn später alles rund läuft, wieder entfernen 
  #state: Status              # wenn später alles rund läuft, wieder entfernen
  device_info: 2033          # dient zur Identifizierung der Vitotronic

Ohne die Konfiguration von Wifi und Api wirst du aber keine Trace-Ausgaben sehen. Vielleicht schaust du dir mal dieses Beispiel an.

14

Ja, gut erkannt. Nur stehen da außer den WIFI Zugangsdaten und dem API Encryption Key keine weiteren Werte drin. Für das Web ungeeignet und für das Problem nicht relevant. Darum habe ich das weggelassen. Mein Schnipsel sollte kein Copy&Paste Konfigurationsbeispiel sein.

Der "uart" Block war ursprünglich auch nicht drin, aber mein Versuch, das System regelkonform von einer alternativen Beschaltung zu überzeugen. Wie geschrieben, wird das vom Optolink Modul in aktueller Fassung sowieso wieder übersteuert und ist daher nutzlos.

Ich habe die ganze Doku zu dem Board hier durchgearbeitet und noch Zusatzdoku zum Wroom-02D Modul, die es extra gibt.

Das Mäuseklavier ist laut Doku dazu da, um zwischen zwei Download Varianten zu wählen. Default = Flow-Control. Damit ist zumindest der RTS nicht an den 2102 angeschlossen.

• Dial Switch
A dial switch used for switching between Auto Download and Flow Control

  • Bit1=OFF, Bit2=ON (Auto Download)
  • Bit1=ON, Bit2=OFF (Flow Control)

Ich werde mich mal bei unseren chinesischen Freunden umsehen. Die Lieferzeiten sind zwar lang und ich werde einen keinen Ameisenhaufen zusammen haben, ehe das läuft. Aber dann habe ich sicher viiiele neue Möglichkeiten, jeden Kleinkram bei mir im Haus ans WLAN zu bringen. :grimacing:

15

Ja ein ESP32 Board ist sicher die bessere Option. Ich würde vorab noch einen WLAN Test vorab machen, um zu prüfen ob du im Keller auch ausreichend Emfpang hast. Da kannst du ja ein super-simples LED-Blink dings flashen, das müsste auch mit dem "spezial" Board funktionieren. Es gibt auch Dev-Boards mit externen Antenne, die dann empfangstechnisch noch was rausholen.

Bei Ali, wo ich ab und zu was bestelle, hab ich die Erfahrung gemacht wenn man die "choice" Angebote checkt werden die in 10 Tagen geliefert (oft auch schneller) manchmal auch kostenlos wenn der Betrag > 10€ ist. Vorallem klappt dann auch der Track&Trace der Päckchen. Da hatte ich noch nie Probleme.

16

Der WLAN Empfang in meinem Keller ist super :wink: An dem scheitert's sicher nicht. Der ESP8266 hängt im Keller am Strom, läuft schon mit ESPhome und wird dort mit allen Sensoren angezeigt. Er tickt jede Sekunde fröhlich ein "Link aktiv" auf dem tx-Sendekanal. Ich bekomme nur die Werte nicht rein. :roll_eyes:

Ich habe mir jetzt eine kleine Mischung von ESP Boards bestellt. Die ALi Preise sind erfreulich. Da ist jetzt auch ein C3 und ein S3 Board dabei. Ich habe am Abend noch einmal versucht, herauszufinden, wodurch sich die ESP32, ESP32-Cx, ESP32-Sx, ... überhaupt unterscheiden.

Offenbar liegen da Welten dazwischen, was Architektur, CPU, Schnittstellen und Einsatzbereiche angeht. Kein Wunder, dass man da nicht "irgendeinen aktuellen" kaufen und erwarten kann, dass der wie bei Intel "einfach nur schneller" als das Vormodell ist. Das ganze Gedöns muss in den Plattform Bibliotheken jedes Mal neu eingebaut werden.

Vor Allem die S3 Variante mit Vektor-Prozessor und zusätzlichem ultra low-power CPU Kern für den Deep-Sleep "Betrieb" (wahlweise RISC-V oder StateMachine Architektur :open_mouth:) klingen interessant für lokale AI Implementationen. Damit könnte man bequem eine NASA Apollo-Mission steuern.

Für "nur eine optische serielle Schnittstelle auszulesen" sollte ein kleiner 8266 eigentlich bei Weitem reichen. :smile:

Danke, wieder was gelernt.

17

Vielleicht klappt es ja relativ schnell mit dem ESP32 Dev-Board, da hast du zumindest den Vorteil, und kannst auf GPIO-16 und GPIO-17 ausweichen, und hast trotzdem noch die Default-Serielle als Debugausgabe-Möglichkeit, d.h. du kannst bottom-up, zuerst die optolink-Schnittstelle für sich testen und alles via Serial.printf() rausschreiben. Wenn das geht ist esphome YAML ja ein Kinderspiel.

Ja die verschiedenen Boards sind so ne Sache. Die ESP32 Risc-V Varianten hab ich noch nicht in den Fingern gehabt. Ich glaube der ESP32-C3 soll sowas wie der Nachfolger des ESP8266 sein, und ist für Batterie-Anwendungen mit deep-sleep und solche Dinge. Da hab ich noch nichts geplant. Den ESP32-S3 hab ich auch mal getestet. Bei dem gefiel mir, dass er native USB hat. Das Board ist aber auch "neu" da muss man tricksen, um das ein esphome bzw. mit platformio zum Laufen zu bekommen. Und vorallem ist diese depperte RGB-LED default-mäßig nicht angeschlossen. Auf meinem ESP32-S3-DevKitC-1 Clone musste dazu eine Lötbrücke gemacht werden.

Der Plan war das S3 Board als Entwicklungsplatform zu betreiben und per JTAG Debugging der SW auf den Zahn zu fühlen bzw. die CPU zu stoppen um in aller Ruhe die Pegel von diversen Pins zu messen. Allerdings ist es wohl noch nicht so weit, dass es wirklich stabil läuft. Es sieht alles gut aus, jedoch wird der initiale Breakpoint nicht (immer) erreicht. Schade, so bleib ich halt beim alten ESP32-DevKit bei dem man allerdings ein zusätzliches JTAG Interface (FTDI 2232HL) braucht.

18

Ali war schnell und hat mir eine kleine Auswahl verschiedener ESP32* Boards geschickt. 3,5€ pro Board sind schon eine Ansage. Das erwähnte "D1 mini ESP32" Design war auch dabei. Sehr praktisch und klein, die 40 Pins in zwei Reihen anzuordnen.

Zwei GPIO Ports ausgewählt, eingetragen, aufgespielt - läuft. Genauso wie ich es von Anfang an wollte. :+1:

Bei der Applikation tut sich mittlerweile auch wieder was in der Entwicklung, aber der bisherige Code war für mich gut genug, weil der "original ESP32" ohne irgendwelche Zusätze genau der passende war. :slightly_smiling_face:

Mal seh'n, wo ich all das Zeug jetzt auch verbaue. Ich habe so gar nichts, das ich unbedingt ins WLAN bringen möchte. :face_with_diagonal_mouth:

19

Ich sag mal so, die ESP8266 kann man schon einsetzen, wenn es passt. Aber immer wieder passiert es mir auch, dass ich mit den D1 Minis nur unnötig Zeit verplempere. Wie gerade bei meinem aktuellen Experiment mit diesen LD2410 Bewegungsmelder. Mit einem D1-mini läuft das so leidlich, jedoch legt der ab und zu die Ohren an. Ich vermute dem läuft der Speicher weg, oder ähnliches. Mit dem ESP32 D1 läuft die SW sofort und es treten auch keine Reboots oder ähnliches auf. Batterie betriebene Projekte hab ich grad nicht im Fokus, daher ist der ESP32 aktuell mein bevorzugter µC, insbesondere wenn serielle Schnittstellen im Spiel sind.

20

@smallfreak
Ich hatte den gleichen Fehler und habe Monate gebraucht um eine Lösung zu finden, und mit Netz war keine Hilfe zum Thema zu finden.
Ich hatte auch immer 3,0V an RX. Diese 3,0V kommen aus dem CH340 Pin2 TX. CH340 Pin 2 TX ist direkt verbunden mit ESP8266 Pin25 RX. Daher kann der Phototransistor kein Lo erzeugen.
Als Lösung habe ich den D1 Mini mit ESP-Home per USB beschrieben und dann Pin2 CH340 von der Leiterplatte getrennt. (Mit Lötkolben erwärmt und hochgebogen). Updates kann man dann per Wlan installieren.

1 Like