[vz-dev] Hardware für Ölstandsmessung

Wed Jan 27 09:50:50 CET 2016

Hallo,
wie ja schon aus meinen Beiträgen durchschimmert bin ich ein interessierter Laie und keiner, der sich mal eben einen Ultraschallfühler in den Öltank setzt.
Bin bei meiner Suche auf dieser Hardware gestoßen und wollte fragen, ob es denkbar wäre, die - nicht spezifizierten - Daten des Messgerätes mitzuloggen.
Bitte nicht den Apothekenpreis würdigen, der dort angegeben ist.

http://www.tecson.de/tankmonitoring_elitro-net_details.html

Danke und Gruß, Thomas

Date: Wed, 27 Jan 2016 09:12:52 +0100
From: cpuidle at gmail.com
To: volkszaehler-dev at demo.volkszaehler.org
Subject: Re: [vz-dev]	Änderungen an vzlogger zur Begutachtung

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/68d1e8c2/attachment-0001.html>