vzlogger Erweiterungen von nyphis/Herrmann

andig commented 8 years ago

Aus der ML von Herrmann:

Achtung: die Sourcen passen zu einem Master Mitte/Ende Januar, wie es jetzt aussieht weiß ich nicht.

[ ] '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.

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.

Files: MeterW1therm.cpp
[x] '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.

nyphis commented 8 years ago

Naja ... das mit dem MeterExec hatte ich ja auch schon mal recht weit getrieben (#149) inkl. Build-Variable für root-Access - da hängt es "nur" noch an den Unit-Tests (und die sind bei der Variante von Herrmann auch nicht mit dabei wenn ich das richtig sehe) ...

Aber das sagt mir, dass es schon einen Bedarf dafür gibt ;-)

Edit: Bei näherer Begutachtung würde ich sagen, dass ein Großteil der MeterExec.cpp aus dem #149 kommt ... also stimmt der Satz " Ich hab deshalb mal einen MeterExec auf Basis des MeterFile implementiert" nicht ganz ...

andig commented 8 years ago

da hängt es "nur" noch an den Unit-Tests

Nutzt ja nix- entweder es kompiliert oder nicht. Seitdem hat sich m.W. aber auch an der Build Infrastruktur wieder einiges geändert- ich glaube wir sind z.B. wieder bei gcc 4.7?

Aber das sagt mir, dass es schon einen Bedarf dafür gibt ;-)

Ich sags nochmal ganz deutlich: das ist hier Arbeit von Freiwilligen. Wer beitragen will ist herzlich willkommen.

I'll have to dive deeper into the unit test to fix the Travis CI buid failures

Der letze Stand schien mir zu sein dass Du einen neuen PR erstellen wolltest?

Edit: Bei näherer Begutachtung würde ich sagen, dass ein Großteil der MeterExec.cpp aus dem #149 kommt ... also stimmt der Satz " Ich hab deshalb mal einen MeterExec auf Basis des MeterFile implementiert" nicht ganz ...

Ich glaube nicht dass Herrmann hier mitliest.

:-(

Was soll mir Negativsmiley jetzt sagen?

Prinzipiell

Ich frage mich ob dieser PR Sinn macht. Uns fehlt eine Strategie für neue Meter. Die Alternative zu MeterExec ist ein Cron Job zusammen mit vzclient.

nyphis commented 8 years ago

Nutzt ja nix- entweder es kompiliert oder nicht. Seitdem hat sich m.W. aber auch an der Build Infrastruktur wieder einiges geändert- ich glaube wir sind z.B. wieder bei gcc 4.7?

Jaaaa ... aber die Zeit mich als Hobby-Anfänger-C-Programmierer da einzuarbeiten habe ich dank Familie und Hausbau gerade nicht.

Aber das sagt mir, dass es schon einen Bedarf dafür gibt ;-)

Ich sags nochmal ganz deutlich: das ist hier Arbeit von Freiwilligen. Wer beitragen will ist herzlich willkommen.

Bitte nicht falsch verstehen - ich habe mir da ja die Arbeit gemacht. Ich freue mich ehrlich, dass es doch noch jemanden interessiert.

I'll have to dive deeper into the unit test to fix the Travis CI buid failures

Der letze Stand schien mir zu sein dass Du einen neuen PR erstellen wolltest?

Neeee ... so meinte ich das nicht. (Jetzt verstehe ich erst Deinen Schließungsgrund) Das war schon so gemeint, dass ich mich erstmal mit der ganzen Travis-Geschichte beschäftigen muss aber gerade absolut keine Zeit dafür habe

Was soll mir Negativsmiley jetzt sagen?

Ich bin weniger begeistert, dass da jemand meine Arbeit als seine Implementatierung auslobt.

Ich frage mich ob dieser PR Sinn macht. Uns fehlt eine Strategie für neue Meter. Die Alternative zu MeterExec ist ein Cron Job zusammen mit vzclient.

Ich finde eine Implementierung sinnvoller als einen Cronjob. Zum einen erzeugt cron bei jedem Aufruf einen syslog-Eintrag und dann starte ich eben immer wieder einen neuen Job - das passiert bei einem eigenständigen Meter eben nicht.

andig commented 8 years ago

Ich finde eine Implementierung sinnvoller als einen Cronjob. Zum einen erzeugt cron bei jedem Aufruf einen syslog-Eintrag und dann starte ich eben immer wieder einen neuen Job - das passiert bei einem eigenständigen Meter eben nicht.

Yep. Aber das eine ist eine Implementierung mit viel Code und das andere sind 2 Skriptzeilen. Worin besteht das Problem von neuem Job und Syslog Eintrag?

mbehr1 commented 8 years ago

Ich schaue mir den PR mal an.

Am 04.05.2016 um 16:58 schrieb andig notifications@github.com:

Ich finde eine Implementierung sinnvoller als einen Cronjob. Zum einen erzeugt cron bei jedem Aufruf einen syslog-Eintrag und dann starte ich eben immer wieder einen neuen Job - das passiert bei einem eigenständigen Meter eben nicht.

Yep. Aber das eine ist eine Implementierung mit viel Code und das andere sind 2 Skriptzeilen. Worin besteht das Problem von neuem Job und Syslog Eintrag?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/volkszaehler/vzlogger/issues/245#issuecomment-216891697

Gruß

Matthias

mbehr1 commented 8 years ago

Siehe PR #251.

Am 04.05.2016 um 16:58 schrieb andig notifications@github.com:

Ich finde eine Implementierung sinnvoller als einen Cronjob. Zum einen erzeugt cron bei jedem Aufruf einen syslog-Eintrag und dann starte ich eben immer wieder einen neuen Job - das passiert bei einem eigenständigen Meter eben nicht.

Yep. Aber das eine ist eine Implementierung mit viel Code und das andere sind 2 Skriptzeilen. Worin besteht das Problem von neuem Job und Syslog Eintrag?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/volkszaehler/vzlogger/issues/245#issuecomment-216891697

Gruß

Matthias

mbehr1 commented 8 years ago

Soll ich die Scaler und MeterW1 Änderung von Herrmann als PR vorbereiten?

Am 04.05.2016 um 16:58 schrieb andig notifications@github.com:

Ich finde eine Implementierung sinnvoller als einen Cronjob. Zum einen erzeugt cron bei jedem Aufruf einen syslog-Eintrag und dann starte ich eben immer wieder einen neuen Job - das passiert bei einem eigenständigen Meter eben nicht.

Yep. Aber das eine ist eine Implementierung mit viel Code und das andere sind 2 Skriptzeilen. Worin besteht das Problem von neuem Job und Syslog Eintrag?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/volkszaehler/vzlogger/issues/245#issuecomment-216891697

Gruß

Matthias

andig commented 8 years ago

Soll ich die Scaler und MeterW1 Änderung von Herrmann als PR vorbereiten?

@mbehr1 ich denke der Scaler mach für jeden Kanal Sinn, gerne als Float statt int, also immer als Multiplikator? Verwende den selber aber nie....

@UdoSchake könntest Du Dir mal das MeterW1 anschauen? Muss die 85000 raus?

UdoSchake commented 8 years ago

Hallo Andi,

Am 05.05.2016 um 11:41 schrieb andig:

könntest Du Dir mal das MeterW1 anschauen? Muss die 85000 raus? m.E. nein. Weil der Temperaturwert kann ja auch mal 85,0C betragen. Wenn laufend nur 85C ausgegeben werden deutet das auf einen Fehler am Sensor oder in der Config hin.

Gruß Udo

andig commented 8 years ago

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.

Ich kann das nicht beurteilen- wäre es evtl. sinnvoll die 85 einmalig zum Start zu ignorieren?

UdoSchake commented 8 years ago

Am 05.05.2016 um 12:12 schrieb andig:

wäre es evtl. sinnvoll die 85 einmalig zum Start zu ignorieren? Warum? Normalerweise sind die Devices initialisiert bevor vzlogger startet.

Gruß Udo

mbehr1 commented 8 years ago

Bei schlechter Verkabelung kommt 85 häufiger mal. Ich wäre auch dafür, den Wert auszublenden (dann kann man halt nur bis 84,xx°C messen)

Am 05.05.2016 um 12:32 schrieb Udo notifications@github.com:

Am 05.05.2016 um 12:12 schrieb andig:

wäre es evtl. sinnvoll die 85 einmalig zum Start zu ignorieren? Warum? Normalerweise sind die Devices initialisiert bevor vzlogger startet.

Gruß Udo — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/volkszaehler/vzlogger/issues/245#issuecomment-217120757

Gruß

Matthias

UdoSchake commented 8 years ago

Am 05.05.2016 um 12:39 schrieb Matthias Behr:

Bei schlechter Verkabelung kommt 85 häufiger mal. Ich wäre auch dafür, den Wert auszublenden (dann kann man halt nur bis 84,xx°C messen) Dann muss eben die Verkabelung geändert werden.

"Oh, der Atomreaktor läuft in einen kritischen Temperaturbereich.....Kein Problem, wir begrenzen die Temperaturanzeige im Programm..." oder aktuell "Mist, der Diesel spuckt zu viel Schadstoffe aus....kein Problem, wir tricksen ein wenig mit der Software"

Sorry, aber ist das die neue Problembeseitigungs-Mentalität? ;)

Gruß Udo

mbehr1 commented 8 years ago

Da hast du vollkommen recht. Wir sollten den Wert ausblenden und einen Fehlereintrag machen.

Am 05.05.2016 um 13:19 schrieb Udo notifications@github.com:

Am 05.05.2016 um 12:39 schrieb Matthias Behr:

Bei schlechter Verkabelung kommt 85 häufiger mal. Ich wäre auch dafür, den Wert auszublenden (dann kann man halt nur bis 84,xx°C messen) Dann muss eben die Verkabelung geändert werden.

"Oh, der Atomreaktor läuft in einen kritischen Temperaturbereich.....Kein Problem, wir begrenzen die Temperaturanzeige im Programm..." oder aktuell "Mist, der Diesel spuckt zu viel Schadstoffe aus....kein Problem, wir tricksen ein wenig mit der Software"

Sorry, aber ist das die neue Problembeseitigungs-Mentalität? ;)

Gruß Udo

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/volkszaehler/vzlogger/issues/245#issuecomment-217127896

Gruß

Matthias

andig commented 8 years ago

MeterExec fixed via https://github.com/volkszaehler/vzlogger/pull/251

andig commented 8 years ago

VZ meeting: fix scaler implementation. Wont fix 1wire.

volkszaehler / vzlogger

vzlogger Erweiterungen von nyphis/Herrmann #245