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!
