[vz-dev] Neue Apidefinition?

[Frank Richter]

Hallo Andreas,

dein Vorschlag sieht für mich recht stimmig aus. Ein paar
Verständnisfragen/Bemerkungen habe ich inline eingefügt.

Willst du die bisherige Struktur aus Kompatibilitätsgründen parallel
erhalten oder nicht? Im wesentlichen geht es wohl um den Parameter group,
denn /consumption ist sowieso neu und options=consumption, wie es next
derzeit benutzt, ist bisher nirgends dokumentiert.

Am 16. Mai 2017 um 08:37 schrieb Andreas Goetz <cpuidle at gmail.com>:

> Hallo Zusammen,
>
> nach diversen Diskussionen mit Frank habe ich mal überlegt wie wir das API
> etwas übersichtlicher und v.a. entlang der Erwartungen der Anwender
> strukturieren könnten. Das erscheint mir insbesondere deshalb sinnvoll weil
> es mit dem next Branch die Möglichkeit gibt auch Verbrauchswerte
> abzufragen, z.B. je Periode. All dies ist heute in den /data Kontext
> gequetscht und recht verwirrend.
>
> Hier mein Vorschlag für eine neue Struktur:
>
> /data: einfach nur Daten, keine Verwendung Aggregation, maximaler
> Detailgrad. options=raw ist erlaubt.
>

wäre tuples dann auch nur noch hier erlaubt? In allen anderen Fällen passt
es eigentlich nicht.


> /data/<hour|day|month>: Durchschnittswerte je Periode. options=raw ist bei
> dieser Abfrage wie künftig sonst auch verboten. Zu überlegen wäre ob
> from..to- falls nicht angegeben- einen Standardwert je Periode bekommen
> sollte (also z.B. immer _aktueller_ Tag oder letzte 24h).
>

Standardwert abhängig von Periode find ich gut. Gruppierung nach Monaten
oder Jahren macht ja wenig Sinn wenn man nur die letzten 24h (wie zur Zeit
ohne from...to) abfragt.

Diese Abfrage würde auch weiter vom FE genutzt um Aggregation für große
> Zeitperioden zu aktivieren.
>
> /consumption/<hour|day|month>: analog /data/<periode>, es werden aber
> Verbrauchswerte ausgegeben. Geht natürlich nur bei entsprechenden Kanälen.
> from…to schränkt die Auswahl ein. Zu überlegen ist ob eine Periodengrenze
> zu erzwingen wäre (eher nicht).
>

Grenze würde ich auch flexibel lassen.


> /consumption: in dem Fall wird der Gesamtverbrauch der Periode ausgegeben.


Also keine Tupel, sondern wirklich nur der Verbrauch als Antwort?


> Die MW bestimmt selber welcher Aggregationsmodus verwendet wird (zu
> überlegen da Anfang/Ende der Daten nicht aggregiert sind). Falls from..to
> nicht angegeben sind wird das Ergebnis um initialconsumption erhöht (heute
> macht- sehr unsexy- das Frontend das).
>

auch mit gesetztem to (aber ohne from) sollte IMHO initialconsumption
addiert werden. Das würde die Möglichkeit schaffen Zählerstände in der
Vergangenheit abzufragen.


> Diese Variante könnte ggf. auch entfallen, dann müsste allerdings der
> Anwender überlegen in welcher Art/ Gruppierung er Gesamtwerte erheben will-
> eher unsexy.
>

Ich finde die Idee schick, der MW die Wahl der effizientesten Gruppierung
zu überlassen.


> Schön wäre auch die Timestampbildung für from..to gleich mit zu
> überarbeiten da im Moment durch die enge Koppelung zum FE zuviele Werte
> erzeugt werden die eigentlich nicht zur Abfrage passen und eher verwirren.
>

Auch dafür +1, insbesondere der bei einer data-Abfrage mitgelieferte
consumption-Wert sollte möglichst genau zum Abfragezeitraum passen. Müssen
wir uns nur noch einigen, welche Werte dazugehören und welche nicht ;-)

Vmtl. habe ich dabei einige Anwendungs- und Randfälle übersehen. Was haltet
> ihr davon?
>
> Viele Grüße, Andreas
>

Viele Grüße
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20170516/696d3f56/attachment.html>