[vz-dev] MeterExec

Fri Mar 25 07:45:23 CET 2016

Hallo Hermann,

hättest du die Zeit und Lust dazu? Das wäre echt super!

Gruß

Dominik

Am 23. März 2016 um 09:30 schrieb Andreas Goetz <cpuidle at gmail.com>:

> Hallo Herrmann,
>
> guten morgen!
>
> 2016-03-22 22:39 GMT+01:00 mail_web_hed007 <hed007 at web.de>:
>
>> 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.
>>
>
> Pull Requests erstellen darf jeder- nur letztlich in das zentrale
> Repository einpflegen nicht- sonst gäbe das schnell Kraut und Rüben. Damit
> das technisch funktioniert sieht der Prozess eben so aus:
>
> - vz Repository "forken", z.B. bei GitHub- damit gekommt man eine "eigene"
> Kopie
> - Änderungen in der Kopie machen, sinnvollerweise in einem eigenen
> "Branch", also Entwicklungszweig
> - Änderungen am Branch als "Pull Request" wieder an das vz Repository
> schicken
>
> Gewöhnungsbedürftig aber kein Hexenwerk.
>
> Wichtig ist einfach zu verstehen dass _alle_ Arbeit bei VZ am Ende i.W.
> von drei Personen gemacht wird die alle auch Jobs und andere Hobbies haben.
> Ich hatte z.B. vor 4 Jahren auch noch keine Ahnung von git, composer,
> websockets, jquery und so weiter- insofern bietet VZ eine hervorragende
> Lernmöglichkeit!
>
> 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.
>>
>
> Genau das ist Teil des Problems. Wir haben jetzt 2 Quelltexte die vmtl.
> nicht mehr viel miteinander zu tun haben.
>
> Könntest Du bei Deinem vzlogger- wenn er noch auf dem alten Stand ist
> bitte nochmal per vzlogger -v rausbekommen auf welcher Version, besser noch
> git hash, das beruht? Wenn sich Freiwillige finden das nach GitHub zu
> übernehmen dann wird es dadurch deutlich einfacher weil wir den Merge dann
> auch auf altem Stand anfangen könnten
>
>
>> 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
>>
>
> Danke und Gruß,
> Andreas
>
>
>>
>>
>> ----- Original Message -----
>> *From:* Dominik Benner <dominik at benner.ws>
>> *To:* volkszaehler.org <volkszaehler-dev at demo.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/20160325/a4dbb695/attachment-0001.html>