[vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Andreas Goetz]

Hi Sven,hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen
Sensortyp handelt es sich?

vg
Andreas

2013/9/17 Sven peitz <sven.peitz at gmx.net>

>  Am 16.09.2013 20:45, schrieb Andreas Goetz:
>
> 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
>
>   Hallo,
> vielen Dank für eure Antworten,.
> seit eben ist mein sql Zugang beim Provider wieder frei und ich kann
> weiter testen.
>
> Ein from=now bringt bei mit folgendes:
>
> {"version":"0.2","data":{"uuid":"**snip**","average":0,"consumption":0,"rows":0}}
>
>
>
> Ein select value from data where channel_id=14 order by timestamp desc
> limit 1;
>
> ist wirklich schnell und bring den aktuellen Wert zu Tage.
> Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
> Ein from=3seconds%20ago funktioniert auch und ist schnell.
> Mal sehen was geschickter Weise zu verwenden ist.
>
> Viele Grüße
> Sven
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20130917/bcc40852/attachment.html>