[vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Andreas Goetz
cpuidle at gmx.de
Mon Sep 16 20:45:38 CEST 2013
Hallo Rainer,
2013/9/16 Rainer Gauweiler <volkszaehler at moppl.inka.de>
> Hallo zusammen,
>
> Am 16.09.2013 16:41, schrieb Andreas Goetz:
>
>> Hallo Thorben,
>>
>> 2013/9/16 Thorben Thuermer <r00t at constancy.org <mailto:r00t at constancy.org
>> >>
>>
>>
>> On Mon, 16 Sep 2013 14:01:31 +0200
>> Jakob Hirsch <jh at plonk.de <mailto:jh at plonk.de>> wrote:
>> > Sven peitz, 2013-09-14 11:07:
>> > > $result1=mysql_query("SELECT value FROM data WHERE id = (select
>> max(id)
>> > > FROM data WHERE channel_id LIKE '14')");...
>> > Allerdings sollte man nicht ohne Grund direkt auf der DB
>> arbeiten. Das
>> > Vorgehen wie von Andreas Götz ist auch deutlich einfacher
>> (Abfrage mit
>> > from=now).
>>
>> from=now...
>> funktioniert doch aber wie gehabt nur bei erfassung absoluter staende.
>> ansonsten war die methode doch "from=<x> seconds ago"...?
>> also so, dass im im angegebenen zeitraum (mit now = nur aktuelle
>> sekunde)
>> genug werte erfasst sind, damit der interpreter in der middleware
>> daraus etwas berechnen kann.
>> also bei s0-zaehlern mindestens zwei impulse, etc...
>> oder wurde da middleware-seitig was geandert?
>>
>> - Thorben
>>
>>
>> Das sollte funktionieren da die MW (schon immer?) mittels zweier
>> SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
>> angefragten Zeitraumes ermitteln und from... to... entsprechend
>> erweitern. Für now() gäbe es also immer den aktuellen und letzten
>> Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu
>> berechnen.
>>
>
> Tut bei mir nicht und tat es noch nie:
> {"version":"0.2","data":{"**uuid":"*snip*","average":0,"**
> consumption":0,"rows":0}}
>
> Wir hatten da auch auf dem Raspi Probleme und haben damals den Zeitraum
> erweitert, damit sicher Daten da waren.
>
> Aber gab es nicht auch "kürzlich" einen Patch der das Verhalten gebaut
> hat? Meine Installation hier ist ca ein Jahr alt.
>
Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der
Code noch nicht im Repository angekommen, sondern steht noch in meinem Pull
Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch mal 3
Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request sind es
immer genau zwei Tupel die benötigt werden, damit klappt dann auch die
Abfrage per "now". "now - x seconds" ist keine allgemeingültige Lösung da
man ja nicht wissen kann wann ein Sensor Daten liefert...
vg
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20130916/d485ded7/attachment-0001.html>
More information about the volkszaehler-dev
mailing list