Probleme beim Datentransfer über SIM800 Modul per MQTT

Hallo Julian nochmals,

was wir an dieser Stelle noch loswerden wollten…

Wir würden uns sehr freuen, wenn Du den Quelltext Deiner Sensorsoftware mit uns teilen möchtest. Wenn Du magst, mach das doch auf eigene Faust auf GitHub oder wo Du es am liebsten hast, wir bieten Dir aber genauso gerne ein Dach in Form unseres kollektiven Repositories, dann müsstest Du Dich nicht so stark selbst darum kümmern:

Als Seiteneffekt davon stünde Dir damit auch fast automatisch die komplette Infrastruktur rund um die Dokumentation und den Firmware Builder zur Verfügung, um kurz die wichtigsten Vorteile zu nennen. Vielleicht interessiert Dich das ja?

Wir hätten Dein MCU Programm u.a. auch deshalb so gerne zur Verfügung für die Community, weil es in der von uns publizierten kollektiven Firmware Sammlung bisher keine Referenzimplementierung mit der PubSubClient Bibliothek von Nick O’Leary gibt, auf die wir schon sehnsüchtig warten ;].

Viele Grüße,
Andreas.

Hallo Julian,

Kann ich gerne machen, Du musst Dich nur gedulden bis ich aus dem Urlaub wiederkomme.

Grüße
Stefan

Hey Stefan. Es wäre cool, wenn du mit deinen Wert demnächst mal sagen kannst. Ist jetzt aber nicht akut. Bis jetzt läuft es erstmal.

Ich habe es erstmal mit 500 weiter versucht. Da mir aber so langsam der Speicher ausgeht, habe ich es wieder auf Standart 128 zurück gesetzt.

Ich werde es mir überlegen. Da ich aktuell sehr viel Beschreibung zwecks Speicher rausgeschmissen habe, und es noch nicht alles funktioniert, werde ich mich erstmal darum kümmern, dass alles funktioniert. Wenn ich dann das ganze noch ein wenig schön gemacht habe, werde ich es mir überlegen. Generell habe ich aber kein Problem damit^^

Wunderbar! Falls Du an irgendeiner Stelle nicht weiterkommen solltest, können wir ggf. auch unsere “Codeanalyse im Trockendock” Hüte aufsetzen und den Quelltext von Ferne betrachten. Das wäre u.U. auch eine passende Gelegenheit, ihn zu veröffentlichen.

Ansonsten verstehen wir natürlich, wenn Du ihn erst polieren und dann veröffentlichen willst. Wir machen halt nur generell immer offensiv Werbung für Release early, release often ;].

Have fun!

Meinst du mit “Speicher” den Arduino? Falls ja, kannst du alles was du möchtest in Kommentaren in den Quelltext schreiben. Kommentare werden nicht mit-compiliert und blähen damit zwar deine *.ino-Datei auf, aber nicht die compilierte Datei, die dann auf den Arduino kommt.

Vielen Dank erstmal für die große Unterstützung. Leider “fressen” die brauchbaren Libs den Speicher der Variablen auf. Somit kann ich mit MQTT und dem Sim-Modul so nicht weiter machen.

@Andreas Wie kann ich denn Sinnvoll mal den aktuellen Quellcode hier senden, damit mal alle drüber schauen können, wie ich weniger Speicher verwenden kann?

Grüße Julian

Hi Julian,

Herzlich gern!

Schade!

Wenn Du Dich mit Git und GitHub auskennst, kannst Du gerne hier [1] einen Pull Request einreichen oder den Code erstmal in ein eigenes Git Repository werfen.

Ansonsten schicke mir den Quelltext doch einfach per Email, dann übernehme ich das, ihn an einer passenden Stelle einzupflegen.

Viele Grüße,
Andreas.

[1] GitHub - hiveeyes/arduino: Arduino-compatible MCU code for sensor and telemetry nodes.

Hier hat übrigens auch jemand Probleme mit der TinyGSM-library in Verbindung mit PubSubClient:

Hallo Julian,

ich habe den Wert für die MAXBUFFERSIZE auf 1024 in der Adafruit_MQTT.h gesetzt.

#define MAXBUFFERSIZE (1024)

Viel Erfolg!

Die TinyGSM Bibliothek nutzt für die Unterstützung von MQTT wiederum die PubSubClient Bibliothek und deren Autor Nick O’Leary schreibt dazu ganz klar:

  • The maximum message size, including header, is 128 bytes by default. This
    is configurable via MQTT_MAX_PACKET_SIZE in PubSubClient.h.

und:

  • Reject topic/payloads that exceed MQTT_MAX_PACKET_SIZE
1 Like

@Kasper027 nochmal eine Nachfrage zum Stand der Dinge. ;-) Hast du mit einem Arduino Uno / ProMini die TinyGSM mit den nötigen MQTT-Libs speichertechnisch zum Laufen bekommen oder ist der einfach zu klein?`

Also mit dem Uno geht es nicht zuverlässig. Ich habe jetzt einen Mega in Verwendung. Da läuft es erstmal. Leider habe ich aber noch andere Probleme, wo ich noch nicht herausgefunden habe, woran es liegt. Hier werde ich demnächst nochmal einen Stand bringen, wo ihr mir eventuell helfen könntet.

6 posts were split to a new topic: SIM800 Stromverbrauch reduzieren

Hallo zusammen.
Ich habe mir heute nochmal mein Projekt vorgenommen. Doch leider Scheiter ich an der Datenübermittlung. Beim “Neustart” funktioniert alles super. Es kommen auch Daten an und können Visualisiert werden. Danach geht der aktuelle Mega in den Ruhemodus. Nach dem aufwecken hohlt er sich wieder alle daten. Doch dann werden die Daten nicht mehr übermittelt. Ich habe mir auch das ganze mal im Seriellen Monitor angeschaut. Doch leider werden, warum auch immer nicht alle prints geschrieben. Vllt kann sich ja jemand nochmal den Code vornehmen und mal gemeinsam mit drüber schauen um den Fehler vllt zu finden.

https://github.com/Kasper027/Bienenwaage-MQTT/blob/master/Beelogger_V0.22.ino

Hier ist einmal der Quellcode.

Und hier kommt einmal der Serial Output.

Void Sensor_DS18
23.31
Void Sensor_DHT
23.40
Void Senden_GSM gestartet
Void setup_gsm gestartet
Modem Restart
MQTT.setServer
Void reconnect Aufgerufen
mqtt.connect ist ok
Temperatur
emperatur
Void Sensor_DS18
23.25
Void Sensor_DHT
23.40
Void Senden_GSM gestartet
Void setup_gsm gestartet
Modem Restart
MQTT.setServer
Void reconnect Aufgerufen
mqtt.connect ist ok
Temperatur
emperaturTemperatur

Dies sind genau 2 Durchläufe. Wernn ich das ganze mehrfach durchlaufen lasse, wird die letzte Zeile immer mit einem Temperatur erweitert. Woher das kommt, habe ich leider noch nicht verstanden. Vllt könnt ihr den Fehler finden.

Für Verbesserungen bin ich sehr Dankbar.

Grüße
Julian

Hallo Julian,

sobald der Knoten verbunden ist, wird Senden_GSM häufiger durchlaufen, das dort stehende Serial.println(topic); ist meines Erachtens die einzige Stelle, wo der Code “Temperatur” ausgeben kann.

Segfault?

Auffällig ist, dass Serial.println("erster Topic"); wohl scheinbar niemals gerufen wird, zumindest sehe ich es nicht in Deiner Ausgabe. Der Übeltäter wäre dann wohl mqtt.publish(strcat(top, topic), temp);, vielleicht führt diese Zeile zu einem Segfault und in Folge zu einem kompletten Restart der MCU? Die Ausgabe wäre nicht unplausibel, es geht danach mit der Ausgabe von Void Sensor_DS18 weiter, genau wie zu Beginn!

Sleepvorgang

Falls beim Sleepvorgang irgendetwas schiefläuft, kann es vielleicht nicht schaden, den entsprechenden Code ebenfalls noch mit mehr debug statements auszustatten.

Bzw. vielleicht auch erstmal andersherum: Deaktiviere vorerst einmal die Sleep Funktionalität, um einen minimalen Stand zu bekommen der robust funktioniert, ohne den Meßknoten schlafenzulegen. Also erstmal a) read sensors, b) publish readings und c) von vorn. Von diesem Zwischenstopp aus kann die Reise dann weitergehen.

Vielleicht bringt Dich das ein wenig weiter.

Herzliche Grüße,
Andreas.


P.S.: Obacht wegen delay():

More knowledgeable programmers usually avoid the use of delay() for timing of events longer than 10’s of milliseconds unless the Arduino sketch is very simple.
Reference > Language > Functions > Time > Delay

Hey Andreas.

Das ist mir auch aufgefallen. Warum auch immer. Was ich halt komisch finde ist, dass wenn ich mir die Protokolle auf https://swarm.hiveeyes.org/transmissions anschaue, beim ersten Senden alles richtig geschrieben wird auch so wie es soll (hiveeyes/kasper/Garten/Stand1/data/Temperatur 24.10). Beim 2ten mal schreiben kommt dann ein weiteres “Temperatur” hinzu (hiveeyes/kasper/Garten/Stand1/data/TemperaturTemperatur 26.70)

Kennst du eine Möglichkeit, dieses zu testen? bzw. anders zu schreiben, dass nicht viel Speicher dabei drauf geht?

Aha, einmal klappts also!

Ja, seltsam. Das deutet irgendwie auf ungünstiges Laufzeitverhalten (Speicherkorruption o.ä.) hin. Versuche es doch einmal “so minimal wie möglich”, also ohne Sleepmode und Dinge, die nicht unbedingt notwendig sind und taste Dich in diese Richtung vor.

Wenn alles nichts hilft, musst Du u.U. nochmal einen isolierten Testsketch auflegen, der nur MQTT Kommunikation macht und Dich von dort aus herantasten. Signifikant anders machen wir es in unserer Werkstatt auch nicht, um subtile Bugs in der Firmware aufzuspüren.

Problem

Ich vermute in der Tat, dass diese Zeile zu Speicherkorruption führt. Damit wäre auch das aktuelle Symptom, dass es ein zwei Mal funktioniert, nicht unplausibel.

Konkret ist es vermutlich strcat(top, topic). Mit der Funktionssignatur

char * strcat ( char * destination, const char * source );

sowie der Dokumentation

destination
Pointer to the destination array, which should contain a C string, and be large enough to contain the concatenated resulting string.

strcat - C++ Reference

kannst Du Dir vermutlich schon selber denken, wo der Hase im Pfeffer liegt: strcat funktioniert nicht ganz so komfortabel wie gedacht. Es alloziert nicht selbständig neuen Speicher um den vergrößerten String darin abzulegen, sondern man muss das vorher selbst tun.

Lösung?

Am besten, Du allozierst Dir auf dem Stack lokal in der Funktion eine neue Variable, die eine ausreichende Größe hat, um sie dann mit dem effektiven Topicstring zu belegen, vielleicht klappt das so in etwa wie im Beispiel für strcat zu sehen:

char effective_topic[255];
strcpy(effective_topic, top);
strcat(effective_topic, topic);
mqtt.publish(effective_topic, temp);

Unter Arduino könnte es aber umso komfortabler auch folgendermaßen klappen:

String effective_topic = top + topic;
mqtt.publish(effective_topic, temp);

Hier liegt es wirklich drann. Warum auch immer. Ich bin jetzt einfach mal her gegangen und habe die Topics oben wieder “lang” geschrieben. Dies dann unten eingetragen und es Funktioniert. Somit lasse ich es erstmal so. Auch mit der Sleep Funktion geht alles.

So jetzt dann “nur” noch alles vom Steckbrett auf ne Platine und dann los^^