• Doku neu bauen, nicht umbauen (parallel zur aktuellen Doku)
• Einstiegsseite mit 3 Buttons → Benutzer weiß sofort, welcher für ihn der richtige ist
• verlinkt auf eine neue Struktur (Link auf die alte Struktur weiterhin vorhanden; alte Struktur inkl. der Links bleiben)
• Doku nicht mehr so tief, statt dessen ein Link auf die Readme.md „in der Nähe“ der Stelle im Code auf github (das erleichtert auch die Pflege der Doku im Zuge der Code-Pflege)

• kompletter neuer Zweig, der ohne Config auskommt, statt neuem Tool zum Schreiben der Config?

• derzeit nicht vorhanden
• könnte ergänzt werden, ohne das bestehende Konzept zu verändern
• Anmeldung würde erlauben, an mehreren Browsern auf alle Kanäle zuzugreifen

• counter
• meter
• sensor
• → Vorschlag in github-Issue eingebaut

• Frontend: Touchsupport → s. github-Issue
• Frontend: Feature Säulendiagramme in 2 Ausbaustufen → s. github-Issue
• Frontend: highcharts einschließlich Minimap
• Middleware: Umbau Aggregation (lohnt das?)
• Middleware: Virtuelle Kanäle (=rechnen mit Kanälen) → s. github-Issue
• Offtopic: PVlng

• vzlogger optional ssl sprechen lassen und für push-server auf web-socket zugreifen lassen analog /ws

- Kanäle abfrage & schreiben (klassisch über Middleware)
- "realtime" Updates (wie das Frontend sie heute schon über WAMP bekommt)

Beim 2. Punkt schließt sich der Kreis zur Frage von Bernd "ich will mqtt & wieso gibts das nicht". Ich überlege gerade wie wir z.B. dem pushserver "einfache" websockets statt dem etwas sperrigen WAMP beibringen können. Den PHP-Support dafür gibt es und die Infrastruktur dafür haben wir auch.

Anstatt dann weitere Protokolle wie MQTT etc. in pushserver oder vzlogger einzubauen könnten wir die über MQTT per drag & drop integrieren.

• MQTT: die ideale Ergänzung für VZ ist node-red. Damit könnte man die push-server Nachrichten dann ganz locker via mqtt in die Welt verteilen und braucht nicht mehr als 5 Zeilen Code.

• lösen wir das oder kann das weg?
• → erledigt für vzlogger und volkszaehler

• aktuelles
• twitter-feed
• …