<div dir="ltr"><div><div><div>Hallo *,<br><br>ich komme langsam voran.<br><br></div>@Nils: Du kannst nochmal testen, Performance sollte jetzt passen.<br></div>@Gernot: die Werte in der Aggreation sind noch falsch. Ich kümmere mich drum wenn die prinzipiell Funktionalität+Performance bestätigt sind.<br>
<br>vg<br></div>Andreas<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-27 22:48 GMT+02:00 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"><div dir="ltr">Hallo *,<br><div class="gmail_extra"><br></div><div class="gmail_extra">das Problem der Resolution für SensorInterpreter ist ja jetzt gelöst.<br>
<br></div><div class="gmail_extra"><div class="gmail_quote">2014-06-24 22:45 GMT+02:00 Nils op den Winkel <span dir="ltr"><<a href="mailto:nils@kusemuckl.de" target="_blank">nils@kusemuckl.de</a>></span>:<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Hallo Andreas!</p>
<p dir="ltr">Vielen dank für deine schnelle Reaktion. Ich habe das heute mal getestet. Nachdem ich in der EntityDefinition.json resolution als optionalen Parameter für den Voltage Sensor eingetragen hatte, hat die Skalierung für mich wunderbar funktioniert. Genau so hatte ich mir das vorgestellt. <br>



ABER: ich kann mir jetzt maximal einen Tag ansehen. Wenn ich mir im Frontend z.B. eine Woche ansehen will kommt es nicht mehr zurück. Mysqld hängt auf 100% CPU und nach 30 Minuten habe ich abgebrochen. <br></p></blockquote>

</div><div>Das Performanceproblem welches durch korrekte Berechnung der Durchschnittswerte eingeführt wurde erscheint allerdings unlösbar (schluck), siehe <a href="http://stackoverflow.com/questions/24457442/how-to-find-previous-record-n-per-group-maxtimestamp-timestamp/24459821#24459821" target="_blank">http://stackoverflow.com/questions/24457442/how-to-find-previous-record-n-per-group-maxtimestamp-timestamp/24459821#24459821</a><br>

</div><div>Es findet sich kein SQL Query das auf kleinen Plattformen ausreichend schnell laufen kann.<br><br></div><div>Dafür sehe ich nur zwei echte Alternativen:<br><br></div><div>1) es is wie's ist und wir leben mit falschen Werten bei tuples=xy oder group=xy (u.a. Problem von Thomas mit zvmon)<br>

</div><div>2) wir erweitern für Sensoren das Datenbankschema für `data` um eine Spalte `period` in der wir- beim Schreiben der Datensätze- den Abstand zum letzten Datensatz reinschreiben. Damit wird der Ermittlungsaufwand von der Auswertung zur Datenerfassung verschoben. Einmalig müsste man dann ein Update fahren, prinzipiell liesse sich die Spalte aber auch jederzeit wieder entsorgen wenn es clevere Optimierungen der Datenbank gäbe.<br>

</div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">
Das scheint an der zweiten Änderung in dem Branche zu liegen (der geänderte select). Ganz habe ich es aber noch nicht durchschaut. <br>
Mit dem aktuellen git master Branche sind die Antwortzeiten auf jeden Fall akzeptabel. Selbst in der Monatsansicht. </p>
<p dir="ltr">Schönen Gruß</p><span><font color="#888888">
<p dir="ltr">Nils</p>
</font></span></blockquote></div></div>Was meint ihr?<br><br></div><div class="gmail_extra">vg<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">
Andreas<br></div></font></span></div>
</blockquote></div><br></div>