Forum: Mikrocontroller und Digitale Elektronik Datenbankanbindung Microcontroller


von Anja (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.

von Anja (Gast)


Lesenswert?

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

von Dauergast (Gast)


Lesenswert?

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.
1
http://meinserver/log_my_temp.php?timestamp=12345678&temp=235

von René (Gast)


Lesenswert?

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é

von Anja (Gast)


Lesenswert?

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.

von chris (Gast)


Lesenswert?

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.

von Dauergast (Gast)


Lesenswert?

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.

von c. m. (Gast)


Lesenswert?

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).

von Birne (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

Kommt drauf an.
In meinem (abgeschlossenen) Hausnetz würde ich das jederzeit so machen. 
Telnet bleibt am Router hängen.

von Birne (Gast)


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Anja (Gast)


Lesenswert?

würde mir gerne mal den Code anschauen.
vielleicht bekomm ich dann ein besseres Verständnis

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Angehängte Dateien:

Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.