<div dir="ltr">Hallo Andreas,<div><br></div><div>dein Vorschlag sieht für mich recht stimmig aus. Ein paar Verständnisfragen/Bemerkungen habe ich inline eingefügt.</div><div><br></div><div>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.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">Am 16. Mai 2017 um 08:37 schrieb Andreas Goetz <span dir="ltr"><<a href="mailto:cpuidle@gmail.com" target="_blank">cpuidle@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo Zusammen,<br>
<br>
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.<br>
<br>
Hier mein Vorschlag für eine neue Struktur:<br>
<br>
/data: einfach nur Daten, keine Verwendung Aggregation, maximaler Detailgrad. options=raw ist erlaubt.<br></blockquote><div><br></div><div>wäre tuples dann auch nur noch hier erlaubt? In allen anderen Fällen passt es eigentlich nicht.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">/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).<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Diese Abfrage würde auch weiter vom FE genutzt um Aggregation für große Zeitperioden zu aktivieren.<br>
<br>
/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).<br></blockquote><div><br></div><div>Grenze würde ich auch flexibel lassen.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/consumption: in dem Fall wird der Gesamtverbrauch der Periode ausgegeben.</blockquote><div><br></div><div>Also keine Tupel, sondern wirklich nur der Verbrauch als Antwort?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Diese Variante könnte ggf. auch entfallen, dann müsste allerdings der Anwender überlegen in welcher Art/ Gruppierung er Gesamtwerte erheben will- eher unsexy.<br></blockquote><div><br></div><div>Ich finde die Idee schick, der MW die Wahl der effizientesten Gruppierung zu überlassen.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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 ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Vmtl. habe ich dabei einige Anwendungs- und Randfälle übersehen. Was haltet ihr davon?<br>
<br>
Viele Grüße, Andreas<br></blockquote><div><br></div><div>Viele Grüße</div><div>Frank </div></div></div></div>