Daten über das Internet in Datei auf Server schreiben;

Warum sollte FTP nicht gehen? Ist doch genau die Lösung.

@Albert:
Nur weil ein normaler ftp-Client eine lokale Datei benutzt muss er das 
nicht so machen.

Der Client ist ein Mikrocontroller, der zur Übertragung von Messdaten 
über ein GSM-Modul per GPRS (mit integrietrem TCPIP-Stack) mit dem 
Server verbunden werden soll.
Gesteuert werden soll soll das ganze mit AT-Kommandos (das GSM-Modul 
unterstützt nach dem ersten Überfliegen des Datenblattes ftp und http)
Das eigentliche Programm auf dem Mikrocontroller wird in C geschrieben.
Zur Zeit teste ich die Ansteuerung des GSM-Modules der Einfachheit 
halber noch über die Ansteuerung mittels UART-Verbindung von einem PC, 
auf dem ein normales C-Programm läuft.

Ah, danke, das mit dem STOR-Befehl ist schon ein guter Hinweis.
Und würde das Schreiben von Daten in eine Datei auf dem Server auch mit 
http gehen ?

cyblord ---- schrieb:
> Laut HTTP Standard: JA, mit dem PUT Befehl.
>
> In der Realität: NEIN, weil dieser Befehl von keinem HTTP Server
> unterstützt wird.

Ironisch oder ernst gemeint?
Lässt sich das ev. individuell einstellen, wenn man bei einem Provider 
Webspace kauft ?
Welcher Provider wäre für solche Anwendungen ev. geeignet (die Dateien 
brauchen nicht so viel Platz, auf jeden Fall weniger als 1 GB)

warum macht du es nicht einfach über eine kleines PHP-Script. Den 
schickt du die daten per HTTP und er schreibt es auf die Festplatte? Ist 
das zu einfach?

Peter II schrieb:
> warum macht du es nicht einfach über eine kleines PHP-Script. Den
> schickt du die daten per HTTP und er schreibt es auf die Festplatte? Ist
> das zu einfach?

Mit PHP kenne ich mich nicht aus.
Du meinst ein Skript, das auf dem http-Server läuft und auf den Eingang 
von Daten wartet und die dann in eine Datei auf dem Server schreibt ?
Hört sich machbar an.

Anfänger schrieb:
> Mit PHP kenne ich mich nicht aus.
das kann man ja mit etwas willen ändern.

> Du meinst ein Skript, das auf dem http-Server läuft und auf den Eingang
> von Daten wartet und die dann in eine Datei auf dem Server schreibt ?
> Hört sich machbar an.
nein PHP warten nicht, es wird in dem moment aufgerufen wenn du die 
daten per http dort hinschickt.

Anfänger schrieb:
> Der Client ist ein Mikrocontroller, der zur Übertragung von Messdaten
> über ein GSM-Modul per GPRS (mit integrietrem TCPIP-Stack) mit dem
> Server verbunden werden soll.

Wie heikel oder kritisch sind die Daten?
Darf auch mal eine Nachricht vergessen gehen?

Vielleicht reicht dir für's erste eine Minimal-Lösung mit syslog. Jedes 
unixoide System hat das mit an Bord, oder es lässt sich einfach 
nachrüsten.
Siehe auch http://de.wikipedia.org/wiki/Syslog

Hier im Forum hab ich auch von einem Syslog Client für AVRs gelesen: 
Beitrag "SYSLOG für Ulrich Radigs Webserver auf AVR-NET-IO"

Helfer schrieb:
> Wie heikel oder kritisch sind die Daten?
> Darf auch mal eine Nachricht vergessen gehen?

Es sollte schon zuverlässig arbeiten. Bei den Daten handelt es sich um 
Messdaten, die vom Remote-System (Mikrocontroller) über ein GPRS-Modul 
an den Server geschickt werden sollen. Als Server denke ich an einen 
Standard-Webserver, ich bin noch auf der Suche nach einem geeigneten 
Provider. Von dort würde ich die Daten dann in eine Datenbank 
eingetragen, weiterverarbeitet und ggf. visualisiert.
Der kritische  Abschnitt ist die Übertragung zwischen Remote-System und 
Webserver.

Anfänger schrieb:
> Es sollte schon zuverlässig arbeiten. Bei den Daten handelt es sich um
> Messdaten, die vom Remote-System (Mikrocontroller) über ein GPRS-Modul
> an den Server geschickt werden sollen. Als Server denke ich an einen
> Standard-Webserver, ich bin noch auf der Suche nach einem geeigneten
> Provider. Von dort würde ich die Daten dann in eine Datenbank
> eingetragen, weiterverarbeitet und ggf. visualisiert.
dann kann PHP die daten ja gleich in den DB eintragen - das bietet 
eigentlich jeder Provider an.

Anfänger schrieb:
> Ah, danke, das mit dem STOR-Befehl ist schon ein guter Hinweis.

cyblord ---- schrieb:
> Laut HTTP Standard: JA, mit dem PUT Befehl.

Mhja, wieso kompliziert wenn's auch einfach geht... ;-)

Nimm doch den altbekannten GET request - KISS ist angesagt. Seit 
Urzeiten können jedem HTTP GET Request Parameter übergeben werden, so in 
der Art:

1

GET /irgendwo/meinskript?tu-Schreiben&was=bla&opt1=grunz&bli=12345 HTTP/1.1

URL encoding beachten und ein paar andere Feinheiten, siehe 
http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Helfer schrieb:
> Nimm doch den altbekannten GET request - KISS ist angesagt.

Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von 
GET verletzt.

Mit PUT kann man es in geschätzt fünf Zeilen Ruby erledigen. 
sinatrarb.com bietet sich an.

Martin schrieb:
> Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von
> GET verletzt.
kannst du mal etwas mehr du sagen? Wo soll hier etwas verletzt werden?

Martin schrieb:
> Das ist nicht KISS, das ist einfach nur falsch, weil es die Semantik von
> GET verletzt.

Falsch? Es ist genau so vorgesehen und spezifiziert. Es ist IMHO einfach 
wenig sinnvoll, einen PUT request zu verwenden, um ein paar Bytes auf 
dem Server "abzuladen". Das zumindest meine ich möchte der TO tun.

> Mit PUT kann man es in geschätzt fünf Zeilen Ruby erledigen.
> sinatrarb.com bietet sich an.

Der springende Punkt ist IMO, wie einfach es auf dem MC implementiert 
werden kann. Ein HTTP GET ist trivial, ein POST etwas aufwändiger (du 
meinst doch POST, nicht PUT?).

Helfer schrieb:
> du meinst doch POST, nicht PUT?).
nein er meint wirklich PUT - wird meines wissens bei WebDAV genutzt.

@Helfer

Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen 
komische Voodoo-Konfigurationen fahren, Google mußte sogar ein Produkt 
zurückziehen, IIRC.

Meditiere halt mal über "safe" und "idempotent". Vorher mußt du aber die 
Grundlagen von HTTP verstanden haben. Der RFC hilft dabei ebenso wie die 
O'Reilly-Bücher zu HTTP und REST.

Martin schrieb:
> Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen
> komische Voodoo-Konfigurationen fahren, Google mußte sogar ein Produkt
> zurückziehen, IIRC.
wer heute noch bei den dynamischen web mit immer mehr https irgendetwas 
cachen will, dem ist eh nicht mehr zu helfen.

Nico Sch. schrieb:
> Das merkst du aber schon noch selbst?

ja deswegen schreibe ich es ja, cachen macht heute mehr arbeit als sinn.

Martin schrieb:
> Stümperer wie du haben das Web kaputtgemacht. Cache-Admins müssen
> komische Voodoo-Konfigurationen fahren...

Mitnichten. Du hast nicht verstanden, was der TO erreichen möchte, 
nämlich mehr oder weniger regelmässig Messwerte via Mobilfunk 
übertragen. Dazu eignet sich ein HTTP GET oder POST request prima. Ein 
Dateiupload ist Quark. WEBDAV und Caching? Hast du verstanden, worum's 
geht?

> , Google mußte sogar ein Produkt zurückziehen, IIRC.

Welches denn?

> Meditiere halt mal über "safe" und "idempotent". Vorher mußt du aber die
> Grundlagen von HTTP verstanden haben. Der RFC hilft dabei ebenso wie die
> O'Reilly-Bücher zu HTTP und REST.

Ich denke, dass der TO erstmal einen kleinen Erfolg mit einer 
lauffähigen Konfiguration erzielen möchte. Richtig sicher wird HTTP mit 
beidseitiger Authentisierung. Ob man das mit einem einfachen 8 Bit MC 
vernünftig hinkriegt (beschränkte Rechenleistung, sehr wenig Speicher), 
sei mal dahin gestellt.

Nico Sch. schrieb:
> Die Kritik zielte ja darauf ab, dass genau das durch irgendwelche
> Programmierer mit "Ich benutze mal ein GET, um eine Datei hochzuladen"
> ganz schön schwer gemacht wird. Den Nutzen von Caching an sich würd ich
> aber nicht unbedingt in Frage stellen.
get ist aber die einzigste möglichkeit für deep links auf anwendungen. 
Oder für Favoriten. Und wenn es nur eine google suche ist, da will man 
auch kein caching.

Post ist ebenso okay wie Put. Von webdav sprach ich nicht.

Also hör auf, groß rumzutönen und mir Dinge in den Mund zu legen. Und 
verzieh dich.

Cachen sei heute unwichtig, unfaßbar...

Google Web Accelerator.

Kurz mal wieder ein Feedback von mir (dem Threadstarter) :
Nach den Dokumentationen zum SIM900-Modul sieht es so aus, als ob 
genügend ftp-Befehle über AT-Kommandos unterstützt werden, um Daten in 
Dateien auf einen Server hochzuladen.
Auch eine http-Verbindung scheint mittels der über AT-Kommandos 
unterstützten http-Fiunktionen möglich.
Wie schon gesagt hat das SIM900 einen integrierten TCPIP-Stack.
Als MC wird ein MSP430F249 zum Einsatz kommen, das ganze soll eine 
Anwendung mit möglichst geringem Energieverbrauch werden.

Leider hatte ich heute zu wenig Zeit, um weiter zu programmieren, aber 
in den nächsten Tagen sollte es Fortschritte geben, werde weiter darüber 
berichten.

Wie ich sehe, hat sich der Thread so ein bisschen an HTTP festgebissen, 
kann das sein?

Aber was dann wieder alles implementiert werden muss.. Denn dann muss 
auch der "Client" (der Mikrocontroller) das HTT-Protokoll beigebracht 
werden.

Dabei will der TE doch eigentlich nur folgendes:

µC verbindet sich mittels TCP/IP zu dem "Server" über einen 
spezifizierten Port.
"Server" akzeptiert verbindung
µC sendet daten
"Server" speichert daten als Datei.

Das kann HTTP und ein gängiger HTTPd (z.B. Apache) natürlich auch ganz 
wunderbar. Doch ein HTTPd kann noch mehr. Viel mehr. Was folgt ist ein 
sehr umfangreiches Protokoll.

Anstatt nun also auf einem sehr umfangreichen und komplexen Protokoll 
aufzubauen, könnte der TE, der kein PHP kann dafür aber anscheinend C, 
sich einen Daemon programmieren und diesen auf seinem Webserver laufen 
lassen.

Der Daemon lauscht dann auf einem Port, über dem sich der µC verbinden 
kann und dem Server die Daten schicken kann.

Das spart eindeutig Code im µC !

µC -> connect to daemon using specified port
daemon -> accepts connection
µC -> sends login verification data
daemon -> checking login data and (if they are valid) sending "OK" 
message
µC -> sending data as plain text
µC -> after data has been sent, finishing with \r\n\0.\0
daemon -> stores data as plaintext-file

Das ist ein ziemlich einfaches Protokoll (was im übrigen fast jeder hier 
tag-täglich nutzt).
Es lässt sich sehr einfach programmieren und auch der Code-Umfang im µC 
wird dadurch WESENTLICH gekürzt, als wenn man HTTP implementiert.

Das einzige, was dann noch wirklich arbeitet bedeutet, ist die 
Login-Verfikiation am Daemon zu entwickeln. Und da gibt es schier 
unendlich Möglichkeiten, wo man die Login Daten unterbringt. Sei es SQL, 
LDAP, Plaintext, passwd, ActiveDirectory etc ;)

Fabian schrieb:
> Anstatt nun also auf einem sehr umfangreichen und komplexen Protokoll
> aufzubauen, könnte der TE, der kein PHP kann dafür aber anscheinend C,
> sich einen Daemon programmieren und diesen auf seinem Webserver laufen
> lassen.
er möchte sich aber einen Server mieten - darunter verstehen viele 
nunmal nur Webspace mit einem webserver. Dort kann man keinen Deamon 
ausführen. Klar kann man auch einen VServer oder sogar echten Server 
mieten aber das ist teurer und man hat sich auch noch im die sicherheit 
zu kömmern. Als nächsten nachteil kommt dazu das heute nun mal http der 
standard ist. Das heist das man in firmennetzen keine direkte verbindung 
aufbauen kann - über http geht es aber.

http ist zwar nicht perfekt dafür, es ist aber sehr gebräuchlich und 
üblich. Auserdem ist es fast kein unterschied im Protokoll zu einem 
eigenem deamon. Man schreibt einfach noch ein festen http header davor 
und gut ist.

Mein Konzept ist eigentlich (zumindest für´s erste) den Webserver als 
Relaisstation zwischen dem Remote-Datenfassungssystem und einem eigenen 
Rechner (bzw. den Rechnern weiterer Nutzer) zu verwenden, damit die 
einzelnen Rechner nicht ständig eingeschaltet sein muss.
Die vom Remote-Datenerfassungssystem auf dem Server angelegten Dateien 
bekommen individuelle Namen (z.B. aus Datum, Zeit, ID), so dass auch 
mehrere bis viele in einem (oder mehreren projektspezifischen) 
Verzeichnissen angelegt und gesammelt werden können.
Und vom Server können sie ja dann von den Nutzer-Rechnern zyklisch (z.B. 
alle 15 Minuten) abgerufen und die Daten weiterverarbeitet werden.

Peter II schrieb:
> Man schreibt einfach noch ein festen http header davor
> und gut ist.

Das ist aber dann auch wieder sinnloses rumgebastel.
Denn dann wird die verarbeitung absolut statisch, was ja eben nicht der 
sinn von HTTP ist. Es ist ja eben so umfangreich, damit es nicht so 
statisch ist.

Und wenn es um einen gemieteten Webserver geht, reicht es nicht, nur den 
Status Code 200 zu unterstützen. Da brauch man schon mehr. Und dadurch 
wird der Code auf dem µC unnötig hochgejubelt. Der Aufwand, einen 
eigenen Daemon mit eigenem Simple Data Transfer Protocol zu realisieren, 
ist ausserdem wesentlich geringer, als nem µC nun beizubringen, mittels 
HTTP reine Textdaten mittels POST zu übermitteln.

Fabian schrieb:
> Das ist aber dann auch wieder sinnloses rumgebastel.
> Denn dann wird die verarbeitung absolut statisch, was ja eben nicht der
> sinn von HTTP ist. Es ist ja eben so umfangreich, damit es nicht so
> statisch ist.

was soll daran schwer sein?

send("GET /data.php?data=");
//sende daten
send("Hallo");
send(" HTTP/1.1\r\n");
send("Host: www.meinedomain.de\r\n");
send("\r\n");

//optional lese errorcode


Fabian schrieb:
> Und wenn es um einen gemieteten Webserver geht, reicht es nicht, nur den
> Status Code 200 zu unterstützen. Da brauch man schon mehr.
warum nicht? Etwas wegen Redirekts, wo sollen die denn plötzlich 
herkommen?

Peter II schrieb:
> was soll daran schwer sein?

SCHWER ist es nicht, aber einfach unnötig. WARUM soll er ein Protokoll 
schlecht implementieren, wenn er mit dem SELBEN Aufwand eine saubere 
Lösung bekommt?

Peter II schrieb:
> //optional lese errorcode
Und schon haben wir den Code wieder aufgeblasen.

Peter II schrieb:
> warum nicht? Etwas wegen Redirekts, wo sollen die denn plötzlich
> herkommen?

Ähm, z.B. wenn der Webhoster temporär auf einen anderen Server 
umschaltet wegen Wartung oder technischem Defekt und bis zum DNS Release 
mittels 307 weiterleitet.
Oder wenn sich das php script im namen geändert hat.
Oder wenn Modrewrite benutzt wird
Oder oder oder oder..

Und dann wären da auch noch nicht-redirects:
401 - wenn sich die Logindaten geändert haben
403 - kommt auch öfters mal vor, wenn der Server defekt war und ein 
Backup eingespielt wird, der Vorgang jedoch noch nicht abgeschlossen ist
503 - Wenn die Server überlastet sind
507 - Gerade wenn es darum geht, dass Daten übertragen und als Datei 
gespeichert werden, MUSS das implementiert sein, damit es ein sauberes 
Produkt ist.

Und ganz wichtig auch ist der Status Code 418 ;)

Ihr benutzt doch auch keinen 16t LKW um PIZZEN auszuliefern.

HTTP ist einfach too much. Der HTTPd erwartet auch urlencodierte 
strings. Das heisst, sämtliche Sonderzeichen müssen umgewandelt werden 
von einem 1 Byte string in einen 2-4 Byte string. Ein µC hat nun mal 
sehr begrenzten Speicherraum. Und das Programm wird garantiert aus mehr 
als nur dem Übertragen der Daten bestehen, denn irgendwoher müssen die 
Daten ja kommen.

FTP ist auch nicht das richtige Mittel, da er den Dateinamen garantiert 
nicht von den "Clients" erzeugen lassen möchte.

Wundert mich, dass noch keiner SMTP vorgeschlagen hat ;) Ist doch auch 
ein Protokoll, um Textdaten über das Internet zu versenden und als Datei 
auf dem Server zu speichern. Genau wie HTTP und FTP.

Warum kein ssh oder scp ?

scp bla user@bar.de:blubb

oder

ssh user@kiste.net "cat > /tmp/blaber" < /tmp/uu


Oder soll (mal wieder) das Rad neu erfunden werden ?

Fabian schrieb:
> SCHWER ist es nicht, aber einfach unnötig. WARUM soll er ein Protokoll
> schlecht implementieren, wenn er mit dem SELBEN Aufwand eine saubere
> Lösung bekommt?
weil man auf einem billigen webspace server nichts anders machen kann.

Fabian schrieb:
> Ähm, z.B. wenn der Webhoster temporär auf einen anderen Server
> umschaltet wegen Wartung oder technischem Defekt und bis zum DNS Release
> mittels 307 weiterleitet.
ich kenne keine hoster wo das jemals vorgekommen ist. Sie haben cluster 
die von aussen immer über die gleiche IP erreichbar sind. Da macht 
niemand etwas mit 307.

> Oder wenn sich das php script im namen geändert hat.
sie genauso wahrscheinlich wie das sich bei einen eigenen protokoll 
plötzlich der Port ändert.

> 401 - wenn sich die Logindaten geändert haben
kommt genauso oft vor wie bei einen eingen Protokoll mit login


> 403 - kommt auch öfters mal vor, wenn der Server defekt war und ein
> Backup eingespielt wird, der Vorgang jedoch noch nicht abgeschlossen ist
> 503 - Wenn die Server überlastet sind
egal, der atmel kann die daten eh nicht zwischen speicher, sind halt 
weg. Auch wenn das internet mal 3Tage lang nicht geht.

> 507 - Gerade wenn es darum geht, dass Daten übertragen und als Datei
> gespeichert werden, MUSS das implementiert sein, damit es ein sauberes
> Produkt ist.
warum? wass soll den der atmel damit anfangen?

Er schickt einfach immer nur eine GET anfage, alles was nicht mit 200 
bestätigt wird, kann ja noch mal wiederholt werden. Was dnan nicht 
durhckommt hat halt pech gehabt. Es geht hier nicht um einen Client-PC 
sondern um einen µC dort hat man nicht die möglichkeit zur not alles in 
eine Datei zu schreiben und später noch mal zu schicken.

Hallo,

wie beim Threadstart schon beschrieben, versuche ich von einem 
SIM900-GPRS-Modul Daten an einen ftp-Server zu schicken und dort in 
einer Datei zu speichern.
Zum testen nutze ich ein selbst geschriebenes C-Programm, das die 
AT-Befehle über UART an das SIM900-Modul übermittelt. Zukünftig soll das 
Modul von einem Mikrocontroller angesteuert werden, aber für die ersten 
Tests verwende ich einen PC.
Im Prinzip scheint alles zu funktionieren, aber die Datendatei taucht 
auf dem ftp-Server nicht auf.
Unabhängig davon funktionieren die auf gleiche Art an den ftp-Server 
übermittelten Befehle zur Angabe des Benutzernamnes, des Passworts und 
Befehle zum Wecghseln des Verzeichnisses und auch zum Anlagen eines 
neuen Verzeichnisses einwandfrei.
Leider kann ich nicht auf das betriebssystem des ftp-Servers zugreifen 
und das dortige logfile ansehen, was die Fehlersuche wohl vereinfachen 
würde.
Vielleicht fehlt auch nur ein einziges Zeichen in einem der beiden 
ftp-Befehle zum Schreiben des Dateinamens bzw. beim nachfolgenden Text, 
der in der Datei enthalten sein soll.
Ich gehe davon aus, dass der Datenstream mit dem ASCII-Zeichen EOF 
"Dezimaler Wert 4" beendet wird. Das ASCII-Zeichen dezimal 26 ([CTRL+Z]) 
signalsiert dem SIM900-Modul das Ende der zu übertragenden Zeichenkette.
Nachfolgend poste ich mal denC-Code mit den AT-Befehlen und die 
jeweilige Antwort des SIM900-Modules.
Hat jemand eine Idee, warum die Datei auf dem ftp-Server nicht angelegt 
wird ?

sprintf(AT_cmd, "AT+CIPMUX=1\r");
SIM900 response cleaned : >"AT+CIPMUX=1 OK "<

sprintf(AT_cmd, "AT+CIPMODE?\r");
SIM900 response cleaned : >"AT+CIPMODE? +CIPMODE: 0  OK "<

sprintf(AT_cmd, "AT+CGATT?\r");
SIM900 response cleaned : >"AT+CGATT? +CGATT: 1  OK "<

sprintf(AT_cmd, "AT+CSTT=\"%s\",\"%s\",\"%s\"\r", "internet.eplus.de", 
"eplus", "gprs");
SIM900 response cleaned : >"AT+CSTT="internet.eplus.de","eplus","gprs" 
OK "<

sprintf(AT_cmd, "AT+CIICR\r");
SIM900 response cleaned : >"AT+CIICR OK "<

sprintf(AT_cmd, "AT+CIFSR\r");
SIM900 response cleaned : >"AT+CIFSR 10.196.204.35 "<

sprintf(AT_cmd, "AT+CIPSTART=0,\"%s\",\"%s\",%d\r\n", "TCP", 
"xxx.xxx.xxx.xxx", 21);
SIM900 response cleaned : >"AT+CIPSTART=0,"TCP","xxx.xxx.xxx.xxx",21  OK 
0, CONNECT OK  +RECEIVE,0,27: 220 Microsoft FTP Service "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  >

sprintf(AT_cmd, "user XXXXX\r\n%c", 26);   //
SIM900 response cleaned : >"user XXXXX   0, SEND OK  +RECEIVE,0,34: 331 
Password required for XXXXX. "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "pass YYYYY\r\n%c", 26);
SIM900 response cleaned : >"pass YYYYY   0, SEND OK  +RECEIVE,0,23: 
230-(BLADE:)XXXXX FTP  +RECEIVE,0,27: 230 User XXXXX logged in. "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "PASV\r\n%c", 26);
SIM900 response cleaned : >"PASV   0, SEND OK  +RECEIVE,0,48: 227 
Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "<

sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP", 
str_IP, pasv_ftp_port);
SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711" 
OK  1, CONNECT OK "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "cwd SIM900\r\n%c", 26);
SIM900 response cleaned : >"cwd SIM900   0, SEND OK  +RECEIVE,0,29: 250 
CWD command successful. "<

sprintf(AT_cmd, "AT+CIPSEND=0\r");
SIM900 response cleaned : >"AT+CIPSEND=0 > "<

sprintf(AT_cmd, "TYPE A\r\n%c", 26);
SIM900 response cleaned : >"TYPE A   0, SEND OK  +RECEIVE,0,20: 200 Type 
set to A. "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "MKD SIMDIR\r\n%c", 26);
SIM900 response cleaned : >"MKD SIMDIR   0, SEND OK  +RECEIVE,0,33: 257 
"SIMDIR" directory created. "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26);
SIM900 response cleaned : >"STOR test01.txt   0, SEND OK  +RECEIVE,0,54: 
125 Data connection already open; Transfer starting. "<

sprintf(AT_cmd, "AT+CIPSEND=1\r\n");
SIM900 response cleaned : >"AT+CIPSEND=1  > "<

sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26);
SIM900 response cleaned : >"hello inhalt01    1, SEND OK "<

sprintf(AT_cmd, "AT+CIPSEND=0\r\n");
SIM900 response cleaned : >"AT+CIPSEND=0  > "<

sprintf(AT_cmd, "QUIT\r\n%c", 26);
SIM900 response cleaned : >"QUIT   0, SEND OK "<

sprintf(AT_cmd, "AT+CIPCLOSE=0,0\r");
SIM900 response cleaned : >"AT+CIPCLOSE=0,0 0, CLOSE OK "<

sprintf(AT_cmd, "AT+CIPCLOSE=1,0\r");
SIM900 response cleaned : >"AT+CIPCLOSE=1,0 1, CLOSE OK "<

sprintf(AT_cmd, "AT+CIPSHUT\r");
SIM900 response cleaned : >"AT+CIPSHUT SHUT OK "<

Oder ganz kurz formuliert :

wenn ich mit dem STOR-Befehl den ftp-Server anweise, eine neue Datei 
anzulegen, wie beende ich dann den nachfolgenden Datenstrom in diese 
Datei, damit der ftp-Server das Ende erkennt ?
Ich dachte, dafür sie EOF (ASCII 4) zuständig ?



sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26);
SIM900 response cleaned : >"STOR test01.txt   0, SEND OK  +RECEIVE,0,54:
125 Data connection already open; Transfer starting. "<

sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26);
SIM900 response cleaned : >"inhalt01    1, SEND OK "<

debugger schrieb:
> Leider kann ich nicht auf das betriebssystem des ftp-Servers zugreifen
> und das dortige logfile ansehen, was die Fehlersuche wohl vereinfachen
> würde.

Hi,
ich kann dich zwar bei der Fehlersuche nicht unterstützen, aber zum 
debuggen ist es immer besser, wenn man an beiden Seiten mitlesen kann. 
Ich würde dir empfehlen erstmal lokal einen FTP Server aufzusetzen, 
damit mit du dir die logdateien angucken kannst. FTP server gibt es für 
linux und windows recht viele, z.B. hier:
http://en.wikipedia.org/wiki/List_of_FTP_server_software

oder du nutzt eine virtual machine z.B. von hier:
http://www.turnkeylinux.org/fileserver

Dann würde ich das ganze erstmal rein lokal bei dir auf dem rechner 
machen.

Verwirrter Anfänger schrieb:
> Ich würde dir empfehlen erstmal lokal einen FTP Server aufzusetzen,
> damit mit du dir die logdateien angucken kannst.

Danke, solche ftp-Serrver kenne ich.
Das bringt mir aber nach meiner Einschätzung nur bedingt was, weil die 
Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet 
erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen.
Ansonsten müste ich ja ein C-Programm schreiben, das über eine  ganz 
andere Methode auf den lokalen ftp-Server zugreift.
Und die Kommandozeilenversion von XP hat wieder eine ganz andere 
ftp-Syntax.

debugger schrieb:
> Das bringt mir aber nach meiner Einschätzung nur bedingt was, weil die
> Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet
> erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen.

Du spinnst. Granatenmäßig.

debugger schrieb:
> weil die
> Kommunikation des SIM900-Modules mit dem ftp-Server ja über das Internet
> erfolgt und so kann ich auf meinen lokalen ftp-Server nicht zugreifen.

Wenn du deine IP Adresse kennst, kannst du auch über das internet auf 
deinen lokalen Server zugreifen. Evtl. musst du noch in deiner Firewall 
einen Port öffnen oder auf deinem Router eine NAT Weiterleitung 
einrichten, aber ansonsten gibt es aus Protokoll Sicht keinen 
Unterschied zwischen dem Webserver und deinem lokalen PC.

Verwirrter Anfänger schrieb:
> Wenn du deine IP Adresse kennst, kannst du auch über das internet auf
> deinen lokalen Server zugreifen.

THX, das wäre einen Versuch wert.
Dann werde ich doch mal auf einem Laptop einen ftp-Server installieren 
und testen, ob ich den so erreiche.

Schön, dass von Genies hier immer noch keiner gemerkt geschweige denn 
dem TS mitgeteilt hat, dass FTP für Datenlogging nun wirklich Blödsinn 
ist, schlichtweg, weil die Datei jedes Mal überschrieben wird und man es 
ohne immensen Aufwand nicht schaffen wird, ein einzelnes vollständiges 
Logfile zu schreiben.
Wäre auch zu einfach, HTTP und PHP zu verwenden, wären ja gerade mal 
geschätzte 20-30 Codezeilen (Client und Server insgesamt). Nein, 
stattdessen wird ihm irendwelcher unfunktionaler und/oder komplizierter 
Schwachsinn empfohlen, bishin zu Socketprogrammierung in C auf dem 
Server, die nicht nur jenen wesentlich teurer macht, sondern auch noch 
ein Krampf im Arsch ist. Ein Clientprogramm, das ein paar Dinge per GET 
überträgt, wäre in kürzester Zeit geschrieben (wohl kürzer, als FTP zu 
implementieren), ein PHP-Zehnzeiler, der das ganze entgegennimmt und in 
eine Datenbank schreibt, ebenso.

Die Messdaten sollen auf dem Server jeweils in einer eigenen Datei mit 
individuellem Dateinamen abgespeichert werden. Daten an eine bereits 
bestehende Datei anzuhängen ist also derzeit nocht nötig. auch wenn das 
mit ftp ebenfalls gehen sollte.
Eigentlich sollte die Datenübertragung mit STOR und einem nachfolgenden 
Datenstream funktionieren.
Das Modul unterstützt auch http, das werde ich auch noch testen, aber 
als Basis will ich zunächst mal die ftp-Version funktionsfähig haben.

So, jetzt werde ich dann den ftp-Server installieren.
Wegen einer starken Erkältung bin ich auch mental etwas angeschlagen, 
also bitte ich für ev. intellektuelle Durchhänger um Nachsicht.

Die Kommunikation läuft über eine Verbindung im Passive Mode, die vorher 
mit dem PASV-Befehl erfolgreich eingerichtet wird (ist auch in der Liste 
oben enthalten).
Es sind zwei Verbindungen aufgebaut, über Port 21 werden die normalen 
Befehle (z.B. STOR test01.txt) und über den vom PASV-Befahl 
zurückgegebenen Port (in dem Fall 2711) wird der Inhalt der anzulegenden 
Datei übertragen (inhalt01):

...
sprintf(AT_cmd, "PASV\r\n%c", 26);
SIM900 response cleaned : >"PASV   0, SEND OK  +RECEIVE,0,48: 227
Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "<

sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP",
str_IP, pasv_ftp_port);
SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711"
OK  1, CONNECT OK "<
...
sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26);
SIM900 response cleaned : >"STOR test01.txt   0, SEND OK  +RECEIVE,0,54:
125 Data connection already open; Transfer starting. "<
...
sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26);
SIM900 response cleaned : >"inhalt01    1, SEND OK "<

Joe Redfish schrieb:
> wo werden denn die Daten gesendet? Vorbereitet ist ja alles, aber wo
> sendest Du diese und wann hat Du dem Server mitgeteilt auf welchem
> Port/IP gesendet wird oder im passiv Mode?

Es soll in die Datei "test01.txt" der String "inhalt01" geschrieben 
werden.

Über Port 21 wird die ftp-Verbindung aufgebaut, die Authentifizierung 
(user, Passwort) durchgeführt, dann wird das PASV-Kommando gesendet und 
mit dem zurückgeliederten Portwert die Passive-ftp-Verbindung 
eingerichtet.
Das klappt alles und wird mit gültigen Rückmeldungen bestätigt.
Dann wird über die Verbindung mit Port 21 und STOR der Dateiname 
("test01.txt") und über die passive Verbindung der Inhalt ("inhalt01") 
gesendet.
Eigentlich hätte ich geadacht, der Ablauf entspricht der Spezifikation.

...
sprintf(AT_cmd, "AT+CIPSTART=0,\"%s\",\"%s\",%d\r\n", "TCP",
"xxx.xxx.xxx.xxx", 21);
SIM900 response cleaned : >"AT+CIPSTART=0,"TCP","xxx.xxx.xxx.xxx",21  OK
0, CONNECT OK  +RECEIVE,0,27: 220 Microsoft FTP Service "<
...
sprintf(AT_cmd, "PASV\r\n%c", 26);
SIM900 response cleaned : >"PASV   0, SEND OK  +RECEIVE,0,48: 227
Entering Passive Mode (xxx,xxx,xxx,xxx,10,151). "<

sprintf(AT_cmd, "AT+CIPSTART=1,\"%s\",\"%s\",\"%ld\"\r\n", "TCP",
str_IP, pasv_ftp_port);
SIM900 response cleaned : >"AT+CIPSTART=1,"TCP","xxx.xxx.xxx.xxx","2711"
OK  1, CONNECT OK "<
...
sprintf(AT_cmd, "STOR test01.txt\r\n%c", 26);
SIM900 response cleaned : >"STOR test01.txt   0, SEND OK  +RECEIVE,0,54:
125 Data connection already open; Transfer starting. "<
...
sprintf(AT_cmd, "inhalt01\r\n%c%c", 4, 26);
SIM900 response cleaned : >"inhalt01    1, SEND OK "<

Läubi .. schrieb:
> anfänger schrieb:
>> Eigentlich hätte ich geadacht, der Ablauf entspricht der Spezifikation.
>
> Du musst die (PASV) Verbindung aber auch wieder beenden sonst weiß die
> Gegenseite nicht das die Datei "fertig" ist.

aaaaaaaaaaaaahhhhhhhhhhhhhhhh, DANKE Läubi, das war es !
Jetzt funktioniert die Übertragung einwandfrei !
Die passive ftp-Verbindung muss geschlossen werden, BEVOR das allgemeine 
QUIT-Kommando über die ftp-Verbindung mit Port 21 gesendet wird.
Dann wird auch der Empfang des Dateinhaltes vom Server bestätigt:

>"AT+CIPCLOSE=1,0 1, CLOSE OK  +RECEIVE,0,24: 226 Transfer complete. "<

Danach folgt dann der normale Quit-Befehl :
>"QUIT  0, SEND OK  +RECEIVE,0,7: 221   "<

Ich hatte mich beim Ablauf an einem Beispiel orientiert, das ANGEBLICH 
funktioniert hat, aber diese Reihenfolge so nicht einhält. Da ist die 
Fehlersuche dann gleich noch schwerer, wenn man nicht weiss, auf was man 
sich jetzt verlassen kann und auf was nicht.

So, jetzt wird das ganze konsolidiert und dann werde ich auch die 
http-Übertragung mal testen.
Also ist dieser Thread wohl noch nicht zu Ende :-)

Übrigens : Das SIM900-Modul macht wirklich einen hervorrragenden 
Eindruck !