<div dir="ltr"><div>Hallo Zusammen,<br><br></div>anbei mein Feedback zur Umfrage bzw. der resultierenden Wunschliste.<br><div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-09 9:48 GMT+01:00  <span dir="ltr"><<a href="mailto:justin@justinotherguy.org" target="_blank">justin@justinotherguy.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Moin,<br>
<br>
vielen Dank für die Teilnahme!<br>
<br>
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).<br>
- die meisten nutzen den RPi unter Debian und betreiben diesen bei sich selbst<br>
- keiner scheint <a href="http://demo.volkszaehler.org" target="_blank">demo.volkszaehler.org</a> zu verwenden (das ist für mich eine gute Nachricht; das verringert den Druck, wenn er mal wieder nicht tut (c: )<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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<br>
- 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!)<br>
- 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<br></blockquote><div><br></div><div>Aus meiner Sicht unser Schwachpunkt und nur in einer konzertieren Aktion lösbar. Bachelorstudent o.ä. mit Arbeitsauftrag...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Fühlt Euch eingeladen, Eure eigenen Schlüsse zu ziehen (und hier zu posten).<br>
<br>
Ich werde drüben auf vz-dev eine Info-Mail zu dieser Umfrage schicken.<br>
<br>
<br>
Gruß, J.<br>
<br>
<br>
Hier die Ergebnisse im Detail (13 Antworten):<br>
...<br>
<br>
Frontend<br>
<span class="">- Ein Berechtigungskonzept mit Login für das Frontend wäre wirklich gut :-)<br>
</span><span class="">- Eine Art Benutzerverwaltung/Login für das Frontend<br>
</span>- Dashboard für das Frontend wäre cool…<br></blockquote><div><br></div><div>Aktuell böte sich <a href="http://freeboard.io">freeboard.io</a> an und ist im aktuellen Image von Udo schon integriert.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">- Flexible Dashboard-Gestaltung, z.B. mehrere Graphen, zusätzliche Meter wie Gauges etc.<br>
- Stacked Lines, z.B. vorzeichenrichtiger Verbrauch und Einspeisung mit negativem Verbrauch (also Netzeinspeisung) im -y Quadranten<br></span></blockquote><div><br></div><div>Bitte konkretes Issue dafür aufmachen.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
- Darstellung von Gesamtverbrauchswerten ohne den Fehler durch die zeitliche Aggregation, z.B. Tag, Woche, Monat, Jahr<br></span></blockquote><div><br></div><div>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.<br><br></div><div>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).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span><span class="">- Rechenoperationen mit den Werten, z.B. für eine PV Eigenverbrauchquote<br></span></blockquote><div><br></div><div>Sowas liegt im dev-Zweig bei mir. Integration möglich wenn es genug Publikum dafür gibt.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>- Auswertung per App<br></blockquote><div><br></div><div>Alternativ: mobiltaugliches Frontend, dazu habe ich einen Lösungsansatz.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Doku<br>
<span class="">- Das Wiki könnte etwas "kompakter" sein (hier unterstütze ich gerne)<br>
- 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.<br></span></blockquote><div><br></div><div>Definitiv. Aus meiner Sicht bräcuhte die Webseite einen Neustart, siehe oben.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>- 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.<br>
<br>
Auswertung<br>
- Logbuchmöglichkeit z.B. Dienstag 13.01.2015 18:00 Uhr - 19:42 Uhr Spülmaschine eingeschaltet<br>
- Grundlast ausblenden um zu sehen welche tasächliche Leistung hat z.B. der Toaster<br>
<span class="">- 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.<br></span></blockquote><div><br></div><div>Sehr einfach zu realisieren...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>- schönere und flexiblere Auswertung (einzelne Diagramme, Heatmap wie neulich vorgestellt)<br>
- "user defined queries" (z.B. die Tagestiefsttemperaturen eines channels)<br></blockquote><div><br></div><div>Gute Idee aber schwierig soetwas performant zu machen- jedenfalls wenn es für alle Kanaltypen funktionieren soll. Gibt es dafür breiteren Bedarf?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">- Export PDF Datei mit Verbrauch und Kosten für Gesammtes Jahr mit einzelnen Monaten auf einer Seite währe Super<br></span></blockquote><div><br></div><div>Passt gut zur "Verbrauchsansicht". Ein Issue mit Detaillierung der Anforderungen wäre hilfreich.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>vzlogger<br>
- Vzlogger kann die GPIOs lesen<br>
<br>
allgemein<br>
- SCHNELLERE Auswertung (trotz Aggregation immer noch lahm)<br></blockquote><div><br></div><div>Da bin ich gespannt. @Daniel: falls der Punkt von Dir kam haben wir das ja gelöst.<br><br></div><div>@all: wer trotz Aggregation Performanceprobleme hat schreibt bitte eine Mail- das geht gegen die Ehre ;)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- stabilerer Betrieb (siehe oben - SD-Karte macht regelmäßig Ärger, System hängt sich auf)<br>
- Monitor-Daemon, der geloggte Werte „beobachtet“ und bei Abweichungen Mitteilungen/Warnungen verschicken kann (z.B. hoher Wasserverbrauch in der Nacht, langer, hoher Stromverbrauch,…<br>
<span class="">- Datenbank automatisch zum Webhoster senden; Graphen in wordpress erzeugen / naja das ist wohl eher mein Problem<br></span></blockquote><div><br></div><div>Warum nutzt Du nicht data.png statt data.json?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span><span class="">- 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<br></span></blockquote><div><br></div><div>Hatten wir wohl schonmal diskutiert, es ist weiterhin unklar wo das Problem liegt...<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span><span class="">…<br><br></span></blockquote><div><br></div><div>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 <a href="https://github.com/volkszaehler/volkszaehler.org/issues/219">https://github.com/volkszaehler/volkszaehler.org/issues/219</a> ohne Feedback blieb habe ich ihn jedoch nicht weiter integriert.<br><br></div><div>Viele Grüße,<br></div><div>Euer Andreas<br> <br></div></div><br></div></div></div>