GSM Modul unbekannter Effekt um Mitternacht

International Deutsch
1

Hallo zusammen,

Ich melde mich bei euch da ich jetzt bereits seit 5 Tagen an meinem Problem herumbastle und einfach nicht herausbekomme an was es liegt.
Hoffe jemand von euch hat bereits eine ähnliche Erfahrung gemacht oder hätte einige Lösungsansätze.

Ich habe drei GSM Module mit jeweils einen Arduino Mega 2560 welche sich untereinander SMSen schicken, um bestimmte Steuerungsaufgaben zu übernehmen. GSM 1 schickt zu GSM 2 einen Schaltbefehl und GSM 2 zu GSM 3 einen Befehl.
Das funktioniert alles einwandfrei bis es 00:01Uhr am Abend wird.

Nämlich genau dann passiert, dass GSM 2 eine Stunde lang keine SMS von GSM 1 empfangen kann, obwohl dieser eine SMS aussendet. Alle 15sec wird ein AT Befehl vom Mega zum GSM Shield geschickt um zu sehen ob eine SMS vorhanden ist. Obwohl es immer funktioniert, beginnt genau ab Mitternacht der Effekt, dass GSM 2 eine Stunde lang keine SMSen bekommt. Erst um 01:01 bekommt dieser eine SMS. Dasselbe passiert bei GSM 2 zu GSM 3. Ich verschicke alle 3 Minuten eine SMS wenn ich keine Rückantwort bekomme. Das summiert sich dann dementsprechend innerhalb einer Stunde.

Ich bin wirklich ratlos an was dieses Problem liegen kann. Interessanterweise hinken alle GSM Module 1 Stunde der echten Zeit hinterher. Sprich wenn es 00:01 ist, ist es am GSM Modul (laut empfangener SMS) 23:01 Uhr. Ich habe bereits mittels RTC und dem CCLK AT-Befehl die richtige Uhrzeit eingestellt. Selbiges Problem.
Weiterhin hinken alle der echten Uhrzeit eine Stunde hinterher. Diese falsche Zeit steht immer in der Antwort auf die Frage ob eine neue SMS vorhanden ist. Der RTC jedoch besitzt die richtige Uhrzeit.

Wenn ich per Handy (richtige Uhrzeit) eine SMS an das GSM Modul sende wird mir plötzlich die richtige Uhrzeit angezeigt. Wenn die GSM Module untereinander kommunizieren nicht. Dann wieder die Stunde hinterher.

Könnte es evtl daran liegen das ab Mitternacht eine Stunde lang keine SMS empfangen wird oder gibt es da noch andere Möglichkeiten?

Um 16.43Uhr gesendet mit meinem Handy bekomme ich vom GSM Modul:

- - - Funktion IsSMSAvailable - - -
Empfangen in Unread: +CMGL: 1,"REC UNREAD","+43660****","","2020/04/05 16:43:00+08"

Um 16.43Uhr gesendet von GSM 1 zu GSM 2 bekomme ich als Antwort:

- - - Funktion IsSMSAvailable - - -
Empfangen in Unread: +CMGL: 1,"REC UNREAD","+4368*****","","2020/04/05 15:43:00+04"

Über den CCLK-Befehl habe ich, wenn ich obige Uhrzeit berücksichtige, folgendes Format geschrieben (ohne Zeitverschiebung am Ende, sprich +00):

AT+CCLK="20/04/05,16:43:00+00"

Die entsprechende Antwort war "OK".

Den Code wie ich nach einer SMS abfrage, kann ich gerne noch posten. Im Endeffekt sende ich nur folgendes Kommando alle 15 Sekunden:

GSMSerial.write("AT+CMGL=\"REC UNREAD\",1\r");

Über eine Antwort würde ich mich sehr freuen!

2

Bist Du sicher daß es kein Problem des Providers ist, daß dieser die SMS nicht gleich weiterleitet?

Grüße Uwe

3

uwefed:
Bist Du sicher daß es kein Problem des Providers ist, daß dieser die SMS nicht gleich weiterleitet?

Dann würden die aber irgendwann gesammelt ankommen.

Für mich hört sich das eher so an, das irgendwo im Code die Uhrzeit eine Rolle spielt.

Denn wenn es um 1:00 weiter geht, dann könnte bis dahin im Code 25:00 Uhr sein....
Oder Umstellung MEZ/MESZ verpasst...
Oder...

@OP: Gibt doch mal den Code. Bitte nicht um vermeintliche nicht benötigte Sachen gekürzt.

4

Bist du denn sicher, dass die SMS auch in der Zeit gesendet wird ?
Wie prüfst du das ?

5

Je öfter ich Deine Ausgaben lese, umsomehr kommt mir der Verdacht auf, das mit der Uhr auf den Modulen was nicht passt.

Erst war ich der Zeitzone gefolgt.
Um 16:43 gesendet würde bedeuten 16:43:00+02. (UTC+2)
Ausgegeben wird:

Um 16.43Uhr gesendet mit meinem Handy bekomme ich vom GSM Modul:

- - - Funktion IsSMSAvailable - - -

Empfangen in Unread: +CMGL: 1,"REC UNREAD","+43660****","","2020/04/05 16:43:00+08"



[/code]

Das wären 6 Stunden daneben. (UTC+8)

Am nächsten Modul:

Um 16.43Uhr gesendet von GSM 1 zu GSM 2 bekomme ich als Antwort:

- - - Funktion IsSMSAvailable - - -

Empfangen in Unread: +CMGL: 1,"REC UNREAD","+4368*****","","2020/04/05 15:43:00+04"



[/code]

wären das 2 Stunden daneben (UTC+4)

Und hier

Über den CCLK-Befehl habe ich, wenn ich obige Uhrzeit berücksichtige, folgendes Format geschrieben (ohne Zeitverschiebung am Ende, sprich +00):

AT+CCLK="20/04/05,16:43:00+00"

Die entsprechende Antwort war "OK".

sind das -2 Stunden daneben (UTC+0)

Aber das hinkt. Du beachtest die Zeitzone garnicht.

Am Modul 2 stimmt jedoch die Zeit nicht. Die Uhr läuft 1 Stunde nach. "2020/04/05 15:43:00+04" Mich würde es nicht wundern, wenn sich das damit auflöst.

6

Danke für eure Antworten!

Ein Problem des Providers kann ich leider nicht ausschließen.
Die SMSen kommen teilweise zu einem späteren Zeitpunkt wieder an! Dabei aber nicht vollständig, oftmals fehlen mehr als die Hälfte der Nachrichten.
Beispielsweise kommen die um 23Uhr gesendeten SMSen erst um 01:20 oder noch später an. Ich habe dazu jedoch ein Unterprogramm programmiert welches sich immer die Uhrzeit der letzten Nachricht merkt. Is die Uhrzeit der neuen Nachricht älter als die der letzten (SMS die vor einigen Stunden schon abgesendet wurde) wird diese ignoriert. Dieses Programm erfüllt seinen Zweck.
Das Problem mit der Uhrzeit, sprich die 1 Stunde um Mitternacht wo nichts empfangen wird, trat schon vor Implementierung dieses Unterprogramms auf!
Ich werde morgen aber mal beim Provider anrufen und fragen ob es hier ggf. irgendwelche Umstellungen um Mitternacht gibt.

Denke auch das die Uhrzeit im Code bzw. auf den Modulen eine Rolle spielt. Im Code selbst habe ich keine Verwendung für die Uhrzeit. Außer oben genanntes Unterprogramm, wobei ich jedoch die Uhrzeit der SMS heranziehe, sprich was als Antwort zum AT Kommando zurückkommt, siehe Post davor.
Dies kann aber nicht die Fehlerquelle sein, da die Effekte bereits vor der Implementierung dieses Unterprogramm aufgetreten ist.

Ob die SMS auch in der Zeit gesendet wird lasse ich mir nicht auf dem Serial Monitor ausgeben. Jedoch bekomme ich zeitgleich wenn eine SMS vom GSM 1 Modul zum GSM 2 Modul gesandt wird, eine weitere SMS zeitgleich auf mein Handy. Somit kann ich dies nachverfolgen.
Ich werde jedoch für diese Nacht testweise mir ebenfalls die Zeit bei jedem Sendeversuch via Serial Monitor ausgeben!

Ebenso werde ich die Rückantwort des Kommandos ob eine neue SMS vorhanden ist (alle 15 Sekunden) mir am Serial Monitor ausgeben lassen. Eventuell sehe ich hier zu Mitternacht einen Effekt oder eine merkwürdige Antwort des Moduls

  • 16:43:00+02. (UTC+2) Okay das ist die richtige Zeit.
  • Antwort des GSM Moduls wenn ich eine Nachricht per Handy sende: 16:43:00+08 Das sind 6 Stunden daneben, stimmt. Kann mir aber nicht erklären warum hier +8 in der Antwort steht.
  • Antwort des GSM Moduls wenn ein Nachricht von einem anderen GSM Modul gesendet wird: 15:43:00+04. Das wären dann 2 Stunden daneben.
  • Und das war mein Eingriff in die Zeit des Moduls, so habe ich sie gestellt: AT+CCLK="20/04/05,16:43:00+00"

Das Problem ist nur, egal wie ich die Uhrzeit per Kommando stelle, die SMS welche am Modul ankommt, besitzt entweder +08 wenn die Nachricht von meinem Handy kommt oder +04 wenn die Nachricht von einem anderen GSM Modul kommt. Da lässt sich nichts dran ändern.
Wenn ich per Kommando die Uhrzeit der CCLK abfrage, kommt genau diese, die ich auch eingestellt hatte. Die +00 eben.

Das Programm selbst ist sehr lange. Ich habe hier mal die paar wichtigsten Unterprogramme rauskopiert. Das gesamte Programm werd ich im Anhand dazuhängen. Das wichtigste und wo eben was passieren kann sind die genannten Unterprogramme, die hier folgen!
Danke schon mal für den Input!
*Edit, leider sind die Unterprogramme etwas zu groß. Die wichtigsten weiter unten im Programm zu finden sind:
int IsSMSAvailable()
Zur überprüfung ob eine SMS vorhanden ist.

void ReadSMS(int index, char phone[20], char timestamp[30], char message[20])
Um die SMS zu lesen

void ReceiveSMS(char sms_buffer2[20])
Weitere verarbeitung der SMS. Und aufrufen des Unterprogramms CheckTimestamp.

int CheckTimestamp(char timestamp[30])
Hier wie bereits erwähnt, das überprüfen auf eine neue alte Nachricht

brunnen1.27_arduinoforum.ino (68.3 KB)

7

Danke für den Code.
Tatsächlich umfangreich.
Du solltest ganz viele Ausgben auf dem Ser.Mon machen.

Ich hab nur kurz drauf gesehen und glaube noch immer, das Du mit der timestamp-Geschichte SMSn verwirfst, weil die Zeit auf dem Modul nicht stimmt.
Für heute bin ich da codeseitig aber erstmal raus, auch weil ich erstmal die wenigen Kommentare zuordnen muss.... Vielleicht findet sich ja wer, der da mehr und schneller über die Zeilen schauen kann. 10Zoll sind dafür ungeeignet...

Hinweis: Du solltest Variablen die sich nicht verändern als const und Variablen die nur TRUE oder FALSE haben können als bool vorgeben.
Macht es dann einfacher zu erfassen was Du willst. :wink:

8

my_xy_projekt:
Für heute bin ich da codeseitig aber erstmal raus, auch weil ich erstmal die wenigen Kommentare zuordnen muss.... Vielleicht findet sich ja wer, der da mehr und schneller über die Zeilen schauen kann. 10Zoll sind dafür ungeeignet...

Hinweis: Du solltest Variablen die sich nicht verändern als const und Variablen die nur TRUE oder FALSE haben können als bool vorgeben.
Macht es dann einfacher zu erfassen was Du willst. :wink:

Verstehe ich, ist wirklich viel Code. Danke für den Input!
Nachdem ich nicht gerade das Programmier-Ass bin, lern ich gern dazu :slight_smile:

Meinst du mit der timestamp-Geschichte meine Unterfunktion oder die Zeit am Modul? Die am Modul kann ich leider einstellen wie ich möchte, es ändert sich nicht wirklich etwas von der Zeit die dann die SMSen besitzen, egal op per Handy oder via anderen GSM Modul.
Ich werd mir das heute mal ansehen und sonst versuchen die richtige Zeit mit UTC Unterschied einzustellen. Vl ändert es ja irgendwas.

9

Habe heute die Auswertung vorgenommen und folgendes bekommen:

Um 23:59 bekam ich eine letzte SMS auf das GSM Modul (auf welchem es 22:59 ist). Das funktionierte problemlos. Bis "Aktuell Zeit" ausgegeben wurde vergingen einige Sekunden aufgrund der AT-Befehle inkl. kleinem Delay weshalb dann 00:01Uhr angezeigt wird.

- - - CHECK Funktion IsSMSAvailable - - -
 
Empfangen in Unread: 

Empfangen in Unread: +CMGL: 1,"REC UNREAD","+4368****","","2020/04/05 22:59:03+04"

 
- - - Funktion IsSMSAvailable - - -
Empfangen in Unread: +CMGL: 1,"REC UNREAD","+43688****","","2020/04/05 22:59:03+04"

Index Nr.: 1
 
Aktuelle Zeit: 
+CCLK: "20/04/06,00:01:40+00"

OK

Ab genau diesem Zeitpunkt an erneut leider dasselbe Problem - keine neue Nachrichten obwohl mehrere versandt wurden. Ich habe alle 15 Sekunden auf eine neue Nachricht überprüft.

- - - CHECK Funktion IsSMSAvailable - - -
 
Empfangen in Unread: 

Empfangen in Unread: OK

OK - Keine neuen Nachrichten!
 
Aktuelle Zeit: 
+CCLK: "20/04/06,00:04:18+00"

OK

Erst pünktlichst um 01Uhr empfing das Modul die ersten Nachrichten (mit kleinen Verzögerungen durch den AT-Befehl). Man erkennt es ist eine alte Nachricht welche innerhalb der nicht funktionierenden Zeit gesendet wurde.

- - - CHECK Funktion IsSMSAvailable - - -
 
Empfangen in Unread: 

Empfangen in Unread: +CMGL: 1,"REC UNREAD","+43688****","","2020/04/05 23:31:50+04"

 
- - - Funktion IsSMSAvailable - - -
Empfangen in Unread: +CMGL: 1,"REC UNREAD","+43688*****","","2020/04/05 23:31:50+04"

Index Nr.: 1
 
Aktuelle Zeit: 
+CCLK: "20/04/06,01:01:02+00"

OK

Gut, ich habe danach meinen Provider angerufen. Hier habe ich einen Low-Cost Anbieter - LycaMobile, falls diesen jemand kennt. Nachdem ich drei Mal weiterverbunden wurde gab ich auf und schrieb ein Mail. Warte noch auf eine Antwort. Werde heute trotzdem nochmals versuchen dort anzurufen. Scheinen recht chaotisch dort zu sein.

Testweise werde ich versuchen die Sim-Karte durch einen anderen Anbieter und die meines Handys zu tauschen um zu sehen ob dasselbe Problem bei zwei weiteren Providern auftritt. Dann wäre schon mal eine mögliche Fehlerquelle ausgeschlossen.

Zusätzlich werde ich die zeit nochmals über AT+CCLK manuell über den SerialMonitor einstellen, diesmal jedoch mit der UTC +2 am Ende.
Habe den gesamten Vormittag noch versucht, die richtige Zeit am GSM Modul über das GSM Netzwerk zu erhalten (AT+QNITZ) aber auch durch einen NTP Server (AT+QNTP) was leider ebenfalls scheiterte.

AT+QNITZ funktioniert leider nicht. Denke das dies mein Provider nicht unterstützt.
AT+QNTP funktionierte mit dem Eintragen des Servers, leider bekam ich jedoch die Antwort:

11:09:29.852 -> AT+QNTP="time1.google.com"

11:09:29.886 -> OK
11:09:29.886 -> 
11:09:29.886 -> +QNTP: 5

wobei die "5" bedeutet: Failed to activate PDP context

Diesen PDP Kontext versuchte ich mit AT+CGACT auf 1 zu setzen, was funktionierte jedoch nichts am Ergebnis von QNTP änderte.

Im anghängten File "Quectel UC20" fand ich den genauen Vorgang. Die AT-Kommando Befehle gibts direkt beim Hersteller Quectel. Gebe ich auch mit dazu, falls diesen jemand benötigen sollte :slight_smile:

Quectel_M10_AT_Commands_Manual_V4.0.pdf (1.74 MB)

Quectel_UC20_Time_Synchronization_Application_Note_V1.0.pdf (237 KB)

10

Guten Morgen,

mit noch kleinen Klüsen hab ich nochmal drübergeschaut...

Thor2018:
Verstehe ich, ist wirklich viel Code. Danke für den Input!
Nachdem ich nicht gerade das Programmier-Ass bin, lern ich gern dazu :slight_smile:

Meinst du mit der timestamp-Geschichte meine Unterfunktion oder die Zeit am Modul? Die am Modul kann ich leider einstellen wie ich möchte, es ändert sich nicht wirklich etwas von der Zeit die dann die SMSen besitzen, egal op per Handy oder via anderen GSM Modul.
Ich werd mir das heute mal ansehen und sonst versuchen die richtige Zeit mit UTC Unterschied einzustellen. Vl ändert es ja irgendwas.

Das mit dem timestamp hattest Du oben drin:
void ReadSMS(int index, char phone[20], char timestamp[30], char message[20])

Da sonst alle anderen SMS'n verarbeitet werden, wäre eine Logikfrage:
Kannst Du ausschliessen, das Du irgendwo unterwegs den Inhalt
"REC UNREAD","+436606xxxxxx","","2019/10/18 10:34:58+08"
auf den aktuellen Tag prüfst um mutmaßlich "veraltete" SMSen zu verwerfen?

Wenn die eigene Uhrzeit 2020/4/2 0:0:1 ist, wäre der Inhalt vom Vortag, nämlich 2020/4/1 23:0:1

Just in der Zeit wo ich an dem Post sitze, kommst Du mit Deiner Erkenntnis.
Das bestärkt mich in meiner Vermutung.
Hinter den Code müsste ich aber erstmal steigen...

11

Mahlzeit,

Danke nochmal fürs drüberschauen!

Verstehe das hast du gemeint.

Da sonst alle anderen SMS'n verarbeitet werden, wäre eine Logikfrage:
Kannst Du ausschliessen, das Du irgendwo unterwegs den Inhalt
"REC UNREAD","+436606xxxxxx","","2019/10/18 10:34:58+08"
auf den aktuellen Tag prüfst um mutmaßlich "veraltete" SMSen zu verwerfen?

Ja das kann ich ausschließen. Was ich aber mache, die neue angekommende SMS Nachricht überprüfe ich auf Jahr, Monat, Tag, Stunde und Minute ob es eine neue Nachricht ist oder eine alte. Ich speichere mir quasi die Werte der letzten Nachricht.
Das überprüfen mache ich jedoch erst, wenn eine SMS mit dem Unterprogramm IsSMSAvailable() identifiziert wurde. Und eine SMS wurde dann identifiziert, wenn mir das AT Kommando eben eine Antwort liefert die ungleich OK ist.
Somit kann es an der Timestamp-Funktion und der ganzen Überprüfung auf Tag Monat etc. nicht liegen, da das Problem bereits vor dieser Funktion bestand.

Zuerst wird im Programmablauf IsSMSAvailable() aufgerufen wobei sich hier bereits bei einer angekommenden SMS eine entsprechende Antwort ergeben sollte. Danach erst ReadSMS() wobei hier char timestamp[30] aus der SMS Nachricht rausextrahiert wird. Und erst im Unterprogramm ReceiveSMS() wird der Vergleich zwischen alter und neuer Nachricht durchgeführt.

12

OK, wenn Du das ausschliessen kannst, dann bauen wir mal.

Vermutlich läuft das schon produktiv ;(

Ich würde trotdem den Inhalt von deleteALLSMS() als erstes deaktivieren und alles empfangen wollen.
Dann würde ich den INHALT von jeder SMS auf dem seriellen Monitor ausgeben lassen.

Ab 23:57:01 würde ich minütlich eine SMS schicken.
Als Inhalt nur die laufende Nummer der SMS.
Um 00:00:01 würde dann 4 drin stehen.
Das Ganze vielleicht noch bis 00:00:05

Wenn die SMSn alle ankommen, aber tatsächlich zwischen der 3ten und der 9ten 1 Stunde vergeht, dann klemmts beim Provider - wobei ich mir das nicht vorstellen kann. Das würde dann alle Kunden betreffen...

Kommen die SMSn zeitnah durch, löscht Du irgendwo innerhalb des Code. Immerhin 8 Einträge im loop...

Noch ein Hinweis:

void loop()
  {
  static char smsin[20];
  int initialize = 1;
  int messageIndex = 0;
  int wiederholen_fuellstandein = 0;
  int wiederholen_fuellstandaus = 0;
  int wiederholen_normalmodus = 0;
  if (initialize)
    {
    initialize = 0;
    smsin[0] = '\0'; //0-te Element auf \0 setzen = löschen
    //Lösche SMSen auch nach Blackout -> Hier wird initialize = 1 gesetzt und einmal durchlaufen
    deleteALLSMS();

Du setzt intitiale bei jedem Durchlauf von loop() IMMER auf HIGH und prüfst darauf.

Auch an anderer Stelle setzt Du auf 1.

Das müsstest Du erstmal reparieren.

13

Danke für die Idee. Das ist ein guter Einfall einfach mal testweise alle Minuten eine SMS zu versenden! Perfekt. Dann werde ich das heute alles vorbereiten und um Mitternacht die Tests durchführen. Bin gespannt ob es funktioniert.

Die Variable initialize setze ich am Anfang einmal auf 1. Danach wird die if-Abfrage if(initialize) genau einmal durchlaufen. Dann wird der Wert dauerhaft auf 0 gesetzt. Der Wert wird erst dann wieder auf 1 gesetzt wenn beispielsweise Stromausfall herrscht (Blackout - und der Arduino über eine USV weiter versorgt wird) oder die Kommunikation über Kabel läuft und nicht via GSM.
Das habe ich deshalb programmiert, dass wenn der Arduino aus dem Zustand Blackout oder Kabel wieder den Normalbetrieb aufnimmt, alle angesammelten SMSen gelöscht werden.

Was ich weiß, wird auch wenn sich int initialize=1; in void loop() befindet nur einmal ausgeführt, nämlich um der Variablen einen Wert zuzuweisen. Danach bleibt der Wert erhalten und initialisiert die Variable initialize ja nicht immer neu. Sonst würde er in der Loop immer und immer wieder den aktuellen Wert von initialize mit 1 überschreiben. Ebenso bei den anderen Variablen.
Zumindest meine ich das in der Oberstufe einmal gelernt zu haben.

14

Thor2018:
Die Variable initialize setze ich am Anfang einmal auf 1. Danach wird die if-Abfrage if(initialize) genau einmal durchlaufen. Dann wird der Wert dauerhaft auf 0 gesetzt.

Schreib mal unter

 if(initialize)
{
  initialize = 0;
  smsin[0] = '\0'; //0-te Element auf \0 setzen = löschen

in die aktuell leere Zeile:

MEGASerial.println(F("INIT mit delete");

Und sag mir, was passiert.

15

Die Zeile

MEGASerial.println(F("INIT mit delete"));

wird genau einmal ausgeführt. Gleich nachdem er von void setup() in void loop() wechselt. Das ist schon mal gut - wär aber schön gewesen wenn es daran gelegen wäre :wink: Danke für die Idee!

Ich lasse den Code-Schnipsel aber mal im Programm, wer weiß wofür er noch gut sein kann.

16

Irgendwas stimmt da nicht.

Was wird ausgegeben, wenn Du direkt unter

void loop() 
{
 static char smsin[20];
 int initialize = 1;
 int messageIndex = 0;
 int wiederholen_fuellstandein = 0;
 int wiederholen_fuellstandaus = 0;
 int wiederholen_normalmodus = 0;

in die leere Zeile 254

MEGASerial.println(initialize);

einfügst.

Warum hast Du eigentlich im Setup soviele delay() drinne - der wird ja nie fertig ,)

Im Übrigen habe ich versucht das zu compilieren.
Setze mal bitte den Haken unter Datei-Voreinstellungen-Ausführliche Ausgabe während Kompilierung und schau was passiert.
Und reparier das noch...

17

Gut noch ein Nachtrag.
Irgendwo ist Dein Sketch anders, als das was Du zur Verfügung gestellt hast. Möglicherweise auch im Nachgang geändert.

#define MEGASerial Serial

void setup() {
Serial.begin(115200);
}

void loop() 
{
  static char smsin[20];
  int initialize = 1;
  int messageIndex = 0;
  int wiederholen_fuellstandein = 0;
  int wiederholen_fuellstandaus = 0;
  int wiederholen_normalmodus = 0;
MEGASerial.println(initialize);
  if(initialize)
  {
    initialize = 0;
MEGASerial.println(initialize);
   
  }

// Hier kommt der ganze andere Code
}

ergibt:

18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18:30:15.054 -> 0
18:30:15.054 -> 1
18

my_xy_projekt:
Irgendwas stimmt da nicht.

Was wird ausgegeben, wenn Du direkt unter

void loop()

{
static char smsin[20];
int initialize = 1;
int messageIndex = 0;
int wiederholen_fuellstandein = 0;
int wiederholen_fuellstandaus = 0;
int wiederholen_normalmodus = 0;




in die leere Zeile 254 

MEGASerial.println(initialize);

einfügst.

Warum hast Du eigentlich im Setup soviele delay() drinne - der wird ja nie fertig ,)

Im Übrigen habe ich versucht das zu compilieren.
Setze mal bitte den Haken unter Datei-Voreinstellungen-Ausführliche Ausgabe während Kompilierung und schau was passiert.
Und reparier das noch...

Wen ich direkt darunter den print-Befehl setze, wird das erste Mal beim Durchlauf von void loop() Initialize mit 1 ausgegeben und INIT mit delete. Danach nie mehr wieder eines der beiden.
Warum das so ist kann ich zum Glück auch erklären. Demnach funktioniert das nicht was du herausbekommen wolltest, bzw. kann nicht funktionieren.

Denn gleich darunter nach der if(initialize) Abfrage wird eine while-Schleife betreten. Diese wird immer und immer wieder ausgeführt solange kein Blackout oder Kabel aktiv ist. Deshalb springt er nie wieder zurück zum Anfang von void loop(). Etwas umständlich programmiert ich weiß. Aber nur so bekomme ich es gebacken, falls einmal Kabel oder Blackout am Eingang anstehen sollte, sofort die Wiederholung der while-Schleife unterbrochen wird und in den if-Zweig von Kabel oder Blackout (weiter unten im Hauptprogramm) gegangen wird. Nach verlassen (wenn einer der beiden nicht mehr aktiv ist) wird wieder die while-Schleife betreten.

Danke für den Mini-Sketch. Das wusste ich schlichtweg einfach nicht, dass void loop() ebenso wieder neue Initialisierungen am Anfang des Programms durchführt. Um Himmels Willen :o Sofern ich mich nicht im Kabel oder Blackout Modus befinde, funktioniert jedoch alles wie gewünscht.

So viele Delays deshalb, da in den Unterprogrammen meist das GSM Modul 1-6sec brauchen kann um etwas zu versenden oder zu löschen. Im Hauptprogramm im Setup, um ein geregeltes Hochfahren zu gewährleisten, da es noch zwei andere GSM Module gibt und nicht alle zur selben Zeit anfangen sollen miteinander zu kommunizieren. Und in den Sende-Schleifen um den anderen Modulen genügend Zeit zum Antworten zu geben. Aber nicht der schönste Programmier-Stil, ich weiß :wink:

Ich habe alles erneut mit der ausführlichen Compilierung compiliert, keine Fehler oder Beanstandungen. Bekommst du hier etwas anderes? Möglicherweise etwas mit einer Bibliothek?

19

Das Du aus while nicht mehr rauskommst, ist mir zwischendurch auch aufgefallen.
So ist das aber auch nicht gedacht.
Du solltest Dir unbedingt eine Struktur ausdenken.

Allerdings sind die Kompilerwarnungen essentiell.
Sowas hier kommt in xfacher Ausführung. Nun. Nicht ganz so problematisch.

85:68: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
           sendSMSdata(Testingenieur,"Fuellstand EIN - Wenig Wasser");

Das geht auch noch durch:

1219:7: warning: unused variable 'i' [-Wunused-variable]
   int i;

Problematischer finde ich z.B. die mehrfachen Ausgaben

1638:1: warning: control reaches end of non-void function [-Wreturn-type]
 }

das Du aus den switch/cases ggfls. nicht mehr rauskommst und der Compiler Dir das auch sagt.

20

Ja das mit der Struktur wäre wohl ein guter Tipp.

Ehrlich gesagt geht bei mir das compilieren ohne Errors und Warnings durch. Merkwürdig.
Ich habe die Version 1.8.9.

Okay das "forbids converting string constant to 'char*'" nicht ganz so problematisch ist kann ich leider nicht beurteilen. Verstehe nicht ganz was der Compiler damit sagen möchte. Aber gut wenn es das nicht ist.

Beim 2. Warning kommt eine unbenutzte Variable zum Vorschein. Okay.

Und beim 3. schätze ich kommt es von den vielen "else if". Da muss ich nachbessern. Etwas ärgerlich das mir mein Compiler das nicht anzeigt.
Verwendest du hier einen externen Compiler?