Arduino online monitoring system on php

Weiß wer wo man die Daten dazu downloaden kann oder ein ähnliches Projekt? Arduino online monitoring system on php

Nicht wirklich!

Was ist denn dein Plan?

Daten in eine Datenbank pumpen?

Server im Internet? Oder lokal?

Auf dem ESP eine Website (fals kein Internet) und eine Website online. Daten sollen in Datenbank und in SPIFFS gespeichert werden und als Charts angezeigt werden, auf dem ESP und auch Online. Daten sollen über 433 Funk gesendet werden, zum Master der Internet hat. Es sollen neue User angelegt werden, sobald neue Daten ankommen. Jeder ESP hat ne eigene chipid, das ist dann der User. Master liest die Settings für den Node, die ich über Händi ändern kann und sendet die dann zum Node. Ich glaub das ist der ganze Plan, momentan.

Das sieht schon mal nicht schlecht aus, für den anfang, da ich kein extra Server aufsetzen will kommt MQTT wohl nicht in Frage. Online Broker kenn ich sonst keine die zu gebrauchen sind. NetIO App ist schon mal nicht schlecht, die muss aber jeder kaufen und es läuft nicht aufm PC.

Läßt Dein Provider direkten Zugriff von außen auf die Datenbanken zu?

Dann kannst Du die ESP8266 die Daten direkt in die Datenbanken schreiben lassen und brauchst nur zum Auswerten mit PHP zu arbeiten. Für die Charts kann ich Dir jpgraph empfehlen.

Ein Anfang mit NodeMCU und SHT21 zur Datenbank sieht so aus. Das ist noch nicht fertig, ich bastel noch dran. In Deinem Fall würde ich den PK aus ChipId und Timestamp (in der Datenbank mit current_timestamp setzen). Gemessen wird in diesem Beispiel aller 15 Minuten.

Gruß Tommy

1 Like

Provider hab ich noch keinen gesucht. JpGraph ist ja für PHP, es soll auch auf dem ESP angezeigt werden.

Ach so, da musst Du schauen, ob Du eine Javascript-Chartlib findest.
Die dann nicht auf dem ESP lagern, sondern aus dem Web von der Quelle einbinden.
z.B. für jQuery:

<script src='http://code.jquery.com/jquery-1.6.4.min.js'>
[code]
Da musst Du den ganzen Traffic nicht über Deinen ESP leiten.

Gruß Tommy

Wenn der ESP kein Netz hat, funktioniert das ganze dann nicht, "muss" es aber. version 1.6.4 ist auch zu hoch für den ESP, da ist mit 1.1.2 oder so schon besser. Websiten mit .js zu laden ist ein Geduldstest.

Grafische Auswertungen verlagert man deswegen auf Server, die etwas mehr Rechenpower haben. Meine Messung läuft nun seit 21.03.2017. Die einzigen Aussetzer sind die Zeiten, in denen ich selbst daran rum schraube.

Ist Deine Netzverbindung so schlecht oder willst Du die 200%-Lösung? Im 2. Fall muss man halt leiden. Ich nehme da lieber die technisch sinnvolle Lösung.

Gruß Tommy

Edit: Bei einem Timeöut bootet der ESP neu.

Die User haben nun mal draußen nicht immer Internet. Daten sollen dann solange auf dem ESP bleiben und wenn dann mal irgendwann Internet zur Verfügung steht, solls zur Datenbank hin.

Das soll also zum mobilen Einsatz sein. Sollen da nur die Daten erfasst werden oder auch grafische Auswertungen möglich sein? Im letzten Fall natürlich nur über die Daten auf SPIFF. Du hättest also 3 Betriebsmodi:

  1. Messen
  2. lokal auswerten
  3. Daten in DB schreiben (fire and forget oder mit Verifikation)

Da brauchst Du dann auch noch eine Benutzerschnittstelle, was gerade getan werden soll.

Gruß Tommy

Mobil, genau. Daten erfassen, darstellen und auch Einstellungen vornehmen. SPIFFS wird eh verwendet, da soll die lokale index.html etc hin.

Was heißt fire and forget oder mit Verifikation?

fire and forget = abschicken und vergessen (wird schon ankommen) Verifikation - Daten werden in die DB geschrieben, von dort wieder gelesen und an den ESP zurück geschickt (dann sollte man einen automatischen numerischen PK verwenden) und der ESP vergleicht mit dem, was er gesendet hat. Wenn nicht ok, den Satz löschen und neu senden. Dabei sollte man einen Zähler mitlaufen lassen, der nach X Versuchen abbricht und Fehler meldet. Das kann sonst leicht zur Endlosschleife mutieren, wenn z.B. ein Datenfeld überläuft.

Welchen Aufwand man betreibt hängt davon ab, was von der Genauigkeit der Daten abhängt. Im Extremfall kommt dann noch Verschüsselung und kryptographische Prüfsumme dazu.

Gruß Tommy

Verifikation - Daten werden in die DB geschrieben, von dort wieder gelesen und an den ESP zurück geschickt kommt eher infrage, ich muss es ja sogar so machen. Wenn ESP Internet hat, soll die Website auf dem Server geladen werden, nicht die lokale index.html

Mit Internet: Node(Slave) sendet per Funk (433Mhz) gesammelte Daten an den Master(Gateway?) der mit Internet verbunden ist. Master holt die Website vom Server und sendet per Funk Daten an den Node. Über den Master soll jeder Node ansprechbar sein. Ich habe hier also mehrere Nodes mit Sensoren und nur ein Master der den Zugang zum Internet hat und keine Sensoren auslesen muss. Wäre natürlich auch cool, wenn der Master kein Internet hat dass ich mich mit dem Master verbinde und die lokale Website aufrufe, dass ich dann somit jeden einzelnen Node steuern kann, über Funk(433Mhz).

Ohne Internet: Ich verbinde mich mit einem Node und rufe die lokale Website auf. Hier soll keine große Website sein, nur das nötigste dass es schnell läuft also kein .js sondern nur .css

Da hast Du ja einiges vor Dir. Ich würde es so aufteilen:

Node hat Verbindung zum Master: Schauen, ob Daten zum Senden da sind - diese senden (evtl. verifizieren) und dann lokal löschen.
Ansonsten lokal messen und aufzeichnen, evtl. lokale Auswertung (die würde ich so klein, wie möglich halten).

Master: hat verbindung zum Server - gespeicherte Daten senden, verifuzieren, wenn ok, löschen (da wirst Du ein Array zwischenschlten müssen.
Wenn nach X Versuchen kein Senden möglich, lokale Daten behalten.

Du musst auf der Server-DB Vorsorge gegen doppelte Datensätze treffen.

Master hat evtl. größere Auswerteroutinen.

Die großen Auswertungen würde ich immer noch auf dem Webserver mit der DB fahren. Also die, wo man alle Daten über einen längeren ZTeitraum braucht.

Gruß Tommy

Node hat Verbindung zum Master: nur über Funk! RFM69 hat ja ein ACK, ich denke mal das ist so eine Verifikation.

Möglichkeit 1: Wenn Node erfolgreich gesendet hat, löscht der seine SPIFF Daten. Da muss der Master die Daten(von mehreren Nodes) zwischenspeichern und erst dann löschen wenn erfolgreich zum Server übertragen.

Möglichkeit 2: Wenn Node erfolgreich gesendet hat, löscht der seine SPIFF Daten NICHT. Da muss der Master die Daten(von mehreren Nodes) NICHT zwischenspeichern. Wenn vom Server ein OK kommt, sendet der Master das OK an den Node und erst dann löscht der Node seine SPIFF Daten.

Thingspeak speichert nicht die Daten über längere Zeit, oder? Ich hatte mal mit Virtuino versucht paar Daten zu senden aber irgendwie wollte die App nicht mit Thingspeak verbinden.

Grad wieder die Umleitung zum Starten neuen Threads, zum Glück Daten im Draft gesaved.

Ack heißt erst mal nur, da ist was angekommen, nicht was. Das kann auch Schrott gewesen sein.

Variante 2 halte ich (je nach Datenmenge) für ungünstig, da viele Abgleichvorgänge nötig sond.

Die Thinkspeak /... Sachen kenne ich nicht. Ich habe immer eine eigene Datenbank für jede Anwendung, in der alles landet. Ich bin halt ein alter Datenbankentwickler ;)

Bei meinem Provider (1blue) habe ich 100 mögliche Datenbanken, von denen ich derzeit 12 verwende. Ich habe Vollzugriff auf die Linux-Kommandozeile und kann cron-Jobs einrichten. Ganz wichtig: Trafic unlimited! Der Service ist nicht so prickelnd, den brauche ich aber kaum (außer zum: startet mal durch)

Gruß Tommy

Erklärst du mir noch kurz was TCP, UDP und Websocket bedeutet?

Websocket sieht für mich am besten aus, weil man da keine URL eingeben kann bzw keine URL erscheint wie zB localhost/index.html/gpio/5/1

Nutzt du die .js von jquerymobile?

Charts auf dem ESP darstellen kann aber funktionieren, oder? Über .js wahrscheinlich?!

Noch Tipps zu HTML und CSS Design könnt ich gebrauchen, am besten so ein drag&drop CSS Designer.

TCP und UDP sind Transportprotokolle auf IP-Ebene. UDP (User Datagram Protocol) ist ein einfacher Transport ohne Handshake und Rückmeldung im Protokoll, das muss der Programmierer selbst machen, wenn er es braucht. Vorteil: geringer Overhead. TCP (Transmission Control Protocol) baut eine virtuelle Verbindung mit Handshake auf und sichert auch die richtige Reihenfolge der fragmentierten Pakete. Hoher Overhead Websocket Verbindung zwischen einem Webclient (meist Browser+Javascript) mit einem Websocketserver. Vorteil: Nach Initialisieren der Verbindung vom Browser kann der Server auch ohne neue Anfrage daten senden). Ein Beispiel habe ich hier mal gebaut. #25

Mehr Infos in Wikipedia.

Gute Links zu HTML und CSS sind Selfhtml und W3C-Schools.

Von Clicktools halte ich nichts, damit kann ich also nichts tun. Ich klöpple meinen Code selbst.

Gruß Tommy

W3C hab ich auch schon gefunden, so wie viele andere unbrauchbare Apps(offline und online).

HTML mach ich wohl noch per Code, beim Designen muss ich passen, da steigt doch kein Mensch durch bei dem css gedöns, da muss schon ein schöner Designer her.

Also schwörst du auch auf Websocket? Den Post #25 hab ich auch schon gesehen, daraus schließe ich dass du erst seit kurzem mit Websocket unterwegs bist?

Ich habe damals nur eine kurze Machbarkeitsstudie durchgezogen, mehr nicht. Ich nutze es auch aktuell nicht. Die Browserverknüpfung ist bei mir im Normalfall nur Beiwerk, um von Außen mal rein schauen zu können. Da ich genügend Webspace und Datenbanken habe, mache ich diesen Teil darüber und die Daten kommen per NodeMCU direkt zur Datenbank. Da das nur "aufgehübschter Nebenzweck" ist, macht es nichts aus, wenn da mal die Verbindung nicht da ist.

CSS ist nicht schwer, man muss nur erst mal dahinter steigen. Wichtig: Alle Abmessungen brauchen eine Einheit also z.B. style="width:400px" (Pixel).

Gruß Tommy