[vz-dev] Virtuelle Kanäle und Ad-hoc Auswertungen

[Andreas Goetz]

Hallo Zusammen,

zu den bisher implementierten "virtuellen", also berechneten, Kanälen habe
ich als neues Feature noch ad-hoc Auswertungen hinzugefügt. Funktionieren
genau wie Kanäle, allerdings ohne dass dieser erst angelegt werden muss.

Damit Ihr Euch ein besseres Bild machen könnt steht unter

https://github.com/andig/volkszaehler.org/blob/dev/VIRTUAL.md

eine Doku und die komplette Implementierung gibts im git:

https://github.com/andig/volkszaehler.org/tree/dev

Bei Fehlermeldungen muss ggf. der VZ Cache einmal geleert werden- dazu
bitte einmal devmode=1 im Config file oder der Middleware URL setzen.

Freue mich über Feedback!

vg
Andreas

Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?

[Andreas Goetz]

Hallo Heiko,

jetzt fällt mir nur noch ein Caching Problem mit Doctrine ein.

On Mon, Jan 13, 2014 at 8:18 PM, Heiko Baumann  wrote:

>  Hi Andi
>
>
>
> Ja- Commit 8ac2c5039273b590aec2a9890f87400c08b949a8 liegt dazwischen.
>
>
> Ich kann's nicht mehr nachvollziehen:
>
> SELECT e0_.id AS id0, e0_.uuid AS uuid1, e0_.type AS type2, p1_.id AS id3,
> p1_.pkey AS pkey4, p1_.value AS value5, e0_.class AS class6, p1_.entity_id
> AS entity_id7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id =
> p1_.entity_id WHERE (e0_.uuid = ?) AND e0_.class IN ('channel',
> 'aggregator') ORDER BY p1_.pkey ASC
> START TRANSACTION
> INSERT INTO data (timestamp, value, channel_id) VALUES (?, ?, ?)
> COMMIT
>
>  Bist Du sicher dass der Code den Du siehst auch wirklich der ist der
> ausgeführt wird?
>
>  Ich bin sicher, dass das aktueller Code ist, ja. Zur Sicherheit habe ich
> gerade eben nochmal kurz mitgeloggt:
> ...
> 118185 QueryUPDATE properties SET value = '1' WHERE id
> = 2
>
> Insofern würde ich schon sagen, dass die updates immer noch heftig
> einprasseln...
>

Sieht so aus. Jetzt kannst Du entweder mal auf meinen Dev-Zweig umsteigen,
oder Du baust Router.php wie unten um:

public static function createEntityManager($admin = FALSE) {
$config = new \Doctrine\ORM\Configuration;

if (extension_loaded('apc')) {
$cache = new \Doctrine\Common\Cache\ApcCache;

if (Util\Configuration::read('devmode') == FALSE) {
$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);
}
else {
$cache->deleteAll();
}
}

$driverImpl = $config->newDefaultAnnotationDriver(VZ_DIR .
'/lib/Volkszaehler/Model');
$config->setMetadataDriverImpl($driverImpl);

$config->setProxyDir(VZ_DIR . '/lib/Volkszaehler/Model/Proxy');
$config->setProxyNamespace('Volkszaehler\Model\Proxy');

$config->setAutoGenerateProxyClasses(Util\Configuration::read('devmode'));

$dbConfig = Util\Configuration::read('db');
if ($admin && isset($dbConfig['admin'])) {
$dbConfig = array_merge($dbConfig, $dbConfig['admin']);
}

return \Doctrine\ORM\EntityManager::create($dbConfig, $config);
}

Danach bitte die MW einmal im Browser mit ...&devmode=1 aufrufen oder im
Configfile mal devmode=true setzen.

Damit wird Doctrine gezwungen mal alle Daten aus den Caches zu leeren
(insbesondere auch zur Konfiguration der Entities).

@Entwickler: gibts eine Idee wir wir das bei Versionswechseln einmalig
erzwingen könnten? Wie wäre es mit sowas wie einer internen Versionsnummer
die wir ebenfalls in den Cache schreiben und mit der aktuellen
Versionsnummer (z.B. aus bootstrap.php) vergleichen und bei Bedarf den
Cache automatisch leeren?

vg
Andreas

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hallo Volker,

zum Darstellungsproblem beim Tagesverlauf pass bitte probehalber die wui.js
mal an. Dazu in vz.wui.drawPlot die Zeilen wiefolgt ändern:

/*
// mangle data for "steps" curves
if (tuples && tuples.length > 0 && tuples.last) {
tuples.push([entity.data.to, tuples.last()[1], 1]);
tuples.push([entity.data.to, null, 1]);
}
*/
// mangle data for "steps" curves by shifting one ts left
("step-before")
if (tuples && tuples.length > 0 && entity.style == "steps") {
tuples.unshift([entity.data.from, 1, 1]);
for (var i=0; i

> Hallo Volker,
>
> über die Wochenansicht muss ich nochmal nachdenken, bei der Tagesansicht
> ist alles- bis auf Verschiebung um einen TS- ok.
>
> 2014/1/12 Volker 
>
>> ...
>>
>> commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a
>>> Merge: feb7ca2 ff2ced5
>>> Author: Justin Otherguy >> >
>>>
>>> Date:   Sun Jan 12 03:26:35 2014 -0800
>>>
>>>  Merge pull request #87 from andig/master-timestampfix
>>>
>>>  Make all interpreters use timestamp at end of period
>>>
>>> Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die
>>> Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt;
>>> aber
>>> halt anders. gleiches Bild, der 0-Wert wird nur später erreicht.
>>> Schau Dir für eine Erklärung gerne mal den PR an.
>>>
>>
>> Ich stecke jetzt in den Details nur wenig drin, ich finde nur das die
>> grafische Darstellung falsch ist. Um bei dem Beispiel des Tageswertes zu
>> bleiben: Um ca. 20:15 wird ein Eintrag mit n S0-Impulsen in die Datenbank
>> geschrieben. Der Verbrauch geht danach auf nahezu 0. Um ca. 21:15 wird
>> vermutlich ein einziger S0-Impus in die Datenbank geschrieben. Dann
>> berechnet sich doch der Momentanverbrauch zwischen 20:15 und 21:15 aus der
>> Zeitspanne (hier 1 Stunde) und dem in der Zeit aufgelaufenen Impulsen (hier
>> 1). Die grafisch Darstellung und auch der Cursor zeigt in dem Zeitfenster
>> aber irgendwas von 570W - und das ist schlichweg falsch.
>>
>
>
>
> Dazu gehören folgende Timestamps (CSV Export und DB-Werte), Uhrzeit habe
> ich mit ausgerechnet:
>
>1388775808000 591
> 20:03:28
> DB  1388775872000 618,75
> 20:04:32 22  1388775936000 591
> 20:05:36 21  138877600 253
> 20:06:40 9  1388780096000 0,439
> 21:14:56 1  1388780288000 9
> 21:18:08 1  1388781888000 20,25
> 21:44:48 18
> Bis 20:04 feuert S0 ordentlcih, Leistung > 500.
> bis 20:06 gehen die Impulse deutlich zurück Leistung 253 (der Abfall)
> Erst 21:14 kommt wieder was- Leistung annähernd 0.
>
> Was jetzt tatsächlich unschön ist ist, dass die "Steps" einen Timestamp
> verschoben scheinen, also "step-after" statt "step-before". Der Effekt
> tritt auf da die MW-Timestamps jetzt korrekt sind, eigentlich ist die
> Grafik falsch.
>
> Ich muss mal schauen ob sich das sinnvoll ändern lässt, zur Not muss der
> commit wieder raus.
>
> vg
> Andreas
>
>

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hallo Volker,

über die Wochenansicht muss ich nochmal nachdenken, bei der Tagesansicht
ist alles- bis auf Verschiebung um einen TS- ok.

2014/1/12 Volker 

> ...
>
>> commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a
>> Merge: feb7ca2 ff2ced5
>> Author: Justin Otherguy > >
>>
>> Date:   Sun Jan 12 03:26:35 2014 -0800
>>
>>  Merge pull request #87 from andig/master-timestampfix
>>
>>  Make all interpreters use timestamp at end of period
>>
>> Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die
>> Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt;
>> aber
>> halt anders. gleiches Bild, der 0-Wert wird nur später erreicht.
>> Schau Dir für eine Erklärung gerne mal den PR an.
>>
>
> Ich stecke jetzt in den Details nur wenig drin, ich finde nur das die
> grafische Darstellung falsch ist. Um bei dem Beispiel des Tageswertes zu
> bleiben: Um ca. 20:15 wird ein Eintrag mit n S0-Impulsen in die Datenbank
> geschrieben. Der Verbrauch geht danach auf nahezu 0. Um ca. 21:15 wird
> vermutlich ein einziger S0-Impus in die Datenbank geschrieben. Dann
> berechnet sich doch der Momentanverbrauch zwischen 20:15 und 21:15 aus der
> Zeitspanne (hier 1 Stunde) und dem in der Zeit aufgelaufenen Impulsen (hier
> 1). Die grafisch Darstellung und auch der Cursor zeigt in dem Zeitfenster
> aber irgendwas von 570W - und das ist schlichweg falsch.




Dazu gehören folgende Timestamps (CSV Export und DB-Werte), Uhrzeit habe
ich mit ausgerechnet:

   1388775808000 591
20:03:28
DB  1388775872000 618,75
20:04:32 22  1388775936000 591
20:05:36 21  138877600 253
20:06:40 9  1388780096000 0,439
21:14:56 1  1388780288000 9
21:18:08 1  1388781888000 20,25
21:44:48 18
Bis 20:04 feuert S0 ordentlcih, Leistung > 500.
bis 20:06 gehen die Impulse deutlich zurück Leistung 253 (der Abfall)
Erst 21:14 kommt wieder was- Leistung annähernd 0.

Was jetzt tatsächlich unschön ist ist, dass die "Steps" einen Timestamp
verschoben scheinen, also "step-after" statt "step-before". Der Effekt
tritt auf da die MW-Timestamps jetzt korrekt sind, eigentlich ist die
Grafik falsch.

Ich muss mal schauen ob sich das sinnvoll ändern lässt, zur Not muss der
commit wieder raus.

vg
Andreas

Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?

[Andreas Goetz]

Hallo Heiko,

2014/1/12 Heiko Baumann 

>  Hm. Ich hab vorhin mit git pull meinen vz geupdatet:
>
> pi@BauratPi /var/www/volkszaehler.org $ sudo git pull
> remote: Counting objects: 73, done.
> remote: Compressing objects: 100% (70/70), done.
> remote: Total 73 (delta 29), reused 34 (delta 3)
> Unpacking objects: 100% (73/73), done.
> From git://github.com/volkszaehler/volkszaehler.org
>ec0c82d..ba113f6  master -> origin/master
> Updating ec0c82d..ba113f6
> Fast-forward
>  .../Interpreter/CounterInterpreter.php |   27 ++
>  lib/Volkszaehler/Interpreter/MeterInterpreter.php  |3 +-
>  .../Interpreter/SQL/MySQLAggregateOptimizer.php|   90
> +++-
>  lib/Volkszaehler/Interpreter/SQL/SQLOptimizer.php  |3 +-
>  lib/Volkszaehler/Interpreter/SensorInterpreter.php |3 +-
>  lib/Volkszaehler/Model/Property.php|   13 ++-
>  lib/Volkszaehler/View/CSV.php  |   52 +++
>  lib/Volkszaehler/View/JSON.php |   32 ++-
>  lib/Volkszaehler/View/JpGraph.php  |8 +-
>  lib/Volkszaehler/View/XML.php  |   80
> ++---
>  misc/tools/vzclient|   16 ++--
>  test/Tests/DataCounterTest.php |2 +-
>  test/Tests/DataMeterTest.php   |2 +-
>  13 files changed, 135 insertions(+), 196 deletions(-)
>
>  - damit sollten doch alle updates drin sein, oder?
>

Ja- Commit 8ac2c5039273b590aec2a9890f87400c08b949a8 liegt dazwischen.


>
> Im mysql-log gehts aber nach wie vor extrem wüst zu:
> 17345 Connect   vz@localhost on volkszaehler
> 17345 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
> e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
> e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
> JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
> 'ae9d1b00-f2f5-11e2-8a1f-0dad1c039958') AND e0_.class IN ('channel',
> 'aggregator') ORDER BY p1_.pkey ASC
> 140112 22:33:47 17345 Query START TRANSACTION
> 17345 Query INSERT INTO data (timestamp, value,
> channel_id) VALUES ('1389562426842', '1', 16)
> 17345 Query UPDATE properties SET value = '1' WHERE id
> = 83
> 17345 Query UPDATE properties SET value = '1' WHERE id
> = 81
> 17345 Query UPDATE properties SET value = '360'
> WHERE id = 79
> 17345 Query commit
> 17345 Quit
>
> Insofern also alles beim alten. Wie krieg ich die neueste Version?
>

Ich kann's nicht mehr nachvollziehen:

SELECT e0_.id AS id0, e0_.uuid AS uuid1, e0_.type AS type2, p1_.id AS id3,
p1_.pkey AS pkey4, p1_.value AS value5, e0_.class AS class6, p1_.entity_id
AS entity_id7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id =
p1_.entity_id WHERE (e0_.uuid = ?) AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
START TRANSACTION
INSERT INTO data (timestamp, value, channel_id) VALUES (?, ?, ?)
COMMIT

Bist Du sicher dass der Code den Du siehst auch wirklich der ist der
ausgeführt wird?

vg
Andreas

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Also...

2014/1/12 Andreas Goetz 

> Hi Volker,
>
> 2014/1/12 Volker 
>
>> Hi Andreas,
>>
>> Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87
>> drin sein.
>>
>
> Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war?
> Git git reset kannst Du auf einen bestimmten Commit zurückgehen.
>
>
>> Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher
>> aus ist, bzw. auf 1W abgesunken ist.
>
>
> Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den
> letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann
> ja nicht wissen ob/ dass "keine Daten" = 0, oder nach welcher zeti dies
> gelten soll...
>
> Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik
>> von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich
>> nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein
>> Verbrauch im 1..4W Bereich besteht.
>>
>
Das Verhalten für 20:30 lässt sich erklären:

commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a
Merge: feb7ca2 ff2ced5
Author: Justin Otherguy 
Date:   Sun Jan 12 03:26:35 2014 -0800

Merge pull request #87 from andig/master-timestampfix

Make all interpreters use timestamp at end of period

Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die
Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt;
aber halt anders. gleiches Bild, der 0-Wert wird nur später erreicht.
Schau Dir für eine Erklärung gerne mal den PR an.


> Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist
>> es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell
>> Wert bei abgeschaltetem Verbraucher s.u.).
>>
>
Für die Wochendarstellung ok/aktuell ist die Ursache eine andere. Hier
liegts daran, dass auf aggregierte Werte mit geringerer zeitlicher
Auflösung (groupy=hour) zurückgegriffen wird.

Wenn Dir das nicht gefällt kannst Du mal in der options.js mit der Variable
speedupFactor rumspielen. Kleinere Werte bringen bessere Auflösung, sind
aber auch langsamer wenn das FE dann kein groupby mehr auswählt...

Erklärung nachvollziehbar und Problem gelöst?

vg
Andreas

...

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hi,


2014/1/12 Volker 

> Hi Andreas,
>
> das mit der Statistik war schon immer so. Die S0 Impulse schreibt ein
> AVR-Netio ein mal pro Minute in die Datenbank, aber ich vermute eben nicht,
> wenn gar kein Impuls kam. 0-Werte werden in der Datenbank so nicht
> auftauchen. Da muss ich mir das Teil mal ansehen, ob ich dem beibringen
> kann die Updates auch zu machen, wenn gar kein Impuls kam...
>
> > Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den
> > letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ
> kann ja
> > nicht wissen ob/ dass "keine Daten" = 0, oder nach welcher zeti dies
> gelten soll...
>
> Ja ok wenn aber zwischen dem vorletzten Datenbankeintrag und dem letzten
> einige Minuten oder Stunden Zeit vergangen ist, muss der Verbrauchswert
> _dazwischen_ aber auch sehr klein oder fast 0 sein.


korrekt. Nicht 0 aber nahe dran.


> Bei der aktuellen middleware wird der vorletzte und letzte
> Datenbankeintrag einfach mit einer Geraden auf der Höhe des letzten
> Verbrauchswerts verbunden.


Das klingt falsch. Darstellung "steps"? Mal schauen ob "lines" einen
Unterschied macht.

Und das stimmt so nicht. Der Verbrauchswert in der Statistik stimmt jedoch.
>
> Ich kann Dir eine SQL-Dump der letzen 3 Jahre zukommen lassen, das sind
> aber gezippt 18MB. Ich habe Dir den Link als PM geschickt.
>
> Angekommen, danke!


> Das mit dem git reset habe ich versucht, die Darstellung ändert sich
> irgendwie nicht. Ist das richtig "git reset 
> feb7ca2b5fe3aa3023e7e640a6aaf4fd207ad95f"
> um den letzten merge rückgängig zu machen?
>

Du musst die Nummer des Commits eingeben auf den Du kommen willst- also den
davor. Im master Zweig ist der letzte vom 3. Januar (siehe git log):

commit 7431faf4c6ebe7b18349919a02ed90a9fca3fac3
Author: andig 
Date:   Wed Jan 1 18:52:20 2014 +0100

Allow --eval to access arrays by index

Also git reset  7431faf4c6ebe7b18349919a02ed90a9fca3fac3 bzw. schrittweise
von neu nach alt an diesen Zeitpunkt herantasten. Es wäre wirklich
hilfreich wenn Du herausfinden könntest welcher Commit das Problem macht.

Egal auf welchen commit ich resette, die Darstellung ist immer falsch. Nur
> die Version die ich am 3.1. mit dem Install script installiert habe
> funktioniert... (und alles davor).
>

Dann müsste sich das mittels git reset ebenfalls hinbekommen lassen. Ist
leider der einzige Weg den Schuldigen zu finden...

vg
Andreas


> Gruß
> Volker
>
> Am 12.01.2014 14:10 schrieb Andreas Goetz:
>
>> Hi Volker,
>>
>> 2014/1/12 Volker mailto:v...@gmx.de>>
>>
>>
>> Hi Andreas,
>>
>> Die Version ist brandaktuell, git pull sagt up-to-date, da sollte
>> merge87
>> drin sein.
>>
>>
>> Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war?
>> Git git
>> reset kannst Du auf einen bestimmten Commit zurückgehen.
>>
>> Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der
>> Verbraucher aus
>> ist, bzw. auf 1W abgesunken ist.
>>
>>
>> Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den
>> letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann
>> ja
>> nicht wissen ob/ dass "keine Daten" = 0, oder nach welcher zeti dies
>> gelten soll...
>>
>> Ganz krass zu sehen in der Wochengrafik (aktuell) und im der
>> Tagesgrafik von
>> ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich
>> nahezu 0.
>> Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein
>> Verbrauch im
>> 1..4W Bereich besteht.
>> Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da
>> ist es
>> korrekt dargestellt. Die Statistiken sind aber ok (bis auf den
>> aktuell Wert
>> bei abgeschaltetem Verbraucher s.u.).
>>
>>
>> Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal
>> reinschauen...
>>
>> Schon immer falsch ist der aktuell Wert aus der Statistik nach
>> Abschalten
>> des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert
>> der
>> dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert
>> als
>> der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig
>> gewesen
>> wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller
>> Wert
>> eigentlich 0 stehen.
>>
>>
>> S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch
>> faken, für
>> alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min
>> eine 

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hi Volker,

2014/1/12 Volker 

> Hi Andreas,
>
> Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87
> drin sein.
>
>
Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war?
Git git reset kannst Du auf einen bestimmten Commit zurückgehen.


> Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher
> aus ist, bzw. auf 1W abgesunken ist.


Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den
letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann
ja nicht wissen ob/ dass "keine Daten" = 0, oder nach welcher zeti dies
gelten soll...

Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik
> von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich
> nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein
> Verbrauch im 1..4W Bereich besteht.
> Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist
> es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell
> Wert bei abgeschaltetem Verbraucher s.u.).
>

Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal
reinschauen...


> Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten
> des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der
> dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als
> der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen
> wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert
> eigentlich 0 stehen.
>

S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken,
für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min
eine 0 loggen könntest,  dann wäre die Sache eindeutig.

Gruß
> Volker
>

Was mich wundert ist dass nicht auch andere Anwender das Problem der
Nullwerte haben und schon immer hatten?

vg
Andreas


>
> Am 12.01.2014 13:19 schrieb Andreas Goetz:
>
>> Hallo Volker,
>>
>> kannst Du mal schauen ob dieser Commit hier
>> https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon
>> mit drin
>> inst? Kanns Du genauer beschreiben was "schon immer falsch" und jetzt
>> "schräg"
>> bedeutet? Was wäre das erwartete verhalten?
>>
>> vg
>> Andreas
>>
>>
>>
>> 2014/1/12 Volker mailto:v...@gmx.de>>
>>
>>
>> Hallo,
>>
>> ich habe gerade die aktuelle Version vom VZ geholt
>> (git://github.com/__volkszaehler/volkszaehler.org.__git
>> <http://github.com/volkszaehler/volkszaehler.org.git>).
>>
>> Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum
>> Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der
>> Version die ich am 3.1. installiert habe.
>> Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden
>> gar
>> keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist.
>> Der Wert
>> "aktuell" in der Statistik war eigentlich schon immer fehlerhaft ,
>> wenn
>> keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon
>> etwas
>> "schräg" ;)
>>
>> Gruß
>> Volker
>> --
>> Volker Troyke
>> Homepage: www.troyke.de <http://www.troyke.de>
>> E-Mail  : v...@gmx.de <mailto:v...@gmx.de>
>>
>>
>>
> --
> Volker Troyke
> Homepage: www.troyke.de
> E-Mail  : v...@gmx.de
>
>

Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version

[Andreas Goetz]

Hallo Volker,

kannst Du mal schauen ob dieser Commit hier
https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit
drin inst? Kanns Du genauer beschreiben was "schon immer falsch" und jetzt
"schräg" bedeutet? Was wäre das erwartete verhalten?

vg
Andreas



2014/1/12 Volker 

> Hallo,
>
> ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/
> volkszaehler/volkszaehler.org.git).
> Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum
> Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der
> Version die ich am 3.1. installiert habe.
> Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar
> keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert
> "aktuell" in der Statistik war eigentlich schon immer fehlerhaft , wenn
> keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon etwas
> "schräg" ;)
>
> Gruß
> Volker
> --
> Volker Troyke
> Homepage: www.troyke.de
> E-Mail  : v...@gmx.de
>

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Hi Heiko,

schau doch mal ob Du mit diesem PR hier
https://github.com/volkszaehler/volkszaehler.org/pull/95 die überflüssigen
SQLs für die properties Tabelle loswerden kannst.

Löst aber nicht die (wichtigeren...) Probleme mit s0vz.

vg
Andreas


2014/1/10 Andreas Goetz 

> Moin,
>
> 2014/1/9 Heiko Baumann 
>
>> Am 09.01.2014 21:26, schrieb Andreas Goetz:
>>
>>  Hallo Heiko,...
>>>
>> PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im
>>> Querystring ;)
>>>
>> Hm, wie kann ich das dem Server beim Starten mit übergeben?
>>
>
> Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
> der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
>
>
>> (/etc/init.d/mysql start &debug=1 oder wie? Nee funktioniert nicht. Aber
>> so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann  SET
>> GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
>>
>>  Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
>>> Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
>>> sowas in 1sec...
>>>
>>
>> Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
>> gestellt, dann nur einen sichtbar gemacht. Logging an, auf "Jahresansicht"
>> geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
>> das angehängte Log.
>>
>
> Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
> Browser, mit &debug=1. Dann schauen was/wo das wie lange dauert.
>
> Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
>> s0-Ereignissen erzeugt.
>>
>
> d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
> Minute?
>
>  Also doch alles ok?
>>
>
> Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
>
>
>>
>> Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im
>> log fällt mir auf, dass das sehr häufig vorkommt:
>>   911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
>> e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
>> e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
>> JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
>> '90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
>> 'aggregator') ORDER BY p1_.pkey ASC
>>   911 Query START TRANSACTION
>>   911 Query INSERT INTO data (timestamp, value,
>> channel_id) VALUES ('1389302896063', '1', 14)
>>   911 Query UPDATE properties SET value = '1' WHERE
>> id = 71
>>   911 Query UPDATE properties SET value = '1' WHERE
>> id = 69
>>   911 Query UPDATE properties SET value = '1000'
>> WHERE id = 67
>>   911 Query commit
>>
>> Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).
>>  Was mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
>> Liefert bei mir z.B.
>>
>> +-+--+---+--
>> ++-+-++
>> | id0 | uuid1| type2 | id3  | pkey4
>>  | value5  | class6  | entity_id7 |
>> +-+--+---+--
>> ++-+-++
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   71 | active
>> | 1   | channel | 14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   70 | color
>>  | navy| channel | 14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   69 | public
>> | 1   | channel | 14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   67 | resolution
>> | 1000| channel | 14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   72 | style
>>  | steps   | channel | 14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   68 | title
>>  | Strom-Ferienwohnung | channel | 14 |
>> +-+--+---+--
>> ++-+-++
>> 6 rows in set (0.00 sec)
>>
>> Muss das wirklich vor jedem Insert sein?
>> Und danach werden _immer

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Moin,

2014/1/9 Heiko Baumann 

> Am 09.01.2014 21:26, schrieb Andreas Goetz:
>
>  Hallo Heiko,...
>>
> PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im
>> Querystring ;)
>>
> Hm, wie kann ich das dem Server beim Starten mit übergeben?
>

Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!


> (/etc/init.d/mysql start &debug=1 oder wie? Nee funktioniert nicht. Aber
> so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann  SET
> GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
>
>  Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
>> Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
>> sowas in 1sec...
>>
>
> Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
> gestellt, dann nur einen sichtbar gemacht. Logging an, auf "Jahresansicht"
> geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
> das angehängte Log.
>

Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
Browser, mit &debug=1. Dann schauen was/wo das wie lange dauert.

Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
> s0-Ereignissen erzeugt.
>

d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
Minute?

Also doch alles ok?
>

Es ist lngsam- aber anscheinend nicht Problem der Aggregation.


>
> Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im log
> fällt mir auf, dass das sehr häufig vorkommt:
>   911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
> e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
> e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
> JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
> '90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
> 'aggregator') ORDER BY p1_.pkey ASC
>   911 Query START TRANSACTION
>   911 Query INSERT INTO data (timestamp, value,
> channel_id) VALUES ('1389302896063', '1', 14)
>   911 Query UPDATE properties SET value = '1' WHERE id
> = 71
>   911 Query UPDATE properties SET value = '1' WHERE id
> = 69
>   911 Query UPDATE properties SET value = '1000' WHERE
> id = 67
>   911 Query commit
>
> Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).  Was
> mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
> Liefert bei mir z.B.
>
> +-+--+---+--
> ++-+-++
> | id0 | uuid1| type2 | id3  | pkey4  |
> value5  | class6  | entity_id7 |
> +-+--+---+--
> ++-+-++
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   71 | active
> | 1   | channel | 14 |
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   70 | color
>  | navy| channel | 14 |
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   69 | public
> | 1   | channel | 14 |
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   67 | resolution
> | 1000| channel | 14 |
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   72 | style
>  | steps   | channel | 14 |
> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   68 | title
>  | Strom-Ferienwohnung | channel | 14 |
> +-+--+---+--
> ++-+-++
> 6 rows in set (0.00 sec)
>
> Muss das wirklich vor jedem Insert sein?
> Und danach werden _immer_ die Werte für resolution, active und public
> "geupdatet" (Unnötig, sind die alten Werte)
>

Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.

Was mich wundert sind Property Updates denn diese sind wirklich völlig
sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...

Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
> PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
> ziemlich

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Hallo Heiko,

jetzt hatte ich extra den Schlepptop hochgefahren um Dich mit Diagnosetipps
zu versorgen und schon rennt die Mieze?! Aber lieber so als anders ;)

Viel Spass mit dem Tier,
Andreas

PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im
Querystring ;)



2014/1/9 Heiko Baumann 

>
>
>> Bin jetzt echt am Grübeln - vielleicht läuft die Optimierung ja doch
>> schon? hmmm... ahhh.. moment, ich schau einfach mal ins mysql.log.
>> Tatsächlich: da wird fleissig auf die aggregate-Tabelle zugegriffen:
>> 140109 20:37:15 70465 Connect   vz@localhost on volkszaehler
>> 70465 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
>> e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
>> e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
>> JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
>> '9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8') AND e0_.class IN ('channel',
>> 'aggregator') ORDER BY p1_.pkey ASC
>>
> 70465 Query SELECT MIN(timestamp) FROM (SELECT
> timestamp FROM data WHERE channel_id='15' AND timestamp<'1389209549459'
> ORDER BY timestamp DESC LIMIT 2) t
>
>> 70465 Query SELECT MAX(timestamp) FROM (SELECT
>> timestamp FROM data WHERE channel_id='15' AND timestamp>'1389295949459'
>> ORDER BY timestamp ASC LIMIT 2) t
>> 70465 Query SELECT aggregate.type, COUNT(aggregate.id)
>> AS count FROM aggregate INNER JOIN entities ON aggregate.channel_id =
>> entities.id WHERE uuid = '9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8' GROUP BY
>> type HAVING count > 0 ORDER BY type DESC
>> 70465 Query SELECT 
>> UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp)
>> / 1000, "%Y-%m-%d")) * 1000 FROM aggregate WHERE channel_id='15' AND
>> type='3' AND timestamp>='1388227905662'
>> 70465 Query SELECT 
>> UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp)
>> / 1000, "%Y-%m-%d"), INTERVAL 1 day)) * 1000 FROM aggregate WHERE
>> channel_id='15' AND type='3' AND timestamp<'1389296017384'
>> 70465 Query SELECT SUM(count) FROM (SELECT COUNT(1)
>> AS count FROM data WHERE channel_id = '15' AND ( timestamp >=
>> '1388227905662' AND timestamp < '138818520' OR timestamp >=
>> '138827160' AND timestamp <= '1389296017384') UNION SELECT SUM(count)
>> AS count FROM aggregate WHERE channel_id = '15' AND type = '3' AND
>> timestamp >= '138818520' AND timestamp < '138827160') AS agg
>>
>>
>> ...also alles richtig und muss damit leben, dass Schmidts Katze bei mir
>> nicht mag...?
>>
>
> ... das war dann wohl auch ein Hauptgrund für die Lahmheit: jetzt hab ich
> das mysql-logging abgedreht, und siehe da... miau ;)
> Das Logging kostet einfach zu viel Performance auf der kleinen Kiste...
>
> Also: Logging zugedreht... tata 11 Sek. für die Jahresansicht
> eines Temperatur-Channels (allerdings nur Werte aus dem 2. Halbjahr) - das
> ist cool..
>
> Sieht gut aus, vielen Dank!!
> Schönen Abend...
> Heiko
>
>

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Moin Heiko,


2014/1/9 Heiko Baumann 

> Ergänzung:
>
> http://vz/middleware.php/capabilities/database.json
>
> liefert mir:
>
> {"version":"0.3","capabilities":{"database":{"
> data_rows":6420892,"data_size":592134144,"aggregation_
> enabled":1,"aggregation_rows":58082,"aggregation_ratio":110.549}}}
>
> ... also ist das doch offenbar richtig aktiviert


Erstmal sind Daten drin. Ob die für die Kanäle drin sind die bei Dir
"langsam" sind sieht man daran nicht.


2014/1/9 Heiko Baumann 

>  ...
>


> Jedenfalls steht in volkszaehler.conf.php was von "administration
> credentials" - ich gehe mal davon aus, dass ich für den user root mein
> login-PW eintrage.
>

Ganz sicher nicht?! Da kommt ein DB-User mit CREATE/DROP Privilegien rein
falls Dein normaler DB-User die nicht hat.


> Die Timezone ("Europe/Berlin") ist rauskommentiert - soll das so sein?
>

Eher nicht.


> Tja und dann kommt also noch als letzte Zeile
> $config['aggregation']=true;
> mit rein. Speichern, aber selbst nach reboot kann ich keine Beschleunigung
> erkennen.
>

Reboot ist nicht nötig. Woran machst Du "keine Beschleunigung" das fest?
Bestimmte Abfrage? Nutzung des Frontends?


> Die aggregate-Tabellen wurden erzeugt und sind befüllt, hat bei 500MB data
> doch ganz schön gedauert.
>

Macht nix. Für Deltabefüllung gibts ja dann den entsprechenden  Modus
womit's auch fix geht.

>
> Woran könnte es liegen, dass die Performanceoptimierungen bei mir nicht
> greifen?
>

S.o.

vg
Andreas


>
> Danke!
>
> LG Heiko
>
> PS: Habe im wiki mal die hier weiter oben im Thread genannten Schritte
> ergänzt, weil das aktuelle Image ja noch vom August ist...
>
>
> Am 27.12.2013 18:22, schrieb Andreas Goetz:
>
>  2013/12/27 W3ll Schmidt 
>
>>  Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
>>
>
>  Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
>
>
>

[vz-dev] Erweiterung für VZClient

[Andreas Goetz]

Hallo,

ich hab eine kleine Erweiterung für vzclient eingestellt mit der auch auf
die Werte in Listen zugegriffen werden kann. Wer den Momentanwert eines
Kanals braucht macht das jetzt mit:

vzclient -u 8f20eb60... -e data,tuples,0,1 get data from=now

https://github.com/volkszaehler/volkszaehler.org/pull/89

vg
Andreas

Re: [vz-dev] AVM Steckdose Wattanzeige

[Andreas Goetz]

So... seit ein paar Stunden läuft die Steckdose stabil. Leider hätte ich
fast den Kühlschrank abgeschossen da ich vergessen hatte sie auch "ein" zu
schalten :O

Datenerfassung funktioniert mit kleinem "fritzdect" Tool aus meinem dev
Repository und folgendem Skript über cron:

pi@prodpi ~ $ cat ./fritzdect.sh
#!/bin/bash

POWER=`/usr/bin/php /home/pi/volkszaehler.org/misc/tools/fritzdect.php -a
087610103568 -c getswitchpower -d 1e3`
COUNTER=`/usr/bin/php /home/pi/volkszaehler.org/misc/tools/fritzdect.php -a
087610103568 -c getswitchenergy`

if [ "$COUNTER" = "" ]; then
echo "ERROR"
echo "Power: $POWER Consumption: $COUNTER"
else
echo "Power: $POWER Consumption: $COUNTER"

/home/pi/volkszaehler.org/misc/tools/vzclient -u 2a148630-... add
data value=$POWER
/home/pi/volkszaehler.org/misc/tools/vzclient -u 7ff0ff00-... add
data value=$COUNTER
fi

Aus Spass zeichne ich erstmal beide Werte auf um zu sehen was mehr Spass
macht. Vmtl. ist Power sinnvoller da genauer, Counter könnte aber dazu
dienen fehlende Werte zu korrigieren. Da brauchts noch einen intelligenten
Algorithmus.

vg
Andreas

PS.: Läuft leider nur mit der Laborversion von Fritz...


2013/12/28 NetFritz 

>  Am 28.12.2013 12:15, schrieb Andreas Goetz:
>
>  2013/12/28 Udo1 
>
>> Am 28.12.2013 11:04, schrieb Andreas Goetz:
>>
>>  z then Call URL/ execute Script
>>>
>>  oder Setze/Rücksetze GPIO-Pin xyz
>>
>> Gruß
>> Udo
>>
>
>  Eher nicht weil zu speziell. Und dafür gibts ja schon
> Kommandozeilentools, das würde also reichen. Bevor wir da was bauen
> brauchts allerdings wirklich eine gute Archtikturidee. Kann/soll/darf man
> das vom Apachen aus machen? Performance??
>
>  Wird spannend..
>
> vg
>  Andreas
>
>  PS.: Habe jetzt hier ein kleines Tool zum auslesen/ setzen der FritzDECT
> mit Laborversion...
>
> Hallo
> Hier habe ich vor ein Paar Tagen mal was gefunden.
> http://www.tdressler.net/ipsymcon/fritz_aha.html
> Ich habe mir vor ein Paar Tagen eine Fritz546e Steckdose zugelegt und dann
> auf meine FB 7270v2 die FRITZ!OS 06.01-27185 
> BETA<http://192.168.2.1/home/pp_fbos.lua?sid=02870eb059eae589>installiert.
> Gruß NetFritz
>

Re: [vz-dev] AVM Steckdose Wattanzeige

[Andreas Goetz]

2013/12/28 Udo1 

> Am 28.12.2013 11:04, schrieb Andreas Goetz:
>
>  z then Call URL/ execute Script
>>
> oder Setze/Rücksetze GPIO-Pin xyz
>
> Gruß
> Udo
>

Eher nicht weil zu speziell. Und dafür gibts ja schon Kommandozeilentools,
das würde also reichen. Bevor wir da was bauen brauchts allerdings wirklich
eine gute Archtikturidee. Kann/soll/darf man das vom Apachen aus machen?
Performance??

Wird spannend..

vg
Andreas

PS.: Habe jetzt hier ein kleines Tool zum auslesen/ setzen der FritzDECT
mit Laborversion...

Re: [vz-dev] AVM Steckdose Wattanzeige

[Andreas Goetz]

Ich hab jetzt mal auf die Laborversion FRITZ!OS 06.01-27185 BETA
umgestellt. Damit funktioniert nach ersten Versuchen auch
homeautoswitch.lua wie erwartet.

Prinzipiell bringt mich das auf die Frage ob wir VZ nicht um sowas wie
Trigger bzw. Aktoren erweitern sollten (if Leistung < xy für Zeitraum > z
then Call URL/ execute Script). Die Frage ist wieweit das vom Webserver aus
sinnvoll ist. Der Charme besteht ja aktuell u.a. darin dass keine
aufwendigen Serverkomponenten benötigt werden...

vg
Andreas


2013/12/27 Andreas Goetz 

> Hi,
>
>
> 2013/12/27 Thomas Gauweiler 
>
>> @Andreas:
>> >Ihr habt mich angefixt.
>> Warum sollte es Dir anders ergehen als mir :-)
>>
>> Und welche Fritz OS Version hast Du?
>>
>
> ist eine 7270v3 74.05.50. Nach dem Update jetzt 74.05.53. Der Fehler
> 'Luacgi not readable filename=/webservices/homeautoswitch.lua' ist nach wie
> vor da :(
>
> Gruß
>> __
>> /homas
>>
>
> Also telfonieren wir im neuen Jahr mal mit AVM. So schwer kann das ja
> nicht sein die 3 Parameter zu dokumentieren. Mannmannmann...
>
> vg
> Andreas
>

Re: [vz-dev] AVM Steckdose Wattanzeige

[Andreas Goetz]

Hi,


2013/12/27 Thomas Gauweiler 

> @Andreas:
> >Ihr habt mich angefixt.
> Warum sollte es Dir anders ergehen als mir :-)
>
> Und welche Fritz OS Version hast Du?
>

ist eine 7270v3 74.05.50. Nach dem Update jetzt 74.05.53. Der Fehler
'Luacgi not readable filename=/webservices/homeautoswitch.lua' ist nach wie
vor da :(

Gruß
> __
> /homas
>

Also telfonieren wir im neuen Jahr mal mit AVM. So schwer kann das ja nicht
sein die 3 Parameter zu dokumentieren. Mannmannmann...

vg
Andreas

Re: [vz-dev] AVM Steckdose Wattanzeige

[Andreas Goetz]

@all: Ihr habt mich angefixt. Jetzt hab ich auch so ein Ding :)

@Berthold: woher kommt Dein Skript? Aus der AVM Doku jedenfalls nicht?!

vg
Andreas



2013/12/27 Thomas Gauweiler 

> Hallo Thorben,
>
> ich gebe Dir recht, aber ich wäre schon froh, wenn die vorhandene Doku
> passend wäre.
>
> Ich denke inzwischen, dass sich die Doku zur AHA auf die Firmware ab
> 5.9 bezieht.
>
> Verwendbar ist die Steckdose über die Oberfläche der Fritz!Box schon ab
> 5.0.
> Infos dazu sind vermutlich inoffiziell über das FHEM-Projekt geflossen.
>
> Mir persönlich reicht es, wenn ich die Form des Verbrauchs erkenne,
> die genauen Verbrauchszahlen brauche ich nicht.
> Da ich daraus aber einen Mechanismus ableiten möchte, brauche ich den
> Zugang via Skript.
>
> Gruß
> __
> /homas
>

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

2013/12/27 W3ll Schmidt 

> Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
>

Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))

Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Moin,

2013/12/27 René Hézser 

>
>
>
>
> Nach der Anleitung (also als Punkt 4) habe ich noch in der
> volkszaehler.conf.template.php $config['aggregation'] = true; gesetzt.
>
> Ist die Aggregation nur dann aktiv?
>
>
>
> Gruß
>
> René
>
>
>
So isses. Sonst würde der Eintrag ja nicht soviel Sinn machen :/ Und er
wirkt auch nur dann wenn die Tabelle befüllt wird...

vg
Andreas

Re: [vz-dev] Vzlogger zum Teilen überreden

[Andreas Goetz]

Hallo *,

auch auf die Gefahr einen alten Faden wieder aufzuwühlen. Die
Fehlerkorrektur ist mir wichtig da es häufiger vorkommen dürfte.


2013/11/27 Frank Kalberg 

>
>
> *Hallo, *
>
>
>
> ich nutze meinen Volkszähler unter anderem auch um die Daten meines
> Windmessers aufzuzeichnen. Das habe ich folgendermaßen umgesetzt:
>
> ...
>
> Nun gut da gab es noch den vzclient damit kann ich mit get data tuples=2
> die letzten Daten der entsprechenden UUID abfragen, klasse ..bekomme aber
> nur max,min,average,consumption angezeigt. Hm und die aktuelle Leistung
>  Habe ich etwas übersehen oder kann ich den vzlogger nicht zum teilen
> überreden ? Wie würdet ihr das Lösen, danke schon mal für eure Ideen.
>

Das tut nicht was Du erwartest :O tuples=2 sagt der MW einfach dass sie
alle Daten (des Requests) in 2 Tuples verpacken soll. Im jeweils 3. Eintrag
siehst Du wieviele Datenpunkte dafür verwurstet wurden.

Was Du suchst heißt from=now. Damit produziert die MW exakt einen, nämlich
den letzten Tupel.

vg
Andreas

Re: [vz-dev] Volkszaehler Performance Verbesserungen - z.B. für RaspberryPi

[Andreas Goetz]

Hallo Zusammen,

es ist vollbracht: https://github.com/volkszaehler/volkszaehler.org/pull/80

Also ab jetzt ein wenig Vorsicht beim aktualisieren!

Frohes Fest,
Andreas



2013/12/14 Andreas Goetz 

> Hallo Zusammen,
>
> ich betreibe VZ seit etwa einem Jahr. Bei mir zeichnet ein kleiner RasPi 5
> Kanäle auf und hat mittlerweile ca. 30 Datensätze geschrieben.
> Mit der Performance der Middleware wie sie mit meiner Monitoring App VZmon
> (https://github.com/andig/vzmon/) oder vom Frontend zu beobachten war war
> ich völlig unzufrieden. Eine Jahresansicht im Frontend z.B. brauchte > 30
> Sekunden- indiskutabel.
>
> Ich habe daher Middleware und Frontend in den relevanten Bereichen
> grundlegend angepasst. Das Ergebnis: die Jahresansicht generiert mir das
> Frontend jetzt in 2 Sekunden, selbst wenn alle 5 Kanäle eingeblendet sind.
>
> Leider besteht momentan keine Chance die Entwicklungen in den offiziellen
> Zweig zu bekommen. Voraussetzungen dafür sind Tests, Tests und Tests.
>
> Daher meine Frage und Bitte: wer das Thema spannend findet und die
> Entwicklungen testen möchte sollte sich hier melden.
> Die Entwicklungen stehen unter
> https://github.com/andig/volkszaehler.org/tree/dev bereit. Wenn Interesse
> besteht gebe ich einen kurzen Einführungskurs.
> Fürs erste wäre es allerdings hilfreich wenn sich nur Interessenten mit
> ein wenig Entwicklungsknowhow meldeten da der Supportaufwand sonst zu gross
> wird.
>
> Viele Grüße,
> Andreas
>

[vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Andreas Goetz]

Hallo Zusammen,

die VZ Admins bzw. Committer arbeiten derzeit daran, die verschiedenen
Patches zur Performanceoptimierung in das VZ Hauptrepository einzubringen.

Leider muss dazu die bestehende VZ Infrastraktur einmalig einer Änderung
unterzogen werden die nicht durch ein einfaches

git pull

zu beheben ist. Wenn Ihr in den nächsten Tagen also vorhaben solltet Eure
VZ-Installation mal wieder auf den aktuellen Stand zu bringen beachtet
bitte folgende Punkte um die Installation möglichst unterbrechungsfrei
durchzuführen:

1. Installiert die "Composer" Paketverwaltung

$ mkdir composer
$ cd composer
$ curl -sS https://getcomposer.org/installer | php
$ sudo cp composer.phar /usr/local/bin/composer

Windowsnutzer laden sich den Installer unter
http://getcomposer.org/download/ herunter.

Zum testen:

composer self-update

Wenn das erfolgreich funktioniert seid Ihr das das Git Update
vorbereitet.

2. Aktualisiert Eure Installation

Dafür macht ihr wie immer in Eurem VZ Verzeichnis ein

git pull

ACHTUNG: nach diesem Schritt ist die Middleware zunächst nicht mehr
erreichbar da die Abhängigkeiten (Doctrine etc) nicht gefunden werden.

Deshalb jetzt schnell die Abhängigkeiten installieren:

composer install

sollten Hinweise über veraltete Software kommen könnt Ihr auch noch
ein optionales

composer update

nachschieben.
Nach diesem Schritt ist die Middleware wieder erreichbar da die
notwendigen Bibliotheken jetzt verfügbar sind.

3. Performanceoptimierung einschalten

Wenn Ihr MySQL nutzt (in der neuen Version werden auch SQlite und
PostgreSQL zusätzlich unterstützt, allerdings ohne
Vollständigkeitsgarantie) dann könnt Ihr die neuen Features wiefolgt
aktivieren.

Hilfstabelle anlegen:

php misc/tools/aggregate.php create

Hilfstabelle befüllen:

php misc/tools/aggregate.php -m full -l day -l hour run

Und den Prozess für die Aktualisierung noch automatisien:

crontab -e

und die folgenden Zeilen hinzufügen:

* 2 * * * /usr/bin/php aggregate.php -m delta -l day run
9 * * * * /usr/bin/php aggregate.php -m delta -l hour run

Damit ist's dann getan- ab jetzt sollte Euer VZ "rennen".
Wir melden uns wieder an dieser Stelle wenn die Änderungen "drin" sind. Die
Ungeduldigen finden bis dahin im dev Zweig unter
github.com/andig/volkszaehler den aktuellen Stand zum spielen.

Euch allen ein Frohes Fest, Schöne Bescherung und
Viel Spass beim auspacken der Geschenke!

Euer Andreas

Re: [vz-dev] Hinweis für vzcompress2 o.Ä.-Nutzer: OPTIMIZE TABLE nicht vergessen

[Andreas Goetz]

wer den dev Zweig nutzt kann php misc/tools/aggregate optimize nutzen ->
data und aggregate


2013/12/20 Florian Knodt 

> Nabend zusammen,
>
> mir ist eben aufgefallen, dass trotz vcompress2 meine Datenbankdatei
> immer weiter (bzw. schneller als erwartet) wächst. Bei MyISAM war die
> Sache recht einfach: Wenn der Überhang wuchs war das Mittel der Wahl ja
> ein OPTIMIZE TABLE, beim hier verwendeten InnoDB scheint das etwas
> komplexer zu sein, da diese Engine offenbar kein separates OPTIMIZE
> unterstützt sondern hierbei die komplette Tabelle neu erstellt.
>
> Erst mal vorab: Es bringt nichtsdestotrotz den von mir gewünschten
> erfolg, meine Datenbank ist von knapp 800 auf nun 150MB geschrumpft -
> kommt sicherlich auch der Performance zu Gute.
>
> Im Internet findet mach häufig den Rat bei InnoDB keinen Optimize
> durchzuführen, sondern die Indizes zu löschen und neu zu erstellen.
> Diese Methode ist deutlich schneller fertig und beansprucht den Speicher
> weniger, da nur die Indizes neu geschrieben werden und nicht der
> komplette Datenbestand. Der Nachteil dürfte diese Methode allerdings für
> die integration in einen Cronjob o.Ä. uninteressant machen: Während des
> Erstellens gibt es keine Indizes, Leseoperationen dürften - wenn sie
> nicht sogar in einen Timeout laufen - ewig dauern und ich bin mir nicht
> einmal sicher, ob in der Zeit Daten aufgezeichnet werden können (data
> basiert auf IDs die per AUTO INCREMENT vergeben werden und das ist afair
> an einen Index gebunden).
>
> Ein OPTIMIZE TABLE alle Nase lang dürfte als Cron auf "richtigen"
> Servern sicher nicht Schaden - die Datenbank war hier während des Laufes
> komplett funktionsfähig und die benötigte Zeit hielt sich bei meinem
> System in Grenzen (bisher nicht komplett gestoppt, aber <5 Minuten).
> Wenn jemand auf seinem Raspi schon regelmäßige OPTIMIZE TABLE ausführt
> wäre ein Erfahrungsbericht nicht schlecht, ich würde schätzen, dass die
> Last ein Problem werden könnte. Auch die Hohe IO-Last dürfte der SD
> nicht gut tun (bessere Karten könnten eventuell durch den freien
> Speicher die Abnutzung wieder vesser verteilen was dann wiederum
> ausgleichen würde). Bei solchen Systemen würde ich eher erst mal nur das
> Testsystem quählen.
>
> --
> Mit freundlichen Grüßen  ||  Sincerely yours
> Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
> www.adlerweb.info · www.56648.de · @adlerweb
>
>

Re: [vz-dev] Einheiten / Fill / Zählerstände

[Andreas Goetz]

Hi Thomas,

lass uns die Diskussion hier mal parken bis die mit August in Users
abgeschlossen ist- das geht m.E. in die richtige Richtung!

vg
Andreas

2013/12/18 

> @Andreas:
> Auf welchen Teil meiner 3 Fragen beziehst du Dich denn?
> bei 1. sind Leistungsmesser als Typ gewählt
> bei 3. sind Stromzähler als Typ gewählt.
>
> Ist da schon der Denkfehler drin?
>
> Viele Grüße
> Thomas
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Andreas Götz
> > Gesendet: Di. 17.12.2013 23:18
> > An: volkszaehler.org ,
> > Betreff: Re: [vz-dev] Einheiten / Fill / Zählerstände
> >
> > Warum Leistungsmesser wenn Du doch Verbrauchswerte misst?!
> >
> > Viele Grüße,
> > Andreas
> >
> >> Am 17.12.2013 um 18:13 schrieb Thomas
> > Schenkel :
> >>
> >> Hi, ich habe diese Fragen schon in der
> > users-Mailingliste angesprochen, aber ich glaube wir kommen da
> > nicht weiter.
> >> Daher einfach mal hier im dev-Forum.
> > Vielleicht hat einer von Euch eine zündende Idee
> >>
> >> Hallo zusammen,
> >>
> >> ich habe eine paar Fragen zum
> > frontend.
> >> - Ich versuche nun seit geraumer Zeit
> > im Wiki rauszubekommen, wie ich
> >> die Einheiten bei den Leistungswerten
> > ändern kann.
> >> Der vzlogger liest einwandfrei
> > beispielsweise 0.864 als Wert und kW als
> >> Einheit (siehe kleines log). Dennoch
> > ist die Anzeige auf dem Kanal 0.864
> >> Watt und nicht Kilowatt. Wo oder wie
> > kann ich das ändern, damit kW
> >> angezeigt wird oder die ausgelesenen
> > Werte mal 1000 genommen werden.
> >> (Bild: Snip - W vs. kW.JPG)
> >> [Dec 16 18:25:50][d0]   sending
> > pullsequenz send (len:5 is:5).
> >> [Dec 16 18:25:50][d0]   Meter supports
> > baudrate of 9600
> >> [Dec 16 18:26:06][d0]   Parsed reading
> > (OBIS code=1-0:1.6.0*255,
> >> value=03.532, unit=kW)
> >> [Dec 16 18:26:07][d0]   Parsed reading
> > (OBIS code=1-0:1.7.0*255,
> >> value=0.864, unit=kW)
> >> [Dec 16 18:26:08][d0]   Parsed reading
> > (OBIS code=1-0:1.8.0*255,
> >> value=166.380, unit=kWh)
> >> [Dec 16 18:26:09][d0]   Parsed reading
> > (OBIS code=1-0:1.8.1*255,
> >> value=094.591, unit=kWh)
> >> [Dec 16 18:26:10][d0]   Parsed reading
> > (OBIS code=1-0:1.8.2*255,
> >> value=071.788, unit=kWh)
> >> [Dec 16 18:26:11][d0]   Parsed reading
> > (OBIS code=1-0:1.8.3*255,
> >> value=000.000, unit=kWh)
> >> [Dec 16 18:26:12][d0]   Parsed reading
> > (OBIS code=1-0:1.8.4*255,
> >> value=000.000, unit=kWh)
> >> [Dec 16 18:26:13][d0]   Parsed reading
> > (OBIS code=1-0:2.6.0*255,
> >> value=02.338, unit=kW)
> >> [Dec 16 18:26:14][d0]   Parsed reading
> > (OBIS code=1-0:2.7.0*255,
> >> value=0.000, unit=kW)
> >> [Dec 16 18:26:15][d0]   Parsed reading
> > (OBIS code=1-0:2.8.0*255,
> >> value=046.574, unit=kWh)
> >> [Dec 16 18:26:16][d0]   Parsed reading
> > (OBIS code=1-0:2.8.1*255,
> >> value=038.423, unit=kWh)
> >> [Dec 16 18:26:17][d0]   Parsed reading
> > (OBIS code=1-0:2.8.2*255,
> >> value=008.150, unit=kWh)
> >> [Dec 16 18:26:18][d0]   Parsed reading
> > (OBIS code=1-0:2.8.3*255,
> >> value=000.000, unit=kWh)
> >> [Dec 16 18:26:19][d0]   Parsed reading
> > (OBIS code=1-0:2.8.4*255,
> >> value=000.000, unit=kWh)
> >>
> >> Ein einfügen von resolution=0.001
> > beim Leistungsmesser scheint keine
> >> Wirkung zu entfalten.
> >>
> >>
> >>
> >> - Pimp my frontend mit "fill: true"
> > funktioniert das wirklich? Bei mir
> >> sieht das so aus: Bild: Snip -
> > Fill.JPG
> >> Was mache ich denn da falsch?
> >>
> >>
> >>
> >> - Zählerstände. Schaut mal
> > bitte auf Bild: Snip - Zählerstände.JPG haut
> >> das mit der roten Linie so hin? Was
> > soll mir das sagen?
> >>
> >>
> >> Schönen Abend noch
> > zusammen.
> >> Grüße
> >> Thomas
> >>
> >>
> >>
> >>
> >> ---
> >> Diese E-Mail ist frei von Viren und
> > Malware, denn der avast! Antivirus Schutz ist aktiv.
> >>" > target="_blank">http://www.avast.com
> >>
> >>
> >>> Zählerstände.JPG>
> >
> >
> > -Ursprüngliche Nachricht Ende-
>
>
>
>
>
> ---
> Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
> http://email.freenet.de/basic/Informationen
>

Re: [vz-dev] [vz-users] Gaszähler Startwert

[Andreas Goetz]

Leider lässt sich das im Moment nicht sinnvoll implementieren da die
Performance dann gen Süden geht da bei jedem Aufruf über alle Werte je
Kanal summiert werden muss (1 Messwer je Minute x 24h x 1 Jahr = 500k
Werte).
Eine Lösung dafür wäre eine Aggregationstabelle mit der gruppierte Abfragen
und Abfragen mit tuples=1 (wie wir sie hier brauchen) dramatisch
beschleunigt werden können.
Code ist weitgehend fertig, kommt aber ohne Tester nicht ins git. Wer
Interesse und Lust am Basteln hat darf sich melden ;)

vg
Andreas


2013/12/7 Andreas Götz 

> Ich war gedanklich eher bei der Frage wo sie in die MW gehört ;)
>
> Viele Grüße,
> Andreas
>
> > Am 07.12.2013 um 23:25 schrieb Rainer Gauweiler <
> volkszaeh...@moppl.inka.de>:
> >
> > Hallo,
> >
> > Am 07.12.2013 14:02, schrieb Andreas Goetz:
> >> - eine Idee wo/wie die Funktion den Anwendern angeboten werden soll:
> >
> > Im Frontend links oben wo aktuell die Verbrauchswerte stehen. Da ist
> Platz und dann kann man den Zählerstand leicht mit eigenen Aufzeichnungen
> vergleichen oder gezielt zu einem gewissen Zeitpunkt sich anzeigen lassen.
> >
> > Gruss
> > Rainer
> >
> >
> >
>

Re: [vz-dev] Fehler: vz und Temperaturen unter -10°

[Andreas Goetz]

Die Frage geht an die Loggerexperten Udo und Rainer- entweder indem Du
direkt die Schnittstelle ausliest oder im vzlogger (nutzt Du den?) mal das
Loggig so erhöhst dass die Daten sichtbar werden.

Genauer weiss ich es leider nicht, sry..


2013/12/8 Heiko Baumann 

>  Am 08.12.2013 13:44, schrieb Andreas Goetz:
>
>  Versuch bitte erstmal rauszufinden welche Werte der Sensor eigentlich
> liefert- ein Fehler der Middleware ist hier ziemlich unwahrscheinlich.
>
>   Hi Andi,
> du meinst also dass der Sensor bei < -10° falsche Werte liefert? Hm, dann
> müsst ich den Außenfühler mal auswechseln. In den Specs steht halt
> "Temperaturbereich -55° bis +125°C". Wär dann ja schon arg bitter wenn er
> bei exakt -10,0°C streikt...
> Hab ich noch eine andere  Möglichkeit, die gelieferten Werte außerhalb der
> DB auszulesen und nachzuprüfen?
>
> Danke!
> LG Heiko
>
>
>
>
> 2013/12/8 Heiko Baumann 
>
>>
>> Hallo zusammen,
>>
>> nachdem es jetzt bei uns leider ziemlich kalt wird, ist mir ein
>> Darstellungsproblem im Frontend aufgefallen.
>> Fällt die Temperatur unter -10°, werden z.B. "-1,5°" anstelle von
>> "-11.5°" angezeigt (siehe Screenshot).
>>
>> Erst dachte ich, das wäre ein Fehler im Frontend, aber leider stehen
>> auch die Werte falsch in der DB:
>>
>> mysql> select *, from_unixtime(timestamp/1000) from data where
>> timestamp>1385517696591 and timestamp<1385517998592 and channel_id=10;
>>
>> +-++---+---+---+
>> | id  | channel_id | timestamp | value |
>> from_unixtime(timestamp/1000) |
>>
>> +-++---+---+---+
>> | 6816491 | 10 | 1385517696592 | -9.94 | 2013-11-27 03:01:37
>>   |
>> | 6816638 | 10 | 1385517779731 |-1 | 2013-11-27 03:03:00
>>   |
>> | 6816772 | 10 | 1385517855444 | -1.01 | 2013-11-27 03:04:15
>>   |
>> | 6816916 | 10 | 1385517937645 | -1.02 | 2013-11-27 03:05:38
>>   |
>>
>> +-++---+---+---+
>> 4 rows in set (0.00 sec)
>>
>> Datensatz 6816638 müsste eigentlich "-10" als Value haben, 6816772
>> "-10.1" usw.
>> Die Temperatursensoren gehen lt. Hersteller bis -55°C.
>>
>> Woran könnte das liegen?
>> Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz.
>>
>> Danke und schöne Grüße
>> Heiko
>>
>>
>>
>
>

Re: [vz-dev] Fehler: vz und Temperaturen unter -10°

[Andreas Goetz]

Versuch bitte erstmal rauszufinden welche Werte der Sensor eigentlich
liefert- ein Fehler der Middleware ist hier ziemlich unwahrscheinlich.

vg
Andreas


2013/12/8 Heiko Baumann 

>
> Hallo zusammen,
>
> nachdem es jetzt bei uns leider ziemlich kalt wird, ist mir ein
> Darstellungsproblem im Frontend aufgefallen.
> Fällt die Temperatur unter -10°, werden z.B. "-1,5°" anstelle von
> "-11.5°" angezeigt (siehe Screenshot).
>
> Erst dachte ich, das wäre ein Fehler im Frontend, aber leider stehen
> auch die Werte falsch in der DB:
>
> mysql> select *, from_unixtime(timestamp/1000) from data where
> timestamp>1385517696591 and timestamp<1385517998592 and channel_id=10;
> +-++---+---+
> ---+
> | id  | channel_id | timestamp | value |
> from_unixtime(timestamp/1000) |
> +-++---+---+
> ---+
> | 6816491 | 10 | 1385517696592 | -9.94 | 2013-11-27 03:01:37
> |
> | 6816638 | 10 | 1385517779731 |-1 | 2013-11-27 03:03:00
> |
> | 6816772 | 10 | 1385517855444 | -1.01 | 2013-11-27 03:04:15
> |
> | 6816916 | 10 | 1385517937645 | -1.02 | 2013-11-27 03:05:38
> |
> +-++---+---+
> ---+
> 4 rows in set (0.00 sec)
>
> Datensatz 6816638 müsste eigentlich "-10" als Value haben, 6816772
> "-10.1" usw.
> Die Temperatursensoren gehen lt. Hersteller bis -55°C.
>
> Woran könnte das liegen?
> Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz.
>
> Danke und schöne Grüße
> Heiko
>
>
>

Re: [vz-dev] [vz-users] Gaszähler Startwert

[Andreas Goetz]

Hallo *,

>
> ...
>
>> Ich wünsche mir allerdings, dass im Volkszähler Projekt die Anzeige von
>> absoluten Zählerständen in Zukunft irgendwann einmal vernünftig realisiert
>> wird.
>>
>
> Die Idee finde ich nicht uncharmant.
>
> Je nachdem welchen Zählertyp Du hast sollte das eigentlich heute schon
> möglich sein. Wenn es sich um ein "Meter" handelt das also Verbräuche
> speichert dann kann man natürlich den Startverbauch in einen Timestamp vor
> dem ersten echten Zählerwert schreiben. Damit die MW den wirklich
> berücksichtigt braucht es zusätzlich noch 1(!) weiteren Wert+Timestamp
> davor da der erste verschluckt wird. Dieser sollte soweit vorher liegen
> dass eine vernünftige Durchschnittsleistung berechnet wird- anderenfalls
> kann das im FE sehr blöd aussehen.
>

Ich habe das Ganze mal in einen Unit Test verpackt- wer Interesse hat
sollte es mit dem Code unten und den Unit Tests in Git nachvollziehen
können. Die Funktion "setTotal" funktioniert so, dass sie

1) den aktuellen Gesamtverbaucht ermittelt
2) ausrechnet wieviel dazu muss um den Wunschwert zu erreichen
3) den ersten Wert der Datenbank um den "dazu" Anteil erhöht
4) und den ersten Wert aktualisiert

Der Ablauf dafür mit den Unittestfunktionen sieht so aus:

function testSetTotal() {
$this->getTuples(1, "1.1.2030");
echo("\nold consumption: {$this->json->data->consumption}\n");

// new desired total consumption
$total = 75; // kWh
$delta = $total - $this->json->data->consumption / 1000; // kWh

$rowCount = $this->json->data->rows;
if ($rowCount) {
// we have starting timestamp + at least one valid tuple- get
tuple range
$ts1 = $this->json->data->from;
$ts2 = ($rowCount > 2) ? $this->json->data->tuples[1][0] :
$this->json->data->to;

// add consumption of first tuple
$delta += $this->json->data->tuples[0][1] * ($ts2 - $ts1) /
3.6e9; // kWh

// update tuple to match desired total
$url = self::$context . '/' . self::$uuid .
'.json?operation=edit&ts=' . $ts2 . '&value=' . ($delta *
self::$resolution); // kWh * res
$this->getJson($url);

// verify total consumption
$this->getTuples(1, "1.1.2030", '', 1);
echo("new consumption: {$this->json->data->consumption}\n");

$this->assertFromTo($ts1, $this->json->data->to);
$this->assertEquals($total * 1000,
$this->json->data->consumption); // compare Wh
}
else {
echo("Not enough tuples\n");
}
}

Um die Funktion "setTotal" jetzt produktiv einsetzen zu können braucht es:
- eine Erweiterung des Datenkontext da editieren aktuell nicht möglich ist
- eine Idee wo/wie die Funktion den Anwendern angeboten werden soll:
  a) Evtl. als kleines Zusatztool für die Kommandozeile?
  b) als Funktion des channel Kontext?
  c) als Funktion des channel Kontext?
  d) als neuer "totals" Kontext?


> Bei "Countern" ist es egtl. kein Problem- hier wird ja ohnehin der echte
> Zählerwert gespeichert, passt also.
>
> Tatsächlich scheint auch das nicht ganz zu funktionieren da die MW immer
nur die Differenzen ausgibt. Auch hierfür wäre es also notwendig 1
zusätzlichen Tuple mit Wert 0 als allerersten Tuple zu schreiben.

Bei "Sensoren" wiederrum die nur Momentanwerte speichern ließe sich das
> analog "Meter" implementieren.
>
> Jetzt käme es mal auf einen Test und Feedback an, dann liesse sich das
> Ganze durchaus auch über den Channel Controller implementieren, z.B. indem
> man eine neue Eigenschaft "hasTotal" definiert die über Channel Updates in
> Form von Tupeln gespeichert werden. Damit könnte Clients die obige nicht
> ganz triviale Logik verfügbar gemacht werden.
>
> Wer probierts aus und gibt Feedback ob/wie die Funktion implementiert
werden soll?

vg
Andreas

Re: [vz-dev] [vz-users] Gaszähler Startwert

[Andreas Goetz]

Hallo Bernd, hallo vz-dev,

2013/12/6 Bernd Gewehr 

> Hallo!
>
> Ich habe mir den Anfangswert in die Tabelle der Zählwerte mit einem frühen
> timestamp des Gaszählerkanals geschrieben und eine SQL Routine, die per
> Event alle 5 Minuten aufgerufen wird, dazu verwendet, die Summe aus den
> Zählwerten zu bilden und in einen neuen Kanal mit aktuellem Timestsmp zu
> schreiben.
>

Ups. Das können sicher nur Leute mit Bastelaffinität.


> Dies funktioniert gut!
>
> Ich wünsche mir allerdings, dass im Volkszähler Projekt die Anzeige von
> absoluten Zählerständen in Zukunft irgendwann einmal vernünftig realisiert
> wird.
>

Die Idee finde ich nicht uncharmant.

Je nachdem welchen Zählertyp Du hast sollte das eigentlich heute schon
möglich sein. Wenn es sich um ein "Meter" handelt das also Verbräuche
speichert dann kann man natürlich den Startverbauch in einen Timestamp vor
dem ersten echten Zählerwert schreiben. Damit die MW den wirklich
berücksichtigt braucht es zusätzlich noch 1(!) weiteren Wert+Timestamp
davor da der erste verschluckt wird. Dieser sollte soweit vorher liegen
dass eine vernünftige Durchschnittsleistung berechnet wird- anderenfalls
kann das im FE sehr blöd aussehen.

Bei "Countern" ist es egtl. kein Problem- hier wird ja ohnehin der echte
Zählerwert gespeichert, passt also.

Bei "Sensoren" wiederrum die nur Momentanwerte speichern ließe sich das
analog "Meter" implementieren.

Jetzt käme es mal auf einen Test und Feedback an, dann liesse sich das
Ganze durchaus auch über den Channel Controller implementieren, z.B. indem
man eine neue Eigenschaft "hasTotal" definiert die über Channel Updates in
Form von Tupeln gespeichert werden. Damit könnte Clients die obige nicht
ganz triviale Logik verfügbar gemacht werden.

vg
Andreas

Re: [vz-dev] Middleware, Data, Rows und Anzahl der Rows und Tuples

[Andreas Goetz]

Dein Tool muss doch eh Zeitstempel setzen- also einfach den aktuellen
nehmen, der kann ja noch nicht benutzt sein. Oder merken ob das Tool
schonmal was getan hat- dann ist der Fall ja auch klar...


2013/12/3 René Hézser 

> >Wenn nur ein Wert vorhanden ist passt das auch da die MW genau(!) 1 Wert
> "verschluckt".
> >Hast Du mal probiert was passiert wenn > 1 Wert in der DB steht?
>  >>Wie wäre es mit einem Parameter "last" oder so, der den letzten
> Datensatz raw ausgibt, ohne zu rechnen?
>
> Bei mehr als einem Wert passt es. Rows ist zwei und der Zeitstempel ist
> richtig.
>
> Nur was mache ich für den Fall dass nur einer da ist? Mein Tool zum
> hochladen von Werten in die Datenbank liest via REST aus, wann der letzte
> Datensatz eingestellt wurde. Wird dieser nicht ausgegeben, versucht es
> natürlich mit demselben Zeitstempel und UUID hinzuzufügen. Und da kommt von
> der Middlware korrekterweise eine Duplicate Key Exception.
>
> Gruß
> René

Re: [vz-dev] Middleware, Data, Rows und Anzahl der Rows und Tuples

[Andreas Goetz]

Zweiter Anlauf.

2013/12/3 René Hézser 

> Ist nur ein Wert in der DB vorhanden, wird z.B. das hier zurück gegeben:
> {"version":"0.3","data":{"uuid":"79585050-5a7f-11e3-93c6-b94baa5526ce","from":138588872,"to":138588872,"average":0,"rows":1}}
>

Wenn nur ein Wert vorhanden ist passt das auch da die MW genau(!) 1 Wert
"verschluckt".
Hast Du mal probiert was passiert wenn > 1 Wert in der DB steht?


> Wie wäre es mit einem Parameter "last" oder so, der den letzten Datensatz
> raw ausgibt, ohne zu rechnen?
>
> Gruß
> René


Bitte vorher nochmal testen, dann schaue ich was sich tun lässt.

vg
Andreas

[vz-dev] Release 0.3?

[Andreas Goetz]

Hallo Zusammen,

vor einiger Zeit haben wir die neuen MW-Funktionalitäten mit Version 0.3 in
den MW Responses kenntlich gemacht. Das letzte offizielle Release ist
0.2-final. Derzeit haben wir Testcases die die Funktionalität der WM
bestätigen.

Gleichzeitig stecken einige Änderungen in der Pipeline:
- Nutzung Composer (r3wald/andig)
- Mehr/andere Unit Tests (r3wald)
- Unterstützung non-MySQL Datenbanken (r3wald/andig)
- Datenaggregation mit Materialized View (andig)

Vor diesem Hintergrund schlage ich vor den aktuellen Stand als 0.3-final zu
taggen.

Wie wärs?

vg
Andreas

Re: [vz-dev] Native Tablet App als Frontend

[Andreas Goetz]

Je nachdem was Du willst könntest Du vielleicht auch Beiträge liefern zu

- https://github.com/andig/vzmon/ oder
- https://github.com/andig/vzvis/

HTML gehört die Zukunft ;)

vg
Andreas


2013/11/27 Julian Vollmer 

> Hallo,
> Im Rahmen meiner Masterarbeit denke ich gerade über eine Native Tablet App
> (mir wäre iOS lieber) nach.
> Ich hatte gerade eine kleine Unterhaltung mit r00t^home für mich klang das
> nicht sehr begeistert.
> 
> [19:42]  Hallo, hat sich schon mal jemand Gedanken um
> eine Tablet-UI gemacht ? im Rahmen meiner Masterarbeit bin ich am überlegen
> ob ich eine native iOS iPad app für die middleare schreibe.
> [19:43]  sorry, ich meine natürlich das frontend ...
> [19:47]  viele leute benutzen das frontend schon auf tablets
> [19:47]  ansonsten, viel spass mit deinem Spielzeug
> 
> Aber vielleicht gibt es ja andere Entwickler die Lust haben darüber mal
> nachzudenken.
>
> Meine Meinung nach ist das Frontend auf Tablets nicht wirklich bedienbar.
>
> Eine kurze Rückmeldung, oder ein erscheinen im IRC, von Leuten die daran
> generell Interesse hätten wäre erfreulich.
>
>
> Beste Grüße
>
> Julian
>

Re: [vz-dev] Falsche Darstellung von "Stromzählerwerten"

[Andreas Goetz]

Hallo Andreas,

2013/11/21 Andreas Tauscher 

> ...
> b) Wenn keine Spannung gemessen wird. Sollte innerhalb einer bestimmten
> Zeit (berechnet aus einer genügend kleinen Grundlast) kein weiterer
> Messpuls auftauchen, dann wird bis zum nächsten Puls auch alles als 0
> geplottet.
>
> Andreas
>
> Der Ansatz interessiert mich. Ich hatte bisher immer versucht, das Problem
im Code der Middleware zu lösen, was aber spätestens dann scheitert wenn
Tuple aggregiert werden und die (evtl. wenigen) Nullen in der Datenbank
eingedampft werden. Wo/ an welcher Stelle hast Du das denn gelöst? Würde
wenn es funktioniert gerne einen Patch für das Frontend daraus entwickeln.

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hier nochmal ein  Beispiel zu "lessons learned" bzgl. Composer aus der
Reimplementierung meiner VideoDB Applikation (videodb.net):

1. Ich möchte meinen Code in eine Library verwandeln. Dafür kann ich
entweder alles in Komponenten verpacken oder ich nutze bestehende.
2. Also switche ich von meinem httpClient auf guzzle:

"require": {
"guzzle/guzzle": "~3.7",
},

3. Ich möchte http Requests auch cachen und switche dafür von meinem Cache
auf Doctrine (weil der nämlich von Guzzle unterstützt wird):

"require": {
"guzzle/guzzle": "~3.7",
"doctrine/cache": "~1"
},

4. Ich suche noch Hilfe bei der Fehlersuche während der Entwicklung:

"require-dev": {
"filp/whoops": "~1",
"phpunit/phpunit": "~3.7"
},

5. Ich brauche einen Autoloader für meinen neuen, besseren Code:

"autoload": {
"psr-0": {
"VideoDB": "."
}
}

6. Jetzt noch `composer update` und alles was ich brauche ist an Ort und
Stelle. Einfacher geht's nicht.

Insgesamt weniger als 30min Arbeit und der Code lief ohne dass ein einziger
require Statement notwendig gewesen wäre.

--

Hat alles mit Volkszähler nichts zu tun? Gestern fragte jemand nach
"Grafiken" aus dem VZ. Braucht leider JpGraph- auch da muss sich der Newbie
erstmal durchwühlen. Bei Installation über Composer wär's dabei...

vg
Andreas



2013/11/14 Andreas Goetz 

> 2013/11/12 Robert Ewald 
>
> Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md
>>
>> Vorteile:
>> * vereinfachte Installation von Abhängigkeiten, inklusive von deren
>> Abhängigkeiten
>> * ein sehr gut getesteter Autoloader, der auch für den eigenen Code
>> verwendet werden kann
>> * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt
>>
>>
> Abgesehen davon, dass sich Composer zum defacto Standard für PHP
> Paketmangement zu entwickeln scheint (+/- PEAR) scheint es z.B. von
> Doctrine (http://www.doctrine-project.org/downloads/) auch keine Pakete
> der aktuellen 2.4er Version mehr zu geben.
> Der einzige offzielle Installationsweg scheint mittlerweile Composer zu
> sein.
>
> vg
> Andreas
>

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

2013/11/12 Robert Ewald 

Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md
>
> Vorteile:
> * vereinfachte Installation von Abhängigkeiten, inklusive von deren
> Abhängigkeiten
> * ein sehr gut getesteter Autoloader, der auch für den eigenen Code
> verwendet werden kann
> * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt
>
>
Abgesehen davon, dass sich Composer zum defacto Standard für PHP
Paketmangement zu entwickeln scheint (+/- PEAR) scheint es z.B. von
Doctrine (http://www.doctrine-project.org/downloads/) auch keine Pakete der
aktuellen 2.4er Version mehr zu geben.
Der einzige offzielle Installationsweg scheint mittlerweile Composer zu
sein.

vg
Andreas

Re: [vz-dev] [vz-users] PerfPerformance-Optimierung des Raspberry Pi mit einem Server?

[Andreas Goetz]

Moin,


2013/11/13 Robert Ewald 

> ...
> Ich werde mir das Erfassen der Daten mal ansehen. Vielleicht findet sich
> da ja was.
>
> Grüße,
> Robert
>

Hatte ich auch schonmal gemacht. Erkenntnis 1: da geht nicht soviel.
Erkenntnis 2: es würde (minimal) helfen wenn Doctrine auf das Query zur
Ermittlung der Channel_ID verzichten würde, die ist ja eh immer gleich. Es
ist mir allerdings nciht gelungen den QueryResultCache dafür zu nutzen-
Doctrine scheint immauf auf "Hydration" zu bestehen. Jetzt liebe z.B.
explizit manuell zu cachen aber das schien mir Nutzen vs. Codekomplexität
nciht wert.


> Am 13. November 2013 23:09 schrieb :
>
>
>> > Allerdings reagiert der Raspi nur noch sehr träge (SD 8GB Kingston
>> class 10).
>> >
>> > Die Beschreibung von Chris Mattheis auf:
>> >
>> >
>> http://wiki.volkszaehler.org/howto/performance-optimierung_des_raspberry_pi
>> >
>> > trifft auch bei mir zu. Jetzt ist mir der Gedanke gekommen: Kann man
>> nicht die zeitkritischen Teile/Dateien auf eine Netzwerksfreigabe meines
>> Server (OpenSuse) verlagern? Tempomäßig ist der sicher schneller und auch
>> eine Datensicherung wäre einfacher.
>>
> >
>> > Macht das Sinn?
>>
>
Nein, oder jedefalls nicht sofort. Zuallererst würde ich mal veruschen
rauszufinden wo die Performance liegen bleibt. 'top' ist Dein Freund.
Wieviele Daten erfasst Du? Hast Du Aggregation im vzlogger schon versucht?


>
>> gerade heute habe ich mich mit einem PHP-Entwickler unterhalten; ich habe
>> ihn auf das Thema „Profiling unter PHP?“ angesprochen; er nannte phpmd [1].
>> Ich hab mir die Seite angeschaut - Profiling scheint zumindest nicht das
>> primäre Feature zu sein.
>>
>> Hat Jemand hier Erfahrung mit PHP-Profiling? Das wäre sicher mal
>> spannend, oder?
>>
>
Erstmal falsches Werkzeug für das Problem:
1. Engpass erkennen
2. Ursache finden
3. Beheben

Du versuchst schon bei 2. einzusteigen...

vg
Andreas

Re: [vz-dev] Ausschließlich MySQL (und Kompatible)?

[Andreas Goetz]

Hallo Zusammen,

wird wohl heute mein Emailtag...


2013/11/14 Thorben Thuermer 

>
> andi hat halt seine optimierungen nur gegen mysql gemacht und getestet,
> und den fall anderer dbms dabei kaputtgemacht.
> das ist auch nicht weiter tragisch oder verwunderlich,
> da eh 99% der user mysql einsetzen.
>
> zumal im Code der vor mir da war exlpizit dokumentiert ist dass nur MySQL
unterstützt wird. Die GroupBy Anfragen funktionieren ebenfalls nur mit
MySQL...


> loesungen, in order of preference:
> - code fixen so dass er ueberall funktioniert
> - die optimierungen nur bei mysql aktivieren
>   (eh fraglich, ob die bei anderen dbms was bringen!)
> - support fuer andere dbms verwerfen, da eh irrelevant
>
> > PS: Wie sieht es denn mit "Issues" bei Github aus? Ich fände es ganz
> > praktisch, wenn man da Fehler melden könnte. Da hat man dann auch den
> Bezug
> > zu Bugfixes.
>
> JUSTIN!!!
>

+1 +1 +1 von mir.


> - T.
>
> On Wed, 13 Nov 2013 22:33:13 +0100
> Robert Ewald  wrote:
> > Hallo allerseits,
> ...
> > Ich versuche es jedenfalls gerade mit SQLite. Es werden zwar erfolgreich
> > Daten erfasst und in der Datenbank gespeichert, aber die Weboberfläche
> > meldet Fehler. Der Grund ist folgendes Statement:
> > SET @row:=...
> >
> > Das ist MySQL-spezifisch und dürfte bei keiner anderen Datenbank
> > funktionieren. Die Jungs von SQLite haben lokale Variablen als Anzeichen
> > ineffizienter Abfragen verworfen und bei Postgresql heißt es schlichtweg
> > anders.
>
> Und es ist auch ganz einfach zu lösen: die übergeordnete Schleife mit &&
false deaktivieren, dann wird die Aggregation wieder in PHP statt MySQL
gemacht. Ist halt langsamer...

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hi,

2013/11/12 Thorben Thuermer 

> On Tue, 12 Nov 2013 10:05:59 +0100
> Andreas Goetz  wrote:
> ...
> > > das ist aber kein problem des maintainers, sondern der community.
> > > da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
> > > mir zB., alles selbst zu testen.
> > >
> >
> > Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer.
> > Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne
> > ist da/wenn die Maintainer keine Kommentare abgeben.
>
> hatte ich ja...
> wollte gerade einen neuen schreiben, als deine mail kam.
>
> neuer kommentar:
> schick wieviel da aufeinmal passiert...
> magst du dich erstmal mit robert absprechen, wessen loesung jetzt
> besser ist, zumal ihr ja anscheinend an den gleichen sachen arbeitet,
> und die patches vermutlich nicht kompatibel sind?
>
>
Es gibt keine Überschneidung.  Robert macht einen Patch, ich nicht, wir
diskutieren im git -> passt.

...
> > > ich wollte schonmal dazu sagen:
> > > was genau hindert dich daran, den test-code zu commiten und einen
> > > pull-request zu stellen?
> > > das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
> > > (wenig?) vorhandener code veraendert wird.
> >
> > Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die
> > letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die
> > Bits setzen langsam Staub an. Für mich als Contributer
> > demotivierend...
>
> ja, hangt bei mir daran, dass ich das nochmal testen wollte
> (die erste version war ja nun eindeutig kaputt ;) ),
> und nicht soviel zeit habe momentan.
> (und die dann noch mit dem lesen von -users verschwende...)
> (und ausserdem ich persoenlich composer nicht mag,
>  und nicht soviele argumente dafuer kamen...
>

Composer hat mit den Unit Tests nichts zu tun.


>  (ausser dass travis-ci das braucht)
>

und Travis auch nicht. Zumindest Travis wird dadurch einfacherm, aber das
ist hier gar nicht das Thema, oder war jedenfalls nciht meins  (aber ich
habe hier tatsächlich noch einen Travis-Patch, aber mit dem warte ich auf
a) Unit Tests und b) Composer...)


> ...
> aber wie gehabt,
> testen koennte das aber auch jeder andere mal,
> und feedback geben ob's bei ihm funktioniert!
> dafuer braucht man keine commit-rechte.
>
>
Macht wohl keiner. Aber genau daher mein zweiter Kommentar zum Composer-PR
von Robert. Selbst wenn ich teste und kommentiere habe ich wenig Lust das
alles umsonst zu machen. Insofern wäre _ein_ Kommentar von den Committern
schon nett damit wir am Ende nicht mit viel Arbeit und ohne Commit dastehen.

> Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die
> > git Notifications auch and die Entwickler-ML?
>
> hatte den satz oben gerade geschrieben, bevor ich deinen gelesen
> hatte ;)
> dass die notifications da momentan nicht hingehen solltest du sehen,
> da du ja auf der liste bist.
>
> > Im Moment bleibe ich bei meiner Einschätzung- VZ ist von
> > Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau
> > einer entsprechenden Community ist aus meiner Sicht mehr Agilität.
> >
> > vg
> > Andreas
>
> - Thorben
>

Vmtl. könnte man für die ML (falls es nix anderes gibt) einen User mit
Adresse der ML bei github anlegen der das Repo abonniert. Geht sicher auch
eleganter...

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo *,

2013/9/27 Thorben Thuermer 

> > > > > - schnellere Bearbeitung von requests
> > > ich sehe noch das problem, inwieweit aenderungen vorher
> reviewed/getestet
> > > werden/sein sollten.
> >
> > Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne
> > commit, sondern auch ohne Test- weil's einfach niemanden interessiert.
>
> das ist aber kein problem des maintainers, sondern der community.
> da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei
> mir zB., alles selbst zu testen.
>

Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer. Leider
ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne ist da/wenn
die Maintainer keine Kommentare abgeben.


> > Und um hier aktiv etwas beizutragen: ich habe immer noch einen
> > Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin-
> > die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von
> > keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen...
>
> ich wollte schonmal dazu sagen:
> was genau hindert dich daran, den test-code zu commiten und einen
> pull-request zu stellen?
> das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein
> (wenig?) vorhandener code veraendert wird.
>
>
Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die letzten
offenen Anmerkungen behoben. Seitdem ruht der Request und die Bits setzen
langsam Staub an. Für mich als Contributer demotivierend...

...



> denke nicht, siehe community-problem.
> siehe auch der naechste punkt.
> (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass
>  es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) )
>
>
Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die git
Notifications auch and die Entwickler-ML?

Im Moment bleibe ich bei meiner Einschätzung- VZ ist von Entwicklerseite
sehr schwer zugänglich. Voraussetzung für den Aufbau einer entsprechenden
Community ist aus meiner Sicht mehr Agilität.

vg
Andreas

Re: [vz-dev] Aggregationsmode "DELTA"

[Andreas Goetz]

Ich denke jetzt nochmal laut...

2013/10/28 Andreas Goetz 

> Moin,
>
> 2013/10/28 Thorben Thuermer 
>
>> ...
>>
>> > Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den
>> Stellen
>> > anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren
>> Intervallen)
>> > wieder auf Daten übergegangen wird.
>>
>> beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte
>> null drinzulassen?
>> wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in
>> welchem zeitraum die naechste aenderung stattgefunden hat,
>> und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.
>>
>
> Schon getestet- tut es leider nicht. Das Problem ist "so gross", wie Tupel
> zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x
> auf x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und
> y) auf y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von
> x/2 bis y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel
> aggegiert werden desto größer die Abweichung.
>

Das Problem ist dass wir im Moment (wenn das FT tupels=xyz übergibt) Pakete
schnüren. Seit dem entsprechenden Patch macht das die Datenbank:

$sql = 'SELECT MAX(aggregate.timestamp) AS timestamp,
SUM(aggregate.value) AS value, COUNT(aggregate.value) AS count '.
   'FROM ('.
   'SELECT timestamp, value, @row:=@row+1 AS row '.
   ' FROM data WHERE channel_id=?' . $sqlTimeFilter .
   ') AS aggregate '.
   'GROUP BY row DIV ' . $packageSize .' '.
   'ORDER BY timestamp ASC';


> In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen
> Hinweis bekommen wird dass zwischendurch die 0 "steht"  und die Daten
> ausgedünnt sind.
>
>
Was spräche denn jetzt dagegen, stattdessen äquidistante Stücke zu
schneiden, also nach timestamp DIV $packageSize zu gruppieren? und den
entsprechenden Timestamp im Select hochzuzählen? Das Ganze noch mit IFNULL
Statements ergänzt sollten wir in der Lage sein, fehlende (Null-)Werte zu
ergänzen. Performance to be tested.
Dann besteht natürlich wieder die Gefahr, dass wir zwischen zwei
Zählerwerten eine Null erfinden falls sich da kein weiterer Messwert
anfindet- Tuples darf also nicht granularer werden als Messwerte wirklich
vorliegen.

Wär hätte Lust einen Prototyp zu bauen und Performance zu testen??

vg
Andreas

Re: [vz-dev] Aggregationsmode "DELTA"

[Andreas Goetz]

Moin,

2013/10/28 Thorben Thuermer 

> ...
> > Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den Stellen
> > anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren Intervallen)
> > wieder auf Daten übergegangen wird.
>
> beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte
> null drinzulassen?
> wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in
> welchem zeitraum die naechste aenderung stattgefunden hat,
> und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.


Schon getestet- tut es leider nicht. Das Problem ist "so gross", wie Tupel
zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x
auf x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und
y) auf y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von
x/2 bis y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel
aggegiert werden desto größer die Abweichung.

In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen
Hinweis bekommen wird dass zwischendurch die 0 "steht"  und die Daten
ausgedünnt sind.

vg
Andreas

Re: [vz-dev] Aggregationsmode "DELTA"

[Andreas Goetz]

Hallo,

die Sache hat leider einen Haken.

2013/10/27 

> ...
>
> ** **
>
> Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses
> Delta zum vorhergehenden Wert überschreitet.
>
> Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die
> nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen
> Wert des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert
> als gelöscht markiert. So wird der latest-Wert und alle relevanten
> Änderungen eingetragen. Da das Delta prozentual vom Istwert berechnet wird,
> werden bei kleinen Werten auch kleine Änderungen erfasst.
> ...
>
> ** **
>
> Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne
> nennenswerte Darstellungsverluste.
>

Das kann ich leider nicht bestätigen. Bei meinen Experimenten habe
aufeinander folgende 0- Werte in der DB gelöscht (da ja PV nachts wenig
produziert) was die Datenmenge für den entsprechenden Kanal mal schlapp
halbiert hat. Leider kommt es dazu zu erheblichen Darstellungsproblemen
beim Übergang da die Middleware für's Frontend die Daten aggregiert- und
zwar portionsweise je Datenbanktupel und nicht nach gleich großen
Zeitscheiben.
Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den Stellen
anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren Intervallen)
wieder auf Daten übergegangen wird.

Mir ist dafür bisher keine Lösung eingefallen- falls es da eine gibt könnte
man neben Änderungen im Logger auch ein späteres Aufräumen der DB auf
diesem Wege ohne Daten- und Darstellungsverlust implementieren.

vg
Andreas

Re: [vz-dev] Auslagern von Initialisierungscode?

[Andreas Goetz]

Hallo Justin & Thorben, hallo *,

2013/10/20 Thorben Thuermer 

> On Sun, 20 Oct 2013 14:02:04 +0200 Andreas Goetz 
> wrote:
> > Hallo Justin,
>
> warum nicht auf vz-dev?
>

Behoben- hiermit an die größere Runde.


> > im git gibt es mehrere Dateien die alle eine Initialisierung der Umgebung
> > brauchen (Pfade und Class Loaders):
> >
> > - middleware.php
> > - misc/tools/doctrine.php
> > ...
> > Spricht etwas dagegen, die Initialisierung in eine gemeinsam genutzte
> Datei
> > auszulagern? Ich dachte an sowas wie "bootstrap.php", vielleicht im lib
> > Verzeichnis, wollte vor einem PR aber gerne Eure Meinung abholen.
>
> absolut vernuenftig.
> wuerd' mir eben den code anschauen, was da die redundanten teile sind,
> aber leider wenig zeit.
>
> > Gibts darüber hinaus Interesse an Unterstützung für composer.json?
>
> sag' doch nochmal was die vorteile waehren...
>

Gute Frage. Ich bin kein Experte, habe im Rahmen der Unit Tests aber gute
Erfahrungen damit gemacht. So war die Installation von Doctrine mit Hilfe
der folgenden composer.json in wenigen Sekunden erledigt:

{
"config": {
"vendor-dir": "lib/vendor"
},
"require": {
"doctrine/orm": "2.4.*"
},
"autoload": {
"psr-0": {
"": "src/"
}
}
}

und dann

> composer install

Ich habe "Continuous Integration" als neues Feature auf der Liste, also die
Überwachung der Builds mittels Unit Tests nach jedem Checkin:
https://travis-ci.org/andig/volkszaehler.org/builds
Dafür müssen bei Travis auch die Abhängigkeiten installiert werden (anders
laufen ja die Tests nicht)- die einfachste Lösung dafür die ich gefunden
habe war composer, es sind aber sicher auch andere denkbar.

Aber zurück zur Frage- wenn wir den Initialisierungscode in einer Datei
zusammenschieben- wo soll er hin? Aktuell liegt er bei mir in
lib/bootstrap.php neben Router.php, sieht dort aber nicht wirklich schön
aus, schon wegen der Gross/Kleinschreibung.

Wäre die Datei neben middleware.php vielleicht besser aufgehoben? misc/
scheint keine gute Idee zu sein?

Freue mich auf Eure Vorschläge,
Andreas

Re: [vz-dev] Pfad von doctrine / doctrine Version

[Andreas Goetz]

Moin *,

On 14.10.2013 08:51, jus...@justinotherguy.org wrote:

Hi Rainer,

Am 13.10.2013 um 16:47 schrieb Rainer Gauweiler:


Wir sind darüber gestolpert, dass doctrine manchmal durch einen Symlink 
eingebunden wird, manchmal durch eine Angabe in der Konfig-Datei.

Der Installer tut das eine, die Anleitung zur manuellen Installation beschreibt 
das andere.

Gibt es was, was man bevorzugen sollte?

ich persönlich hab mich schon ein paar Mal über die (fehlenden) Links geärgert; 
mir gefällt die Idee mit dem direkten Verweis auf das lokale Verzeichnis in der 
Config sehr gut.



Und spricht etwas dagegen, das debian-Paket zu verwenden? Dann hätte man auch 
aktuelle Updates.

Zumindest in der Theorie:

$ cat /etc/debian_version
7.2
$ dpkg -l | grep doctrine
ii  doctrine 1.2.4-1all 
 Tool for object-relational mapping in PHP

Ist eben Debian - wir verwenden doctrine in Version 2; ansonsten wäre ich mehr 
als dafür.


Gruss, J.
Mit aktuellen Doctrine Versionen wird das ganze noch schlimmer das die 
GIT Repositories jetzt aufgeteilt sind. Einfacher wäre die Installation 
via composer. Wenn Interesse besteht kann ich einen Patch bereitstellen, 
die Unit Tests laufen alle auch mit Doctrine 2.4, einem Upgrade sollte 
also nichts im Weg stehen.


vg
Andreas

[vz-dev] HUGE performance improvement for grouped queries

[Andreas Goetz]

Hallo Zusammen!

Um der Performance meiner VZ Installation auf dem Raspi etwas nachzuhelfen
habe ich Aggregation von Daten als neues Feature zum VZ hinzugefügt.
Anstatt wie bei vzcompress2 Daten zu löschen werden diese in einer
separaten Tabelle aggregiert- in der aktuellen Version auf Tagesebene.

Wenn die MW jetzt Abfragen nach aggregierten Daten stellt, wie z.B.
from=1.1.2000 to=now group=month dann werden die SQL statements so
umgebaut, dass die Daten aus der Agrgegationstabelle kommen statt aus der
Datentabelle. Da hier _deutlich_ weniger Daten liegen gehts natürlich
schneller.

Bisher nicht implementiert ist ein automatisches Tuning eingehender
Anfragen. Wenn z.B. das Frontend obenstehende Anfrage mit tuples=200
ausführt, wird es ohne vzcompress immer noch sehr lange dauern. Denkbar
wäre eine Automatik einzubauen die je nach "Aggressivität" eine Gruppierung
nach Tag oder Stunde hinzuschaltet.

Added data aggregation:
1. create aggregate table using misc/sql/aggregation.sql
2. run initial aggregation using misc/sql/aggregation.sql
3. set $config['aggregate'] = true in etc/volkszaehler.conf.php
4. setup CRON to run delta aggregation using misc/sql/aggregation.sql

https://github.com/andig/volkszaehler.org/tree/aggregate

Jetzt würde ich mich über Feedback und vor allem Tests freuen!

Gruss,
Andreas

[vz-dev] Unittests für die Middleware

[Andreas Goetz]

Hallo Zusammen,

unter https://github.com/andig/volkszaehler.org/tree/unittest/test steht
ein erster Satz Unit Tests bereit. Getestet werden können damit v.a. die
verschiedenen Meter (z.B. DataMeterTest).
Das Ganze ist als work in progress zu betrachten, ängst nicht alle Tests
sind imlementiert und der Code ist sicher auch nicht so elegant wie die MW
selbst.
Aktuell baue ich weitere Tests auf um eine Datenaggregation zur
Performanceoptimierung einzubauen.

Kommentare bitte direkt mittels git issues.

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo Torben,


2013/9/27 Thorben Thuermer 

> On Tue, 24 Sep 2013 14:35:02 +0200
> Patrik Karisch  wrote:
> > Bis jetzt hat sich weder Justin noch Steffen dazu geäußert.
>
> damit da mal was zu gesagt wird:
> justin ist der initiator des projekts,
> eine antwort von ihm fehlt hier irgendwie,
> er sagte mir er hat leider gerade keine zeit dafuer/anderes zu tun.
> steffen ist schon laenger nichtmehr gross im projekt aktiv.
>
> > Am 24. September 2013 14:07 schrieb Andreas Goetz :
> > > Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
> > > einbringen kann und das sich vielleicht generell etwas
> interaktionsfreudiger
> > > gitb als die aktuelle Struktur:...
>


> wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist,
> wuerde ich vorschlagen justin zu kontaktieren.
>
> Dh. außerhalb dieser Liste per Mail?


> > > - schnellere Bearbeitung von requests
>
> ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet
> werden/sein sollten.
>

Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne
commit, sondern auch ohne Test- weil's einfach niemanden interessiert.
Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den
eingeführten Fehler abzumildern.

ersichtlich ist worum es ueberhaupt geht (commit messages und kommentare
> helfen!),
> bin ich auch erstmal skeptisch.
>
> wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist,
> als der eine oder andere neue bug.
> (ein schoenes beispiel war, wie justin zuletzt relativ hektisch
>

Du meinst nach 6 Wochen ist Hektik aufgekommen ;?


>  diesen germerged hatte:
> https://github.com/volkszaehler/volkszaehler.org/pull/47
>  und da prompt ein bug drin war, der die api unbrauchbar gemacht hat
>
> http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html
>  und der bei einer kurzen review (justin ist kein programmierer),
>  oder einem test woanders als beim autor, aufgefallen waehre.
>

Korrekt- hat aber keine gemacht :/

 (was aber dann ja auch schnell behoben war!)
>  https://github.com/volkszaehler/volkszaehler.org/pull/49 )
>

So isses. Und um hier aktiv etwas beizutragen: ich habe immer noch einen
Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin-
die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von
keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen...

und das problem, dass die aenderungen schnell unuebersichtlich werden,
> und man sich schwerer tut grosse pull requests zu mergen,
> als kleinere fixes fuer einfache probleme.
>

Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle
meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal
nicht...


> (siehe den herrn hirsch, der herumlurkt und kleine aber wichtige commits
>  blitzartig merged ;) )
> ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren,
> zB hier (oder in den github issues?) und zu einem konsens zu kommen.
>

Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun. Oder
doch?

es gab es ja zB den thread
> "Feedback benötigt: vzlogger / aggregation / random meter / sml-pull /
> s0-meter"
> ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 )
> der leider recht schleppend verlief.
>
>
> die letzte meldung von justin dazu war...
> http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html
> On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy <
> jus...@justinotherguy.org> wrote:
> > korrekt (leider). Die Patches lassen sich nicht "g'schwind(TM)" mergen.
> > Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit).
> > Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-)
>
> darauf hatte sich niemand gemeldet...
> ich werde mir das sonst mal anschauen.
>
>
> > > - Nutzung der github Issues
>
> habe anscheinend nicht die rechte das einzustellen...
> werde justin mal anhauen, wenn er nicht selber mitliest.
>
>
> - Thorben
>

Logger ist leider nicht mein Thema :(

vg
Andreas

Re: [vz-dev] Entitydefinition: Wo sind die Einheiten?

[Andreas Goetz]

Wieder was gelernt- das reicht tatsächlich, also nix neues benötigt, danke!


2013/9/27 Thorben Thuermer 

> On Tue, 24 Sep 2013 18:04:32 +0200
> Andreas Goetz  wrote:
> > ich beschäftige mich jetzt seit einiger Zeit mit der Visualisierung von
> > VZ-Daten (Stichwort VZmon App).
> >
> > Jetzt bin ich darüber gestolpert, dass wir zwar allerlei
> > Präsentationsparameter (steps, color) in den Entities speicher, bzgl. der
> > physischen Eigenschaften aber ziemlich blank sind, u.a. fehlen hier ganz
> > banal die Einheiten.
>
> soweit ich das sehe, stehen die einheiten hier (als "unit"):
>
> https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Definition/EntityDefinition.json
>
> das sind dann wohl die statischen eigenschaften des entity-typs,
> und in der datenbank stehen nur die speziellen der jeweiligen instanz?
>
> > Da ich mich mit den Doctrine Entity Definitionen nicht gut genug auskenne
> > um dafür eine Erweiterung zu bauen bin ich auf Hilfe angewiesen.
> > Gibts dafür Interesse/ Unterstützung?
>
> ansonsten auch keine weitere erfahrung damit.
>
> > vg
> > Andreas
>
> - Thorben
>

Re: [vz-dev] JSONP exception handling

[Andreas Goetz]

Moin,

das ging tatsächlich verblüffend einfach- deshalb hab ich mir die Freiheit
genommen die 5 geänderten Teilen in einen Pullrequest zu packen:

The following changes since commit 1670af32d3986887f754ad785628b003243cf3cf:

  Fix JSONP exception handling and add CORS support
  Also fixed an artifact in AggregatorInterpreter (2013-09-26 20:42:29
+0200)

are available in the git repository at:

  htto://github.com/volkszaehler/volkszaehler.org

for you to fetch changes up to 1670af32d3986887f754ad785628b003243cf3cf:

  Fix JSONP exception handling and add CORS support Also fixed an artifact
in AggregatorInterpreter (2013-09-26 20:42:29 +0200)

Wie siehts denn mit VZ_VERSION aus- wollen wir auf 0.3 gehen? Damit könnte
ich das Dokuupdate im Wiki sauber einem Releasestand zuordnen?

vg
Andreas



2013/9/26 Thorben Thuermer 

> On Thu, 26 Sep 2013 16:26:19 +0200
> Patrik Karisch  wrote:
> > Eine gnereller Responsecode von 200 widerspricht aber grob
> > REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig,
> > dann benötigt es kein JSONP mehr.
>
> OK,
> wir bekommen dann also zwei patches,
> einen von Andreas um bei jsonp fehlermeldungen als 200/OK auszuliefern,
> einen von Patrick fuer das viel elegantere CORS;
> desweiteren bringt Patrick allen unseren (l)usern bei,
> ihren webserver entsprechend zu konfigurieren, und kuemmert sich um
> alle anfallenden support-anfragen diesbezueglich.
>
> - Thorben
>
> > Am 26.09.2013 13:33 schrieb "Andreas Goetz" :
> >
> > > Hallo Zusammen,
> > >
> > > wenn in der MW eine Exception auftritt wird diese vom JSON view an
> > > den Aufrufer zurückgesandt (z.B. "invalid uuid").
> > > Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400
> > > das JSONP Skript von remote gar nicht erst ausgeführt wird.
> > >
> > > Einen RFC für JSONP konnte ich nicht finden, daher meine Frage
> > > bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht
> > > _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes?
> > >
> > > Das Frontend wäre von dieser Änderung nicht betroffen- hier werden
> > > Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code
> > > gesehen habe.
> > >
> > > +1 für den Patch von mir- was meint Ihr?
> > >
> > > vg
> > > Andreas
> > >
> > > PS.: ich würde dann auch gerne- zusammen mit den sonstigen
> > > Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende
> > > Doku im Wiki anpassen.
> > >
> > >
>
>

Re: [vz-dev] JSONP exception handling

[Andreas Goetz]

Hallo Patrick,

das kann alles sein. Da wir Clients mit JSON(P) haben würde ich jetzt aber
gerne erstmal das Problem lösen. CORS zusätzlich zu implementieren ist eine
nette Aufgabe die ich ebenfalls übernehmen würde.

vg
Andreas



2013/9/26 Patrik Karisch 

> Servus,
>
> Eine gnereller Responsecode von 200 widerspricht aber grob
> REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann
> benötigt es kein JSONP mehr.
> Am 26.09.2013 13:33 schrieb "Andreas Goetz" :
>
> Hallo Zusammen,
>>
>> wenn in der MW eine Exception auftritt wird diese vom JSON view an den
>> Aufrufer zurückgesandt (z.B. "invalid uuid").
>> Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das
>> JSONP Skript von remote gar nicht erst ausgeführt wird.
>>
>> Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich
>> einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK
>> zurückgeben statt 400 oder sonstiger Codes?
>>
>> Das Frontend wäre von dieser Änderung nicht betroffen- hier werden
>> Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen
>> habe.
>>
>> +1 für den Patch von mir- was meint Ihr?
>>
>> vg
>> Andreas
>>
>> PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen-
>> die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.
>>
>>

[vz-dev] JSONP exception handling

[Andreas Goetz]

Hallo Zusammen,

wenn in der MW eine Exception auftritt wird diese vom JSON view an den
Aufrufer zurückgesandt (z.B. "invalid uuid").
Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das JSONP
Skript von remote gar nicht erst ausgeführt wird.

Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich
einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK
zurückgeben statt 400 oder sonstiger Codes?

Das Frontend wäre von dieser Änderung nicht betroffen- hier werden
Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen
habe.

+1 für den Patch von mir- was meint Ihr?

vg
Andreas

PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die
MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.

[vz-dev] Entitydefinition: Wo sind die Einheiten?

[Andreas Goetz]

Hallo Zusammen,

ich beschäftige mich jetzt seit einiger Zeit mit der Visualisierung von
VZ-Daten (Stichwort VZmon App).

Jetzt bin ich darüber gestolpert, dass wir zwar allerlei
Präsentationsparameter (steps, color) in den Entities speicher, bzgl. der
physischen Eigenschaften aber ziemlich blank sind, u.a. fehlen hier ganz
banal die Einheiten.

Da ich mich mit den Doctrine Entity Definitionen nicht gut genug auskenne
um dafür eine Erweiterung zu bauen bin ich auf Hilfe angewiesen.

Gibts dafür Interesse/ Unterstützung?

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo,

2013/9/24 W3ll Schmidt 

> Am 24. September 2013 14:35 schrieb Patrik Karisch <
> patrik.kari...@gmail.com>:
>
>  geäußert. Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum
>> seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^
>>
>> LG Patrik
>>
>
> Ähmm, ehrlich?
>
> Naja- vielleicht etwas sehr unglücklich formuliert- von "schulden" kann
man sicher nicht sprechen.

Aber es ist aus meiner Erfahrung schon so, dass VZ sich relativ unnahbar
darstellt. Das sage ich trotz eigenem Git Account und seit mehreren Jahren
aktiv betriebenen Open Source Projekten.

Jetzt scheint es ein paar neue Leute zu geben die sich ebenfalls engagieren
möchten. Die Frage ist in welchem Rahmen und mit welchen Rechten- oder ob
überhaupt Interesse besteht.

Die eher verhaltene Diskussion zeigt vielleicht auch, dass die Maintainer
mit dem Stand von VZ eigentlich ganz zufrieden sind und tatsächlich gar
keinen großen Änderungsbedarf sehen?

vg
Andreas

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo Zusammen,

ich habe mal auf Basis von
https://github.com/frasermac/xively-visualizer/eine kleine
Visualisierung für alle öffentlichen Kanäle des VZ
zusammengedübelt.
Wenn man das auf demo.volkszaehler.org zeigen lässt hätten wir damit ein
schönes Frontend mit deutlich weniger Code (und ein paar weniger
Fähigkeiten) als das "richtige" Frontend. Das könnte eine schöne Basis für
eigene Weiterentwicklungen der Community sein.

Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas
einbringen kann und das sich vielleicht generell etwas
interaktionsfreudiger gitb als die aktuelle Struktur:

- mehr Committer
- mehr Unterrepositories die eine Zusammenarbeit erlauben
- schnellere Bearbeitung von requests
- Nutzung der github Issues

Wie siehts aus?

vg
Andreas



2013/9/24 Patrik Karisch 

> Hi
>
> Am 23. September 2013 20:15 schrieb W3ll Schmidt :
> > Haste mal überflogen?
> >
> > http://sqlite.org/speed.html
>
> Das sqlite generell schneller ist, ist sowieso klar. Besonders auf dem
> RPi dürften die Faktoren noch größer sein, da dieses nicht für MySQL
> geeignet ist. Mir ging es eher darum, ob wirklich Doctrine
> signifikante Performanceeinbußen hervorruft, oder ob es einfach nur
> der MySQL ist.
>
> LG Patrik
>

Re: [vz-dev] Nach update auf git Version können keine Kanäle hinzugefügt werden.

[Andreas Goetz]

Gefunden:

in lib/Controller/DataController Zeile 84:

ändere
if ($json['data']) {
in
if (isset($json['data'])) {

Ich schiebe einen Patch nach.

vg
Andreas



2013/9/18 Andreas Götz 

> Den Fehler dürfte ich eingebaut haben- autsch! Schaus mir nachher an.
>
> Viele Grüße,
> Andreas
>
> Am 18.09.2013 um 06:05 schrieb Sven peitz :
>
> > Am 18.09.2013 00:25, schrieb Thorben Thuermer:
> >> On Tue, 17 Sep 2013 23:56:05 +0200 Sven peitz 
> wrote:
> >>> Am 17.09.2013 23:18, schrieb Sven peitz:
>   gerade mal ein Update gemacht.
>  Jetzt funktioniert zwar die Abfrage from =now wie sie soll, aber ich
>  kann keine Kanäle mehr anlegen im GUI/webinterface
>  Der Button "Kanal Hinzufügen" lässt sich nicht anklicken und alle
>  vorher gespeicherten Kanäle zeigt er nicht an.
> >>> OK das Problem liegt am Browser, der muss unsichere Scripte zulassen..
> >>> dann kann man Kanäle anlegen.
> >> was auch immer "unsichere scripte" sind?
> >> vlt. lag es auch an alten scripte im cache und ein gruendlicher reload
> hilft?
> > Das mit dem reload(restart) könnte der Schlüssel gewesen sein ;-)
> >>
> >>> Was aber komisch ist, vzlogger produziert jetzt einen Fehler
> >>> POST /middleware.php/data/*snip*.json HTTP/1.1" 400 302 "-"
> >>> "vzlogger/0.3.3 (libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25
> >>> libssh2/1.4.2 librtmp/2.3)"
> >>>
> >>> Andere per curl gesendete Daten laufen aber
> >>> POST /middleware.php/data/*snip*.json HTTP/1.1" 200 192 "-" "-"
> >>>
> >>> Woran mag das liegen?
> >> ich vermute die erklaerung im status-text oder body der 404-antwort.
> >> wenn es mit curl funktioniert, kommt der 404 wohl nicht von apache,
> >> sondern vom php-script.
> >>
> >> im zweifelsfall vzlogger unter strace -s 999 laufen lassen,
> >> oder die requests mit wireshark/tcpflow/tcpdump mitschneiden...
> >>
> >>> Gruß
> >>> Sven
> >> - Thorben
> > vzlogger sammelt in der queue und nach dem abschicken kommt es zu
> folgendem Fehler
> > Im Log von vzlogger findet sich folgendes:
> >
> > Sep 18 05:58:17][chn2] CURL Error from middleware: 'ErrorException':
> 'Undefined index:  data'
> > [Sep 18 05:58:17][chn2] Waiting 30 secs for next request due to previous
> failure
> > [Sep 18 05:58:17][chn0] CURL Error from middleware: 'ErrorException':
> 'Undefined index:  data'
> > [Sep 18 05:58:17][chn0] Waiting 30 secs for next request due to previous
> failure
> > [Sep 18 05:58:17][chn1] CURL Error from middleware: 'ErrorException':
> 'Undefined index:  data'
> > [Sep 18 05:58:17][chn1] Waiting 30 secs for next request due to previous
> failure
> > [Sep 18 05:58:19][mtr0] Updating interval to 2
> > [Sep 18 05:58:19][chn0] Adding reading to queue (value=3422328.50
> ts=1379476699.086)
> > [Sep 18 05:58:19][chn0] Buffer dump (size=1 keep=300): {3422328.5000,}
> >
> > Gruß
> > Sven
> >
> >
> >
>

Re: [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 

>  Am 16.09.2013 20:45, schrieb Andreas Goetz:
>
> Hallo Rainer,
>
> 2013/9/16 Rainer Gauweiler 
>
>> Hallo zusammen,
>>
>> Am 16.09.2013 16:41, schrieb Andreas Goetz:
>>
>>> Hallo Thorben,
>>>
>>> 2013/9/16 Thorben Thuermer >> r...@constancy.org>>
>>>
>>>
>>> On Mon, 16 Sep 2013 14:01:31 +0200
>>>   Jakob Hirsch mailto:j...@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= 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
>
>
>

Re: [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 

>  Am 16.09.2013 20:45, schrieb Andreas Goetz:
>
> Hallo Rainer,
>
> 2013/9/16 Rainer Gauweiler 
>
>> Hallo zusammen,
>>
>> Am 16.09.2013 16:41, schrieb Andreas Goetz:
>>
>>> Hallo Thorben,
>>>
>>> 2013/9/16 Thorben Thuermer >> r...@constancy.org>>
>>>
>>>
>>> On Mon, 16 Sep 2013 14:01:31 +0200
>>>   Jakob Hirsch mailto:j...@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= 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
>
>
>

Re: [vz-dev] VZ Codebasis, Unit-Tests, und so

[Andreas Goetz]

Hallo Zusammen!

Nachdem ich wirklich viel Zeit in den Untiefen der MW verbracht habe und
mittlerweile auch ein paar Patches bis ins git steht es mir vielleicht zu
mich zu dem Thema auch mal zu äußern- meine 2cents, auch wenn einige Fragen
sicher reine Geschmackssache nennt.

2013/9/17 Patrik Karisch 

> Am 17. September 2013 14:33 schrieb Thorben Thuermer :
> >
> > schon doctrine war schon immer overkill fuer das projekt...
>

Zunächst mal muß ich sagen, dass ich die Codebasis wirklich genial finde.
Die Struktur aus Controllern, Interpretern und Views ist auf den ersten
Blick zwar nicht ganz offensichtlich, funktioniert in der Praxis aber
wunderbar.

Ok, das ist jetzt wirklich Ansichtssache. Aus Programmierersicht
> nicht, denn mit puren SQL Statements (ob prepared oder nicht), kann
> ganz schnell ungut werden und führt zu Spaqhetticode. Ein ORM macht
> das OOP-Handling um einiges einfacher. Was die Anwendersicht betrifft,
> ist Doctrine nicht so inperformant. Vorrausgesetzt sind natürlich auch
> die richtigen Indizes.


Das sehe ich etwas anders. Doctrine hat gerade auf langsamen Plattformen
wie dem RasPi einige Probleme- so war es mir nicht möglich trotz Query
Caching wirklich performant zu bekommen.

Ich bin der Meinung Frameworks und passende
> Bibliotheken sind nie ein Overkill. Gut, aber das ist nur meine
> Meinung. Man sollte auch Bedenken, ein Framework bietet die
> Möglichkeit, dass sich das Projekt in größe Konzepte weiter entwickeln
> kann. Mit rein eigenen Code wird das schwieriger. Einarbeitungszeit
> für neue Entwickler ist dann immer recht hoch.
>

S.o.- der Code funktioniert und war für mich gut erweiterbar. Er ist aber
(dank Doctrine) auch nicht rasend schnell- einige Overheads kann mein
letzter Commit mildern.

Dazu kommt, dass die MW jetzt sehr lange stabil war- soweit ich sehen kann
gibt es sehr wenige Änderungen (und damit wohl auch Anforderungen).


> Ich finde ja eher MySQL für die Art von Daten ineffizient.
>

Solche Kommentare finde ich besonders schwer zu greifen. Es ist halt eine
Datenbank und relationale DBs eignen sich i.A. ganz gut für "die Art von
Daten". Aber dafür gibts ja das Potential weitere DBs zu unterstützen.


> > der bugtracker ist ohnehin tot - keine aktivitaet seit 2012-03...
>
> ja, da wäre es mal an der Zeit, einfach mal die Issues auf GitHub zu
> aktivieren. Ansonsten kann es auch einfach sein, das hier noch die dev
> Community fehlt? ;p
>

+1 für Issues im GitHub, idealerweile mit Mail an die Liste. Habe mit
ebenfalls schwer getan ich mit der Mailingliste anzufreunden.

2013/9/16 Justin Otherguy 

> Hi Patrik,
>
> Am 16.09.2013 um 21:07 schrieb Patrik Karisch:
>
> >> Anders formuliert:
> >> bitte testen und beschweren, wenn etwas kaputt ist.
> > Für das wären Unit-Tests und ein CI-Server gedacht ^^ -> travis-ci.org
> >
> > Zumindestens für die großteil einer Applikation.
> super Idee.
>
> Du hast den Job! ;-)
>
> Im Ernst: wenn du uns helfen kannst, das an den Start zu bringen - mich
> würd's freuen. Und ich wette: nicht nur mich :-)
>

Ich habe bereits einen Satz Unit Tests für diverse Meter- nicht schön aber
funktionieren. Ohne dieses Hilfsmittel hätte ich die Änderungen am Code
niemals machen können und habe damit Fehler in meinem, aber auch Unschärfen
in der Codebasis  entdeckt.
Entwickelt mit PHPUnit- bei Interesse bitte melden!

In diesem Sinne: ich würde mich freuen wenn etwas Schwung in die MW käme.
Primäres Ziel aus meiner Sicht wäre allerdings nicht Funktionalität,
sondern Performance und dazu Unittests als Basis für weitere Optimierungen.
Um ohne Tests arbeiten zu können ist die MW bereits deutlich zu komplex.

In diesem Sinne- Viel Spass beim Basteln!

vg
Andreas

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Andreas Goetz]

Hallo Rainer,

2013/9/16 Rainer Gauweiler 

> Hallo zusammen,
>
> Am 16.09.2013 16:41, schrieb Andreas Goetz:
>
>> Hallo Thorben,
>>
>> 2013/9/16 Thorben Thuermer mailto:r...@constancy.org
>> >>
>>
>>
>> On Mon, 16 Sep 2013 14:01:31 +0200
>> Jakob Hirsch mailto:j...@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= 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

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Andreas Goetz]

Hallo Thorben,

2013/9/16 Thorben Thuermer 

> On Mon, 16 Sep 2013 14:01:31 +0200
> Jakob Hirsch  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= 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.

vg
Andreas

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Andreas Goetz]

Hallo Sven,

sowas in der Form sollte helfen:

http://host/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3a387429e.json?from=now

vg
Andreas


2013/9/15 Sven peitz 

>  Hallo,
>
> leider kann ich derzeit nicht weiter testen, weil mein Provider den
> Zugriff wegen zu hoher SQL Last gesperrt hat.  ;-(
> [X] MySQL-Last (Wartezeit auf Festplattenzugriff)
>
> [X] MySQL-Last lesend (SELECT-Statements)
>
> [X] Kontinuierlich hohe Last
>
> Also sind die 6 Sekunden verursacht durch Auslastung des Servers.
> Dem Vorschlag kann ich jetzt nicht folgen. SQL ist nicht mein täglich Brot
> ;-)
>
> Select value where channel order by id desc limit 1
>
>
>
> Aber den Vorschlag über die Middleware zu gehen würde ich gerne aufgreifen
> wenn ich wüsste wie.
>
> Eigentlich brauche ich ja nur den zuletzt in der Datenbank eingetragenen
> Wert zur ID.
> Ich muss jetzt aber erst mal warten bis der Zugriff wieder frei ist.
>
> Gruß
> Sven
>
> Am 14.09.2013 11:40, schrieb Thorben Thuermer:
>
> On Sat, 14 Sep 2013 11:07:20 +0200
> Sven peitz   wrote:
>
>  für mein neues Verbrauchs oder Vergleichsanzeige Projekt der aktuellen
> PV Einspeisung und Bezug vom EVU frage ich in einem PHP script die
> Volkszähler Datenbank ab.
>
>  [...]
>
>  $result1=mysql_query("SELECT value FROM data WHERE id = (select max(id)
> FROM data WHERE channel_id LIKE  '14')");
>
>  auch zu beachten,
> was genau in data.value steht ist vom channel-type abhaengig...
> diese loesung funktioniert nur, wenn leistungswerte geloggt werden.
>
>
>  Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man
> dieses beschleunigen kann?
>
>  die anfrage ohne subquery formulieren?
> (subqueries sind fuer nicht sql-er zwar oft intuitiver,
>  aber meist nicht effizient.)
>
> select value where channel order by id desc limit 1
>
>
>  Gruß
> Sven
>
>  - Thorben
>
>
>

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Andreas Goetz]

Ich hatte ähnliche Probleme- Grund dabei war allerdings 1s Connect Time für
MySQL. Warum gehst Du für die Abfragen eigentlich nicht über die
Middleware? Dann klappts auch für alle Sensortypen!

vg
Andreas


2013/9/14 Florian Knodt 

> Auch kann es helfen ein explain vor den SQL-Befehl zu setzen und sich die
> Analyse anzusehen - da sieht man recht schnell ob Teile ohne Index
> ablaufen, was meist in langsamen Abfragen endet.
> --
> Mit freundlichen Grüßen  ||  Sincerely yours
> Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
> www.adlerweb.info · www.56648.de · @adlerweb

[vz-dev] Middleware Erweiterung: add tuples to multiple channels with JSON POST

[Andreas Goetz]

The following changes since commit b111cfa2d2d3e34203fd61cd470d8685c3991d26:

  Added capability to add multiple tuples to multiple channels via JSON
post to data context (2013-09-07 14:08:42 +0200)

are available in the git repository at:

  htto://github.com/volkszaehler/volkszaehler.org

for you to fetch changes up to b111cfa2d2d3e34203fd61cd470d8685c3991d26:

  Added capability to add multiple tuples to multiple channels via JSON
post to data context (2013-09-07 14:08:42 +0200)

[vz-dev] Fwd: Neues Projekt & Ferrariszählerkopf

[Andreas Goetz]

Hallo Thomas,


2013/8/21 Thomas Gauweiler 

> Hallo Andreas,
>
> > FAST scheint eine sehr spannende Alternative zu sein- was kosten denn
> die Dinger?
>
> Etwa 100 Euro. Evtl. + MwSt, weiss ich grade nicht genau.
>
> Hallo Franz,
>
> >> http://www.fastforward.ag
> >> Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von
> Udo geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern
> wertet das Zählwerk aus.
>
> Welche Variante hast Du genommen? D.h. mit welchem Interface? Ich habe
> einen mit TTL und weiss mich nicht so recht, wie ich ihn anschliesse.
>
Ich habe keinen von Udo sondern selbstgelötet und an GPIO angeschlossen,
auslesen via Python skript das dann in eine VZ-Datenbank schreibt.

> Für Gas halte ich ihn zu teuer.
> Da tut es auch ein S0-Clip (16 Euro) mit Rs 232 Adapter.
>
S0-Clip auf einen Gas-Rollenzähler? Was meinst Du damit?

>  Aber ich werde das Auge auch mit dem Hauptwasserzähler probieren.
>
Da gehen ja noch weniger Euros drüber- sprechen wir wirklich über das
Gleiche?

> Gruss
> __
> /homas
>
vg
Andreas

Re: [vz-dev] Neues Projekt & Ferrariszählerkopf

[Andreas Goetz]

Hallo Thomas,


2013/8/21 Thomas Gauweiler 

> Hallo Andreas,
>
> > FAST scheint eine sehr spannende Alternative zu sein- was kosten denn
> die Dinger?
>
> Etwa 100 Euro. Evtl. + MwSt, weiss ich grade nicht genau.
>
> Hallo Franz,
>
> >> http://www.fastforward.ag
> >> Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von
> Udo geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern
> wertet das Zählwerk aus.
>
> Welche Variante hast Du genommen? D.h. mit welchem Interface? Ich habe
> einen mit TTL und weiss mich nicht so recht, wie ich ihn anschliesse.
>
Ich habe keinen von Udo sondern selbstgelötet und an GPIO angeschlossen,
auslesen via Python skript das dann in eine VZ-Datenbank schreibt.

> Für Gas halte ich ihn zu teuer.
> Da tut es auch ein S0-Clip (16 Euro) mit Rs 232 Adapter.
>
S0-Clip auf einen Gas-Rollenzähler? Was meinst Du damit?

> Aber ich werde das Auge auch mit dem Hauptwasserzähler probieren.
>
Da gehen ja noch weniger Euros drüber- sprechen wir wirklich über das
Gleiche?

> Gruss
> __
> /homas
>
vg
Andreas

Re: [vz-dev] Neues Projekt & Ferrariszählerkopf

[Andreas Goetz]

PS.: es lohnt sich auch hier querzulesen:
http://www.photovoltaikforum.com/volkszaehler-org-f131/welcher-ir-schreib-lesekopf-und-woher-zu-beziehen-t92007.html


2013/8/21 Andreas Goetz 

>
> Hallo Zusammen,
>
> ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus-
> ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann
> ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank
> Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich
> mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi +
> Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und
> dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen
> zu können. Im VZ landen die Daten mittels eigenen Skriptes.
> FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die
> Dinger?
>
> vg
> Andreas
>
>
>
> 2013/8/21 Franz Datzer 
>
>> Servus Jens,
>>
>> auf wiki.volkszaehler.org bist Du sicher schon über diese Seite
>> http://wiki.volkszaehler.org/**hardware/controllers/**
>> ferrariszaehler_lesekopf<http://wiki.volkszaehler.org/hardware/controllers/ferrariszaehler_lesekopf>
>> gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran.
>>
>> Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese
>> aktuell:
>> http://www.fastforward.ag
>> Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo
>> geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet
>> das Zählwerk aus.
>> Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es.
>> Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem
>> raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script.
>>
>> Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit
>> bin ich aber noch nicht.
>>
>> Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du
>> auf jeden Fall.
>>
>> Gruß
>>
>> Franz
>>
>>
>> Jens Schmelkus schrieb:
>>
>>  Hallo Zusammen,
>>>
>>> Mein Name ist Jens Schmelkus und ich
>>> studiere in München Maschinenbau.
>>>
>>> Vor kurzem bin ich auf die Volkszaehler-page gestoßen
>>> und habe seitdem ein neues Projekt. :)
>>>
>>> Ich habe die Technischen Möglichkeiten Bauteile und
>>> Platinen zu Ätzen, Löten,Fräsen etc.
>>>
>>> Mein Ziel ist es unser Haus mit einem Logger für
>>> je Wasser, Gas und Strom auszustatten und an meinen
>>> Linux- Bladeserver anzuschließen.
>>>
>>> Der Stromzähler ist noch ein Antiker Ferraris-Zähler.
>>>
>>> Daher meine Frage.
>>> Wie steht es um die Entwicklung des Ferrariszählerkopfes ?
>>>
>>> Gibt es schon Target Dateien oder Schaltpläne
>>> die ich ausprobieren könnte ?
>>>
>>> Dankeschön schonmal.
>>>
>>> Mit freundlichem Gruß
>>>
>>> Jens
>>>
>>>
>>>
>>>
>>>
>>>
>
>

[vz-dev] Fwd: Neues Projekt & Ferrariszählerkopf

[Andreas Goetz]

Hallo Zusammen,

ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus-
ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann
ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank
Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich
mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi +
Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und
dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen
zu können. Im VZ landen die Daten mittels eigenen Skriptes.
FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die
Dinger?

vg
Andreas



2013/8/21 Franz Datzer 

> Servus Jens,
>
> auf wiki.volkszaehler.org bist Du sicher schon über diese Seite
> http://wiki.volkszaehler.org/**hardware/controllers/**
> ferrariszaehler_lesekopf
> gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran.
>
> Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese
> aktuell:
> http://www.fastforward.ag
> Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo
> geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet
> das Zählwerk aus.
> Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es.
> Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem
> raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script.
>
> Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit
> bin ich aber noch nicht.
>
> Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du
> auf jeden Fall.
>
> Gruß
>
> Franz
>
>
> Jens Schmelkus schrieb:
>
>  Hallo Zusammen,
>>
>> Mein Name ist Jens Schmelkus und ich
>> studiere in München Maschinenbau.
>>
>> Vor kurzem bin ich auf die Volkszaehler-page gestoßen
>> und habe seitdem ein neues Projekt. :)
>>
>> Ich habe die Technischen Möglichkeiten Bauteile und
>> Platinen zu Ätzen, Löten,Fräsen etc.
>>
>> Mein Ziel ist es unser Haus mit einem Logger für
>> je Wasser, Gas und Strom auszustatten und an meinen
>> Linux- Bladeserver anzuschließen.
>>
>> Der Stromzähler ist noch ein Antiker Ferraris-Zähler.
>>
>> Daher meine Frage.
>> Wie steht es um die Entwicklung des Ferrariszählerkopfes ?
>>
>> Gibt es schon Target Dateien oder Schaltpläne
>> die ich ausprobieren könnte ?
>>
>> Dankeschön schonmal.
>>
>> Mit freundlichem Gruß
>>
>> Jens
>>
>>
>>
>>
>>
>>

Re: [vz-dev] Neues Projekt & Ferrariszählerkopf

[Andreas Goetz]

Hallo Zusammen,

ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus-
ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann
ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank
Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich
mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi +
Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und
dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen
zu können. Im VZ landen die Daten mittels eigenen Skriptes.
FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die
Dinger?

vg
Andreas



2013/8/21 Franz Datzer 

> Servus Jens,
>
> auf wiki.volkszaehler.org bist Du sicher schon über diese Seite
> http://wiki.volkszaehler.org/**hardware/controllers/**
> ferrariszaehler_lesekopf
> gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran.
>
> Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese
> aktuell:
> http://www.fastforward.ag
> Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo
> geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet
> das Zählwerk aus.
> Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es.
> Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem
> raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script.
>
> Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit
> bin ich aber noch nicht.
>
> Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du
> auf jeden Fall.
>
> Gruß
>
> Franz
>
>
> Jens Schmelkus schrieb:
>
>  Hallo Zusammen,
>>
>> Mein Name ist Jens Schmelkus und ich
>> studiere in München Maschinenbau.
>>
>> Vor kurzem bin ich auf die Volkszaehler-page gestoßen
>> und habe seitdem ein neues Projekt. :)
>>
>> Ich habe die Technischen Möglichkeiten Bauteile und
>> Platinen zu Ätzen, Löten,Fräsen etc.
>>
>> Mein Ziel ist es unser Haus mit einem Logger für
>> je Wasser, Gas und Strom auszustatten und an meinen
>> Linux- Bladeserver anzuschließen.
>>
>> Der Stromzähler ist noch ein Antiker Ferraris-Zähler.
>>
>> Daher meine Frage.
>> Wie steht es um die Entwicklung des Ferrariszählerkopfes ?
>>
>> Gibt es schon Target Dateien oder Schaltpläne
>> die ich ausprobieren könnte ?
>>
>> Dankeschön schonmal.
>>
>> Mit freundlichem Gruß
>>
>> Jens
>>
>>
>>
>>
>>
>>

Re: [vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ "power meter"?

[Andreas Goetz]

Hallo Zusammen,

ich habe die ganzen Optimierungen in einen Patch verpackt:

https://github.com/volkszaehler/volkszaehler.org/pull/47

Viele Grüße,
Andreas


On 25.07.2013 13:53, Andreas Goetz wrote:

Hallo Zusammen,

es handelt sich um einen Fehler in der MW aufgrund Aggregation von 
Tupeln und Skippen des ersten Records.


Vollständiger Patch hier: https://github.com/andig/volkszaehler.org

Nebenbei gibts noch neue Features (database section im 
CapabilitiesController) und Performanceverbesserung 
(Packageaggregation in MySQL statt PHP).


@Justin: ich kann leider keinen Pull Request stellen da der alte (den 
wir jetzt löschen können) noch aktiv ist. Könntest Du den Weg freimachen?


Danke,
Andreas


On 12.07.2013 12:10, Andreas Goetz wrote:



Hallo,

für meine Monitoring App http://github.com/andig/vzmon 
<http://github.com/andig/vzmon> versuche ich die Erzeugung des Tages 
(Mitternacht bis jetzt) auszusummieren. Für Kanäle vom Typ Power 
klappt das wunderbar:


http://ip/middleware.php/data/kanalid.json?fomr=today&to=now&tuples=1,

dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:

Kanal:

http://ip/middleware.php/channel.json

{"version":"0.2","channels":[
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","type":"electric

meter","active":true,"color":"gold","public":true,"resolution":1000,"style":"steps","title":"Erzeugung
2.8.0"},

Daten:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=1

{"version":"0.2",
"data":
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f",
"from":"137349300",
"to":"137356350",
"average":0,
"consumption":0,
"rows":236}}

Consumption bleibt hier 0 obwohl rows=236 und größer werdende 
Zählerstände erfasst sind??


Mit >1 Tupeln:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=10


{"version":"0.2","data":{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","from":"137349300","to":"137356350","min":
[137349990,57.878],"max":

[137356200,16237.989],"average":3645.213,"consumption":71385.42,"rows":236,"tuples":
[[137349990,57.878,23],
[137352060,1248.973,23],...

Wird tuples komplett weggelassen so stimmt die ermittelte consumption 
nach erster Analyse.


Meine Frage: funktioniert "consumption" bei diesem Kanaltyp anders 
oder ist das evtl. ein Bug in der Ermittlung der Consumption bei 
diesem Kanaltyp?


Viele Grüße,
Andreas

Re: [vz-dev] Bug: CapabilitiesController ignoriert section parameter

[Andreas Goetz]

Mein Fehler. Natürlich muss der Aufruf so lauten:

http://localhost/vz/middleware.php/capabilities/database.json

ergibt

{"version":"0.2","capabilities":{"database":{"rows":70990,"size":5858562}}}

Damit kann ich den Patch für die neue database Section stellen. Wohin damit?

vg
Andreas

On 28.07.2013 12:51, Andreas Goetz wrote:
Bei dem Versuch, den CapabilitiesController um Statusinformationen zur 
Datenbank zu erweitern ist mir aufgefallen, dass der 
CapabilitiesControllerdie übergebene section nicht verarbeitet 
(section=null).


So liefert 
http://../middleware.php/capabilities.json?section=configuration immer 
alle sections zurück.


Vermutung: analog DataController muss die section per 
$this->view->request->getParameter('section'); ermittelt werden da sie 
nicht direkt in im get-Aufruf übergeben wird.


Wenn gefixt liesse sich dann auch die Datenbankgröße gezielt abfragen:

if (is_null($section) || $section == 'database') {
$conn = $this->em->getConnection(); // get dbal connection 
from EntityManager


$sql = 'SELECT ('.
   'SELECT count(1) '.
   'FROM data'.
   ') AS rows, ('.
   'SELECT sum(data_length + index_length) '.
   'FROM information_schema.TABLES '.
   'WHERE table_schema = ?'.
   ') AS size';

$res = $conn->fetchArray($sql, 
array(Util\Configuration::read('db.dbname')));


$capabilities['database'] = array(
'rows' => $res[0],
'size' => $res[1]
);
}

Wer kann meine Vermutung bestätigen und wohin darf ich den Patch 
schicken?


vg
Andreas

[vz-dev] Bug: CapabilitiesController ignoriert section parameter

[Andreas Goetz]

Bei dem Versuch, den CapabilitiesController um Statusinformationen zur 
Datenbank zu erweitern ist mir aufgefallen, dass der 
CapabilitiesControllerdie übergebene section nicht verarbeitet 
(section=null).


So liefert 
http://../middleware.php/capabilities.json?section=configuration immer 
alle sections zurück.


Vermutung: analog DataController muss die section per 
$this->view->request->getParameter('section'); ermittelt werden da sie 
nicht direkt in im get-Aufruf übergeben wird.


Wenn gefixt liesse sich dann auch die Datenbankgröße gezielt abfragen:

if (is_null($section) || $section == 'database') {
$conn = $this->em->getConnection(); // get dbal connection 
from EntityManager


$sql = 'SELECT ('.
   'SELECT count(1) '.
   'FROM data'.
   ') AS rows, ('.
   'SELECT sum(data_length + index_length) '.
   'FROM information_schema.TABLES '.
   'WHERE table_schema = ?'.
   ') AS size';

$res = $conn->fetchArray($sql, 
array(Util\Configuration::read('db.dbname')));


$capabilities['database'] = array(
'rows' => $res[0],
'size' => $res[1]
);
}

Wer kann meine Vermutung bestätigen und wohin darf ich den Patch schicken?

vg
Andreas

[vz-dev] Fehler in Interpreter->getData wenn from/to keine Daten enthält

[Andreas Goetz]

Der per from..to angegebene Zeitraum wird von Interpreter->getData für 
das Frontend um die vorliegenden/nachfolgenden Datenpunkte erweitert.


Wenn in dem durch from...to angegebenen Zeitrange keine Tuple liegen 
werden durch die Erweiterung from..to plötzlich Tupel gefunden und 
werden damit auch aus der Datenbank geholt. Dadurch wird das Ergebnis 
der Middleware verfälscht- was immer dann weh tut wenn die Abfrage nicht 
durch das Frontend gestellt wird.


Denkbare Lösungen:
- die from/to Erweiterung wird unterbunden wenn in der Ursprungsrange 
keine Tupel liegen- auf Kosten eines zusätzlichen DB-Queries
- ein neuer "pure" Parameter meldet an, dass der Request nicht vom 
Frontend kommt
- die from/to Erweiterung wird nur durchgeführt wenn Aufrufe durch das 
Frontend erfolgen. Diese müssten dafür extra markiert werden.


Was meinen die Experten?

Implementierung übernehme ich gerne da ich die Funktionen benötige.

Viele Grüsse,
Andreas

Re: [vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ "power meter"?

[Andreas Goetz]

Hallo Zusammen,

es handelt sich um einen Fehler in der MW aufgrund Aggregation von 
Tupeln und Skippen des ersten Records.


Vollständiger Patch hier: https://github.com/andig/volkszaehler.org

Nebenbei gibts noch neue Features (database section im 
CapabilitiesController) und Performanceverbesserung (Packageaggregation 
in MySQL statt PHP).


@Justin: ich kann leider keinen Pull Request stellen da der alte (den 
wir jetzt löschen können) noch aktiv ist. Könntest Du den Weg freimachen?


Danke,
Andreas


On 12.07.2013 12:10, Andreas Goetz wrote:



Hallo,

für meine Monitoring App http://github.com/andig/vzmon 
<http://github.com/andig/vzmon> versuche ich die Erzeugung des Tages 
(Mitternacht bis jetzt) auszusummieren. Für Kanäle vom Typ Power 
klappt das wunderbar:


http://ip/middleware.php/data/kanalid.json?fomr=today&to=now&tuples=1,

dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:

Kanal:

http://ip/middleware.php/channel.json

{"version":"0.2","channels":[
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","type":"electric

meter","active":true,"color":"gold","public":true,"resolution":1000,"style":"steps","title":"Erzeugung
2.8.0"},

Daten:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=1

{"version":"0.2",
"data":
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f",
"from":"137349300",
"to":"137356350",
"average":0,
"consumption":0,
"rows":236}}

Consumption bleibt hier 0 obwohl rows=236 und größer werdende 
Zählerstände erfasst sind??


Mit >1 Tupeln:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=10


{"version":"0.2","data":{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","from":"137349300","to":"137356350","min":
[137349990,57.878],"max":

[137356200,16237.989],"average":3645.213,"consumption":71385.42,"rows":236,"tuples":
[[137349990,57.878,23],
[137352060,1248.973,23],...

Wird tuples komplett weggelassen so stimmt die ermittelte consumption 
nach erster Analyse.


Meine Frage: funktioniert "consumption" bei diesem Kanaltyp anders 
oder ist das evtl. ein Bug in der Ermittlung der Consumption bei 
diesem Kanaltyp?


Viele Grüße,
Andreas

[vz-dev] Consumption für CounterInterpreter falsch wenn Tuples gepackt werden?!

[Andreas Goetz]

Hallo Zusammen,

ich versuche den Verbrauch (=Consumption) eines CounterInterpreter (Power
Meter, siehe Post
http://demo.volkszaehler.org/pipermail/volkszaehler-users/2013-July/002287.html)
in einem Zeitraum zu ermitteln.
Da der Zeitraum beliebig groß sein kann ist es angezeigt, die Anzahl der
Tuples zu begrenzen, idealerweise =1 da nur der Verbrauch jedoch nicht die
Datenpunkte interessieren.

Für MeterInterpreter funktioniert das wunderbar, für CounterInterpreter
jedoch nicht da der erste Zählerstand "weggeschmissen" und nur der
Timestamp verwendet wird. Je weniger Tupel und je mehr Tupel in ein
"Package" verpackt werden, desto falscher der Wert- bei tuples=2 kann der
auch um 100% falsch sein.

Bisher habe keinen Lösungsansatz gefunden wie verlässlich der Verbrauch
eines CounterInterpreters ermittelt werden kann. Auch der Code
(DataIterator, CounterInterpreter oder die Gruppierungen im Interpreter)
haben keine Ideen generiert.

Wer kann helfen?

vg
Andreas

Re: [vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ "power meter"?

[Andreas Goetz]

Hallo liebe Entwickler,

kann wirklich niemand helfen? Frage falsch gestellt? Anwenderfehler?

Danke Euch!

On 12.07.2013 12:10, Andreas Goetz wrote:



Hallo,

für meine Monitoring App http://github.com/andig/vzmon 
<http://github.com/andig/vzmon> versuche ich die Erzeugung des Tages 
(Mitternacht bis jetzt) auszusummieren. Für Kanäle vom Typ Power 
klappt das wunderbar:


http://ip/middleware.php/data/kanalid.json?fomr=today&to=now&tuples=1,

dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:

Kanal:

http://ip/middleware.php/channel.json

{"version":"0.2","channels":[
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","type":"electric

meter","active":true,"color":"gold","public":true,"resolution":1000,"style":"steps","title":"Erzeugung
2.8.0"},

Daten:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=1

{"version":"0.2",
"data":
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f",
"from":"137349300",
"to":"137356350",
"average":0,
"consumption":0,
"rows":236}}

Consumption bleibt hier 0 obwohl rows=236 und größer werdende 
Zählerstände erfasst sind??


Mit >1 Tupeln:


http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=10


{"version":"0.2","data":{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","from":"137349300","to":"137356350","min":
[137349990,57.878],"max":

[137356200,16237.989],"average":3645.213,"consumption":71385.42,"rows":236,"tuples":
[[137349990,57.878,23],
[137352060,1248.973,23],...

Wird tuples komplett weggelassen so stimmt die ermittelte consumption 
nach erster Analyse.


Meine Frage: funktioniert "consumption" bei diesem Kanaltyp anders 
oder ist das evtl. ein Bug in der Ermittlung der Consumption bei 
diesem Kanaltyp?


Viele Grüße,
Andreas

[vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ "power meter"?

[Andreas Goetz]

 

Hallo,

für meine Monitoring App http://github.com/andig/vzmon versuche ich die
Erzeugung des Tages (Mitternacht bis jetzt) auszusummieren. Für Kanäle vom
Typ Power klappt das wunderbar:

http://ip/middleware.php/data/kanalid.json?fomr=today&to=now&tuples=1,

dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:

Kanal:

http://ip/middleware.php/channel.json

{"version":"0.2","channels":[
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","type":"electric
meter","active":true,"color":"gold","public":true,"resolution":1000,"style":"steps","title":"Erzeugung
2.8.0"},

Daten:

http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=1

{"version":"0.2",
"data":
{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f",
"from":"137349300",
"to":"137356350",
"average":0,
"consumption":0,
"rows":236}}

Consumption bleibt hier 0 obwohl rows=236 und größer werdende Zählerstände
erfasst sind??

Mit >1 Tupeln:

http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=today&to=now&tuples=1
0

{"version":"0.2","data":{"uuid":"5b340280-9248-11e2-bf0b-adb29ee33b6f","from":"137349300","to":"137356350","min":
[137349990,57.878],"max":
[137356200,16237.989],"average":3645.213,"consumption":71385.42,"rows":236,"tuples":
[[137349990,57.878,23],
[137352060,1248.973,23],...

Wird tuples komplett weggelassen so stimmt die ermittelte consumption nach
erster Analyse.

Meine Frage: funktioniert "consumption" bei diesem Kanaltyp anders oder ist
das evtl. ein Bug in der Ermittlung der Consumption bei diesem Kanaltyp?

Viele Grüße,
Andreas

Re: [vz-dev] Welche 2-Richtungs-Zähler verbaut EON in Leipzig?

[Andreas Goetz]

On 08.05.2013 22:00, Udo1 wrote:

Siehe Betreff.

Danke

Udo



Wieso EON? Ist der Netzbetreiber nicht Netz Leipzig?

Re: [vz-dev] SolaranaLyzer - Daten aus der Api

[Andreas Goetz]

Wäre interessant zu sehen mit welchem Request der SA die Daten abholt. 
Kannst Su das z. B. in /var/log/apache2/access.log sehen?


Von meinem iPhone gesendet

Am 01.05.2013 um 10:46 schrieb sollner11 >:



Hallo,

ein Schönheitsfehler ist zu verzeichnen:
die Daten werden vom Solaranalyzer dargestellt und ausgewertet
dabei habe ich wohl ein Problem ... die timestamps "wandern"
werden also nicht immer zur gleichen Sekunde genommen und auch nicht 
alle 60 sec

kann das sein?

damit ich nicht zuviel kB poste hier ein Link, wie das aussieht:
http://www.photovoltaikforum.com/volkszaehler-org-f131/aggregierung-von-daten-im-vzlogger-t90247.html
ganz hinten

was kann man da machen?
kann ich die aggtime auf tatsächlich z.B. 300 sec setzen, z.B. mit 
Startwert  00:00:00 > 00:05:00 > 00:10:00 usw.?


Danke und Gruss

warum auch immer
Am 21.04.2013 um 11:32 schrieb sollner11 >:



ok, Daten kommen fein im Minutentakt
läuft einwandfrei
Raspi langweilt sich ;-)
Danke nochmal.

Das ist die Darstellung der middleware. Die Daten die eingeliefert 
werden und in der DB gespeichert sind immer "Roh-werte X zum 
Zeitpunkt Y".
Wenn Du Dir die Daten in der DB Anschaust siehst du deine 
Zählerstände keine Leistung.

passt und wäre ok

Die middleware macht dann aus "Zählerstandsänderung in eine 
Zeitraum" die Leistungsanzeige.


@all
und es gibt keine Möglichkeit die in der DB abgelegten Zählerstände 
 auch als Zählerstände per Api rauszubekommen?


Danke und Gruss

Re: [vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

On 24.04.2013 18:47, Jakob Hirsch wrote:

Andreas Goetz, 24.04.2013 17:31:

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei




Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz 
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man 
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende 
Umbau steht schon länger auf meiner Liste. Das könnte man aber 
allerdings auch mit SQL machen . 
Ja, ist mir auch aufgefallen. Dafür hätte ich jetzt auch schon Code 
liegen, der allerdings erst zu 90% funktioniert- in PHP, nicht in SQL. 
Er wird damit allerdings deutlcih komplexer als das was jetzt drin ist.
Und: die Vorgehensweise dafür ist auch diametral zu dem was ich oben 
vorgeschlagen hatte da eine Vorab-Aggregation dann nicht mehr wirklich 
wünschenswert ist da sie die Rundungen an den Grenzen der Zeiträume 
negativ beeinflusst.


Wenn Du Interesse hast schicke ich Dir meinen aktuellen Stand- ich trink 
jetzt lieber mal ein Bier ;)


Vielel Grüße,
Andreas

Re: [vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Ich hab's Dir mal als Pull Request verpackt: 
https://github.com/jahir/volkszaehler.org/pull/1


vg
Andreas

On 24.04.2013 18:47, Jakob Hirsch wrote:

Andreas Goetz, 24.04.2013 17:31:

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei

Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das
Frontend kann ja eh nicht mehr darstellen.


müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.

Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist,
weil alle rows erstmal von der Platte gelesen werden müssen.


Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).

Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist
das allerdings auch nicht gerade hochperformant gelöst (mit callbacks
und Interface-Klasse).

Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt
anders ist.

Hast du denn mal gemesen, ob's damit wirklich signifikant schneller
geht? Also ein

   time curl
'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440&tuples=100'

mit beiden Methoden (mehrmals ausgeführt).


Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau
steht schon länger auf meiner Liste. Das könnte man aber allerdings auch
mit SQL machen


.

Re: [vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Ich hab's Dir mal als Pull Request verpackt: 
https://github.com/jahir/volkszaehler.org/pull/1


vg
Andreas

On 24.04.2013 18:47, Jakob Hirsch wrote:

Andreas Goetz, 24.04.2013 17:31:

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei

Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das
Frontend kann ja eh nicht mehr darstellen.


müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.

Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist,
weil alle rows erstmal von der Platte gelesen werden müssen.


Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).

Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist
das allerdings auch nicht gerade hochperformant gelöst (mit callbacks
und Interface-Klasse).

Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt
anders ist.

Hast du denn mal gemesen, ob's damit wirklich signifikant schneller
geht? Also ein

   time curl
'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440&tuples=100'

mit beiden Methoden (mehrmals ausgeführt).


Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau
steht schon länger auf meiner Liste. Das könnte man aber allerdings auch
mit SQL machen


.

Re: [vz-dev] Bearbeitung von Gruppenkontexten?

[Andreas Goetz]

Problem gelöst- Ursache ist natürlich die EntityDefinition. Behelfsweise 
nehme ich jetzt einfach das "description" property zum testen...


On 26.04.2013 11:44, Andreas Goetz wrote:

Hallo Zusammen,

ich versuche gerade mit Hilfe von Gruppenkontexten meine Idee der 
"virtuellen" Kanäle zu realisieren. Bisher ist es mir gelungen, über 
das API eine Gruppe anzulegen und Kanäle zuzuordnen:


{
"version":  "0.2",
"entity":  {
"uuid": "c95f53e0-ae51-11e2-bed8-6b20ada53128",
"type":  "group",
"title":  "Group 1",
"children":  [
{
"uuid": "82fb2540-60df-11e2-8a9f-0b9d1e30ccc6",
"type":  "power",
"color":  "lightblue",
"public":  true,
"resolution":  1000,
"style":  "lines",
"title":  "Lieferung" },
{
"uuid": "8f20eb60-60df-11e2-81a1-3d3ab836429e",
"type":  "power",
"color":  "blue",
"public":  true,
"resolution":  75,
"style":  "lines",
"title":  "Erzeugung" }
]
}
}

Jetzt würde ich zu der bestehenden Gruppe gerne ein Attribut als 
"Rechenregel" hinzufügen:


http://localhost/vz/middleware.php/group/c95f53e0-ae51-11e2-bed8-6b20ada53128.json?op=rechenoperation&operation=edit

Gemäß Referenz sollte es möglich sein, Eigenschaften (=properties) 
einer Gruppe zu bearbeiten. Leider läufts auf einen Fehler:


{ "version": "0.2", "exception": { "message": "Unknown property: 
'op'", "type": "Exception", "code": 0 } }


Habe ich hier die Referenz falsch verstanden oder bezieht sich die 
Möglichkeit Eigenschaften zu bearbeiten nur auf vordefinierte 
Eigenschaften?


Viele Grüße,
Andreas

[vz-dev] Bearbeitung von Gruppenkontexten?

[Andreas Goetz]

Hallo Zusammen,

ich versuche gerade mit Hilfe von Gruppenkontexten meine Idee der
"virtuellen" Kanäle zu realisieren. Bisher ist es mir gelungen, über das
API eine Gruppe anzulegen und Kanäle zuzuordnen:

{
"version":  "0.2",
"entity":  {
"uuid":  "c95f53e0-ae51-11e2-bed8-6b20ada53128",
"type":  "group",
"title":  "Group 1",
"children":  [
{
"uuid":  "82fb2540-60df-11e2-8a9f-0b9d1e30ccc6",

"type":  "power",
"color":  "lightblue",
"public":  true,
"resolution":  1000,
"style":  "lines",
"title":  "Lieferung" },
{
"uuid":  "8f20eb60-60df-11e2-81a1-3d3ab836429e",

"type":  "power",
"color":  "blue",
"public":  true,
"resolution":  75,
"style":  "lines",
"title":  "Erzeugung" }
]
}
}

Jetzt würde ich zu der bestehenden Gruppe gerne ein Attribut als
"Rechenregel" hinzufügen:

http://localhost/vz/middleware.php/group/c95f53e0-ae51-11e2-bed8-6b20ada53128.json?op=rechenoperation&operation=edit

Gemäß Referenz sollte es möglich sein, Eigenschaften (=properties) einer
Gruppe zu bearbeiten. Leider läufts auf einen Fehler:

{ "version": "0.2", "exception": { "message": "Unknown property: 'op'",
"type": "Exception", "code": 0 } }

Habe ich hier die Referenz falsch verstanden oder bezieht sich die
Möglichkeit Eigenschaften zu bearbeiten nur auf vordefinierte Eigenschaften?

Viele Grüße,
Andreas

Re: [vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Hi Jakob,

Ich habs gemessen- bringt bei mir (5 Kanäle, Auflösung 5min, Raspi, Zoom 
aufs Jahr, grosser Monitor=500 Tupel) 30% schnellere Antworten.


Mit dem Umbau auf feste Zeiträume wärs kein Thema mehr, habe es 
allerdings nicht geschafft, das elegant in SQL zu realisieren. Wenn Du 
da eine Idee hast helfe ich gerne.


Diff/ Pull Request ist kein Problem, wollte aber abwarten obs jemanden 
interessiert.


Viele Grüsse,
Andreas

On 24.04.2013 18:47, Jakob Hirsch wrote:

Andreas Goetz, 24.04.2013 17:31:

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei

Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das
Frontend kann ja eh nicht mehr darstellen.


müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.

Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist,
weil alle rows erstmal von der Platte gelesen werden müssen.


Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).

Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist
das allerdings auch nicht gerade hochperformant gelöst (mit callbacks
und Interface-Klasse).

Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt
anders ist.

Hast du denn mal gemesen, ob's damit wirklich signifikant schneller
geht? Also ein

   time curl
'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440&tuples=100'

mit beiden Methoden (mehrmals ausgeführt).


Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau
steht schon länger auf meiner Liste. Das könnte man aber allerdings auch
mit SQL machen

Re: [vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Hi Jakob,

Ich habs gemessen- bringt bei mir (5 Kanäle, Auflösung 5min, Raspi, Zoom 
aufs Jahr, grosser Monitor=500 Tupel) 30% schnellere Antworten.


Mit dem Umbau auf feste Zeiträume wärs kein Thema mehr, habe es 
allerdings nicht geschafft, das elegant in SQL zu realisieren. Wenn Du 
da eine Idee hast helfe ich gerne.


Diff/ Pull Request ist kein Problem, wollte aber abwarten obs jemanden 
interessiert.


Viele Grüsse,
Andreas

On 24.04.2013 18:47, Jakob Hirsch wrote:

Andreas Goetz, 24.04.2013 17:31:

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei

Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das
Frontend kann ja eh nicht mehr darstellen.


müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.

Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist,
weil alle rows erstmal von der Platte gelesen werden müssen.


Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).

Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist
das allerdings auch nicht gerade hochperformant gelöst (mit callbacks
und Interface-Klasse).

Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt
anders ist.

Hast du denn mal gemesen, ob's damit wirklich signifikant schneller
geht? Also ein

   time curl
'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440&tuples=100'

mit beiden Methoden (mehrmals ausgeführt).


Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau
steht schon länger auf meiner Liste. Das könnte man aber allerdings auch
mit SQL machen

[vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Hallo Zusammen,

beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir 
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl 
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der 
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit 
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei 
müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese 
auch erstmal aus MySQL abgeholt werden.


Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren. 
Die untenstehende Methode erledigt das und kann in MeterInterpreter 
eingefügt werden (siehe unterer Teil nach EmptyIterator).


Ich freue mich über Feedback/ Testergebnisse:


/**
 * Get raw data
 *
 * Optimized version for thinning meter data
 *
 * @param string|integer $groupBy
 * @return Volkszaehler\DataIterator
 */
protected function getData() {

// get timestamps of preceding and following data points as a 
graciousness
// for the frontend to be able to draw graphs to the left and 
right borders

if (isset($this->from)) {
$sql = 'SELECT MIN(timestamp) FROM (SELECT timestamp FROM 
data WHERE channel_id=? AND timestamp$from = $this->conn->fetchColumn($sql, 
array($this->channel->getId(), $this->from), 0);

if ($from)
$this->from = $from;
}
if (isset($this->to)) {
$sql = 'SELECT MAX(timestamp) FROM (SELECT timestamp FROM 
data WHERE channel_id=? AND timestamp>? ORDER BY timestamp ASC LIMIT 2) t';
$to = $this->conn->fetchColumn($sql, 
array($this->channel->getId(), $this->to), 0);

if ($to)
$this->to = $to;
}

// common conditions for following SQL queries
$sqlParameters = array($this->channel->getId());
$sqlTimeFilter = self::buildDateTimeFilterSQL($this->from, 
$this->to, $sqlParameters);


if ($this->groupBy) {
$sqlGroupFields = self::buildGroupBySQL($this->groupBy);
if (!$sqlGroupFields)
throw new \Exception('Unknown group');
$sqlRowCount = 'SELECT COUNT(DISTINCT ' . $sqlGroupFields . 
') FROM data WHERE channel_id = ?' . $sqlTimeFilter;
$sql = 'SELECT MAX(timestamp) AS timestamp, SUM(value) AS 
value, COUNT(timestamp) AS count'.

' FROM data'.
' WHERE channel_id = ?' . $sqlTimeFilter .
' GROUP BY ' . $sqlGroupFields;
}
else {
$sqlRowCount = 'SELECT COUNT(*) FROM data WHERE channel_id 
= ?' . $sqlTimeFilter;
$sql = 'SELECT timestamp, value, 1 AS count FROM data WHERE 
channel_id=?' . $sqlTimeFilter . ' ORDER BY timestamp ASC';

}

$this->rowCount = (int) $this->conn->fetchColumn($sqlRowCount, 
$sqlParameters, 0);

if ($this->rowCount <= 0)
return new \EmptyIterator();

// potential to reduce result set?
if ($this->rowCount > $this->tupleCount && !$this->groupBy) {
$packageSize = floor($this->rowCount / $this->tupleCount);

// worth doing -> go
if ($packageSize > 1) {
$this->rowCount = floor($this->rowCount / $packageSize);
$this->conn->query('SET @row:=0;');
$sql = 'SELECT MAX(aggregate.timestamp) AS timestamp, 
SUM(aggregate.value) AS value, '.$packageSize.' AS count '.

   'FROM ('.
   'SELECT timestamp, value, @row:=@row+1 AS row '.
   ' FROM data WHERE channel_id=?' . 
$sqlTimeFilter .

   ') AS aggregate '.
   'GROUP BY row DIV ' . $packageSize .' '.
   'ORDER BY timestamp ASC;';
}
}

$stmt = $this->conn->executeQuery($sql, $sqlParameters); // 
query for data


return new DataIterator($stmt, $this->rowCount, $this->tupleCount);
}
}


Viele Grüße,
Andreas

Re: [vz-dev] Alternative Implementierung für vzcompress

[Andreas Goetz]

Hallo Florian,

mit etwas mehr Zeit kann ich Dir jetzt ausführlicher antworten. Zur 
Erinerung nochmal das Statement (mit kleinen Optimierungen):


-- delete - all channels
delete from data
where id in (
select id from (
select o.channel_id, o.id,
(
select max(timestamp)
from data i_p
where i_p.channel_id = o.channel_id
and i_p.timestamp < o.timestamp
) as prev_ts,
p.id as prev_id, p.value as prev_value,
(
select min(timestamp)
from data i_n
where i_n.channel_id = o.channel_id
and i_n.timestamp > o.timestamp
) as next_ts,
n.id as next_id, n.value as next_value
from data o
left join data p on p.timestamp = prev_ts and o.channel_id 
= p.channel_id
left join data n on n.timestamp = next_ts and o.channel_id 
= n.channel_id
where o.channel_id in (select id from entities where class = 
"channel")

and p.value = o.value
and n.value = o.value
and o.value = 0
)
)


On 15.04.2013 22:34, Florian Knodt wrote:

Nabend die Dritte,

das ist jetzt die 0-Wert-Löschung? Er sucht 3 aufeinanderfolgende 
Werte eines Kanals und löscht wenn alle 0 sind den Mittleren, richtig?




Wenn Du Dir das innere SELECT anschaust siehst Du, dass alle Datensätze 
zurückgegeben werden, die den gleichen Wert aufweisen wie der vorherige 
und nächste Datensatz im gleichen Kanal- das sind also die 
"innenliegenden" Datensätze einer Folge. Mit dem äußeren SELECT wird 
diese Liste auf die IDs reduziert und der Löschung zugeführt.
Die Einschränkung auf Nullwerte erfolgt mit dem letzten Teil der 
WHERE-Clause.



Am 2013-04-14 20:22, schrieb Andreas Goetz:

eine Optimierung welche mir für vzcompress noch einfiele wäre die
Löschung (nicht nur Komprimierung) redundanter Nullwerte.


Bei MeterInterpreter die nullen, bei SensorInterpreter 
aufeinanderfolgende und identische Werte würde ich sagen - wenns bei 
letzterem gleich bleibt sollte das ähnlich funktionieren.


Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0) weglässt, 
ist jetzt auch dieser Fall mit abgedeckt.



0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend
keine Rampen in die Darstellung einbaut.


Guter Punkt, das hätte ich glatt verpennt…


Leider funktioniert das nach meinen Tests trotzdem nicht. Die Werte 
stehen korrekt in der DB, werden per JSON korrekt zurückgeliefert, aber 
im Chart wird die letzte Null eines Bereiches ignoriert. Ursache ist mir 
nicht klar.



Nachteilig ist natürlich dass man nich tmehr so einfach auf der
Datenbank Werte mehrerer Kanäle für einen Timestamp "zusammenjoinen"
kann


...und ggf. nicht so weit im Frontend zoomen kann - afair zeigt das 
nichts an wenn keine Daten vorhanden sind. Wenn wir den ganzen 
(Sonnen)Tag von 0 reden und z.B. auf Stundenansicht gehen könnte das 
ggf. auch etwas seltsam aussehen


Auch ein guter Punkt- aber das gleiche Problem, welches auch bei 
Komprimierung der Werte besteht, oder? Im SQL könnte man den maximalen 
Zoomraum durch Einschränkung der WHERE-Clause vor Löschung schützen:


...
and p.timestamp < o.timestamp - 1*60*1000
and n.timestamp > o.timestamp - 1*60*1000

damit sind dann nur Datensätze betroffen, deren Vorgänger und Nachfolger 
_innerhalb_ eines angegebenen Intervalls liegen (vmtl. müsste man sich 
aber eher auf den Intervallanfang/ende konzentrieren- das braucht noch 
etwas Bastelei). Der Weg sollte der gleiche sein.



Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein?
"noch"? ich mach von meiner Seite keinen Schreibschutz drauf und 
deklariere es als fertig ;) Spaß beiseite: Ist notiert und hört sich 
erfolgsversprechend an, wenn ich etwas Zeit bekomme und der 
Schleifenbug raus ist schau ichs mir an.



Ich bin gespannt- gibts eigentlich ein GIT dafür?

Viele Grüße,
Andreas

Re: [vz-dev] Alternative Implementierung für vzcompress

[Andreas Goetz]

Hallo Zusammen,

und gleich noch ein Vorschlag hinterher- mit untenstehendem SQL konnte 
ich meine DB mit 5 Kanälen um 30% reduzieren- ohne Information zu verlieren:


delete from data
where id in (
select id from (
select o.id,
(
select max(timestamp)
from data i_p
where i_p.channel_id = o.channel_id
and i_p.timestamp < o.timestamp
) as prev_ts,
p.id as prev_id, p.value as prev_value,
(
select min(timestamp)
from data i_n
where i_n.channel_id = o.channel_id
and i_n.timestamp > o.timestamp
) as next_ts,
n.id as next_id, n.value as next_value
from data o
left join data p on p.timestamp = prev_ts and o.channel_id 
= p.channel_id
left join data n on n.timestamp = next_ts and o.channel_id 
= n.channel_id
where o.channel_id in (select id from entities where class = 
"channel")

and o.value = 0
and p.value = 0
and n.value = 0
)
)

Viele Grüße,
Andreas

On 15.04.2013 17:47, Andreas Goetz wrote:

Hallo Zusammen,

eine Optimierung welche mir für vzcompress noch einfiele wäre die 
Löschung (nicht nur Komprimierung) redundanter Nullwerte.


Hintergrund: bei "normalen" Stromzählern (aber auch Verbrauchsmessern) 
ist tagsüber während die PV läuft der Bezug meist 0, ebenso sind 
Einspeisung und Erzeugung nachts eigentlich immer 0. Diese Nullen 
ließen sind- bis auf die jeweils erste und letzter einer 0-Strecke 
einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen 
in die Darstellung einbaut.


Nachteilig ist natürlich dass man nich tmehr so einfach auf der 
Datenbank Werte mehrerer Kanäle für einen Timestamp "zusammenjoinen" 
kann- aber andererseits ist auch klar, dass kein Wert automatisch eine 
0 im Verbrauch bedeutet.


Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein?

Viele Grüße,
Andreas

Re: [vz-dev] Alternative Implementierung für vzcompress

[Andreas Goetz]

Hallo Zusammen,

eine Optimierung welche mir für vzcompress noch einfiele wäre die 
Löschung (nicht nur Komprimierung) redundanter Nullwerte.


Hintergrund: bei "normalen" Stromzählern (aber auch Verbrauchsmessern) 
ist tagsüber während die PV läuft der Bezug meist 0, ebenso sind 
Einspeisung und Erzeugung nachts eigentlich immer 0. Diese Nullen ließen 
sind- bis auf die jeweils erste und letzter einer 0-Strecke einsparen. 
Die letzte 0 wird benötige, damit das Frontend keine Rampen in die 
Darstellung einbaut.


Nachteilig ist natürlich dass man nich tmehr so einfach auf der 
Datenbank Werte mehrerer Kanäle für einen Timestamp "zusammenjoinen" 
kann- aber andererseits ist auch klar, dass kein Wert automatisch eine 0 
im Verbrauch bedeutet.


Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein?

Viele Grüße,
Andreas

Re: [vz-dev] Aggregierung von Daten im vzlogger ?

[Andreas Goetz]

Hallo Zusammen,

2013/4/10 Jan Tamm 

> > Meinungen? blöde Idee ? Gibt es schon ?
>
> Ich schaue mir eh gerade den S0 Meter via RS232 an und wollte das mit dem
> Durchschnitt eh einfügen. Nun nehme ich Deinen Vorschlag für die
> Parameternamen und baue das dort einfach einmal ein. Die Änderungen sollten
> nur pro Meter gemacht werden, ich glaube nicht dass da etwas übergeordnetes
> geändert werden muss.
>
> An welchen Metern wird sonst noch gearbeitet?
>
> - Jan
>

Ich bin mir nicht sicher ob es wirklich hierher gehört (falls nein gerne
ignorieren):
- ich nutze VZ als Datensenke und Visualisierung
- Datenerfassung für mehrere Stromzähler (=Impulszähler) habe ich mit
Eigenbau Hard- und Software realisierung

-> Falls das als "Meter" zählt und ein Interesse an einem
"ImpulsCounterMeter" auf Basis von General Purpose IOs (GPIO) besteht, dann
könnte ich meinen Code (Python) in ein "Meter" wandeln und gerne beitragen.

Viele Grüße,
Andreas

Re: [vz-dev] Error executing grouped queries

[Andreas Goetz]

Kommando zurück- die Angaben sind natürlich in Watt bzw. Consumption in 
Wh und die Zahlen stimmen wenn man Wh daraus macht- DANKE!


Wäre Klasse wenn die Anpassungen (inkl. Fix für from/to) es ins zentrale 
Git schaffen würden.


vg
Andreas

On 10.04.2013 19:56, Andreas Goetz wrote:

Hallo Jakob,

ich bin jetzt nochmal ganz in Ruhe hergegangen und habe mir die Daten 
angeschaut. Mal abgesehen davon, dass die relativen Datenformate alles 
andere als intuitiv sind habe ich immer noch ein paar Problem (SQL 
dump hatte ich geschickt):


http://.../middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.csv?from=first%20day%20january&to=now

# source: volkszaehler.org
# version: 0.2
# uuid: 8f20eb60-60df-11e2-81a1-3d3ab836429e
# to: 136560900
# min: 136412340 => -7040
# max: 0 => 0
# average: -1.188
# consumption: -450600
# rows: 5069

...
1,36419E+12 -1601
1,36419E+12 0   1
1,36419E+12 -1601
1,36419E+12 -1601
1,36419E+12 -1601
1,36419E+12 -3201


Was hier auffällt ist, dass- und zunächst mal unabhängig von der 
Gruppierung:

- die Consumption nicht der Summe der Einzelwerte entspricht (?)
- die Einzelwerte komisch sind. Es scheint die Energie in Wh (also = 
die Anzahl der Zählerimpulse) zu sein, allerdings dürfte dann kein 
Wert von 160 dabei rauskommen da der Zähler eine Auflösung von 
75imp/kWh hat, ein Impuls also etwas in der Größenordnung von 13,3Wh 
sein müsste.

- demzufolge stimmt auch der Durchschnitt nicht überein

Ich habe die Analyse dann mit einem anderen Kanal 
(2a93a9a0-60df-11e2-83cc-2b8029d72006) mit Auflösung 1000imp/kWh 
wiederholt:


# source: volkszaehler.org  

# version: 0.2  

# uuid: 2a93a9a0-60df-11e2-83cc-2b8029d72006

# from: 2013-03-24 02:15:00 

# to: 2013-04-03 19:35:00   

# min: 2013-03-24 06:55:00 => 0  

# max: 2013-03-30 19:00:00 => 4332   

# average: 220.112  

# consumption: 56422

# rows: 3075

24.03.2013 02:15204 1
24.03.2013 02:20144 1

24.03.2013 02:25144 1
24.03.2013 02:30228 1
24.03.2013 02:35396 1


Auch hier fällt auf, dass die Werte der Tupel anders aussehen als die 
ersten Einträge in der Datenbank (für den Kanal wären das 20, 17, 12, 
12, 19).


Zur Vollstädnigkeit nochmal die Channels:

{"version":"0.2","entity":{"uuid":"8f20eb60-60df-11e2-81a1-3d3ab836429e","type":"power","color":"blue","public":true,"resolution":75,"style":"lines","title":"Erzeugung"}}
{"version":"0.2","entity":{"uuid":"2a93a9a0-60df-11e2-83cc-2b8029d72006","type":"power","color":"maroon","public":true,"resolution":1000,"style":"lines","title":"Bezug"}}

Kann es sein, dass die Einzelwerte der Tupel in anderen Einheiten 
angegeben werden? Aber welchen? Der Versuch einer Umrechnung in Wmin 
hat auch nicht funktioniert...


Viele Grüße,
Andreas


On 04.04.2013 18:25, Jakob Hirsch wrote:

Hi,

Andreas Goetz, 03.04.2013 19:50:

Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal
gefixt.

Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde
(mit Update der Doku..)- die Logik ist wirklich krank :/

Das dürfte schon klappen :)


Ok, schicke ich per PM hinterher.

Hab ich mir angeschaut. Das Problem ist, daß du im März Daten hast, aber
nicht im Februar. Die Auswertung läuft aber so, daß mit group die Daten
einzelner Monate zusammengefasst werden und dann von processData wie
sonst auch verarbeitet werden, d.h. vom ersten Tupel wird nur der
timestamp genommen und der Rest verworfen, bei dir eben die
zusammengefassten Daten vom März. Ohne mittelgroße Umbauten oder
unschöne Hacks ist das aber leider nicht zu fixen.Ich schau's mir evt.
nochmal an, aber du solltest nicht darauf warten...
Workaround für dich: Einen einzelnen Impuls (mit Wert 0) für Ende
Februar einfügen (28.2. 23:59:59).

Re: [vz-dev] Error executing grouped queries

[Andreas Goetz]

Hallo Jakob,

ich bin jetzt nochmal ganz in Ruhe hergegangen und habe mir die Daten 
angeschaut. Mal abgesehen davon, dass die relativen Datenformate alles 
andere als intuitiv sind habe ich immer noch ein paar Problem (SQL dump 
hatte ich geschickt):


http://.../middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.csv?from=first%20day%20january&to=now

# source: volkszaehler.org
# version: 0.2
# uuid: 8f20eb60-60df-11e2-81a1-3d3ab836429e
# to: 136560900
# min: 136412340 => -7040
# max: 0 => 0
# average: -1.188
# consumption: -450600
# rows: 5069

...
1,36419E+12 -1601
1,36419E+12 0   1
1,36419E+12 -1601
1,36419E+12 -1601
1,36419E+12 -1601
1,36419E+12 -3201


Was hier auffällt ist, dass- und zunächst mal unabhängig von der 
Gruppierung:

- die Consumption nicht der Summe der Einzelwerte entspricht (?)
- die Einzelwerte komisch sind. Es scheint die Energie in Wh (also = die 
Anzahl der Zählerimpulse) zu sein, allerdings dürfte dann kein Wert von 
160 dabei rauskommen da der Zähler eine Auflösung von 75imp/kWh hat, ein 
Impuls also etwas in der Größenordnung von 13,3Wh sein müsste.

- demzufolge stimmt auch der Durchschnitt nicht überein

Ich habe die Analyse dann mit einem anderen Kanal 
(2a93a9a0-60df-11e2-83cc-2b8029d72006) mit Auflösung 1000imp/kWh wiederholt:


# source: volkszaehler.org  

# version: 0.2  

# uuid: 2a93a9a0-60df-11e2-83cc-2b8029d72006

# from: 2013-03-24 02:15:00 

# to: 2013-04-03 19:35:00   

# min: 2013-03-24 06:55:00 => 0  

# max: 2013-03-30 19:00:00 => 4332   

# average: 220.112  

# consumption: 56422

# rows: 3075

24.03.2013 02:15204 1
24.03.2013 02:20144 1

24.03.2013 02:25144 1
24.03.2013 02:30228 1
24.03.2013 02:35396 1


Auch hier fällt auf, dass die Werte der Tupel anders aussehen als die 
ersten Einträge in der Datenbank (für den Kanal wären das 20, 17, 12, 
12, 19).


Zur Vollstädnigkeit nochmal die Channels:

{"version":"0.2","entity":{"uuid":"8f20eb60-60df-11e2-81a1-3d3ab836429e","type":"power","color":"blue","public":true,"resolution":75,"style":"lines","title":"Erzeugung"}}
{"version":"0.2","entity":{"uuid":"2a93a9a0-60df-11e2-83cc-2b8029d72006","type":"power","color":"maroon","public":true,"resolution":1000,"style":"lines","title":"Bezug"}}

Kann es sein, dass die Einzelwerte der Tupel in anderen Einheiten 
angegeben werden? Aber welchen? Der Versuch einer Umrechnung in Wmin hat 
auch nicht funktioniert...


Viele Grüße,
Andreas


On 04.04.2013 18:25, Jakob Hirsch wrote:

Hi,

Andreas Goetz, 03.04.2013 19:50:

Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal
gefixt.

Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde
(mit Update der Doku..)- die Logik ist wirklich krank :/

Das dürfte schon klappen :)


Ok, schicke ich per PM hinterher.

Hab ich mir angeschaut. Das Problem ist, daß du im März Daten hast, aber
nicht im Februar. Die Auswertung läuft aber so, daß mit group die Daten
einzelner Monate zusammengefasst werden und dann von processData wie
sonst auch verarbeitet werden, d.h. vom ersten Tupel wird nur der
timestamp genommen und der Rest verworfen, bei dir eben die
zusammengefassten Daten vom März. Ohne mittelgroße Umbauten oder
unschöne Hacks ist das aber leider nicht zu fixen.Ich schau's mir evt.
nochmal an, aber du solltest nicht darauf warten...
Workaround für dich: Einen einzelnen Impuls (mit Wert 0) für Ende
Februar einfügen (28.2. 23:59:59).

Re: [vz-dev] jsonp support für vz

[Andreas Goetz]

Hallo Jakob,

danke für den Hinweis! padding=? funktioniert tatsächlich auch (hatte 
ich in der Doku anders verstanden)- damit ist alles Paletti, danke! 
Jetzt fehlt nur noch ein eleganter weg, zusätzliche MWs in der 
Konfiguration anzugeben.


Viele Grüsse,
Andreas

On 07.04.2013 02:33, Jakob Hirsch wrote:

On 04.04.2013 19:14, Andreas Goetz wrote:

Das hab ich glatt übersehen :/, content-type ist definition falsch. Ich
fände dennoch "callback" statt "padding" als Parameter schöner- dann
liesse sich nämlich auch jQuery getJSON nutzen. Mit der jetzigen Lösung

Wenn ich die Beschreibung von getJSON richtig verstanden habe (es ist
leider nicht explizit beschrieben), funktioniert das mit jedem
Parameter, der vor "=?" steht, in unserem Fall also "padding=?".
Ich finde "padding" als Parametername auch nicht so prall (auch wenn es
technisch korrekt ist), aber ohne Not ändert man sowas nicht.


muss man zwangsweise auf $.ajax ausweichen um die notwendigen Parameter
reinzufummeln. Aber ja- es ist möglich ;)

Also der Unterschied zwischen
$.getJSON(url, data, success)
und
   $.ajax({dataType: "json", url: url, data: data, success: success});
ist jetzt nicht soo riesig...

Re: [vz-dev] jsonp support für vz

[Andreas Goetz]

On 04.04.2013 14:52, Jakob Hirsch wrote:

Hi,

Andreas Goetz, 03.04.2013 08:46:

ich hatte den Wunsch, remote (d.h. per iphone-app) auf die mw
zuzugreifen. Aus Sicherheitsgründen ist das nur per JsonP, nicht jedoch
json möglich.

interessante sache irgendwie...
es ist doch eigentlich im frontend vorgesehen, kanaele von verschiedenen
middlewares abbonieren zu koennen - funktionierte das bisher garnicht?!

Kann nicht. Allerdings habe ich auch keinen Platz in rigendeiner Config
gefunden wo ich eine zweite MW hätte eintragen können- für's durch JS
hacken fehlte mir bisher die Zeit. Wäre aber eine spannende Aufgabe auch
daran ein wenig zu basteln.

Das ist jetzt auch schon möglich. Kann man einfach selbst testen, indem
man in seinem Frontend einen der öffentlichen Kanäle von
demo.volkszaehler.org abonniert.


 https://github.com/volkszaehler/volkszaehler.org/pull/44

Ich paste einfach mal meinen Kommentar von dort:

JSONP wird bereits über den Parameter "padding" unterstützt, siehe
http://wiki.volkszaehler.org/development/api/reference?s[]=padding#json
Dieser wird auch schon vom frontend benutzt, wenn man eine andere als
die lokale middleware ausgewählt hat.

Allerdings belässt padding den Content-type auf application/json, das
sollte wohl wie bei dir application/javascript sein, das sollten wir
noch fixen.

Das hab ich glatt übersehen :/, content-type ist definition falsch. Ich 
fände dennoch "callback" statt "padding" als Parameter schöner- dann 
liesse sich nämlich auch jQuery getJSON nutzen. Mit der jetzigen Lösung 
muss man zwangsweise auf $.ajax ausweichen um die notwendigen Parameter 
reinzufummeln. Aber ja- es ist möglich ;)


Danke und Gruss,
Andreas

Re: [vz-dev] Error executing grouped queries

[Andreas Goetz]

Hallo,

so richtig "click" macht es bei mir noch nicht. Für Gruppierung nach 
Monaten kann ich das ja nachvollzieren- aber auch bei Gruppierung nach 
Wochen oder Tagen kommt nix raus- und spätestens hier müsste es ja >2 
Tupel geben:


http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?group=day&from=1.1.2013&to=today

Letztlich- fällt mir gerade noch ein- wenn group=monat oder jahr 
angegeben ist wäre es evtl. auch sinnvoll, das "from-to" Intervall, 
falls nicht angegeben, automatisch auf einen sinnvollen Wert, z.B. 
"dieses Jahr" zu setzen?


vg
Andreas

On 04.04.2013 18:25, Jakob Hirsch wrote:

Hi,

Andreas Goetz, 03.04.2013 19:50:

Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal
gefixt.

Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde
(mit Update der Doku..)- die Logik ist wirklich krank :/

Das dürfte schon klappen :)


Ok, schicke ich per PM hinterher.

Hab ich mir angeschaut. Das Problem ist, daß du im März Daten hast, aber
nicht im Februar. Die Auswertung läuft aber so, daß mit group die Daten
einzelner Monate zusammengefasst werden und dann von processData wie
sonst auch verarbeitet werden, d.h. vom ersten Tupel wird nur der
timestamp genommen und der Rest verworfen, bei dir eben die
zusammengefassten Daten vom März. Ohne mittelgroße Umbauten oder
unschöne Hacks ist das aber leider nicht zu fixen.Ich schau's mir evt.
nochmal an, aber du solltest nicht darauf warten...
Workaround für dich: Einen einzelnen Impuls (mit Wert 0) für Ende
Februar einfügen (28.2. 23:59:59).

Re: [vz-dev] Error executing grouped queries

[Andreas Goetz]

Hallo Jakob,

habe mir das jetzt nochmal in Ruhe angeschaut.



>mal möchte ich Dir aber ein kleines "goodie" zeigen dass Dich vielleicht
>interessieren wird- nämlich ein kleines Dashboard für meine PV-Anlage
>das ich als iPhone-WebApp zusammengedübelt habe:
>
>Wenn's da Interesse gibt kann ich gerne Code beitragen. Die Widgets sind
>aus dem emoncms und auf jQuery widgets umgebaut...

Sieht gut aus, bringt mir mit meinen Android-Geräten allerdings nix,
oder?
Ist alles HTML+JS- läuft überall. Die Widgets sind von emoncms.org 
ausgeborgt und für jQuery angepasst.

>Komisch- da from&to den gleichen Wert haben, aber anders angegeben
>waren! Damit glaube ich, dass mindestens noch ein weiteres Problem
>besteht- sobald "from" gesetzt ist, wird dieses nämlich in der Abfrage
>von "to" als now() gesetzt- die Abfragen sind also counterintuitiv
>_immer_  relativ zueinander.

Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal
gefixt.
Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde 
(mit Update der Doku..)- die Logik ist wirklich krank :/

>Die Gruppierung läuft allerdings weiter nicht- auch nicht mit:
>http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?from=1.1.2013&to=1.4.2013&group=month

Das hab ich gerade mal mit meinem Test-Channel probiert, das
funktioniert problemlos:

$ curl
'http://localhost/vzdemo/middleware.php/data/x.csv?tsfmt=sql&from=1.1.2013&to=1.4.2013&group=month'
# source: volkszaehler.org
# version: 0.2
# uuid: x
# from: 2013-03-31 23:59:28
# to: 2013-04-01 00:01:29
# min: 2013-03-31 23:59:28 => 297,892
# max: 2013-03-31 23:59:28 => 297,892
# average: 297,892
# consumption: 10
# rows: 2
2013-03-31 23:59:28;297,892;2

Mhm. Bei mir tatsächlich nicht. Ohne group:

{"version":"0.2","data":{"uuid":"8f20eb60-60df-11e2-81a1-3d3ab836429e","from":136408770,"to":136476780,"min":[136412340,-7040],"max":[136408770,0],"average":-1070.666,"consumption":-202266.667,"rows":2266,"tuples":[...[136447140,-480,1],[136447170,-640,1],[136447200,-800,1],[136447230,-640,1],[136447260,-800,1],[136447290,-640,1],[136447320,-960,1],[136447350,-800,1],[136447380,-640,1],[136447410,-480,1],[136447440,-320,1],[136447470,-480,1],[136447500,-640,1],[136447530,-640,1],[136447560,-800,1],[136447590,-640,1],[136447620,-800,1],[136447650,-640,1],[136447680,-800,1],[136447710,-1440,1],[136447740,-1600,1],[136447770,-1280,1],[136447800,-1440,1],[136447830,-1120,1],[136447860,-1120,1],[136447890,-1120,1],[136447920,-960,1],[136447950,-800,1],[136447980,-640,1],[136448010,-320,1],[136448040,-640,1],[136448070,-800,1],[136448100,-800,1],[136448130,-640,1],[136448160,-640,1],[136448190,-800,1],[136448220,-800,1],[136448250,-640,1],[136448280,-640,1],[136448310,-640,1],[136448340,-640,1],[136448370,-800,1],[136448400,-800,1],[136448430,-640,1],[136448460,-640,1],[136448490,-480,1],[136448520,-480,1],[136448550,-480,1],[136448580,-320,1],[136448610,-320,1],[136448640,-160,1],[136448670,-160,1],[136448700,-160,1],[136448730,-320,1],[136448760,-160,1],[136448790,-320,1],[136448820,-160,1],[136448850,-160,1],[136448880,-160,1],[136448910,-160,1],[136448940,-160,1],[136448970,-160,1],[136449000,0,1],[136449030,0,1],[136449060,0,1],[136449090,-160,1],[136449120,0,1],[136449150,0,1],[136449180,0,1],[136449210,0,1],[136449240,0,1],[136449270,0,1],[136449300,0,1],[136449330,0,1],[136449360,0,1],[136449390,0,1],[136449420,0,1],[136449450,0,1],[136449480,0,1],[136449510,0,1],[136449540,0,1],[136449570,0,1],[136449600,0,1],[136449630,0,1],[136449660,0,1],[136449690,0,1],[136449720,0,1],[136449750,0,1],[136449780,0,1],[136449810,0,1],[136449840,0,1],[136449870,0,1],[136449900,0,1],[136449930,0,1],[136449960,0,1],[136449990,0,1],[136450020,0,1],[136450050,0,1],[136450080,0,1],[136450110,0,1],[136450140,0,1],[136450170,0,1],[136450200,0,1],[136450230,0,1],[136450260,0,1],[136450290,0,1],[136450320,0,1],[136450350,0,1],[136450380,0,1],[136450410,0,1],[136450440,0,1],[136450470,0,1],[136450500,0,1],[136450530,0,1],[136450560,0,1],[136450590,0,1],[136450620,0,1],[136450650,0,1],[136450680,0,1],[136450710,0,1],[136450740,0,1],[136450770,0,1],[136450800,0,1],[136450830,0,1],[136450860,0,1],[136450890,0,1],[136450920,0,1],[136450950,0,1],[136450980,0,1],[136451010,0,1],[136451040,0,1],[136451070,0,1],[136451100,0,1],[136451130,0,1],[136451160,0,1],[136451190,0,1],[136451220,0,1],[136451250,0,1],[136451280,0,1],[1364513100

Re: [vz-dev] jsonp support für vz

[Andreas Goetz]

Hallo Thorben,

On 03.04.2013 08:03, Thorben Thuermer wrote:

On Mon, 01 Apr 2013 17:33:46 +0200
Andreas Goetz  wrote:

Hallo Zusammen,

ich hatte den Wunsch, remote (d.h. per iphone-app) auf die mw
zuzugreifen. Aus Sicherheitsgründen ist das nur per JsonP, nicht jedoch
json möglich.

interessante sache irgendwie...
es ist doch eigentlich im frontend vorgesehen, kanaele von verschiedenen
middlewares abbonieren zu koennen - funktionierte das bisher garnicht?!


Kann nicht. Allerdings habe ich auch keinen Platz in rigendeiner Config 
gefunden wo ich eine zweite MW hätte eintragen können- für's durch JS 
hacken fehlte mir bisher die Zeit. Wäre aber eine spannende Aufgabe auch 
daran ein wenig zu basteln.



(fuer die die die problematik nicht kennen: http://en.wikipedia.org/wiki/JSONP )


Wenn Interesse besteht hätte ich hier einen Patch mit dem
sich JsonP darstellen lässt- es fehlt nur noch eine
Default-Konfigurationsoption um das Verhalten standardmäßig zu deaktivieren.

warum schickst du den patch nicht einfach?
oder noch besser, einen pull-request auf github.

Da war ich schneller ;)

https://github.com/volkszaehler/volkszaehler.org/pull/44

In der jetzigen Version ist das allerdings ein potentielles 
Sicherhitsrisiko- es lassen sich ja nicht nur Daten abfragen sondern 
auch löschen. Was fehlt ist m.E. eine Konfigurationsoption mit der jsonp 
standardmäßig erstmal deaktiviert ist.



interessant waehre noch die technische umsetzung...
ein zusaetzlicher parameter um das format anzugeben,
und den namen der callback funktion?
Sind nur 3 Zeilen- siehe patch. Aufgerufen wird es- wenn man jQuery 
einsetzt- indem einfach callback=? an die Anfrage gehängt wird, jQ 
bastelt daraus dann einen eindeutigen Funktionsnahmen den es auf dem 
Rückweg auch aufruft und die Daten rausholt.



ich denke das "standard"-rueckgabeformat der middleware zu aendern
waehre keine gute idee, zumal es auch andere clients als das standard-frontend
gibt.
Nicht nötig- es wird ja über den Request gesteuert, der Client kann also 
entscheiden.



Frohe Ostern,
Andreas

- Thorben


Viele Grüße,
Andreas