<div dir="ltr">Hallo Daniel,<br><div class="gmail_extra"><br><div class="gmail_quote">Am 16. Mai 2017 um 13:25 schrieb Daniel Lauckner <span dir="ltr"><<a href="mailto:vz@jahp.de" target="_blank">vz@jahp.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-"><br>
> Zu überlegen<br>
> wäre ob from..to- falls nicht angegeben- einen Standardwert je<br>
> Periode bekommen sollte (also z.B. immer _aktueller_ Tag oder letzte 24h).<br>
<br>
</span>Nach meinem Verständnis ist die Preisfrage:<br>
- Aktuelle Periode (Tag ab 00:00, Monat ab 01., Jahr ab 01.01.) oder<br>
- vollständige Periode (24h, 30/31 Tage, 365 Tage)?<br>
Aktuelle Periode scheint mir Zweckdienlicher zu sein.<br></blockquote><div><br></div><div>ja, bei aktiver Gruppierung sollte der Default-Zeitraum mit ganzer Periode beginnen, "angefressene" sollten nur am Ende vorkommen. So läuft das schon bei next im Barchart-Mode (dort kümmert sich allerdings das Frontend um Rundung auf ganze Perioden). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Möchten wir Abfragen der Art /data/month&tuples=12 ermöglichen?<br>
In dem Fall könnte ich mir als Antwort den aktuellen + die letzen 11<br>
vollständigen Monate vorstellen.<br>
Oder besser ein neuer Bezeichner für sowas?<br></blockquote><div><br></div><div>Das wäre für händische Abfragen sicher sehr intuitiv, aber ich denke es sollte nicht tuples heißen, weil tuples ja gerade nicht auf from...to wirkt, sondern innerhalb eines gegebenen Intervalls. Lieber periods oder count oder sonst was.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-">> /consumption/<hour|day|month>: analog /data/<periode>, es werden<br>
> aber Verbrauchswerte ausgegeben.<br>
<br>
</span>Cool.<br>
<span class="gmail-"><br>
> /consumption: in dem Fall wird der Gesamtverbrauch der Periode<br>
> ausgegeben. Die MW bestimmt selber welcher Aggregationsmodus<br>
> verwendet wird (zu überlegen da Anfang/Ende der Daten nicht<br>
> aggregiert sind).<br>
<br>
</span>Verstehe ich es richtig das dabei das Problem besteht, wenn z.B.<br>
die letzen 48h abgefragt werden, die day-Aggregation nur für einen Tag<br>
nützt, die übrigen 24h müssen aus minute-Aggregation und data ermittelt<br>
werden?<br>
<span class="gmail-"><br>
>  Falls from..to nicht angegeben sind wird das<br>
> Ergebnis um initialconsumption erhöht (heute macht- sehr unsexy- das Frontend das).<br>
<br>
</span>Also consumption über den gesamten Datenbestand? Sprich: Aktueller<br>
Gesamtzählerstand als Standardperiode?<br>
<br>
Das klingt erstmal vernünftig, hat aber den Beigeschmack einer<br>
Inkonsistenz zur Standardperiode (24h ago) von /data.<br></blockquote><div><br></div><div>Das ist tatsächlich irgendwie inkonsistent. Verbrauch über den ganzen Datenbestand könnte man ja auch mit from=0 abfragen?</div><div><br></div><div>Grüße</div><div>Frank</div></div></div></div>