"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

HTTP API Design - langsames IoT Device

Vinci 01.05.2023 - 11:41 4798 11
Posts

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
Grüß euch

Mal angenommen ich hab ein ein lahmes IoT Device dass von irgendwelchen angeschlossenen Sensoren Daten lesen und schreiben kann. Wie sähe da eine sinnvolle HTTP API aus wenn das Ding so lahm is dass man auf den 1.Request nicht synchron antworten kann?

Mein aktueller Vorschlag wäre
  1. PUT mit JSON Anhängsel lesen/schreiben/Daten usw. -> 202 Accepted sofern JSON sinnvoll is
  2. GET pollen bis alles gelesen/geschrieben wurde, oder ev. Timeout, Fehler, etc. -> Antwort Code je nach Ergebnis

Ergibt das irgendwie Sinn? Gibts irgendeine "best practice" was man tut wenn angeforderte Daten nicht sofort zurückgemeldet werden können?

tia

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12069
Meiner erfahrung nach i. w. so, wie du das bereits beschrieben hast :)

Der Request Handler am Server, der die Daten entgegennimmt, retourniert "schnellstmoeglich" eine Response, die einen einen einzigartigen Token beinhaltet, den sich der Client/UA merkt. Spaeter kommt der Client/UA mit dem Token im Request an einem anderen Endpoint/Request Handler vorbei, wo er dann pollen kann, was der Server inzwischen zum Ergebnis seines urspr. Requests sagen kann.

Welche Verben du dafuer verwendest, bleibt dir ueberlassen (zumal du eh Client und Server kontrollierst), aber zumindest fuer die zweite Haelfte ist GET sicher nicht grundfalsch.

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 49912
pollen ist sicher nicht falsch.
Je nach dem was es genau ist und wie Zeitkritisch die Daten sind bzw Reihenfolge relevant ist kannst du auch auf eine (fertige) Message Queue setzen

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
Ok, Danke für die Tips, wollte nur wissen ob ich nicht eh irgendwas komplett unsinniges tu da ich in dem Bereich frisch bin.

Zeitkritische Daten hab ich in dem Projekt auch, allerdings für andere Dinge. Dort ist aber auch vieles bidirektional und ich hab gleich einen Websocket dafür genutzt.

JDK

Oberwortwart
Avatar
Registered: Feb 2007
Location: /etc/graz
Posts: 2827
Wennst eh schon Websockets am Start hast, kannst die doch gleich weiterverwenden, oder was ist der Use-Case?

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
Zitat aus einem Post von JDK
Wennst eh schon Websockets am Start hast, kannst die doch gleich weiterverwenden, oder was ist der Use-Case?

Die Websockets verwend ich aktuell für Firmware-Updates die vom IoT Device selbst noch rausgehn. Also nicht das Update vom IoT Ding selbst, sondern von den Modulen die dran hängen.

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 49912
Was ist denn dass für ein SoC?
Was verwendest für ein Framework?

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
SoC ist ein ESP32-S3, das Framework is von Espressif selbst, ESP-IDF.

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 49912
Da würd ich garnicht all zu viel selbst stricken und ein Framework verwenden
ESPHome, Tasmota, Esp easy, ESPurna ...

Drunter verwenden glaub ich alle PlatformIO - musst shcauen welcher den S3 jetzt schon kann

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
Die Sensoren waren eigentlich nur ein Beispiel für irgendeine Peripherie die etwas Zeit braucht um Werte zu liefern, in Wahrheit is das alles noch viel schlimmer. Ich möchte Modelleisenbahnen ansprechen wo die Kommunikation mit einer Modulation der Stromversorgung funktioniert und teilweise nur Binärrückmeldungen auf Basis von Stromimpulsen existieren... Man kann sich vorstellen dass da selbst ein f* Byte lesen etwas dauert kann. :D

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 49912
Kann ich mir gut vorstellen dass es alles andere als einfach umgesetzt ist.

Da ich kein guter Entwickler bin setz ich lieber auf konfigurieren und halt kleine Teile erweitern als alles selbst zu schreiben.

Da kannst dann den "Kern" von der Stange nehmen und musst dich "nur" um den Part für die Interpretation der Binär Meldung kümmern.

Firmware Update und MQ ist da schon gelöst

Vinci

hatin' on summer
Registered: Jan 2003
Location: Wien
Posts: 5821
Zitat aus einem Post von Viper780
Kann ich mir gut vorstellen dass es alles andere als einfach umgesetzt ist.

Da ich kein guter Entwickler bin setz ich lieber auf konfigurieren und halt kleine Teile erweitern als alles selbst zu schreiben.

Da kannst dann den "Kern" von der Stange nehmen und musst dich "nur" um den Part für die Interpretation der Binär Meldung kümmern.

Firmware Update und MQ ist da schon gelöst

Das System hat jetzt aber nicht zig Nodes die irgendwie "generisch" sein könnten. Ich hab meine Elektronik, also ein selbst designtes SoC und sonst nur noch arkanes Modellbauzeug. Dazwischen is sonst eigentlich nix mehr.

Auch wenn ich das natürlich begrüßen würde, aber ich wüsst grad nicht wo mir da was Arbeit abnehmen könnte. :D
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz