[vz-users] Wie nutzt Du vzlogger?

[Andreas Goetz]

Hallo Zusammen,

anbei mein Feedback zur Umfrage bzw. der resultierenden Wunschliste.

2015-02-09 9:48 GMT+01:00 <justin at justinotherguy.org>:

> Moin,
>
> vielen Dank für die Teilnahme!
>
> Hier mal meine persönliche Zusammenfassung (natürlich nur bezogen auf die
> Rückmeldungen - über die „Dunkelziffer“ könnte ich naturgemäß nur
> spekulieren; und das lass’ ich).
> - die meisten nutzen den RPi unter Debian und betreiben diesen bei sich
> selbst
> - keiner scheint demo.volkszaehler.org zu verwenden (das ist für mich
> eine gute Nachricht; das verringert den Druck, wenn er mal wieder nicht tut
> (c: )
>

Das dürfte auch daran liegen dass es "demo" heißt. Wir könnten uns schon
fragen ob es eine offizielle "gehostete" Version von VZ geben sollte. Das
macht die lokale Installation/ Administration einfacher, mit Privacy ist
dann natürlich nichts mehr.


> - Debian-Paket: kaum Jemand verwendet dieses; das ist gut zu wissen (das
> war auch der konkrete Anlass für die Umfrage, obwohl ich das schon länger
> „auf dem Zettel“ hatte); mir erscheint ein Image mit integrierter
> Build-Umgebung daher der sinnvollste Ansatz; ein Update lässt sich dann via
> „git pull && cmake . && make install“ machen; das ist m.E. einfach genug
> und lässt sich zur Not dann auch noch skripten. Das erspart außerdem den
> immensen Einmalaufwand für die regelmäßige Bereitstellung
> plattformspezifischer Debian-Pakete
> - zu den Feature-Wünschen möchte ich gar nicht viel sagen; das ist m.E. in
> einem Open-Source-Projekt eine Art „Spiel von Angebot und Nachfrage“; nun
> ist zumindest mal bekannt, wofür es eine Nachfrage gibt - ob es nun ein
> Angebot geben wird? Man weiß es nicht ;-) (will sagen: liegt auch an Euch!)
> - die Struktur der Doku und der Zustand der Doku ist wohl für manche ein
> Stolperstein; so toll ein Wiki auch ist - die Struktur wächst nicht von
> alleine; vielleicht fühlt sich hier Jemand berufen, konkrete Verbesserungen
> vorzunehmen oder zumindest vorzuschlagen
>

Aus meiner Sicht unser Schwachpunkt und nur in einer konzertieren Aktion
lösbar. Bachelorstudent o.ä. mit Arbeitsauftrag...


> - Frontend/Login: dass man sich am Frontend und auch an der API nicht
> anmelden muss/kann, ist ungewöhnlich; das hat aber einen konkreten Grund:
> zu einer Anmeldung gehört zwingend ein „Passwort-Reset“-Mechanismus; und da
> endet dann die Anonymität (derzeit sieht die Middleware nur die IP-Adresse
> des Clients); da würde dann eine Mail-Adresse benötigt… Es gibt einen
> Mittelweg: Ihr könnt eine HTTP(s)-Authentisierung vorschalten; das bedeutet
> aber, dass Eure Freunde keine Kanäle mehr anschauen können; ich halte das
> immer noch für sinnvoll
>

Das stünde auf meiner Todoliste. Es gibt ein paar gute Bibliotheken dafür
die von "login with facebook" bis Rechteverwaltung alles bieten, teilweise
aber zumindest Microframeworks wie Silex voraussetzen. Der Aufwand wäre
recht erheblich und ist zumindest von mir nicht nebenbei zu leisten.


> Fühlt Euch eingeladen, Eure eigenen Schlüsse zu ziehen (und hier zu
> posten).
>
> Ich werde drüben auf vz-dev eine Info-Mail zu dieser Umfrage schicken.
>
>
> Gruß, J.
>
>
> Hier die Ergebnisse im Detail (13 Antworten):
> ...
>
> Frontend
> - Ein Berechtigungskonzept mit Login für das Frontend wäre wirklich gut :-)
> - Eine Art Benutzerverwaltung/Login für das Frontend
> - Dashboard für das Frontend wäre cool…
>

Aktuell böte sich freeboard.io an und ist im aktuellen Image von Udo schon
integriert.


> - Flexible Dashboard-Gestaltung, z.B. mehrere Graphen, zusätzliche Meter
> wie Gauges etc.
> - Stacked Lines, z.B. vorzeichenrichtiger Verbrauch und Einspeisung mit
> negativem Verbrauch (also Netzeinspeisung) im -y Quadranten
>

Bitte konkretes Issue dafür aufmachen.


> - Darstellung von Gesamtverbrauchswerten ohne den Fehler durch die
> zeitliche Aggregation, z.B. Tag, Woche, Monat, Jahr
>

Guter Punkt. Ich habe überlegt ob es sinnvoll wäre neben der
"Momentanwerte" Ansicht im VZ eine "Verbrauchsansicht" einzuführen die- als
Balkendiagramm oder steps- nur Verbauchswerte darstellt (h, Tag, Woche,
Monat, Jahr). Das könnten wir auch api-seitig so abrunden dass wir neben
/data einen /consumption Kontext mit einführen.

Apropos Kontext: auch ein /raw Kontext wäre denkbar um dem wiederkehrenden
Wunsch nach auslesbaren Zählerständen Rechnung zu tragen und SQL-Basteleien
zu erübrigen (auch wenn dies für das Frontend nicht notwendig ist).


> - Rechenoperationen mit den Werten, z.B. für eine PV Eigenverbrauchquote
>

Sowas liegt im dev-Zweig bei mir. Integration möglich wenn es genug
Publikum dafür gibt.


> - Auswertung per App
>

Alternativ: mobiltaugliches Frontend, dazu habe ich einen Lösungsansatz.


>
> Doku
> - Das Wiki könnte etwas "kompakter" sein (hier unterstütze ich gerne)
> - Für ein Projekt mit dem Namen Volkszähler steht der Begriff Middleware
> oft im Vordergrund und baut eine unnötige Hürde für Laien auf. Wenn man
> über Zähler, Vzlogger/Vzclient und Volkszähler-Frontend kommunizieren
> würde, verstehen Einsteiger das Thema einfacher.
>

Definitiv. Aus meiner Sicht bräcuhte die Webseite einen Neustart, siehe
oben.


> - Dokumentation ist teilweise veraltet, inkonsistent (zum Beispiel im
> Vergleich zu FHEM). Inbetriebnahme mit viel Trial & Error, es fehlen
> praktische konkrete aktuelle Beispiele und Erklärungen. Support per
> Mailing-List finde ich etwas umständlich.
>
> Auswertung
> - Logbuchmöglichkeit z.B. Dienstag 13.01.2015 18:00 Uhr - 19:42 Uhr
> Spülmaschine eingeschaltet
> - Grundlast ausblenden um zu sehen welche tasächliche Leistung hat z.B.
> der Toaster
> - eine automatische (zB. wöchentlich) Mail mit kleinem Bericht der
> täglichen Verbräuche und der Wochensumme. Verhaltensänderungen im
> Stromverbrauch können leicht mit der Vorwoche verglichen werden und
> motivieren.
>

Sehr einfach zu realisieren...


> - schönere und flexiblere Auswertung (einzelne Diagramme, Heatmap wie
> neulich vorgestellt)
> - "user defined queries" (z.B. die Tagestiefsttemperaturen eines channels)
>

Gute Idee aber schwierig soetwas performant zu machen- jedenfalls wenn es
für alle Kanaltypen funktionieren soll. Gibt es dafür breiteren Bedarf?


> - Export PDF Datei mit Verbrauch und Kosten für Gesammtes Jahr mit
> einzelnen Monaten auf einer Seite währe Super
>

Passt gut zur "Verbrauchsansicht". Ein Issue mit Detaillierung der
Anforderungen wäre hilfreich.


> vzlogger
> - Vzlogger kann die GPIOs lesen
>
> allgemein
> - SCHNELLERE Auswertung (trotz Aggregation immer noch lahm)
>

Da bin ich gespannt. @Daniel: falls der Punkt von Dir kam haben wir das ja
gelöst.

@all: wer trotz Aggregation Performanceprobleme hat schreibt bitte eine
Mail- das geht gegen die Ehre ;)


> - stabilerer Betrieb (siehe oben - SD-Karte macht regelmäßig Ärger, System
> hängt sich auf)
> - Monitor-Daemon, der geloggte Werte „beobachtet“ und bei Abweichungen
> Mitteilungen/Warnungen verschicken kann (z.B. hoher Wasserverbrauch in der
> Nacht, langer, hoher Stromverbrauch,…
> - Datenbank automatisch zum Webhoster senden; Graphen in wordpress
> erzeugen / naja das ist wohl eher mein Problem
>

Warum nutzt Du nicht data.png statt data.json?


> - Eine Idee wie man an Werte aus anderen Quellen, z.B. einer homematic
> Stuerung o.ä. ran kommt, ohne 90% der zeitlichen Auflösung zu verlieren.
> Irgendwas mit Event-Triggern, soll heissen wenn hier update dann Werte
> schnappen und Update im VZ oder so
>

Hatten wir wohl schonmal diskutiert, es ist weiterhin unklar wo das Problem
liegt...

…
>
>
Was mir bei den Features noch fehlt ist eine Echtzeitanzeige- sowohl für
das Frontend als auch für API Clients. Code dazu gibt es ebenfalls bereits,
da https://github.com/volkszaehler/volkszaehler.org/issues/219 ohne
Feedback blieb habe ich ihn jedoch nicht weiter integriert.

Viele Grüße,
Euer Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150221/852a4f83/attachment.html>