Hallo zusammen, ein Gerät (Aktor) soll über das Internet mit einer Datenbank kommunizieren. Problem: Dabei soll der Aktor NICHT im Sekundentakt seinen (eventuell neuen) Status von der Datenbank abfragen. Meine bisherigen Kenntnisse in HTML, CSS, PHP, Java-Script, MySQL (incl. Routinen) und CronJob reichen allerdings nur für eben diese Lösung im Polling-Betrieb. Statt dessen soll der Server zu gegebener Zeit aktiv werden und den Aktor kontaktieren. Idee: Mit Hilfe der GET Methode konnte ich Aktoren bereits dazu bewegen bestimmte Dinge zu tun. Bitte nicht nach Details fragen, auf dem Aktor lief DOS :D Fragen: Leider fehlt mir hier der letzte Step: Wie bekomme ich meine Datebank dazu eine Webseite aufzurufen (um den GET Befehl an meinen Aktor zu senden)? Oder macht man das ganz anders? Welche Suchbegriffe helfen mir hier weiter? Vorab vielen Dank, Stefan
Hi Stefan, Du suchst MQTT. Das ist genau für sowas gemacht. https://de.wikipedia.org/wiki/MQTT https://mqtt.org/ Es gibt da schon jede Menge Bibliotheken undClients sowie auch Message Broker für alle möglichen Systeme/Microcontroller/wasauchimmer.
Stefan R. schrieb: > Fragen: > Leider fehlt mir hier der letzte Step: Wie bekomme ich meine Datebank > dazu eine Webseite aufzurufen (um den GET Befehl an meinen Aktor zu > senden)? > Oder macht man das ganz anders? > Welche Suchbegriffe helfen mir hier weiter? Macht man so nicht. Irgendwas wird ja den Status in der DB umsetzen. Das kann dann auch den Aktor ansprechen. Ev. kann es auch die DB machen wie hier beschrieben, ist aber wirklich Pfusch Pfusch Pfusch: https://stackoverflow.com/questions/27665066/send-an-http-request-in-mysql-trigger-after-insertion-in-a-table
Ne Datenbank macht gar nix aktiv von selbst nach aussen, die reagiert nur auf das was von aussen an Kommandos reinkommt. Wie macht man das nun? Man klemmt nen Dienst davor der das regelt.
Thomas V. schrieb: > Du suchst MQTT. Das ist genau für sowas gemacht. Wenn der TO das Protokoll frei wählen kann, ist MQTT sicher eine schöne Lösung. Aber ich habe irgendwie denn verdacht das der TO sich im Web Umfeld (vielleicht RESTfull) unterwegs ist. Dann währen wahrscheinlich Webhooks die Technik welche seine Anforderungen erfüllen. Allerdings wie auch schon erwähnt ändert sich die DB nicht so spontan, es muss einen Trigger geben und im Idealfall sollte dieser Trigger auch gleich ein Event zum Client schicken das dieser neue Daten abholen kann oder besser gleich die neuen Daten.
Postgres hätte für sowas "LISTEN/NOTIFY" Bei MySQL könnte man mit table-locks was basteln, der Schreib-Task hält dann ständig ein exclusive lock und gibt es nur kurz nach updates/inserts frei. der Lese-Task kann dann ohne Polling auf dem Lock warten. Ist aber sehr "hacky" und vmtl. nicht was der TE braucht.
:
Bearbeitet durch User
Um bei einer Änderung in einer Datenbank eine Aktion auszulösen gibt es Datenbanktrigger. Damit sollte sich das gewünschte Verhalten realisieren lassen.
Michael H. schrieb: > Damit sollte sich das gewünschte Verhalten realisieren > lassen. Bei Postgres: Kein Problem. AFTER UPDATE or INSERT --> pg_notify(kanalname...) und der Client führt ein "LISTEN kanalname" aus, und wird so bei jeder Änderung benachrichtigt. MySQL hat m.W. keinen vergleichbaren Mechanismus. Evtl. könntest du kurz beschreiben, wie du dir das gedacht hast.
Das MQTT-Protokoll scheint genau das zu sein was ich gesucht habe. Auch weil in diesem Zusammenhang immer wieder der Begriff IoT fällt. Die Sensor-Variante scheint recht simpel zu sein. Die stelle ich mir so vor: Sensor -> MQTT via Internet -> mit Hilfe von Python in MySQL Hier habe ich in der Vergangenheit mit Python auf dem Sensor gearbeitet und konnte die Daten direkt in die Datenbank schreiben. Die Aktor-Variante habe ich noch nicht ganz durchblickt und scheint auch dünner dokumentiert. MySQL -> ? -> MQTT via Internet -> Aktor Sprechen MySQL Events/Trigger/Routinen MQTT? Hier muss ich mich erst einmal einlesen. Vielen Dank für alle Antworten.
MQTT funktioniert anders: Zentraler "Datenspeicher"(vermutlich, das was Du mit der DB abbilden willst) ist ein Stück Software, der "message broker". Dafür gibt es unter Linux z.B. mosquitto. Dort melden sich alle Aktoren und Sensoren an. Jeder Sensor und Aktor sendet in regelmäßigen Abständen als auch bei akut eingetretenen Ereignissen seinen Status an den message broker. Alle am message broker angemeldeten Sensoren und Aktoren teilen gleichzeitig dem MB mit, der Status welcher anderer Geräte sie interessiert. Somit sendet der Broker bei einer Änderung am SensorX eine Nachricht an Aktor Y, da dieser sein Interesse daran bekundet hat. Mal ganz vereinfacht und vielleicht nicht 100%ig korrekt ausgedrückt. p.s: Einer dieser MQTT-Clients kann auch eine Home-Automation-Software sein, die z.B.eine WebGUI, nette Graphen, Automatismen oder ähnliches zur Verfügung stellt.
Deutscher Riese schrieb: > Ne Datenbank macht gar nix aktiv von selbst nach aussen, die reagiert > nur auf das was von aussen an Kommandos reinkommt. > Wie macht man das nun? Man klemmt nen Dienst davor der das regelt. Man könnte sich -- also: rein theoretisch, natürlich -- ein bisschen mit diesem Datenbankzeug auskennen und die NOTIFY-Funktionen von PostgreSQL oder Blocking Reads von Redis kennen, oder Redis Streams, oder... ;-)
Εrnst B. schrieb: > Postgres hätte für sowas "LISTEN/NOTIFY" > Bei MySQL könnte man mit table-locks was basteln, der Schreib-Task hält > dann ständig ein exclusive lock und gibt es nur kurz nach > updates/inserts frei. > der Lese-Task kann dann ohne Polling auf dem Lock warten. Ist aber sehr > "hacky" und vmtl. nicht was der TE braucht. ... und vermutlich lossy.
@Stefan, für was ist denn die Datenbank überhaupt da? Nur um den letzten Wert vorzuhalten? MQTT wird für den Zweck schon das beste sein. Dein Sensor sendet die Daten an den Broker und der gibt sie zum Aktor. Wenn die auch noch in der Datenbank benötigt werden (Langzeitaufzeichnung) dann kann der Broker die auch noch an einen Dienst geben der sie in die Datenbank schreibt. Damit der Aktor beim Anmelden am Broker den letzten Wert bekommt den der Sensor geliefert hat, kann dieser seine Nachricht mit gesetztem Retain-Flag senden - dann merkt sich der Broker den letzten Wert. Ansonsten reicht er nur das weiter was reinkommt. Sascha
Thomas V. schrieb: > MQTT funktioniert anders: > ... Sascha W. schrieb: > @Stefan, > > für was ist denn die Datenbank überhaupt da? Nur um den letzten Wert > vorzuhalten? > ... Prima, jetzt wird klarer wie MQTT funktioniert. In einem anderen Projekt habe ich in der MySQL Datenbank den Status mehrerer Aktoren je als Bool gespeichert. Die Aktoren selbst haben permanent und im Sekundentakt ihren Status in der Datenbank abgefragt. Auch wenn das im LAN sehr gut funktioniert hat, konnte ich mich für diese Polling-Variante nie so richtig begeistern. Davon abgesehen gefällt mir an MySQL wie leicht man Daten mit Webseiten einsehen und verändern kann. Gemäß einer kurzen Google-Suche kann ich dies scheinbar auch mit MQTT via JavaScript/PHP/Phyten lösen. Somit wüsste ich nicht, wofür ich MySQL noch benötigen sollte. Nochmals vielen Dank =)
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.