v0.17.0

[ledermann]

Neuerungen

• Dunkelmodus (Dark mode #1859)
• Sensoren für E-Auto-Ladestand und -Verbindung (Ladestand Elektroauto anzeigen #2881)

Verbesserungen

• Optimierte InfluxDB-Query zum Befüllen von Diagrammen
• Optimiertes Routing per URL zur Auswahl des Diagramms
• Besserte Bezeichnung für Eigenverbrauch
• Aktualisierte Abhängigkeiten, u.a. Puma 6.4.3, Turbo-Rails 2.0.10

Fehlerkorrekturen

• Beim Verlassen einer Seite werden Event-Listener jetzt korrekt abgemeldet

Full Changelog: v0.16.1...v0.17.0

---

This discussion was created from the release v0.17.0.

[boecks]

Hi Georg, du schreibst, das Routing per URL wäre jetzt optimiert, ist das gleichbedeutend damit, dass man auch ohne einen fiktiven Sensor zu haben ein Chart darstellen kann? Das ist ja ein offener Punkt aus dem PR für das kombinierte Chart.

Btw. deine Aufforderung für die neuen Features zu stimmen lässt für mich die Frage offen, was davon nur für Sponsoren kommen wird - wenn es kommt.

Ich kann dein Abo Modell aus wirtschaftlicher Sicht total verstehen, jedoch habe ich kein klares Bild vor Augen, wie Solectrus in Zukunft ausschauen könnte - vor allem für die User ohne Sponsoring. Wird ab jetzt jedes quality of life feature hinter die Paywall kommen?

Gleichzeitig ist dein verständlicherweise hoher Anspruch auf Code Qualität und deine Vision von Solectrus so stark präsent, dass das Contributing (was dir potentiell irgendwann viel Arbeit abnehmen könnte) kein einfacher Task ist.

Wäre es für dich auch denkbar etwas Einblick in die ökonomische Entwicklung von Solectrus zu geben? Vielleicht offenlegen wie viele User oder Instanzen es gibt usw. darauf kann man ja auch durchaus sehr stolz sein und es zeigen.

[ledermann]

Mit "Routing-Verbesserung" meinte ich den Commit 9c79700. Mit dem kombinierten Chart hat das eher wenig zu tun. Dein offener PR bleibt hochinteressant, ist in der letzten Zeit aber etwas untergegangen, da andere Dinge im Vordergrund standen.

Zu deinen anderen Fragen, die die Wirtschaftlichkeit betreffen:

Es ist eine wunderbare Erfahrung, ein Open-Source-Projekt zu betreiben. Solange ein Produkt kostenfrei ist, sind die Leute begeistert und dankbar.

Da ich aber nicht unbegrenzt von meinen Ersparnissen leben kann, ist die Idee des Sponsoring-Modells entstanden. Bislang läuft es auch gut an, aber da ist noch recht viel Luft nach oben ;-)

Langfristig werde ich meinen zeitlichen Einsatz für SOLECTRUS an die Sponsoring-Einnahmen koppeln. Je mehr reinkommt, desto mehr Zeit werde ich erübrigen können.

Es ist natürlich eine berechtigte Frage, ob zukünftige Features nur für Sponsoren oder auch für Free-User angeboten werden. Derzeitig werde ich mich auf Sponsoren-Features konzentrieren, und das hat drei Gründe:

1. Sponsoren halten: Wer sich einmal für ein Sponsoring entschieden hat, soll dies möglichst auch bleiben. Neue Features, die nur für Sponsoren verfügbar sind, liefern eine Bestätigung für die getroffene Entscheidung.

2. Sponsoren gewinnen: Mit jedem neuen Sponsor-Only-Feature erhöht sich die Motivation, ein Sponsoring-Abo abzuschließen.

3. Kapazität beachten: Features für Free-User zu entwickeln, geht eigentlich nur, wenn dafür Kapazitäten da sind, beziehungsweise wenn die Sponsoring-Einnahmen so hoch sind, dass ich mir das leisten kann. Das ist noch nicht der Fall.

Fehlerbehebungen und kleinere Verbesserungen wird es zweifellos auch für Free-User geben. Aber die großen Neuerungen werden wohl eher Sponsoren vorbehalten sein.

Ich hatte vor der Entscheidung für das Sponsoring-Modell viele Gespräche geführt - mit anderen Entwicklern, mit Nutzern, mit BWL-Spezis. Mir ist bewusst, dass es immer Leute gibt, die nicht bereit sind, für digitale Güter überhaupt etwas zu bezahlen. Oder zumindest nicht als Abo, sondern bestenfalls einmalig oder bei größeren Updates. Diese Meinung akzeptiere ich voll und ganz. Als Zielgruppe für SOLECTRUS sehe ich aber eher diejenigen, die bereit sind, ein gutes Produkt auch finanziell zu unterstützen.

SOLECTRUS hat mittlerweile auch für den Free-User einen breitgefächerten Funktionsumfang. Wer grundsätzlich nicht zahlen möchte, erhält dennoch viel geboten. Aber mein Ziel muss sein, die Sponsoring-Einnahme zu steigern, also möglichst jeden Free-User zu einem Sponsor zu machen.

Jetzt zum Contributing:

Derzeitig gibt es noch nicht so viele andere Entwickler, die eigenen Code beisteuern. Du bist einer davon und fällst somit aus dem Sponsoring-Zwang heraus. Ich bin dankbar für deinen bisherigen Einsatz und freue mich über jeden weiteren Beitrag.

Code-Qualität ist für mich eine wichtige Anforderung, der ich mich auch selbst unterwerfe. Der von dir begonnene PR #3211 mit dem kombinierten Chart kollidiert nicht mit meinen hohen Erwartungen - ganz im Gegenteil finde ich den bisherigen Code sehr wertvoll! Die gestellte Aufgabe ist allerdings wirklich nicht trivial und erfordert auch einige Umbauten in SOLECTRUS. Das lässt sich aber lösen, denke ich.

[Zeppelin-PV]

hallo Georg
mein erster Raspi hat sich über Watchtower (latest - nicht develop) die 17.0 geholt
jetzt werden nur Zahlen statt Texte angezeigt, auch nach einem manuellen docker compose pull && docker compose up -d

der zweite Raspi mit Watchtower (develop) zeigt Texte an

--- Entwarnung
mit docker compose down und docker compose pull && docker compose up -d geht es wieder

[pauldresen]

Hallo Georg,
die .env bei mir hat noch keine Definition der Sensoren. Wenn ich eine neue .env mit dem Configurator erzeuge, reicht es dann, mit der neuen .env Docker neu zu starten. Muß ich auch die mit dem Configurator erstellte *.yaml anstelle der bisherigen *.yml benutzen?

[ledermann]

Für die Umstellung auf die Sensor-Konfiguration empfehle ich diesen Artikel:
https://docs.solectrus.de/wartung/sensor-konfiguration

Wenn du den Konfigurator verwenden möchtest (der eher nur für Neuinstallationen gedacht ist), müsstest du sehr darauf achten, dass du danach die Sensoren so einstellst, dass sie zu deinen bestehenden Daten passen - sonst werden deine historischen Daten nicht mehr angezeigt. Es ist daher sicherer, den im obigen Link erklären Weg zu gehen.

Die Compose-Datei muss übrigens nichts umbenannt werden. In älteren Docker-Versionen hieß es docker-compose.yml, aktuell ist compose.yaml der empfohlene Name. Docker kommt aber mit beidem klar, der Inhalt ist der gleiche.

[pauldresen]

Hallo Georg,
vielen Dank für den Hinweis.
"Eine Warnung im Docker-Log des Dashboards sieht z.B. so aus:"
Kannst Du bitte einem DAU erklären, wo ich das Docker-Log finde.

[ledermann]

Das geht mit docker compose logs dashboard (ggfs. docker compose logs app, je nachdem, wie der Service in deiner Compose-Datei heißt).

Etwas mehr Infos dazu findest du hier:
https://docs.solectrus.de/support/docker#protokoll-der-docker-container

Die Docker-Logs sind wirklich essenziell, um bei etwaigen Problemen eine Lösung zu finden. Sonst ist man im Blindflug unterwegs.