[vz-dev] MeterExec

Wed Mar 23 09:30:55 CET 2016

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/20160323/ca92fba1/attachment.html>