Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- development:api:start [2010/12/26 00:55] – Externe Bearbeitung 127.0.0.1
+++ development:api:start [2018/12/10 15:15] (aktuell) – Beispiel hinzugefügt zugschlus
@@ Zeile 7: / Zeile 7: @@
 Alternativ zum Browser sind aber auch andere Frontends angedacht: eine direkte Anzeige des aktuellen Verbrauchswertes z.B. via [[http://www.chumby.com/|Chumby]].
-==== Backend ====
+==== Middleware ====
-Hierbei handelt es sich im Wesentlichen um einen Wrapper um die Datenbank. Sämtliche Kommunikation in Richtung Datenbank wird über das Backend abgewickelt.
+Hierbei handelt es sich im Wesentlichen um einen Wrapper um die Datenbank. Sämtliche Kommunikation in Richtung Datenbank wird über die Middleware abgewickelt.
@@ Zeile 14: / Zeile 14: @@
 ==== Frontend-API ====
-Diese definiert die Kommunikation zwischen dem Frontend und dem Backend.
+Diese definiert die Kommunikation zwischen dem Frontend und der Middleware.
-==== Backend-API ====
+==== Middleware-API ====
-Das ist jetzt leicht: die Backend-API beschreibt die Kommunikation zwischen dem Messgerät (AVR Net-IO, Flukso, ...) und dem Backend.
+Das ist jetzt leicht: die Middleware-API beschreibt die Kommunikation zwischen dem Messgerät (AVR Net-IO, Flukso, ...) und der Middleware.
+[[development/api/reference|Hier geht's zur Referenz]]
-**[[reference]]**
 ===== Aufgaben der API =====
-  * die komplette Kommunikation mit dem Backend übernehmen (Logging, Auswertung & Verwaltung)
+  * die komplette Kommunikation mit der Middleware übernehmen (Logging, Auswertung & Verwaltung)
-  * die Möglichkeit bieten Daten in Paketen an den Backend-Server schicken, um die Netzwerkverbindung zu entlasten und dadurch Strom zu sparen oder Verbindungsprobleme zum Backend-Server abfangen können
+  * die Möglichkeit bieten Daten in Paketen an den Middleware-Server schicken, um die Netzwerkverbindung zu entlasten und dadurch Strom zu sparen oder Verbindungsprobleme zum Middleware-Server abfangen können
   * nicht nur Pulse übertragen können, sondern auch Messwerte anderer Sensoren (Temperatur, Wind, Luftdruck etc.).
   * eine eindeutige Versionierung beinhalten
@@ Zeile 33: / Zeile 32: @@
 ===== Umsetzung =====
-Die gesamte Kommunikation mit dem Backend wird ausnahmslos über HTTP-Anfragen abgewickelt.
+Die gesamte Kommunikation mit der Middleware wird ausnahmslos über HTTP-Anfragen abgewickelt.
 Beim Entwurf der API wurde auf folgende Punkte geachtet:
@@ Zeile 53: / Zeile 52: @@
   * performante Verarbeitung der Daten mit Javascript
-===== Zukunftsmusik =====
+===== Beispiel =====
+** (nachträgliches) Auslesen von Zählerständen zum 01. des laufenden Monats **
+(alles auf eine Zeile schreiben)
+  http://IP/middleware.php/data.csv?
+    uuid[]=...&
+    uuid[]=...&
+    group=month&
+    options=raw&
+    to=first%20day%20of%20this%20month%20midnight
+Man kann beliebig viele `uuid[]=...` (also auch nur einen einzigen) Abschnitte angeben und erhält ein CSV zurück, in dem die Zählerstände zum 01. des Monats Mitternacht enthalten sind.
-  * Direktzugriff auf den Controller für Echtzeitdarstellung & Steuerung des Controllers (Ethersex besitzt bereits einen HTTPD, Flukso auch)
-    * Matthias von mysmartgrid hat das bereits für den Flukso Controller implementiert
-  * Erkennung und Übertragung der Sensortypen, Auflösungen etc..
-  * Google Power Meter like Workflow zum installieren neuer Zähler