[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