Hallo Andreas,

davon gehe ich aus. Wenn ich die dallstempsensor wieder auskommentiere ist die Fehlermeldung weg und kompilieren läuft durch.
Habe jetzt auch einen Mega angeschlossen

Beste Grüße

Peter

Hallo Andreas, hallo Philipp,

danke für die Tipps, leider bislang noch ohne Erfolg oder ich übersehe was.

- Sketch Z21 ESP8266 UDP v32 + 4.92 die selbe Konfiguration wie Andreas mit Ausnahme von Uref-Wert und ich habe den NTC statt 18B20 drin --> keine Besserung
- Sketch Z21 ESP8266 UDP v32 + 4.90 unveränderte Konfiguration --> keine Besserung
- Sketch Z21 ESP8266 UDP v27 --> keine Einwahl vom Smartphone ins Z21 WLAN möglich
- Sketch Z21 ESP8266 UDP v31 + 4.90 unveränderte Konfiguration --> wie v32, keine Besserung
- Wemos + Sketch Z21 ESP8266 UDP v32 + 4.90 --> keine Besserung
- Sketch Z21 ESP8266 UDP v32 + 4.92 unveränderte Konfiguration mit Ausnahme von Uref auf neuem Arduino Mega --> keine Besserung

Kann beim ESP8266 auch irgendwas im Speicher bleiben wie beim Arduino im EEPROM, dass mir hier Probleme macht? Der erste Wemos war jungfräulich beim ersten Einsatz auf der Zentrale mit v27 Sketch. Auf dem zweiten Wemos war zuvor WLED.

Ich habe jetzt für den Mega mit Debugging kompiliert und per USB den Serial Monitor angeschlossen.

Zitat von Holger28 im Beitrag #2177

---

1
2
3
4
5
6
7
8
9
10
11
 

WiFi-AP: OK
SSIP-AP: 192.168.0.111
PASS-AP: Z21_ESP
CHAN-AP: 12345678
WiFi-CL: 6
SSIP-CL: (IP unset)
PASS-CL: lauter spiegelverkehrte Fragezeichen
ESP-S88: lauter spiegelverkehrte Fragezeichen Z21_ESP lauter spiegelverkehrte Fragezeichen
ESP-Version: 62
 
 

---

 #define Z21DATADEBUG //to see RAW DATA of Z21 LAN Protokoll 
 

mit einschalten.

Ich habe jetzt extra Andreas Hardware Zentrale angeschlossen und mich mit zwei Apps daran verbunden (Z21PG-Version: v4.30; ESP-Version: v3.20).
Wenn du auf der APP die Daten, welche durch ein anderes Gerät geändert wurden nicht direkt dargestellt bekommst, könnte das an den nicht abonierten BC-Flags liegen. Um die App zu zwingen diese Daten zu senden muss sie komplett beendet werden (Task schließen). Dann die App starten nachdem die Zentrale bereit ist, so kann sich die App korrekt an der Zentrale registrieren.
Bei mir stellen sich die Änderungen 1:1 und egal auf welchem der beiden Geräten getätig, sofort auf dem anderen dar.

Es könnte aber auch bei dir an der Serial Kommunikation mit dem ESP liegen. Aber das sieht man auch wenn du den Flag oben aktiviert hast. Die umgedehten Fragezeichen bei der SSIP-CL und PASS-CL sind bei dir vorhanden, weil der ESP keine Zugangsdaten zu deinem privatem WLAN in der Weboberfläche eingetragen wurden.

Hallo Philipp,

ja, der Versatz ist in der Konsole so.

Ich habe auf der Zentrale vom 5V-Regler 4,88 V und 12V sind 11,33 V. Das waren aber auch die Werte am Anfang. Der Wemos erzeugt auf den 3,3 V 3,29 V, passt.

Wenn ich den Sketch auf das Wemos mit 80MHz flashe (ja, Philipp ich sollte eigentlich 160 MHz nehmen) habe ich eine Verzögerung in der App von nur etwa 1 s. Verbinde ich zwei Geräte dauert es 3-6 s und die Verbindung bricht auch mal ganz ab, kommt aber wieder. Ist aber nicht nutzbar und die Fehlermeldung EE Flush! kommt.
Mit nur einem Gerät ist die Steuerung halbwegs stabil, wenn auch nicht so wie erwartet und ich habe die "EE Flush!"-Fehler nicht.

Ich hoffe das gibt Hinweise auf mein Problem.

Viele Grüße,
Holger

Hallo Zusammen,

heute wollte ich mal meinen Railcom Rückmelder updaten. Bisher lief darauf V37 und das funktioniert einwandfrei.
So nahm ich den Sketch V41, änderte noch den Loconet TX Pin auf 13, damit es mit meiner Hardware arbeitet.
Als weitere Einstellung nahm ich nur #define LCD2SERIAL, da ich ich kein Display brauche.
Den Sketch auf einen neuen Nano gespielt und den seriellen Monitor gestartet. Da zeigt er auch brav die erste Blockadresse an sowie die acht Standardwerte.
Kalibrieren läßt er sich mit D5 an Masse, die neuen Werte werden im seriellen Monitor angezeigt.
Habe ich nun eine Lok auf dem Gleis oder einen sonstigen Verbraucher, dann tut sich nichts, keinerlei Anzeige, auch keinerlei Rückmeldung über Loconet. Das gilt für alle 8 Eingänge.
Den Nano wieder gewechselt, mit V37 funktioniert es. Ich testete weitere Nanos mit V41, da war keine Funktion ausser dem Kalibrieren.
Loconet Library ist 1.1.4
Hat jemand eine Idee was ich falsch mache bzw was ich noch probieren könnte?

Hallo Ralf,
folglich hast du auch in der funktionierenden Version V37 Loconet TX Pin auf 13 geändert.
Hast du in der V37 sonst noch etwas geändert damit die Hardware passt und bei V41 vergessen?
Ich würde define LCD2SERIAL wieder aktivieren. Möglicherweise hat dein #define LCD2SERIAL ein Timingproblem verursacht.
Es ist immer schlecht mehrere Änderungen zeitgleich vorzunehmen. Immer nur 1 Änderung und testen.
Volker

Hallo Holger,

also "EE Flush" bedeutet, dass der ESP die Serial Daten vom Arduino nicht verstanden hat! Das "Z21 OK" zeigt, dass der ESP und der Arduino immer wieder ein "sync" der Datenrate (Baud) am Serial durchführen.
Was bedeutet das für dich, der ESP erhält fehlerhafte Daten!
- Wie ist dein Aufbau des Spannungsteilers am Serial RX des ESP8266?
- Was wird auf der ESP Konfigurationswebseite unten bei "Run at Baudrate: ..." angezeigt? Ändert sich dies über x Zeit (Seite zum Update mit F5 aktualisieren)?

@ralfio: Ralf, schaue doch mal Bitte in dem v37 nach, welchen Zustand #define NOSCOTTY dort im Sketch hat? Dies hat Auswirkungen auf die Empflindlichkeit der Rückmeldeeingänge.

Hallo Philipp,

ich nutze die Platine von Andreas, WIFI_RX und WIFI_TX vom D1 mini sind 1:1 mit dem Mega verbunden ohne Spannungsteilser oder Diode nach GND wie in älteren Plänen mal vorgesehen.

Die Baudrate ist 500000 und ändert sich auch bei Fehlern nicht.

Nachtrag: Ich habe einen 470 Ohm Widerstand zwischen RX vom ESP 8266 und MEGA gesteckt und nun habe ich keine Fehler (EE Flush) mehr, nur noch die langsame Reaktionszeit. Ich probiere nochmal 160 MHz aus.
2.Nachtrag: mit 160 MHz und 2 Geräten anfangs langsame aber synchrone Rückmeldung, aber nach einer kurzen Weile wieder EE Flush. Wieder bei 80 MHz 1 Gerät Steuerung anfangs ok, später kommen immer häufiger EE Flush-Meldungen.
3. Nachtrag:
- 80 MHz 1 Gerät ohne Rückmelder am LN angeschlossen: fast fehlerfreie Nutzung.
- anschließen des Rückmleders am LN ergibt einige Fehlermeldungen, ohne dann wiedr weniger
- 2. Gerät angemeldet: sofort deutlich mehr Fehler, Synchronisierung der Anzeige noch viel langsamer
- zusätzlich LN angeschlossen, ähnliche Fehlerzahl
- das ganze lief etwa 15 Minuten dann stieg der Wemos aus, sprich keine WLAN-Verbindung mehr vorhanden

Sieht meines Erachtens nach einem Problem bei zuviel Datenverkehr aus, wenngleich das eigentlich nicht zu viel sein sollte.

Viele Grüße,
Holger

Hallo Holger,

die Menge der Daten kann bei einem Rückmelder nicht "zu viel" sein. Kannst du bitte mal den "#define DALLASTEMPSENSE" deaktivieren, dieser macht immer noch Fehler in dem Moment wo er gelesen wird.
Was mich wundert ist die Verschiebung auf deinem Serial Monitor und das der Wemos ESP8266 bei dir nach max. 15 Minuten nicht mehr arbeitet. Hier ist doch vielleicht ein Spannungsproblem möglich. Du betreibst deine Zentrale mit einem 20,0 Volt Netzteil?
Ich habe hier über Sunden hinweg die Zentrale ohne Reset aktiv und kein Abbruch oder Ausfall des ESP8266.

Hallo Philipp,

Den Dallas habe ich nicht verbaut und nicht aktiviert. Ja, ich habe ein 20 V Netzteil. Soll noch auf 15 geändert werden.

Spannungen auf der Zentrale 11,3 und 4,9V

Viele Grüße,
Holger

Hallo Holger,

um das Verhalten deiner Zentrale nachzuvollziehen habe ich jetzt mal drei Apps (IOS, Android App alt, Android App neu) direkt mit dem ESP Acesspoint verbunden (Connected Clients: 3 of 4). Es gibt bei mir an Andreas Aufbau kein "EE Flush!" oder "Z21 OK". Auch nach starker Nutzung mit der aktuellen Software.
Ich kann den "Z21 OK", dass passiert wenn der ESP seine Baudrate einstellt nur simulieren, indem ich bei diesem im Betrieb einen Reset durchführe.
Ich betreibe dabei die Zentrale mit einem 16 Volt 4A Netzteil.
Da es ja vorher funktioniert hat - schreibe doch mal Bitte welche Version du im Boardverwalter für den ESP8266 geladen hast. Ich bespiele dann auch mal den ESP neu mit der 3.0.2?
Bild entfernt (keine Rechte)

Hallo Philipp und Volker,

erst einmal vielen Dank für eure Hinweise.

@VolkerS: Bei der V37 war der TX Pin standardmäßig auf D13 gelegt, die Hardware war entsprechend aufgebaut. Ebenso ist 'define LCD2SERIAL in der V41 aktiv.
@Philipp: define NOSCHOTTKY ist in V37 und V41 auskommentiert. Macht ja auch Sinn, da ich SB330 Dioden benutze.

Hallo Philipp,

Ich habe die Version 3.0.2 der ESP8266 Boards. Aber wenn du mir deine Version nennst kann ich meine auch mit der älteren Version testen. Ich sollte ja eher versuchen mich dem funktionierenden System anzunähern als das du deine demontierst 😉
Aber ich nehme mal an, du versuchst den Fehler nachzuvollziehen.

Viele Dank,
Holger

Hallo Holger,

ja so ist es. Erstmal muss der Fehler auch bei mir auftreten, dann kann ich Ihn auch lokalisieren.
Sooooo, Fehler ist lokalisiert aber nicht gefunden!

EE FLUSH!
EE FLUSH!
1 Z21 RX: A 0 40 0 E4 13 0 17 92 72 WLAN ok
1 Z21 TX: 8 0 A1 0 0 0 17 92 
LnTX: A0 01 12 4C 
1 Z21 TX: E 0 40 0 EF 0 17 4 92 0 0 0 0 6E 
1 Z21 RX: A 0 40 0 E4 13 0 17 80 60 WLAN ok
1 Z21 TX: 8 0 A1 0 0 0 17 80 
LnTX: A0 01 00 5E 
1 Z21 TX: E 0 40 0 EF 0 17 4 80 0 0 0 0 7C 
1 Z21 RX: A 0 40 0 E4 13 0 17 80 60 WLAN ok
1 Z21 TX: 8 0 A1 0 0 0 17 80 
LnTX: A0 01 00 5E 
1 Z21 TX: E 0 40 0 EF 0 17 4 80 0 0 0 0 7C 
1 Z21 RX: 7 0 40 0 21 24 5 WLAN ok
1 Z21 TX: 8 0 40 0 62 22 0 40 
EE FLUSH!
EE FLUSH!
EE FLUSH!
 
 

Fazit die aktuelle Version 3.0.2 aus dem Boardverwalter für den ESP8266 ist nicht nutzbar!
Jetzt geht meine Zentrale auch nicht mehr und wir müssen zur Behebung ersteinmal die letzte funktionierende Version finden. Ich hatte ja leider auch immer auf update geklickt und dann in der Zwischenzeit keinen ESP für die Zentrale mehr bespielt.
Ich denke mal hier gibt es in der aktuellen Version ein Timing Problem. Ich habe übrigens auch die Verschiebung der Konfigurationsdaten vom ESP im Serial Monitor.

Update: Ändern der Baudrate für die Übertragung anstatt 500000 nur 115200 bringt keine Verbesserung!

Dann kann ich mich noch mit Ralf seinem Problem befassen.

Hallo Philipp,

das Durchprobieren ging jetzt schneller als erwartet. Die Versionen 3.0.1 und 3.0.0 verhalten sich wie 3.0.2, 2.7.4 funktioniert tadellos. Beide Apps zeigen in Echtzeit die Eingaben an und EE Flush kommt gar nicht vor.

Ich habe auf die Github-Seite nach dem Changelog geschaut, bin aber noch nciht fündig geworden. Ich befürchte aber auch, dass ich mangels Kenntnis gar nciht den relevanten Punkt erkenne

Viele Dank und Grüße,
Holger

Hallo Philipp, hallo Holger,

die Erfahrung habe ich letztes Jahr auch machen dürfen und habe darüber hier berichtet. Je nach ESP8266 musste ich bis auf V2.4 für den Boardverwalter zurück gehen. Dies war damals mein verzweifelter letzter Versuch, nachdem die Module sich ständig weigerten eine stabile Verbindung zum Mega aufzubauen.

Hallo Zusammen,

mal wieder eine Wasserstandsmeldung. Ich habe mal den Lötkolben angeworfen und den Pin 7 anstatt 13 belegt. Dann noch die neueste Version V42 geladen und auf den Nano gespielt. Siehe da, jetzt funktioniert es. Ich möchte mich jetzt nicht beschweren 😁 aber warum funktioniert es jetzt?

BTW: Ich hatte festgestellt, dass beim Aufspielen eines neuen Sketches der EEPROM wohl nicht immer sauber überschrieben wird, da waren oft die kalibrierten Werte und die erste Blockadresse von vorherigen Versuchen noch erhalten. Zumindest passiert das wenn der Sketch über die USB Schnittstelle hochgeladen wird. Ich habe daraufhin mal einen USBasp genommen und den Sketch mittels "Hochladen mit Programmer" übertragen. Da wird dann auch der EEPROM zuverlässig überschrieben.

Hallo zusammen,

wie in den USB-Mitschnitten auch gestern schon z. T. zu sehen war, habe ich immer wieder mal die POWER 1 Meldung, d. h. der Bahnstrom bleibt zwar eingeschaltet, die Loks erhalten aber den Stopp-Befehl und die Power-LED blinkt in kurzer Frequenz, also nicht wie Power off (wobei die App das wie Bahnstrrom aus anzeigt, blau blinkendes Symbol), was durch gleichmäßiges an/aus/an signalisiert wird. Im USB-Debug kommt leider nur die Meldung Power 1, sonst habe ich darin keine Systematik gefunden, was unmittelbar davor passiert und als Auslöser fungiert.

Das passiert im Fahrbetrieb z. T. direkt eine Sekunde nach dem wieder Einschalten über den Taster an der Zenrale oder alternativ über die z21-App oben rechts Stop-Taste. Z. T dauert es aber auch mehrere Minuten bis dieser Zustand eintritt.

Ich kann das Verhalten auch reproduzieren, wenn die Zentrale ohne jeglichen Anschlüße gestartet wird, also weder Gleis, noch Belegtmelder, USB und LAN sind angeschlossen, also nur das Netzteil für die Zentrale.
Auch mit abgezogenem Wemos tritt das auf.

Was ist denn gewöhnlich der Auslöser für diesen Zustand?
Welche Bedeutung haben jeweils die drei Blinkzustände: lang aus, kurz an / an, aus gleich lang / kurz aus, lang an?

Nachtrag: Ich habe Rocrail aufgesetzt und die Meldung dort beim Ausschalten lautet:
LAN_X_BC_STOPPED (192.168.8.95)

Viele Grüße,
Holger

Hallo Holger,

der Taster für die Gleisspannung hat zwei Funktionen. Entweder Gleisspannung aus oder alle Loks stoppen. Die Grundfunktion kann dabei über die App eingestellt werden.
Bild entfernt (keine Rechte)
Der Taster kann aber trotzdem beides, je nach Einstellung über die App kann mit einem kurzen Druck die Gleisspannung oder Nothalt ausgelöst werden. Mit einem langen Druck größer 1,2 sec. kann die andere Aktion ausgelöst werden.
Die LED stellt den Zustand folgendermaßen dar:
- langsames Blinken = Gleisspannung aus = Power 2
- dauerhaftes Leuchten = Gleisspannung ein = Power 0
- schnelles Blinken = Nothalt / Lok stopp = Power 1
Im Serial Debug wird, immer durch einen Zusatz davor angezeigt wenn der Power Zustand durch den Taster geändert wurde!

Hallo Philipp,

ja, irgendwie war mein Debug-Protokoll nicht gesprächiger. Ich hatte ja auch alles an DEBUG bis auf LN_RAW und XN eingeschaltet.

der Taster ist direkt zwischen GND und Pin 47 ohne Widerstand angeschlossen. Eigentlich ist der interne Pullup in dem Sketch der 4.92 aktiviert.

1207 pinMode(Z21ButtonPin, INPUT_PULLUP); //Turn on internal Pull-Up Resistor
 

Ich könnte aber von PIN47 über einen 10 k auf 5 V gehen. Oder wird der Widerstand in Kombination mit dem internen dann evtl. zu groß?

Viele Grüße,
Holger

Hallo Andreas, die Platinen die nach deinen Gerberfiles gefertigt wurden sind nun bei mir gelandet. Dabei ist mir etwas aufgefallen. Auf dem Bestückungsaufdruck fehlt eine Bezeichnung für einen Widerstand und zwar der unter dem Arduino links oben neben R1/2 oberhalb der Zenerdiode. Was hat der für einen Wert? Und zu Sicherheit auch noch dies: Der Schaltregler-Baustein - ich verwende ja nicht mehr die kleinen mit denen ich bei der Zentrale Schiffbruch erlitten habe - wenn man auf die Platine schaut Links Ein - Masse - Aus . Das stimmt doch so. Ansonsten nochmal herzlichen Dank für deine Mühe und die Files.

Gruß Jürgen

P.S. Wenn ich mir das auf dem Plan anschaue scheint das der Vorwiderstand der LED zu sein? Und der Wert ist abhängig von der Betriebsspannung ? Liege ich da richtig?

War zu spät ! 😉👍

Hallo Jürgen,

den Plan zum Bestücken findest du hier. In der Bauteile.zip, in der PDF-Datei "melder1". Du meinst sicher den Vorwiderstand 560 Ohm der LED.
RE: Suche Erfahrungsaustausch zur Z21 nach Philipp Gahtow (83)

Der Spannungsregler ist als z.B. L7805 geplant, hier kannst du es auch zur Sicherheit im Datenblatt nachlesen.

Viele Grüße
Andreas

Hallo Holger,

Zitat von Holger28 im Beitrag #2196

---

ja, irgendwie war mein Debug-Protokoll nicht gesprächiger. Ich hatte ja auch alles an DEBUG bis auf LN_RAW und XN eingeschaltet.

---

Button Power: 2
 

Die für die anderen Änderungen am Powerzustand wird dann nur "Power" dargestellt.
Leider kann man aufgrund der "EE FLUSH!" problematik aus dem Log nicht erkennen wer der Auslöser ist!

Zitat von Holger28 im Beitrag #2179

---

1
2
3
4
5
6
7
8
9
10
11
 

1 Z21 RX: 9 0 40 0 E3 F0 0 7 14 WLAN ok
1 Z21 TX: E 0 40 0 EF 0 7 C 80 0 8 0 0 6C 
1 Z21 RX: 9 0 40 0 E3 F0 0 1 12 WLAN ok
1 Z21 TX: E 0 40 0 EF 0 1 C 80 0 0 0 0 62 
1 Z21 RX: 7 0 40 0 21 24 5 WLAN ok
1 Z21 TX: 8 0 40 0 62 22 0 40 
EE FLUSH!
EE FLUSH!
EE FLUSH!
Power: 1
 

---

Hallo Philipp,

so, alles an Debugging eingeschaltet bis auf XN. Ich habe immer die letzten paar Meldung vor einer "Power: 1" Meldung kopiert imer getrennt durch die -------------. Mit 4.92 (HTTP und DHCP aktiviert, sonst alles auf Standard belassen)