openWB Forum

osblo hat geschrieben: ↑Do Jan 07, 2021 7:35 am Ich lasse das mal einfach so stehen, auch wenn es m.E. falsch ist.
Wir haben hier keine sicherheitsrelevante Anforderung und bezüglich der Antwortzeiten habe ich mich schon ausgelassen.
Und für das Lastmanagement gibt es Rückfalloptionen.

Na was machst du z.B. wenn der Hersteller der Meinung ist, seine tolle Cloud API abzudrehen, zu verändern oder andere auszusperren?
Das Gemecker kommt dann als erstes hier an. Das ist unnötiger Supportaufwand.
Von daher bin ich da absolut auf der Seite von zimberg44
Bei lokalen APIs sieht das schon wieder ganz anders aus. Um die zu verändern muss der User zumindest mal selber irgendwie aktiv werden oder zumindest ein Update freigeben oder so. Bei Cloud Kram geht's dann einfach nicht und keiner weiß warum und Schuld sind eh immer die anderen.

osblo hat geschrieben: ↑Do Jan 07, 2021 7:35 am Ich lasse das mal einfach so stehen, auch wenn es m.E. falsch ist.
Wir haben hier keine sicherheitsrelevante Anforderung und bezüglich der Antwortzeiten habe ich mich schon ausgelassen.
Und für das Lastmanagement gibt es Rückfalloptionen.

Also das Lastmanagement, welches verhindert, dass meine Hauptsicherungen auslösen, würde ich durchaus als sicherheitsrelevant einstufen.

Und man sollte sich nicht auf best effort Internetverbindungen und ebensolche Cloud-Dienste verlassen. Ich verfolge den lokalen Ansatz bei der gesamten Smart Home Infrastruktur und habe zuletzt aus eben diesem Grund Tahoma rausgeworfen und durch KLF200 ersetzt. Auch wenn wegen best effort Diensten manchmal nur der Komfort leidet, schont der lokale Ansatz auch die Nerven.

Welche Rückfalloption hast Du beim Lastmanagement? Bereitliegende Ersatzsicherungen und eine persönliche vor Ort Überwachung wohl nicht?

Sorry, aber wenn du mit dem Begriff Rückfalloption bei fehlender Cloud Antwort nichts anfangen kannst und über durchgebrannte Sicherungen philosophierst dann ist vielleicht das Studium der Basics empfehlenswert.

Außerdem besteht durch den HTTP Ladepunkt ja durchaus die Möglichkeit die Easee-Wallbox selbst anzubinden, mit einer eigenen Zwischenstelle.
Das müsste halt jemand mit dieser Anforderung selbst programmieren (und dann hier für andere posten), damit gibt es ja schon die Möglichkeit Easee zu verwenden UND OpenWB ist supporttechnisch raus.
Einzig die Möglichkeit der Phasenumschaltung, welche die Easee glaube ich unterstützt, bin ich mir aber nicht sicher, ist mit dem HTTP-Ladepunkt denke ich noch nicht umsetzbar. Aber das könnte ja eventuell auch implementiert werden, indem der HTTP Ladepunkt einfach die Leistung für alle Phasen einzeln übergibt. Sind dann zwei Phasen auf 0, würde das einphasiges Laden heißen. Nur so als Idee...

Es war Osblo sein Wunsch seinen Account (und seine Beiträge) zu löschen. Diesem Wunsch bin ich nachgekommen.
Hierdurch fehlt in diesem Thread einiges an Zusammenhang, sollte sich jemand wundern.

Ich denke, dass es hier um eine grundlegende Einstellung geht.

Wenn ein OEM alles über seine cloud laufen lässt und keine lokale API bietet (openWB, go-e, smartWB haben das), zudem die SW nicht open source ist, dann ist es aus oWB-Sicht einfach legitim zu sagen, dass man sich hierfür nicht den (unbezahlten) Support auf den Tisch holt.
Der hochkompetente oWB-Support, das werden die oWB-Nutzer bestätigen, ist verglichen zu anderen OEM schon fast ein Alleinstellungsmerkmal. Hier sollte auf den Erhalt der Qualität und nicht auf Quantität (viele Fremdhersteller) geachtet werden.

btw
Sowohl go-e als auch Easee sind all-in-one-Produkte (aio), die günstig hergestellt werden (beiden fehlen zudem fest angeschlossene Ladekabel) und optisch ganz gut was hermachen. Upgrade- und reparaturfreundlich geht allerdings besser mit non-aio-Hardware, wie das z.B. openWB und smartWB praktizieren.

ps
Das mit der 1p3p-Umschaltung bei der Easee sollte erst einmal sicher geklärt werden, ob sie es tatsächlich kann. Im Produktvideo konnte ich zumindest nichts dazu finden. Nicht, dass die 1p-3p-Anklemmoption damit gemeint ist.
Dass 1p3p in http kommt, denke ich eher nicht. Das muss mit passender Hardware abgesichert werden, da sonst AC-Lader kaputt gehen können.

openWB hat geschrieben: ↑Do Jan 07, 2021 9:57 am Es war Osblo sein Wunsch seinen Account (und seine Beiträge) zu löschen. Diesem Wunsch bin ich nachgekommen.
Hierdurch fehlt in diesem Thread einiges an Zusammenhang, sollte sich jemand wundern.

Alter Schwede - mal Gegenargumente gehört und gleich in den Sack gehauen?
Egal - Konzentration auf oWB und weitere Verbesserungen.

aiole hat geschrieben: ↑Do Jan 07, 2021 9:58 am Der hochkompetente oWB-Support, das werden die oWB-Nutzer bestätigen, ist verglichen zu anderen OEM schon fast ein Alleinstellungsmerkmal. Hier sollte auf den Erhalt der Qualität und nicht auf Quantität (viele Fremdhersteller) geachtet werden.

Sehe ich genauso. Deswegen finde ich ist die HTTP-Schnittstelle eine super Lösung um trotzdem noch möglichst offen zu bleiben.

aiole hat geschrieben: ↑Do Jan 07, 2021 9:58 am Sowohl go-e als auch Easee sind all-in-one-Produkte (aio), die günstig hergestellt werden (beiden fehlen zudem fest angeschlossene Ladekabel) und optisch ganz gut was hermachen. Upgrade- und reparaturfreundlich geht allerdings besser mit non-aio-Hardware, wie das z.B. openWB und smartWB praktizieren.

Auch dass sehe ich genauso, aber am Ende muss das jeder für sich selbst entscheiden und muss das auch dürfen!

aiole hat geschrieben: ↑Do Jan 07, 2021 9:58 am Das mit der 1p3p-Umschaltung bei der Easee sollte erst einmal sicher geklärt werden, ob sie es tatsächlich kann. Im Produktvideo konnte ich zumindest nichts dazu finden. Nicht, dass die 1p-3p-Anklemmoption damit gemeint ist.

Ich habe mittlerweile schon aus ziemlich vielen Quellen gehört dass sie es kann, aber ja, richtig offizielle Aussgaen fehlen.

aiole hat geschrieben: ↑Do Jan 07, 2021 9:58 am Dass 1p3p in http kommt, denke ich eher nicht. Das muss mit passender Hardware abgesichert werden, da sonst AC-Lader kaputt gehen können.

Wäre finde ich halt eine super Möglichkeit um oWB als Open-Source Lösung nochmal ein bisschen offener zu machen.
Die Funktion müsste natürlich An/Ausschaltbar sein.
Wallboxen die das unterstützten, was es ja bis jetzt nicht gibt, Easee wäre meines Wissens nach die erste, müssen sich natürlich selbst um die entsprechende Sicherheit kümmern. oWB würde nur vorgeben OB einphasig oder dreiphasig geladen werden soll, und mit welcher Leistung geladen werden soll. Das Umschalten, inklusive aller Sicherheit, muss dann natürlich, wie auch jetzt schon das tatsächliche Anpassen der Ladeleistung, die Wallbox selbst übernehmen.

JSAnyone hat geschrieben: ↑Do Jan 07, 2021 10:18 am

aiole hat geschrieben: ↑Do Jan 07, 2021 9:58 am Dass 1p3p in http kommt, denke ich eher nicht. Das muss mit passender Hardware abgesichert werden, da sonst AC-Lader kaputt gehen können.

Wäre finde ich halt eine super Möglichkeit um oWB als Open-Source Lösung nochmal ein bisschen offener zu machen.
Die Funktion müsste natürlich An/Ausschaltbar sein.
Wallboxen die das unterstützten, was es ja bis jetzt nicht gibt, Easee wäre meines Wissens nach die erste, müssen sich natürlich selbst um die entsprechende Sicherheit kümmern. oWB würde nur vorgeben OB einphasig oder dreiphasig geladen werden soll, und mit welcher Leistung geladen werden soll. Das Umschalten, inklusive aller Sicherheit, muss dann natürlich, wie auch jetzt schon das tatsächliche Anpassen der Ladeleistung, die Wallbox selbst übernehmen.

Wäre technisch sicher machbar. Ein wenig hängt man da zwar als übergeordneter Energiemanager (oWB) mit drin, aber ja, die Umschaltsicherheit muss in der Box erledigt werden.

Was aber immer noch stört ist, dass - angenommen Easee kann 1p3p - oWB wunderbar die Vorgaben macht, aber Easee weder lokale API noch open source bietet (oder hat irgendjemand etwas auf Github gefunden?).

Ich schätze, dass sie ihr eigenes EM verkaufen wollen und deshalb cloud/closed source gewählt wurde. So ähnlich macht das auch die ID-charger-Fraktion. Bin mal gespannt, wann dort die ersten Abo-Modelle eingeführt werden .

ps
Gegen Diskussionen zu Fremdfabrikaten hat niemand etwas, solange es "umgänglich" zugeht. Wenn sich Osblo selbst entlässt, kann man nichts machen.

aiole hat geschrieben: ↑Do Jan 07, 2021 10:32 am Was aber immer noch stört ist, dass - angenommen Easee kann 1p3p - oWB wunderbar die Vorgaben macht, aber Easee weder lokale API noch open source bietet (oder hat irgendjemand etwas auf Github gefunden?).

Nicht Open Source ist natürlich ärgerlich. Und die fehlende lokale API seeeehr ärgerlich.
Der Solarmanager (ich würde sagen eine sauteure oWB Standalone mit weniger Funktionen ) unterstützt die Easee Wallbox ja schon, und da steht auch nochmal das mit der Phasenumschaltung. Leider verwendet der auch die Cloud-API zur Steuerung:
https://www.solarmanager.ch/produkt/un ... te-geräte/
Hier nochmal in nem anderen Artikel:
https://technikblog.ch/2020/10/elektro ... r-manager/