welche Option würdet ihr wählen um Sensordaten möglichst in Echtzeit anzeigen zu lassen? Ich nutze aktuell ESP32 Dev mit Wifi und BLE, leider ist das Senden via Wifi an eine Datenbank zu langsam. Nun hatte ich mir überlegt, dass ich entweder von dem einen ESP32 der die Daten sammelt via BLE an einen anderen sende, dieser dann mittels Wifi in die Datenbank, oder aber dass der zweite ESP32 einen eigenen Server erstellt (hab hier igw noch einen Code rumliegen, weiß aber nicht mehr wie schnell das ging). Alternativ hätte ich an einen Raspberry gedacht oder eine kleine Handy oder PC App. Leider hab ich bisher noch nie was mit Handy Apps gemacht und PC Programme fast auch nichts. Aus dem Bauch raus würde ich entweder zu 2 ESP und einem Senden in die Datenbank (mir ist klar, dass es hier nicht besonders schnell läuft, insofern würde ich das bspw für EKG Kurven ungern machen) oder an ein Dashboard auf dem ESP32 und diesen als Server. Hier würde sich allerdings auch anbieten, je nachdem wie schnell das läuft, dass ich auf dem ESP den Server hoste auf dem die Sensordaten abgegriffen werden und auf den zweiten in die Datenbank (wie viele Sampels pro s würden sich denn da ca ausgehen, weiß das wer?). Sind jetzt verschiedene Optionen und ich würde mal anfangen die 2 ESP mittels BLE zu verbinden, sofern jemand allerdings noch Infos hätte die mir beim planen helfen (sonst ginge ich via trial und error vor) würde ich diese dankend annehmen.
Wieso? Bei mir ist das schnell genug. Welche Daten möchtest Du denn in welchen Zeitabständen darstellen?
Oft sind eher die Vorstellungen wie schnell man die Daten haben will, etwas stark überzogen an der Realität vorbei.
Wirkliche Hochgeschwindigkeitssysteme (sowohl Sensoren, als auch Übertragung) lassen sich nicht mit Bastelmitteln realisieren.
Also Grundfrage: Welch Daten willst Du denn erfassen?
Baue Dir ein struct.
In dem fasst Du zusammen, was Du anzeigen/auswerten willst.
Dann füllst Du das so wie Du willst und kannst.
Die Daten schreibst Du weg.
Die Anzeige der aktuellen Daten dann nicht aus der Datenbank lesen sondern das struct weiterverwenden.
Wenn Du mit einem Browser auf dem Tablet/PC/telefon arbeitest, kannst Du dem html-code ein refresh() im Header mit übergeben.
Bei einer APP kannst die Daten via Push (unsinnigerweise) bei jedem Umlauf raus schicken.
Oder eben nur, wenn geändert.
Es hängt etwas davon ab von welchen Daten wir sprechen. Die Sauerstoffwerte zB müssen nicht sofort angezeigt werden und da genügt auch 1 Wert pro Sekunde oder auch alle 5 Sekunden (Pulse ebenso), aber bei der EKG und der Pulswelle benötigt es mehrere Daten, damit diese korrekt angezeigt werden. Da ich alles in Grafana einspielen will, habe ich aktuell die Influx DB gewählt, hierbei ist es aber so, dass diese die Daten mit Zeitstempel speichert, insofern kann ich diese - soweit ich das verstehe - nicht in einem "Ruck" schicken, ich müsste mEn dann eine zweite Datenbank nutzen wie mySQL, richtig? Es geht auch eher mehr darum, ausreichend Datenpunkte mit korrektem Zeitstempel zu verschicken, es muss nicht "perfekt live" übermittelt werden. Bzgl der Hardware darf diese auch etwas mehr kosten als ein 10€ Arduino, da ich auch möglichst gute Sensoren verwende (primär Texas Instruments) und die Platine auch Multilayer ätzen lasse. Aber ich möchte das Step by Step aufbauen und die meiste Zeit in die Algos und machine learning investieren, insofern sollte das "Grobe" in überschaubarer Zeit umsetzbar sein (und beim Programmieren bin ich Anfänger, wie wohl schon deutlich geworden ist ^^). Dafür kann ich die Platinen in Altium routen und planen. Eine kleine Handyapp wäre auch insofern "fein" weil ich gerne mal das grob können würde, das müsste ich ev mal überschlagen wie viel Zeit sowas verschlingt. Aktuell präferiere ich denke ich die 2 ESP Version, einen Beispielcode hab ich mir schon rausgesucht. Wie das mit struct läuft muss ich mir auch noch anschauen. (Es summiert sich sehr viel, insofern kann ich das nur etwas "häppchenweise" durcharbeiten, sry wenn ich mal wo etwas "hänge" ^^).
Hoffe ich hab grob die nötigen Antworten gegeben. Ich würde btw gerne so 10 Sample pro Pulskurve abgreifen, bei einem 120er Puls wären das 1200 Datenpunkte pro Minute.
Influx-DB habe ich keine Erfahrung, aber bei MySQL könntest Du auch Datenpakete erst mal im RAM zusammen fassen (evtl. Tiefpass zur Glättung) und dann an die DB übertragen. Kennst Du die Direktzugriffslib für MySQL/MariaDB von Charles Bell (ORACLE). Das macht natürlich nur Sinn für eine DB im lokalen Netz, wenn es schnell gehen soll.
Hier wirst Du viel Testaufwand rein stecken müssen, um die optimale Lösung zu finden.
ich hatte mal einen Tempsensor an eine mySQL via ESP gesendet, das ging auch nicht flotter als die InfluxDB, aber da ich den Code noch hab (glaub es war eh die von dir erwähnte Lib) wäre das auch eine Option. Wenn ich aber die Daten sammle, wie wird da der Zeitstempel gesetzt? Das wäre dann ein Zeitstempel pro Datenpaket, oder man sendet die Millis mit, so dass man nachher verschiedene Abweichungen miteinander abgleichen kann, korrekt?
NUr noch mal zum Verständnis: Von was sprechen wir denn hier?
Du kannst Deine Datenpakete an ein DBMS schicken und dort zu jedem Paket einen Zeitstempel generieren, oder aber einen Zeitstempel beim senden erzeugen.
Wenn Du sichergehen willst, das Du die Daten immer in der Reihenfolge bekommst, wie Du sie versendest, kommt nur der Stempel vom Erzeuger in Frage.
Für Dein EKG kommt ggfls. auch die Zusammenfassung mehrerer Datenpunkte in ein Paket infrage. Dann reicht ein Zeitstempel für das gesamte Paket und wenn Du Aufwand betreiben willst, kannst Du auch noch eine ID erzeugen, die innerhalb des Paketes die Zuordnung des Wertes in der Timeline ermöglicht.
Das schreiben direkt in die DB ist dabei die einzige sinnvolle Möglichkeit. Ein Versuch, das ggfls. über einen Webservice und /GET zu machen, ist wohl zum scheitern verurteilt.
Und nun zum spannenende Teil:
Ich hab selbst eine Zeit lang mit der mySQL-Lib ein etwas größeres Projekt begleitet.
Da wurde in jedem Umlauf ein Datenpaket geschickt.
Dafür gabs auch die Infrastruktur.
Dein EKG ist doch nix weiter als ein Wert.
Wie viele davon willst Du während eines Wimpernschlages übertragen und anzeigen?
Ich denke, das es eher am Frontend hapert als an der Zusammenstellung und Übermittlung des Datensatzes aus Deinem Gesundheitsscanner.
Ich denke Du hast schon recht, dass das Frontend schwieriger wird als das Senden in die DB. Darum wollte ich auch mit fertigen Dashboards arbeiten, bei denen ich nichts programmieren muss, sondern mittel drag and drop das aufbauen kann.
Das denke ich auch.
Ich hätte an 10 Datenpunkte gedacht, bei einem Maximalpuls von 220 währen das bei 10 Datenpunkte pro Pulskurve 2200 Datenpunkte und 220 Pakete pro Minute.
Das macht aller Sekunde nicht mal 40 Datenpunkte.
Nehmen wir an, das Du mit jeden DP 10 Bytes verschickst.
Det kannste mit nem Akkustikkoppler übertragen
Ich meinte eher Sensorwerte. ^^ Gerade hab ich mir mal mySQL auf den Windows PC installiert, das werde ich dann mal auf die Performance hin testen. Auf einem alten Laptop, einen ASUS Yoga, werde ich mal Linux darauf spielen und dann dort dann nochmal mySQL und die InfluxDB (die Influx DB will auf Windows einen AMD und ich hab leider einen Intel ), die werde ich dann direkt über den localhost ansprechen und die Performance testen, mal sehen was dabei rauskommt. Danach versuche ich es mit den Datenpaketen, wie von dir empfohlen. Bei der Gelegenheit kann ich auch gleich wieder Hassio installieren.
Du hast verstanden, dass localhost der Computer selbst ist? Du damit also keine Performancetests mit dem Arduino durchführen kannst? Für den ist localhost er selbst.
Aktuell tendiere ich dazu das über einen BLE Dongle zu machen, aber ich nehme jede Hilfe / jeden Ansatz gerne an, da ich lieber verschiedene Lösungen teste und dann die beste auswähle.
Ich mach es ja mit ioBroker-Pi, dem ioBroker für den RaspberryPi. Über mqtt hab ich den esp8266 eingebunden, sodass das Float-Diagramm dann in Echtzeit, je nachdem, wie oft es sich aktualisiert, in Echtzeit die Daten anzeigt.
Mal so ganz unabhängig von der eigentlichen Frage, aber was heißt schnell genug? Bzw. mit was für Zeiten ist zu rechnen, wenn man Daten (wenige Byte) über das WLAN an eine Online Datenbank schickt und diese mit einem zweiten ESP32 wieder abruft?
Also die Zeit vom senden bis zum empfangen?
Da ich nur aller 15 Minuten messe, ist mir die Übertragungszeit eigentlich egal.
Was ist schnell genug hängt immer vom realen Einsatzzweck ab. Da sich Umgebungsparameter nicht so schnell ändern genügt für mich dieses Intervall.
@ESCHICK
der Löwenanteil wird die Wifi Übertragung sein. Das Eintragen auf eine DB geht dann fix.
ich habe es nicht gemessen, aber du kannst das ja selber mal probieren.
uint32_t starttime = millis();
clientSend(); // oder wie es auch immer bei dir heißen mag
uint32_t endtime = millis();
Serial.println(endtime - starttime);
Frage ist halt, wie schaut dein Endpoint aus (der die Daten entgegen nimmt) und ist dieser performant.
Für "sehr schnelle" Aktionen kommt eigentlich nur der direkte Schreibzugriff im lokalen Netz unter einmaliger Anmeldung an der DB und dann nur noch Inserts in Frage. Ob das ausreicht, kann man nur experimentell ermitteln. Der DB-Server sollte auch einiges an Performance können.
So wie ich die Anforderung verstanden habe, würde ich das Ganze etwas anders aufbauen.
Die Daten sollen quasi in Echtzeit dargestellt werden. Warum das dann nicht einfach machen?!
Der ESP sendet die Daten direkt zu der Anwendung, welche die Diagramme darstellt.
Dann kann im Hintergrund, in einem separaten Task, der Datensatz in eine Datenbank der Wahl geschrieben werden.
Bzw. verwendet man ein sog. MiddleTier. Das stellt den Webservice für den ESP bereit (Oder Bluetooth-Endpunkt) und verbindet sich parallel mit der DB und der Anzeigesoftware.
Hat den Vorteil, dass nicht zeitgleich in die DB geschrieben und gelesen wird. Die Anmeldung und Verbindung zur DB wir dann von dem MiddleTier (Dienst) geregelt.
Für die genannte Anzahl der Daten mache ich mir da keine Gedanken, was die Performance angeht.
), die werde ich dann direkt über den localhost ansprechen und die Performance testen, mal sehen was dabei rauskommt. Danach versuche ich es mit den Datenpaketen, wie von dir empfohlen. 
