Hallo liebe Leute! Ich habe vor langer Zeit mit meinem Projekt angefangen. Ich habe einen AVR-Controller mit selbtgebautem Board, welches mir mehrere Pumpenmotoren ansteuert, um meine Zimmer- und Balkonpflanzen zu gießen. Außerdem werden über Temperatursensoren einige Temperaturen (Raum- und Außentemperatur) ermittelt. Da das Ganze bisher mit einer von mir geschriebenen Applikation verwaltet wurde (GUI mit Buttons "Pumpe-1 EIN", "Pumpe-2 EIN") möchte ich nun den nächsten Schritt wagen. Und zwar möchte ich das Ganze webbasierend über ein Webinterface machen. Sprich, ich habe eine Webseite, auf der mittels Login der Benutzer authentifiziert wird, um die Berechtigung zu bekommen, ein Gießen zu aktivieren :) Das Ganze sollte außerdem auf einem von mir bereits optimierten Linux-Distri laufen, die in kürzester Zeit startet (Boot dauert etwa 10 Sekunden). Anschließend startet sofort ein TestProgramm ("Hallo Welt"). Das Hallo-Welt-Programm soll später dann durch ein Messwert-Programm ersetzt werden, welches mir dann vor-Ort (daheim) die Daten liefert und eventuell weitere Konfigurationsmöglichkeiten überlässt, die vom Web aus aus Sicherheitsgründen nicht erreichbar sein sollten (Beispielsweise Lichter ein/ausschalten). Als kleines Zusatzfeature sollte dann noch die Temperatur stündlich in einer mySQL-Datenbank mitgeschrieben werden, um ggf. später ein Diagramm des Temperaturverlaufs eines Monats ausgeben zu können. Leider weiß ich nicht, wie ich die Schnittstelle zwischen Web und Mikrocontroller knüpfe. Eine I/O-Karte (PCI) fällt definitiv flach, da der Controller ggf. später eine Eigenintelligenz verpflanzt kriegt, falls der Computer abstürzt, die Wohnung nicht vom Gießwasser überflutet wird ;-) Nochmal der Aufbau. - Am Mikrocontrollerboard sind Sensoren/Aktuatoren angeschlossen. - Mikrocontrollerboard hängt über RS232 an dem Linux-"Server"-PC. - Linux-Server-PC liefert kontinuierlich Messwerte vom Controller, veröffentlicht sie außerdem im Netz. Die Linux-Applikation würde ich (konsolenbasierend) in C schreiben, da das noch relativ hardwarenah ist und ein gutes Handling mit Schnittstellenprogrammierung (RS232) ermöglicht. Ich habe nun an folgendes gedacht: - Der "Weblayer" (damit meine ich ausschließlich das Webinterface) greift ausschließlich auf die mySQL-Datenbank zu, liest Daten (Messwerte) oder setzt Werte (z.B. Befehl: "jetzt gießen"). Dafür würde ich z.B. PHP nehmen. - Die Linux-App. macht die Kommunikation zwischen Mikrocontroller und PC, liefert dabei die Daten an die mySQL-DB und gibt die Werte am Bildschirm aus. - Der Mikrocontroller ist soweit programmiert, dass er Daten vom PC empfängt und diese dann ausführt. Was haltet ihr von meinem Lösungsansatz? Vielen Dank im Voraus!
Einwas noch: Ein Bekannter von mir hatte mal ähnliches aufgebaut, allerdings nicht mit Linux und einer C-App. sondern komplett mit PHP. Allerdings ist mir das explizite Ansteuern meines Mikrocontrollers direkt via PHP viel zu heikel, da Skriptsprache und echtzeitähnliches Verhalten nun mal nicht vereinbar sind. Deshalb würde ich lieber die Methode mit C vorziehen.
Irgendwie hab ich das Gefühl, das ist alles so halbgegoren. * Hast du eine ständige Leitung ins Internet oder wie stellst du dir diese Anbindung vor? * Wenn ich dich richtig verstehe, dann willst du die Web Seite selbst extern hosten. Bei deinem externen Provider soll es also eine Web-Seite geben Diese Web Seite holt sich die Werte aus eine Datenbank, die ebenfalls beim Provider liegt und schreibt ihre Ergüsse (Giessen ja/nein) da ebenfalls rein. Bei dir lokal zu Hause steht ein Linux Rechner, dessen einzige Aufgabe darin besteht als Mittler zwischen dem Provider und deinem µC zu fungieren. Dieser Linux Rechner: läuft der ständig? Oder sieht der zb alle halbe Stunde in der Datenbank nach, ob es etwas zu tun gibt bzw. der updated die aktuellen Werte in der Datenbank und danach legt er sich wieder schlafen. Und dann gibt es noch den µC, der über eine Serielle mit dem Linux Rechner verbunden ist. Hab ich das so richtig? Das hört sich für mich alles mächtig kompliziert und komplex an. Wenn ich sowas machem müsste (Ich habe eine ständige Verbdinung ins Internet), dann würd ich mir eine AVR Net I/O kaufen, vom Ulli den Web Server da drauf installieren und den ganzen AVR direkt mit einer eigenen IP/Port ins Netz hängen. Ich bin nicht auf einen Provider angewiesen, dass mir der eine Datenbank zur Verfügung stellt, ich brauch keinen Provider zum Hosten einer Website, ich brauch keinen PC dazwischen. Ein externer Browser verbindet sich direkt zum µC und macht dort seine Sache. Laufende Kosten sind minimal und die AVR Net I/O kostet einen Spottpreis. > Allerdings ist mir das explizite Ansteuern meines Mikrocontrollers > direkt via PHP viel zu heikel, da Skriptsprache und echtzeitähnliches > Verhalten nun mal nicht vereinbar sind. Der war gut. Wozu brauchst du da Echtzeit? Weißt du überhaupt was man in der EDV unter Echtzeit versteht?
JK schrieb: > da Skriptsprache und echtzeitähnliches > Verhalten nun mal nicht vereinbar sind. Wieso das? Echtzeit bedeutet nur schnell genug, und beim Blumenbewässern seh ich nicht so viel Zeitdruck. Zur Frage: Bemühe doch mal die suche hier gibt etliche Threads die sich mit AVR in verbindung mit Ethernet beschäftigen.
>* Hast du eine ständige Leitung ins Internet oder wie stellst > du dir diese Anbindung vor? Eigener Webserver mit Portforwarding (Router) dürfte wohl kein Problem darstellen. >* Wenn ich dich richtig verstehe, dann willst du die Web Seite > selbst extern hosten. Eigener Webserver. Sehr wohl weiß ich was man unter Echtzeit versteht. Man versteht darunter, dass etwas in einer vorgegebenen (maximalen) Zeit ausgeführt werden muss. Ich habe vor, später etwas Zeitkritisches zu steuern, zum Beispiel eine Heizungssteuerung. Tut euch das nicht weh, wenn man mit einer Skriptsprache (PHP) einzelne Bytes an eine Hardware schickt? Mir schon.
Nochmals zum Verständnis. Dieser Linux-Rechner soll nichts anderes sein als ein Webserver, an den mein Controller angeschlossen ist, in einer Datenbank Werte protokolliert werden und das Ganze im Web zu veröffentlichen. Das alles findet bei mir DAHEIM statt. Also kein Provider.
Ich weiss ja nicht, wie zwingend für dich die Protokollierung in einer DB ist, aber die oben erwähnte Variante mit dem Pollin NET IO Modul sollte einfacher und vor allem platzsparender sein. Ich hab sowas vor ein, zwei Jahren mal gebaut - allerdings in der Sparvariante, also ohne AVR und SQL-DB, dafür mit Parallelport und mini-C-Programm, das über die Kommandozeile Bitnummer und Zustand (an/aus) entgegen genommen hat und entsprechend die Bits des Parallelports gesetzt hat. Direkt aus PHP ist afaik ja kein Zugriff auf die Hardware möglich (warum auch, dafür gibts ja andere Sprachen). Quintessenz: Wenn du auf deine SQL-DB verzichten kannst, aber Zugriffe und Aktionen loggen willst, nimm das NET-IO-Modul und spendier ihm ne SD-Karte und logge Zugriffe in eine csv-Datei.
Naja Parallelport ist Asbach-Uralt. Und direkt die Datenleitungen als Zustandssteuerung herzunehmen möchte ich eigentlich auch nicht. Sicherlich brauchbar, wenn es darum geht, nur zwei Zustände an Aktuatoren zu geben. Das Problem ist eben, dass ich dieses Mitloggen haben möchte, außerdem erscheint mir da ein AVR etwas zu unsicher, wenn ich daran denke, einen Userlogin auf dem Webinterface mit Verschlüsselung (gibts das beim AVR? ) zu verwenden. -Ich denke nicht, dass das der AVR-Webserver bietet. Da fühle ich mich bei einem millionenfach bewährten Apache-Server schon deutlich wohler, wenn ich daran denke, dass via Web meine Heizung nicht von irgendwem gesteuert wird. Nächster Grund, warum ich für den Linux-PC bin: Beim AVR ist man immer eingeschränkt, sei es die Leistungsfähigkeit, der Speicher oder eben die Möglichkeiten. So kann ich in Linux in C, Perl, Bash, was auch immer programmieren, was beim AVR erstmal ein Experiment wird. Gruß
Ein AVR als Gieß-Controller ist ja OK. Ein Linux-Server mit WEB-Server ja auch. Was fehlt ist ein klize kleines Programm, das eine Kommunikation zwischen der Datenbank und dem Controller herstellt. Das geht ganz einfach: - Datenverbindung seriell. V24 gibts schon ewig und tut sicher. - Auch der AVR kann serielle Daten. - Das Linux Programm öffnet einen seriellen TTY Port und kann dann relativ leicht komunizieren. Einfach ein Byte Schicken, darin sind 8 Bits = 7 Pumpen + Parität. - der AVR kann dann auch irgend was schicken, das dann das PC Programm in die Datenbank baggert. Die Web-Seite läuft über den Apache-Server mit PHP direkt unter Linux und der muss nichts vom Mikrocontroller wissen, nur von der Datenbank. Das PC-Programm pollt z.B. jede Sekunde ob ein neuer Befehl in der DB eingetragen wurde und tut den dann zum AVR übermitteln. Wo ist jetzt das Problem?
JK schrieb: >>* Hast du eine ständige Leitung ins Internet oder wie stellst >> du dir diese Anbindung vor? > > Eigener Webserver mit Portforwarding (Router) dürfte wohl kein Problem > darstellen. OK. Dieses klitzekleine Detail hast du vorher ja nicht erwähnt. > > Sehr wohl weiß ich was man unter Echtzeit versteht. Man versteht > darunter, dass etwas in einer vorgegebenen (maximalen) Zeit ausgeführt > werden muss. > > Ich habe vor, später etwas Zeitkritisches zu steuern, zum Beispiel eine > Heizungssteuerung. Was ist an einer Heizungssteuerung kritisch? Ob die Heizung jetzt 2 Hunderstel Sekunden früher oder später abschaltet dürfte kaum eine Rolle spielen. Wenn du nebenher vom Rechner ein Pendel balanzieren lassen willst, dann bist du zeitkritisch und brauchst ein Echtzeitsystem! > Tut euch das nicht weh, wenn man mit einer Skriptsprache (PHP) einzelne > Bytes an eine Hardware schickt? Mir schon. Nicht wirklich, solange es den Zweck erfüllt. > außerdem erscheint mir da ein AVR etwas zu unsicher Auch wenn Linux sehr stabil läuft, dein AVR läuft stabiler. Da gibt es keinen anfälligen Unterbau oder fehlerhafte Treiber. Dein Programm ist das einzige was am AVR läuft. Was du programmierst passiert und sonst nichts anderes. > Ich denke nicht, dass das der AVR-Webserver bietet. Er bietet das, was du hineinprogrammierst. Der kleine Web-Server ist beileibe nicht so aufgebläht und ausgefuchst wie ein großer Apache. Dafür ist er aber überschaubar und du hast jedes Detail in der Hand. Aber egal: Du hast dich bereits auf Linux eingeschossen und das ist auch ok so. Wozu du dann da überhaupt noch einen AVR brauchst, ist mir allerdings wirklich nicht klar. Parallelport, daran mgl ein paar Schieberegister oder eine fertige I/O Platine für den PC und fertig. Je mehr Prozessoren beteiligt sind, desto fehleranfälliger wird das Gesamtsystem normalerweise solange man keine Erfahrung mit Multiprozessoren hat.
@ Markus Müller: Genau so habe ich es mir vorgestellt, wie auch aus meinem ersten Beitrag zu entnehmen ist. Meine Frage war ja >Was haltet ihr von meinem Lösungsansatz? >Wozu du dann da überhaupt noch einen AVR brauchst, ist mir allerdings wirklich nicht klar. Wiegesagt, um dem kleinen AVR irgendwann mal eine Eigenintelligenz einzuhauchen, falls der PC abstürzt und die Heizung kurz vor der Kernschmelze steht. >Parallelport, daran mgl ein paar Schieberegister oder eine fertige I/O >Platine für den PC und fertig. Von den Preisen einer I/O-Karte verglichen mit einem AVR ganz zu schweigen. Hier nochmal der Aufbau meines Projekts: +-----------------------------+ +------+ | Linux-PC | |Sensor|============>|-----| | +---------+ +---------+ | +------+ | AVR |<===>|SteuerApp|<==>|Datenbank| | +--------+==========<|-----| | | | +---------+ | |Aktuator| | | | \/ /\ | +--------+ | | | +---------+ | | | | | Apache | | | +---------+ | mit PHP-| | | | Webseite| | | +---------+ | | | | | +-----------------------------+
Wozu auch? Du hast einen Plan wie du das machen willst. Irgendwelche Veränderungen an deinem Plan lässt du nicht zu bzw. schmetterst du ab. Dein Plan klingt nicht schlecht und realisierbar. Und mehr kann man dazu auch nicht sagen. Der Rest hängt von deinen Fähigkeiten ab, die hier keiner kennt.
Naja am "Grundplan" lasse ich natürlich gerne Vorschläge/Veränderungen zu, aber ich möchte halt keinen AVR-NET-IO dafür verwenden, der oben gezeigte Aufbau sollte schon so sein. Aber vielleicht gibt es ja da noch einen Feinschliff? Danke!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.