Hallo Existiert eine PgSQL lib für STMs? Konkret geht es in dem Projekt um folgendes: 1. STM32s beziehhen sich über DHCP eine jeweils seine IP 2. STM32s verbinden sich zum PgSQL server. 3. STM32s holen sich von der DB seine jeweiligen Kalibrationsdaten (identifizierung über die per DHCP zugewisene IP) 4. STM32s schreiben seine Messwerte in die DB des Servers (Identifikation jeweils wieder über IP) OT: Der DHCP wird so konfiguriert sein, dass er jeweils die korrekte IP anhand der MAC vergiebt. SSL/TLS wird nicht zwangsläufig benötigt. Welches framework/library/os/cube etc. ist für diese Anwendung am besten geeignet?
Unabhängig davon, ob so eine PG-Client-Lib für STM32 existiert (oder wg. der Komplexität überhaupt sinnvoll auf kleineren µCs umzusetzen ist): Überleg dir ob du nicht einen kleinen Teil der Aufgabe auf den Server der auch das PG beherbergt verlagern willst. Ein kleiner Dienst der die gewünschten Funktionen per z.B. HTTP oder MQTT bereit stellt braucht nur ein paar Zeilen Code, oder ließe sich auch ohne Code Clicki-Bunti in node-red zusammenstöpseln. Und damit hat du auf µC-Seite deutlich weniger Komplexität.
Max M. schrieb: > 1. STM32s beziehhen sich über DHCP eine jeweils seine IP ... > 3. STM32s holen sich von der DB seine jeweiligen Kalibrationsdaten > (identifizierung über die per DHCP zugewisene IP) Dafür eine Datenbank verwenden zu wollen, ist ein typisches Beispiel für overengineering. Das kann man problemlos mit einem eigenen TCP oder UDP daemon machen. Oder an einen Webserver knüppern. Oder man verwendet gleich den DHCP daemon dafür. Mehr als ein paar Dutzend Bytes wird die Kalibrierung ja wohl nicht umfassen.
Axel S. schrieb: > Dafür eine Datenbank verwenden zu wollen, ist ein typisches Beispiel für > overengineering Naja es nicht zu tun wäre m.E. unterengineering. Die Datenbank, ist standartisiert und hat offensichtlich erhebliche vorteile für Ambitionen die Daten weiter zu verwenden. Weiter ist die DB SW gut gewartet, wenn ich selbst usercode schreiben würde bleibt nur Risiko für bugs/vulnerabilities etc. Εrnst B. schrieb: > (oder wg. > der Komplexität überhaupt sinnvoll auf kleineren µCs umzusetzen ist): > Überleg dir ob du nicht einen kleinen Teil der Aufgabe auf den Server > der auch das PG beherbergt verlagern willst. Hmm also ein 480MHz H7 mit mehreren mB ROM wird hoffentlich in der Lage sein einen DB client machen zu können. Unabhängig davon diene Idee dies auf dem Server zu machen ist gut. Εrnst B. schrieb: > Ein kleiner Dienst der die gewünschten Funktionen per z.B. HTTP oder > MQTT bereit stellt braucht nur ein paar Zeilen Code, oder ließe sich > auch ohne Code Clicki-Bunti in node-red zusammenstöpseln. Hast du hier ein bsp? Nach welchem standart? einfach JSON-RPC? Harry L. schrieb: > Schau mal hier: > https://github.com/ethanak/SimplePgSQL Danke! Scheint mir aber etwas quick and dirty zu sein, ohne infos ob der Code auch ordentlich gewartet wird + Sorgen Langzeitsupport. Giebts evtl. eine etwas mehr "mature" Softwarelösung?
Max M. schrieb: > Hast du hier ein bsp? Schau Mal bei den ganzen ESP/MQTT/Hausautomatisierung Beispielen. Das Prinzip sollte sich leicht adaptieren lassen. Du erstelltst einen MQTT Broker auf deinem Server und z.B. eine Graphana Instanz mit der Datenbank deiner Wahl. Eine evtl Visualisierung der Daten kannst du dann auch gleich mit Graphana machen. Es gibt für jeden STM ein Main-Topic unter dem die Sub-Topics liegen. Als Main-Topic könnte man z.B. die SNR des STM nehmen. Der STM subscribt auf SNR/Calibdata und bekommt beim Startup oder Änderung die Kalibrierungsdaten. Er kann theoretisch auch darauf published wenn er die Kalibrierungsdaten selbst erheben kann. Wenn nicht kannst du über ein Webinterface o.ä. die Kalibrierungsdaten für jeden Slave vorgeben. Gleichzeitig publisht jeder STM auf SNR/Data seine erhobenen Daten. Die Graphana Instanz kann man dann so einstellen dass sie zyklisch/onchang/onwrite einen neuen Datenpunkte in die Datenbank aufnimmt. Sollte so gehen, Beispiele gibt es da echt viele. Deshalb spare ich mir da einen Link.
Axel S. schrieb: > Dafür eine Datenbank verwenden zu wollen, ist ein typisches Beispiel für > overengineering. Das kann man problemlos mit einem eigenen TCP oder > UDP daemon machen. Oder an einen Webserver knüppern. Oder man verwendet > gleich den DHCP daemon dafür. Mehr als ein paar Dutzend Bytes wird die > Kalibrierung ja wohl nicht umfassen. Das wäre vielleicht nicht ganz flashc, wenn die zweite Anforderung nicht "schreiben seine Messwerte in die DB des Servers" lauten würde. Aber diese Anforderung setzt ohnehin irgendeine Art von Datenspeicher voraus, völlig unabhängig davon, was das dann ist. Wenn jedoch ohnehin ein Datenspeicher sowohl vonnöten, als auch vorhanden ist, dann ist es auch sinnvoll, diesen Datenspeicher zur Speicherung der Kalibrierungsdaten zu benutzen.
Max M. schrieb: > Εrnst B. schrieb: >> Ein kleiner Dienst der die gewünschten Funktionen per z.B. HTTP oder >> MQTT bereit stellt braucht nur ein paar Zeilen Code, oder ließe sich >> auch ohne Code Clicki-Bunti in node-red zusammenstöpseln. > > Hast du hier ein bsp? Nach welchem standart? einfach JSON-RPC? Im Anhang findest Du eine kleine Beispielimplementierung in Go(lang), die ein kleines statisches Binary erzeugt -- 5 MB ohne Kompression mit upx(1) und nur 2,1 MB mit. Die Kompression kannst Du im Makefile abschalten, wenn Du magst, ansonsten müssen natürlich die Datenstrukturen "MeasurementData" (main.go(23)), "CalibrationData" (main.go(34)) und die SQL-Queries (Zeilen 45, 72 und 73 in main.go) an Deine Anforderungen angepaßt werden, außerdem natürlich der URL zur PostgreSQL-Datenbank (main.go(15)), mit curl sieht das dann etwa so aus:
1 | $ curl 'http://localhost:3000/calibration/5' |
2 | {"value1":5,"value2":5.5}
|
Das Programm bekommt die Datenbank-ID eines Geräts per GET-Requests auf den Endpunkt "/calibration/<DB-ID>" und gibt die Daten des Geräts dann via JSON zurück. Das kann man natürlich beliebig abwandeln und zum Beispiel die IP-Adresse des Geräts als Schlüssel benutzen -- ein UNIQUE-Constraint auf der Datenbankspalte ist natürlich sinnvoll. Unter dem URL "/measurement/" nimmt das Programm POST-Requests mit einem Body im JSON-Format entgegen, in curl sieht das etwa so aus:
1 | curl -XPOST 'http://localhost:3000/measurement/' \ |
2 | -d '{"sensor1": 1, "sensor2": 2, "sensor3": 3.3}'
|
Wenn hier ein HTTP 200 Ok zurückgegeben wird, konnten die Daten fehlerfrei dekodiert und der Datenbank übergeben werden, ansonsten hat die Response in diesem Fall einen leeren Body. Ach so: die Namen der Felder in den Datenstrukturen müssen mit einem Großbuchstaben beginnen, sonst klappt das De- und Enkodieren nicht. Viel Vergnügen und Erfolg! :-)
Ich kenne PostgresSQL nicht, aber google sagt mir das einen Adapter mit Rest API gibt. Dann muss auf dem H7 'nur' HTTPS implementiert werden um darüber mit der DB zu schwätzen. https://github.com/PostgREST/postgrest
:
Bearbeitet durch User
J. S. schrieb: > Ich kenne PostgresSQL nicht, aber google sagt mir das einen Adapter mit > Rest API gibt. Dann muss auf dem H7 'nur' HTTPS implementiert werden um > darüber mit der DB zu schwätzen. > https://github.com/PostgREST/postgrest Mir ist PostgreSQL recht gut bekannt, aber Postgrest kannte ich bislang noch nicht, daher vielen Dank für den Hinweis. Für Anwendungsfälle mit komplexeren Anforderungen insbesondere hinsichtlich Authentifizierung und Autorisierung ist das wohl ein feines Tool, wenngleich das Setup dafür anscheinend nichts für Einsteiger ist. Dafür ist die Dokumentation von Postgrest allerdings ein leuchtendes Beispiel dafür, wie man sowas sauber in PostgreSQL implementieren kann, richtig gut! :-)
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.