openWB Forum

Ich denke auch, dass Abo-Modelle in der letzten Zeit deutlich an Akzeptanz gewonnen haben. (Geht ja in vielen Fällen auch gar nicht anders bzw. man hat ja keine Wahl) Ob das in dem open source Bereich auch der Fall ist, gälte es zu eruieren. Ich meine evcc macht ja nun nichts anderes. Und das mit dem nicht funktionierenden Heartbeat bei Fremdhardware ist ja eigentlich kein Hinderungsgrund, sondern nur ein Argument. Wer das Lastmanagement gegenüber dem VNB bestätigt haben möchte, muss halt die richtige Hardware kaufen.

Die Frage ist nur, ob man alle Leute von damals noch zusammenbekommt.

Eine gescheite, modulare und damit wirklich nachhaltige Ladehardware, ist mir persönlich schon sehr wichtig. Deren Vorteile zeigen sich leider nicht gleich zu Beginn - eher im Gegenteil, da bei Kauf teurer. Dafür kann man die openWB dann sehr lange nutzen und bei Problemen einfach Einzelteile tauschen. Dank der sw2-updates bleibt das HEMS im Ganzen aktuell.

Man darf auch nicht verkennen, dass openWB einen wirklich professionellen, fachkundigen Support (mit echten Techies) für seine Partner und Endkunden bietet. Sie kennen sich 1a mit allen möglichen Energiesystemen aus - nicht nur mit openWB. So etwas ist nicht günstig mit üblichem Privat-Abo abbildbar, da man auch die Fremdfabrikate kennen muss. Ein Nerd kann vermutlich darauf verzichten, aber nicht die "normalen" Leute.

Ich wollte da jetzt keine Grundsatzdiskussion lostreten

Aber damals war es ja konkret von openWB so geplant. Das bedeutet, auf all die von aiole angesprochenen Punkte muss es ja auch damals schon eine Antwort/Lösung gegeben haben bzw. oWB muss sich darüber im Klaren gewesen sein. Damals waren eigentlich sogar genau das die Gründe (bzw. einige der Gründe) für das Abo bzw. für eine zusätzliche Bezahlung. Erst auf „Druck“ der hiesigen Community wurde davon dann Abstand genommen.

Ich wollte damit nur sagen, dass sich die Einstellung bzw. Situation bezüglich dieser Art der Bezahlung vielleicht schon etwas gewandelt haben könnte und nun vielleicht auf breitere Akzeptanz stoßen würde. Wie gero schon schrieb: andere machen es ja auch irgendwie…

Wollte nur einen Denkanstoß geben.

Aber damals war es ja konkret von openWB so geplant. Das bedeutet, auf all die von aiole angesprochenen Punkte muss es ja auch damals schon eine Antwort/Lösung gegeben haben bzw. oWB muss sich darüber im Klaren gewesen sein.

Damals war die Situation aber auch etwas anders als heute.

Damals haben wir gegenüber dem Netzbetreiber für unser Lastmanagement eingestanden.
Wäre es so gekommen hätten wir das ausschließen müssen oder uns etwas überlegen müssen. Tatsächlich gab es bereits Überlegungen mit extra Schützen den Ladepunkt kappen zu können.

Gerade mit §14a hat sich die rechtliche Lage aber grundlegend geändert.
Der Betreiber ist dazu verpflichtet Sorge zu tragen das im Fehlerfall (Software stürzt ab, Netzwerk nicht erreichbar, usw...) der gedimmte Zustand erreicht oder unterboten wird. In unserem Kosmos mit Dimm und Control Kit und unseren Ladepunkten mit Heartbeat ist das auch kein Thema.
Die Problematik haben wir ja schon bei Speichern die "nur" per ModbusTCP steuerbar sein aber keine Heartbeat Funktionalität haben.

Wenn wir nun als HEMS mit §14a werben, diese Anforderung aufgrund eines fehlenden Heartbeats aber nicht zur Verfügung stellen ist das in meinen Augen irreführende Werbung. Der Betreiber verstößt (ggf. unwissend) gegen seine Pflichten den sicheren Betrieb zu gewährleisten. Im Fehlerfall ist aber nicht sichergestellt das gedimmt wird.
Ob sich der Betreiber darüber im klaren ist oder nicht sei mal dahingestellt.
In der Folge sollte der Kunde/Betreiber dann aber (zurecht) rechtlich einen Anspruch haben.

Ich wollte damit nur sagen, dass sich die Einstellung bzw. Situation bezüglich dieser Art der Bezahlung vielleicht schon etwas gewandelt haben könnte und nun vielleicht auf breitere Akzeptanz stoßen würde. Wie gero schon schrieb: andere machen es ja auch irgendwie…

Tjoa...

Wollte nur einen Denkanstoß geben.

Danke dafür. Gerne interessiert mich dazu auch mehr Feedback.