[vz-dev] Änderungen an vzlogger zur Begutachtung

[Andreas Goetz]

Hallo Herrmann,

erstmal Klasse dass Du Dich mit vz auseinander setzt und sogar
Verbesserungen mitbringst! In der Form können wir sie leider nicht
verarbeiten- wir wissen nicht auf welchem Stand Du Deine Änderungen gemacht
hast und vmtl. hat auch niemand die Zeit die Dateien manuell zu mergen.
Unser Werkzeug für die Softwareentwicklung ist github- unter
https://github.com/volkszaehler/vzlogger kannst Du sog. "Pull Requests"
erstellen- bitte einen je Änderung.

Viele Grüße,
Andreas

PS.: und ganz wichtig: bitte niemals auf alte Mailinglistenthemen mit
"Reply" antworten sondern _immer_ ein neues Thema anfangen. Sonst wirds
einfach zu unübersichtlich....


2016-01-27 2:46 GMT+01:00 mail_web_hed007 <hed007 at web.de>:

> Hallo,
>
> ich bin erst vor Kurzem auf 'volkszaehler' gestoßen und finde hier vieles,
> was ich schon immer haben wollte.
> Allerdings bin ich auch auf ein paar Ungereimtheiten gestoßen und habe
> daraufhin ein bißchen rumgebastelt.
> Ich hatte schon seit Ewigkeiten nichts mehr mit C/C++ zu tun und mit der
> STL stehe ich immer noch auf Kriegsfuß.
> Ich kenne mich mit den Gepflogenheiten hier nicht aus und weiß nicht, wie
> hier mit Änderungen und Erweiterungen verfahren wird. Mit 'Open-Source'
> hatte ich bisher nur als 'User' zu tun.
> Ich schicke meine Änderungen hier einfach mal mit, hoffe das sich das
> jemand mal ansieht und ein paar sinnvolle Sachen findet, die evtl.
> übernommen werden können.
>
>
> Im Einzelnen:
>
> 'scaler':
> Der 'scaler' hängt am Channel-Objekt und sollte damit auch von diesem
> ausgewertet werden. Wie es eigentlich sein sollte steht in Channel.cpp am
> Schluß als Kommentar.
> Wie dem auch sei, aktuell wird der 'scaler' an den verschiedensten Stellen
> verwendet und ausgewertet (MySmartGrid, MeterOCR, ...) , so daß eine
> zentrale Behandlung nicht mehr möglich ist.
> Deshalb wird der 'scaler' bei meinen Änderungen bei der api MySmartGrid am
> Channel-Objekt deaktiviert und auch sonst nur bei den Metern 'Exec', 'D0'
> und 'W1therm' aktiviert (threads.cpp).
> Da 'scaler' ein int ist, ich aber einen Teiler brauchte, wird für positive
> Werte der value mit dem scaler mulipliziert, bei negativen mit dem
> Absolutwert des scalers dividiert und bei '0' werden die Input-Values
> ignoriert.
>
> Files: Channel.hpp, Channel.cpp, tests_mocks_Channel.hpp als
> tests/mocks/Channel.hpp, threads.cpp
>
>
> MeterW1therm:
> hier sollte der Wert '85000', bzw '85.0' ignoriert werden , da das der
> Initial-Wert ist, wenn die Konversion noch nicht stattgefunden hat oder
> fehlerhaft war. Leider wird in diesem Fall vom Baustein auch der Status-Ok
> als 'YES' ausgeliefert, so daß nur der Wert an sich als Indiz bleibt, der
> zu ignorieren ist.
> Allerdings tritt das fast nur an der Standard-Schnittstelle de RasPi nach
> einem Kaltstart auf.
> Aber es stört schon sehr, versaut das Diagramm massiv und wird im
> wirklichen Leben von den Bausteinen auch nur im Fehlerfall/Problemfall
> ausgeliefert.
>
> Files: MeterW1therm.cpp
>
>
> 'MeterExec':
> Ich wollte unbedingt die CPU-Temperatur meines RasPi mit protokollieren -
> der hängt im Keller und läuft normalerweíse im Runlevel=3 (Netzwerk).
> Interessiert hat mich vor allem der Unterschied zu Runlevel=5
> (Multiuser/graphische Oberfläche/X-Server).
> Das MeterFile erwies sich für diesen Zweck allerdings als Flop und ist -
> ehrlich betrachtet - zu Nichts zu gebrauchen.
> Den Exec-Meter aus dem Config-Editor gabs dann im echten Leben gar nicht
> und in den Sourcen war tatsächlich nur ein inaktiver Rahmen zu finden.
> Ich hab deshalb mal einen MeterExec auf Basis des MeterFile implementiert.
> Durch die Modifikationen mit dem scaler (s.o.) war auch die Anpassung auf
> einen 'lesbaren' Wert relativ einfach.
> Hier ein Beispiel-Konfigurations-Fragment nach dieser Änderung:
> {
>      "enabled": true,
>      "allowskip": true,
>      "interval": 10,
>      "aggtime": -1,
>      "aggfixedinterval": false,
>      "channels": [
>  {
>          "uuid": "e6b19980-c3a5-11e5-b52d-535f1e98f80e",
>          "identifier": "",
>          //"api": "volkszaehler",
>          "middleware": "http://localhost/middleware.php",
>         "scaler": -1000,
>        },
>  {
>          "uuid": "691dc7f0-c414-11e5-802e-4f04aa6c0c22",
>          "identifier": "test",
>          "middleware": "http://localhost/middleware.php",
>         "scaler": -100,
>        },
>      ],
>      "protocol": "exec",
>      "command": "cat /sys/devices/virtual/thermal/thermal_zone0/temp",
>      //"command": "cat /sys/devices/virtual/thermal/thermal_zone0/temp;
> echo \"123 test\";",
>    "format": "$v $i", // $t=timestamp $v=value $i=identifier
>    },
>
> Der auskommentirte 'command' mit dem 'echo' macht zwar keinen Sinn, zeigt
> aber schön, wie Werte aus einem Aufruf auf mehrere Channel verteilt werden
> können.
> Werte ohne identifier-Angabe landen beim Channel mit '"identifier": ""'.
>
> Files: Meter.cpp, MeterExec.hpp, MeterExec.cpp, MeterMap.cpp
>
>
> Was mir noch aufgefallen ist:
> Ich habe die Entwicklung tatsächlich direkt auf einem RasPi durchgeführt
> (allerdings auf einem B+...).
> Und das auch noch ohne einen aktuellen, komfortablen Debugger, sondern mit
> 'EXHIBIT NAMES'. Aber das sagt wahrscheinlich nur einem altgedienten
> Cobol-Programmierer was und bedeutet: Debugging per 'print-Statements'.
> Die Übersetzungszeiten haben mich allerdings immer an meine Anfangszeiten
> als Programmierer erinnert. Das war - ehrlich gesagt - vor einer Ewigkeit,
> aber auch eine neue oder vergessene Erfahrung.
> Da ich genügend Zeit hatte, den Fortschritt zu verfolgen, ist mir auch
> aufgefallen, daß die meiste Zeit der Übersetzung den Tests gewidmet ist.
> Das sollte sich jemand, der sich auskennt vielleicht mal ansehen.
> Das eigentliche Projekt scheint relativ schnell durch zu sein, aber der
> ganze Test- und Mock-Scheiß der dauert und dauert und dauert...
> Ich hätte die Übersetzung auch auf meinem Linux-Server machen können, aber
> ich bin ja - hoffentlich - kein Feigling.
>
>
> tschau
> hermann
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160127/55ffb72a/attachment.html>