WIFI ESP8266 zu ESP8266 Kommunikation Problem

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • WIFI ESP8266 zu ESP8266 Kommunikation Problem

      Hallo Zusammen,

      ich möchte gerne mit euch mein zweites Problem in meiner Heizungssteuerung besprechen und natürlich auch eine Lösung finden.

      In meinem ersten Beitrag wurden ständig Werte verändert und ihr geht es darum, das unregelmäßig die Verbindung nicht funktioniert.

      Die Steuerung (das Programm ist im ersten Beitrag hochgeladen) macht jede Minute eine Verbindung zu den Sensoren und diese geben einen Temperaturwert zurück.
      Soweit so gut. In unregelmäßigen Abständen funktioniert das nicht.

      Ich habe das Programm für die Sensoren angehängt und auch ein Beispiel was nicht funktioniert.

      Ich hoffe, ihr könnte mir wieder helfen.

      Vielen Dank im Voraus
      Horst
      Dateien
    • Ging eine Uhr falsch oder sind die Aufzeichnungen nicht gleichzeitig passiert?
      Das immer mal einer abschmiert/kein Wlan hat/rausgekickt wird/undeulich spricht ist normal. Bedenkt man das das Programm nicht mal annähernd auf Fehlermelungen reagiert kommt es doch sehr gut mit solchen Dingen klar. Häuft sich das ganze geht die Suche los: Stromversorgung stablil? (Scope ) Wlan gut?(Handy).
      Beim Tinny selber ist das saveall kontraprodulktiv. Da der Timer die SW Uarts empfindlich stört was dann zu Missverständnissen mit dem ESP führen könnte. Da nur ein Zähler vergrößert wird würde ich ein nosave vorschlagen.
      Wie oft passiert das ? Erholt es sich immer von alleine? (Das ESP hat keinen Reset angeschlossen)
    • Hallo Pluto25,

      schön von dir zu hören.

      Ich hatte nur ein Serial to USB Adapter und deshalb einmal am RX und danach am TX angeschlossen.
      Falls notwendig, würde ich es auch gleichzeitig mit zwei Adapter auf zeichnen.


      Pluto25 schrieb:

      Wie oft passiert das ?
      Zwischen 5 und 20 mal pro Tag und Sensor.

      Pluto25 schrieb:

      Erholt es sich immer von alleine? (Das ESP hat keinen Reset angeschlossen)
      Ja, der Sensor macht einen Reset, deshalb der Timmer 1 mit zwei Minuten.

      Pluto25 schrieb:

      würde ich ein nosave vorschlagen
      Das probiere ich gleich mal aus.

      Pluto25 schrieb:

      Stromversorgung stablil? (Scope ) Wlan gut?(Handy).
      Hab ich überprüft und es schaut gut aus. Ganz ausschließen kann man das fast nicht.

      Horst
    • Topgun schrieb:

      Ja, der Sensor macht einen Reset,
      Jedoch nur der Avr oder? Den Reset vom 05.12. 08:47:34 hat es selbst gemacht? Möglicherweise weil es unklare Anweisungen bekam?
      Der Serial2Usb kann über zwei Dioden und einen Pullup beide Kanäle gleichzeitig mithören (solange sie nicht gleichzeitig sprechen)
      Ca 10 mal pro Tag bei 1440 Nachrichten klingt jetzt nicht so tragisch - aber gut wenn sich verbessern läßt.
    • Hallo


      Pluto25 schrieb:

      Ca 10 mal pro Tag bei 1440 Nachrichten klingt jetzt nicht so tragisch
      Stimmt, am Anfang waren es mehr als 200.

      Ich habe mal eine Mitschrift angehängt (mit RX und TX) in einer Datei.

      Was mir dabei aufgefallen ist:
      a) der Fehler tritt immer bei der Temperatur Abfrage auf
      b) der Neustart des ESP8266 ist meiner Ansicht nicht vom Programm ausgelöst oder?
      das dürfe erst nach 2 Minuten der Fall sein Timeout TIMER1


      Pluto25 schrieb:

      Den Reset vom 05.12. 08:47:34 hat es selbst gemacht?
      Das ist mir auch aufgefallen (siehe oben)

      Horst
      Dateien
    • Hallo,

      ich habe direkt am ESP8266 eine 220uF Elko von 3,3V auf GND. Sollte der größer sein? Welche Größe?

      Ich habe auch einen Beitrag gefunden, der von sehr empfindlichem Reset Eingang am ESP spricht und wie man dies beheben könnte.

      Darf man hier im Forum einen Link darauf eintragen?

      Gruß
      Horst
    • Hallo Horst,
      in der ISR solltest du etwas ändern:
      Serielle_lesen:
      Pcmsk0.0 = 0 ' Solange Bits reinkommen, PCINT sperren
      Recbyte = Inkey(#1)
      Uartstring = Uartstring + Chr(recbyte) ' ASCII- Zeichen ans Ende des Pufferstrings anhängen
      Pcmsk0.0 = 1 ' PCINT wieder freigeben
      Return

      Dies ist eine ISR, beim Einsprung werden automatisch alle Interrupts gesperrt und beim Rücksprung wieder freigegeben. Du brauchst also keine INTs zu sperren, wobei du dies hiermit nur indirekt machst, indem du die Maske änderst.
      Tatsächlich solltest du im GIFR Register das Bit PCIF0 setzen:
      GIFR.PCIF0=1
      Andernfalls wird sofort nach Beendigung der ISR wieder ein Interrupt ausgelöst und versucht, ein neues Zeichen einzulesen. Das wird aber nicht synchron mit dem Ankommen von Bits gemacht, sodass da im besten Fall nur 0 eingelesen wird.

      Auch dir würde ich raten, das Abspeichern über Overlays zu machen, weil das Anhängen an den String viel zu langsam wird, wenn du lange Strings einliest.
    • Das mit dem DIM habe ich so eingetragen

      Dim Uartstring As String * 100
      Dim Uart_overlay(101) As Byte At Uartstring Overlay

      aber wie kommt jetzt die Variable "recbyte" in Uart_overlay ??

      Serielle_lesen:

      recbyte = Inkey(#1)
      Uart_overlay = Uart_overlay + Chr(recbyte) ' ASCII- Zeichen ans Ende des Pufferstrings anhängen

      GIFR.PCIF0 = 1 ' Bit 4 – PCIF0: Pin Change Interrupt Flag 0

      Return

      Und gleich noch eine Frage:
      Mach ich dann die Abfrage unter Uartstring oder Uart_overlay

      Du siehst, ich bin noch ganz an Anfang, aber lernfähig.

      Horst
    • Da Uart_overlay ein Array ist, machst du es so:

      BASCOM-Quellcode

      1. Serielle_lesen:
      2. Recbyte = Inkey(#1)
      3. Incr Bytes_received ' oben dann Dim Bytes_received As Byte
      4. Uart_overlay(Bytes_received )= recbyte ' ASCII- Zeichen ans Ende des Pufferstrings anhängen
      5. GIFR.PCIF0=1 'PCINT0 Flag löschen
      6. Return
      Du solltest dann gleich Bytes_receivedüberprüfen, damit es nicht größer als 120 werden kann. An geeigneter Stelle dann noch auf 0 zurücksetzen.
      Und wenn am Ende immer ein CR, LF oder CRLF ist, dann speicher die nicht mit ab. Und setze ein Flag, falls die gekommen sind, weil es erst dann Sinn macht, den Uartstring zu überprüfen.
      Die Abfragen kannst du dann so lassen, dann bleibt dein Code einfacher.

      Später würde ich mir mal überlegen, ob du von diesem fixen Ablauf weggehen willst. Dein Programm wird doch hängenbleiben, wenn nicht alle Strings exakt so übertragen werden, wie es erwartet wird.
    • Topgun schrieb:

      Das ESP sendet unterschiedlich.
      Außer bei sendebereitschaft ist immer? ein(oder mehrere) CrLf. Vielleicht so

      Quellcode

      1. Serielle_lesen:
      2. Recbyte = Inkey(#1)
      3. if recbyte = $3E then '>
      4. sendgo=1
      5. Bytes_received=1 'oder 0 bei Config base=0
      6. elseif recbyte=10 then ' Lf empfangen
      7. ** if Bytes_received<=2 then ' verwerfen weil zu kurz??
      8. ** Bytes_received=1 'oder 0 bei Config base=0
      9. ** else
      10. Uart_overlay(Bytes_received)= 0 'für Stringabschluß
      11. ** end if
      12. ** String_fertig_flag=1 '?????
      13. elseif Bytes_received >120 then
      14. ** Bytes_received=1 ' bei Überlauf neu anfangen???
      15. else
      16. Incr Bytes_received 'oben dann Dim Bytes_received As Byte
      17. Uart_overlay(Bytes_received )= recbyte 'ASCII- Zeichen ans Ende des Pufferstrings anhängen
      18. end if
      19. GIFR.PCIF0=1 'PCINT0 Flag löschen
      20. Return
      Alles anzeigen
      Ob die Zeilen mit den ** Sinvoll/brauchbar sind??
    • Hallo Horst,
      sorry, wenn die Frage etwas despektierlich ist, aber wirst du bei diesem Projekt eigentlich nach der Anzahl der Zeilen bezahlt ;) ?
      Ich tue mich echt schwer, deinen Code in BME280_1.6_111_1090.bas zu lesen.
      Ich habe den mal etwas aufgeräumt und die ganzen do..loop durch While ersetzt.
      Scheint für mich viel einfacher lesbar zu sein. Was denkst du?


      Quellcode

      1. Const Not_found = 0
      2. ' *** Wait for WIFI connected and WIFI setup
      3. Soft_timer = 0
      4. Start Timer1
      5. Uartstring = ""
      6. Print #2 , "ATE0" ' ESP8266 set auf No Echo
      7. While Instr(uartstring , "OK") = 0 : Wend
      8. Waitms 300
      9. Uartstring = ""
      10. Print #2 , "AT+CIFSR"
      11. While Instr(uartstring , "192.168.178.111") = Not_found : Wend
      12. Waitms 300
      13. Uartstring = ""
      14. Print #2 , "AT+CIPMUX=1"
      15. While Instr(uartstring , "OK") = Not_found : Wend
      16. Waitms 300
      17. Uartstring = ""
      18. Print #2 , "AT+CIPSERVER=1,1090"
      19. While Instr(uartstring , "OK") = Not_found : Wend
      20. Waitms 300
      21. Stop Timer1
      22. ' Die Hauptschleife wird nie beendet
      23. ' Das System ist jetzt gestartet und wartet auf den Temperaturabfrage Befehl
      24. Do
      25. '** BME280 auslesen
      26. Call Read_bme280_value()
      27. 'List die unkompensierten Wert vom Sensor,
      28. 'diese werden in Ut, Uh abgelegt
      29. '** Temperatur
      30. Temp = Temperatur()
      31. Temp_int = Temp
      32. Temp_string = Str(temp)
      33. 'Gibt die Temperatur in °C zurück, die Auflösung beträgt 0.01°C
      34. 'Der Wert 02415 entspricht 24.15°C
      35. '** Luftfeuchte
      36. Humi = Humidity()
      37. Humi = Humi / 10
      38. Humi_int = Humi
      39. Humi_string = Str(humi)
      40. 'Gibt die Luftfeuchtigkeit in % zurück, die Auflösung beträgt 0.001hPa
      41. 'Der Wert 04633 entspricht 46.33%
      42. Soft_timer = 0
      43. Start Timer1 ' sollte innerhalb 2 Min. keine Abfrage kommen, dann Reset
      44. 'Subroutine 1-Wire Temp-Sensor lesen
      45. Uartstring = ""
      46. While Instr(uartstring , "+IPD,0,8:TEMP=?") = 0 : Wend ' Wir antworten nur auf eine Verbindung, auf Verbindung 0
      47. Set Porta.3
      48. Waitms 300
      49. Reset Porta.3
      50. ' Unsere Antwort an Verbindung 0 besteht aus 5 Zeichen
      51. Uartstring = ""
      52. Print #2 , "AT+CIPSEND=0,7"
      53. While Instr(uartstring , ">") = Not_found : Wend
      54. Waitms 300
      55. Uartstring = ""
      56. Print #2 , Format(temp_string , "00000") 'Print #2 , Temp
      57. While Instr(uartstring , "SEND OK") = Not_found : Wend
      58. Uartstring = ""
      59. While Instr(uartstring , "+IPD,0,8:HUMI=?") = Not_found : Wend
      60. Set Porta.3
      61. Waitms 300
      62. Reset Porta.3
      63. ' Unsere Antwort an Verbindung 0 besteht aus 5 Zeichen
      64. Uartstring = ""
      65. Print #2 , "AT+CIPSEND=0,7"
      66. While Instr(uartstring , ">") = Not_found : Wend
      67. Waitms 300
      68. Uartstring = ""
      69. Print #2 , Format(humi_string , "00000") 'Print #2 , Humi
      70. While Instr(uartstring , "SEND OK") = Not_found : Wend
      71. Uartstring = ""
      72. While Instr(uartstring , "0,CLOSED") = Not_found : Wend
      73. Stop Timer1
      74. Loop
      Alles anzeigen
      Ich habe übrigens gerade bemerkt, dass dein Programm ja gar nicht hängen bleibt, wenn nicht die korrekte Abfolge kommt. Allerdings resettet der Controller dann, was ja auch nicht die feine Art ist.
      Und wenn dir do..loop besser gefällt geht das auch so gut zu lesen:
      Do : Loop Until Instr(uartstring , "SEND OK") > 0

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Franz ()

    • Franz schrieb:

      Allerdings resettet der Controller dann, was ja auch nicht die feine Art ist.
      Sicher, aber damit arbeitet es zuverlässig. Was wäre besser?
      Einige Fehler könnte es noch abfangen vor Flashende, Evt einige Statusabfragen um wieder in die Spur zu kommen? Oder den letzten String genauer untersuchen ? War da ein ready/GotWifi/Connect ?
      @Topgun Es könnte Aufschluß geben wenn der Tiny den letzten String ausgibt bevor er neustartet.
      Vielleicht ist es nicht immer Sock 0, würde es von 1 oder 2-4 kommen gibts auch ein Timeout
      Ist die CIFSR Abfrage hilfreich? Bekäme es eine andere IP resettet er bis es "bricht"
      @Franz ein Not_found anstelle 0. Du wirst nach Buchstaben bezahlt? :D
    • Pluto25 schrieb:

      Sicher, aber damit arbeitet es zuverlässig. Was wäre besser?
      Während der Fehlersuche ist es für mich vollkommen akzeptabel.
      Aber als finale Lösung würde ich sowas nicht einbauen, gerade wo eine serielle Verbindung immer mal ein Zeichen falsch übertragen kann.
      Dies scheint mir eine typische Anwendung für eine State Machine zu sein.
      Von jedem Zustand zum nächsten ist eine bestimmte Aktion (Print) und eine Antwort (UartString) notwendig.
      Dies lässt sich schön und vor allem lesbar und wartbar umsetzen. Den Reset im Notfall kann man immer noch machen.
      Aber das wäre sicherlich eine größere Änderung in seinem Programm, allerdings wird die auch immer größer, je später man sie macht.

      Pluto25 schrieb:

      @Franz ein Not_found anstelle 0. Du wirst nach Buchstaben bezahlt?
      Lesbarkeit ist für mich wichtiger.
    • Hallo Franz, Hallo Pluto25,

      ich siehe, ich bin in guten Händen.
      Nein, ich werde nicht nach Zeilen bezahlt. :D
      Im Serielle_lesen sind bei mir 2 Zeilen und bei dir? Bitte nicht ernst nehmen. ^^


      Pluto25 schrieb:

      Es könnte Aufschluß geben wenn der Tiny den letzten String ausgibt bevor er neustartet.
      Vielleicht ist es nicht immer Sock 0, würde es von 1 oder 2-4 kommen gibts auch ein Timeout
      Ist die CIFSR Abfrage hilfreich? Bekäme es eine andere IP resettet er bis es "bricht"
      Die CIFSR Abfrage ist nicht unbedingt notwendig. Ist eigentlich noch ein Überbleibsel aus der Fehlersuche.

      Das mit dem letzten String ausgeben überlege ich auch schon, habe aber noch keine Idee wie.

      So jetzt zu euren Vorschlägen:

      Das mit der "While" Abfrage ist sehr gut und ich habe es auch umgesetzt. Das mit "Not_found" verstehe ich nicht. Was bewirkt das?

      Das mit dem neuen "Serielle_lesen" funktioniert leider nicht und ich verstehe nicht warum.

      Ich hab das Programm angehängt. Nicht wundern, dass ist nur für die Temperatur Sensoren.


      Zum Schluss, alle Änderungen haben bisher keine oder nur wenig gebracht. Ich versuche parallel mit der Hardware noch Verbesserungen zu erreichen. Die Hoffnung ....

      Ich hoffe, ihr habt noch Ideen.

      Horst
    • Topgun schrieb:

      Im Serielle_lesen sind bei mir 2 Zeilen und bei dir? Bitte nicht ernst nehmen.
      Ich meine die in den allermeisten Fällen überflüssigen Leerzeilen, die den Code für mich schlecht lesbar machen. Aber vielleicht ist bei euch ja nicht so.

      In der ISR musst du überall
      Bytes_received =0
      schreiben, da ja erst inkrementiert wird und dann abgespeichert.
      Diese Zeile muss dann entsprechend geändert werden:
      Uart_overlay(bytes_received+1) = 0 'für Stringabschluß
      und hier auch
      Elseif Bytes_received = 20 Then

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Franz ()