guten Abend
würde gerne mit meinem Pollin Microcontroller Board:"AVR NET IO"
Messwerte sammeln, z.B. Temperaturmesswerte und diese dann per Netzwerk
an meine SQL-Datenbank übertragen. Hat von euch jemand mal eine TCP/IP
bzw UDP verbindung über die Netzwerkschnittstelle aufgebaut und eine
Datenbank angesprochen?
Danke im voraus für eure Hilfe
Kannst du dich mit dem Server Rechner per Telnet einloggen?
Wenn ja: gibt es für deinen SQL Server ein Command Line Utility?
Wenn ja: Du hast den Fuss in der Tür. Dein Embedded System loggt sich am
Server Rechner ein, startet den Client und setzt die SQL Commandos über
diesen Client ab.
erstmal Danke für die schnelle und Gute antwort.
über telnet kann ich mich einloggen und ja meine Postgresql Datenbank
lässt sich über die Kommandozeile ansprechen.
deine antwort liefert einen sehr guten Ansatz, darauf wäre ich nicht
gekommen. werde in dieser richtung ein paar versuche mache
Möglicherweise ist es einfacher und/oder flexibler und/oder portabler,
die Daten über einen Http-GET oder POST an ein Script auf dem DB-Rechner
zu übertragen:
z.B.
Hallo,
direkt in die Datenbank zu loggen halte ich für keine gut Idee vom
Design her.
Du hast schon eine TCP/IP Verbindung von MCU zu Server. Auf dem Server
solltest Du die DB und einen kleinen AppServer laufen lassen, z. B.
Tomcat. Diesen sprichts Du über REST an, damit kannst Du sehr einfach
CRUD Operationen auf Ressourcen erzeugen. REST ist meistens eine
Mischung aus HTTP Befehlen mit XLM oder JSON. Der Appsserver speichert
dann die Daten in die DB. Der Vorteil Plattform und
implementierungsunabhängiges Protokoll. Jede Ressource ist eindeutig
über eine URI adressierbar. Einfach zu implementieren für alle
Programmiersprachen. Du kannst per REST auch von mobilen Clients
zugreufen.
z. B. Messwert speichern
PUT auf URI http://meinserver/messwert/15072012/2015
<messwert>
<radiation>
1000
</radioation>
<messwert/>
GET http://meinserver/messwert/15072012
liefert XML oder JSON mit allen Messwerten vom 15072012
Gruß,
René
die Aussage von "Dauergast" check ich leider nicht.
warum soll es besser sein wenn man die Daten über einen Post schickt?
ich tendiere ehrlich gesagt dazu, die daten mit telnet zu übertragen.
Ich würde Syslog dafür verwenden, entweder direkt oder auf alternativem
Port über netcat dämon, welcher dann die Daten über ein kleinen Filter
in SQL umwandelt und über stdout dann psql übergibt. Der Filter liest
die Daten über stdin ein und gibt über stdout dann das SQL Query aus.
Syslog, entweder Beitrag "SYSLOG für Ulrich Radigs Webserver auf AVR-NET-IO" oder
die Implementierung von Ethernut. Syslog nach RFC 3164,
Entsprechende SW für den Host: syslog-ng auf Unix, Kiwi syslog daemon
auf Windows.
Anja schrieb:> warum soll es besser sein wenn man die Daten über einen Post schickt?> ich tendiere ehrlich gesagt dazu, die daten mit telnet zu übertragen.
1. Ein http-Server bietet bereits diverse Sicherheitsmechanismen, die
einfach benutzt werden können. Bei Telnet mußt Du das selbst basteln.
2. Bei http-Server+Script brauchst Du auf dem µC nichts zu ändern, wenn
sich die zugrundeliegende Datenbank oder deren OS ändert.
3. Ein http-Server skaliert üblicherweise wesentlich besser als telnetd.
4. Fehlerbehandlung auf Verbindungsebene wird bereits von http geregelt.
Du schickst einen Block und bekommst einen zurück. Bei Telnet-Zugriff
hast Du es mit mehreren Aktionen nacheinander zu tun, deren Fehlschlagen
Du jeweils einzeln behandeln mußt.
5. http funktioniert über übliche Proxies und Firewalls.
ein script in der crontab das per http get(netzwerk) oder serial(z.b.
usbtty) die temp aus dem µc holt und in eine datenbank einträgt - bei
perl z.b. über dbi (dbd-mysql, -oracle, etc).
Karl Heinz Buchegger schrieb:> Kannst du dich mit dem Server Rechner per Telnet einloggen?> Wenn ja: gibt es für deinen SQL Server ein Command Line Utility?> Wenn ja: Du hast den Fuss in der Tür. Dein Embedded System loggt sich am> Server Rechner ein, startet den Client und setzt die SQL Commandos über> diesen Client ab.
Der Stoff aus dem die Sicherheitslücken sind.
Karl Heinz Buchegger schrieb:> Kommt drauf an.> In meinem (abgeschlossenen) Hausnetz würde ich das jederzeit so machen.> Telnet bleibt am Router hängen.
Das haben die Betreiber der iranischen Uranzentrifugen auch gedacht.
Das ist vielleicht eine Geschmackssache, aber eventuell wäre folgendes
sinnvoll:
Du definierst ein primitives Textformat. Eine Zeile ist ein Datensatz.
Dieses Format schickst Du dann irgendwie hin. Beispielsweise in dem Du
einen Port aufmachst auf dem per inetd oder netcat ein Dienst lauscht,
der diese Zeilen entgegen nimmt, und sie weiterverarbeitet. (z.Bsp. in
einen SQL-Server schreibt)
Durch diese Trennung kannst Du jederzeit später eine Komponente ändern.
Nervt Dich beispielsweise der SQL-Server so kannst du die Textdateien
auch direkt speichern und verarbeiten. Genau so ist es wenn Du den
SQL-Server wechselst, oder das Tabellenformat änderst.
So ein simples Textformat kann beispielsweise den Doppelpunkt : als
Feldtrenner haben. Nimm in jedem Fall ein Zeichen das möglichst selten
(oder nie) in Deinen Daten vorkommt.
Glaub mir, die Modularität ist wichtig. Irgendwann wirst Du oder Dein
Nachfolger feststellen, dass ein Teil von dem was Du gemacht hast, Mist
ist. Das ist ganz normal, so geht es jedem von uns. Idealerweise kannst
Du dann die entsprechenden Teile austauschen.
Ich kenne leider den Net I/O nicht, wir haben aber für unseren
Statsserver (Battlefield 2 Mod) so was ähnliches gemacht. Die Gameserver
stehen weltweit verstreut und POSTen am Ende der Runde die Statistiken
an ein PHP Skript, das auf meinem Apache 2 Server läuft. Das PHP Skript
fusselt den Statistik String auseinander, prüft auf Passwort und
Gültigkeit und sortiert ihn dann in die Datenbank (hier mySQL) ein. Bei
Bedarf kann ich gerne mal das Empfängerskript und das Sendeskript (in
Python) posten.
Das ganze hat den Vorteil, das die normalen Sicherheitsmechanismen des
Apache wirksam bleiben und man mit ein bisschen fummeln sogar eine
sichere Verbindung auf Port 443 aufbauen kann.
Das ist unwichtig, solange es um ein internes lokales Netz geht, aber
ich habe z.B. Telnet komplett abgeschaltet und lasse als Terminals eh
nur SSH zu. Nach aussen ist alles dicht bis auf 80 und 443. Und wenn es
mal mehrere Messstationen geben sollte, wird es auch schnell
unübersichtlich.
Ok, hier ist er. 'sendstats.py' ist der Sender, der vom in BF2
eingebauten Python Interpreter gestartet wird. Das wäre der Job für
deinen Net I/O. Bevor der Sender aktiv wird, wird ein String formatiert
und dem Sender übergeben. So ein String hab ich dir mal in 'tmp.xml'
gepostet. 'pcode' enthält das Passwort, das ich ein wenig geändert habe.
Auch der Targetserver ist fiktiv, setze hier deine realen Werte ein.
parsestats.php ist das eigentliche Empfangsskript, welches auf der LAMP
Platform (Linux,Apache,mySQL,PHP) läuft. Es checkt Passwort und ob es
überhaupt etwas ist, mit dem es etwas anfangen kann und sortiert die
vielen Werte dann in die Datenbank 'XWW2' (der Name unseres Spieles)
ein.
Es ist ein bisschen komplex, das gebe ich zu, aber die Runden liefern
immer eine Menge Daten, deswegen der strukturierte Ansatz mit XML und
dem ganzen Tag-Brimborium. Zum Testen habe so ein XML File immer am
Server direkt an PHP gesendet, um die Datenbank Einsortierung in den
Griff zu kriegen. Die beiden Skripte enthalten Kommentare. Für Fragen
stehe ich weiterhin zur Verfügung.