[vz-dev] MeterExec

Tue Mar 22 22:39:30 CET 2016

Hallo,

eine Implementierung für MeterExec hab ich mal gemacht. Hab das auch per EMail bekannt gegeben, aber ich sollte dann Pull-Requests dafür erstellen - was ich aber mangels Rechten direkt nicht darf. 
Nach einigem Durchprobieren sollte es mit einem Git-Clone->merge->was_weiß_ich_ doch irgendwie gehen - bin aber noch nicht dazu gekommen. 
Ich häng die Sourcen einfach an diese EMail nochmal mit dran, den EMail-Text s.u.
Achtung: die Sourcen passen zu einem Master Mitte/Ende Januar, wie es jetzt aussieht weiß ich nicht.
Es sind zwar einige Änderungen, sie halten sich abernoch im Rahmen. 
Der vzlogger läuft seitdem auch immer noch stabil. 
Größere Probleme habe ich dabei eher mit vzlogger-W1therm (3 Sensoren, einer mit parasitärer Stromversorgung) - der stoppt öfter oder startet nach einem Reboot manchmal gar nicht erst (die anderen Meter - auch 'exec' laufen aber weiter). Allerdings verwende ich auch keine Hardware-Erweiterungen, sondern 'RasPi-native' und da wird 1wire halt nur emuliert, bzw. versucht das Beste aus den vorhandenen Möglichkeiten zu machen. Für solcherart angebundene 1wire-Temp-Sensoren sollte in Meter-W1therm zusätzlich auch alles unter -60 und über 130C ignoriert werden, da das die Sensoren zwar manchmal melden aber gar nicht können (hatte auch schon mal Werte mit -87 und +1120, leider jeweils mit CRC=YES). Die 'besseren' Sensoren können offiziell -55 bis +125.

Viel Spaß

tschau
hermann

  ----- Original Message ----- 
  From: Dominik Benner 
  To: volkszaehler.org 
  Sent: Tuesday, March 22, 2016 12:49 PM
  Subject: [vz-dev] MeterExec

  Hallo,

  im Wiki steht, dass das Exec Meter "untested" ist. Jedoch scheint es mir nicht implementiert. Gibt es eine Binary oder auch sourcen, die dieses Meter implementiert haben?

  Gruß

  Dominik
-------

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/20160322/67e83f79/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Channel.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0009.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Channel.hpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0010.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Meter.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0011.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MeterExec.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0012.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MeterExec.hpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0013.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MeterMap.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0014.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MeterW1therm.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0015.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tests_mocks_Channel.hpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0016.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: threads.cpp
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20160322/67e83f79/attachment-0017.ksh>