openWB Forum

Das ist schon eine Möglichkeit, aber auch sehr aufwändig, das sicher und sinnvoll zu implementieren. Und den Support Aufwand der da entstehen kann, kannst du vermutlich als kleine Firma gar nicht leisten.

Wenn du das siehst, was openWB jetzt an Modi implementiert hat, findest du meiner Meinung nach in keinem anderen Produkt. Es wird immer noch was geben, was man verbessern kann, oder einen Fall, den man mit der V1.9 nicht out of the Box einstellen kann.

Schau dir andere Anbieter an, Go-e hat seinen lange angekündigten Controller immer noch nicht realisiert. Ohne Support eines eigenen Energie Managers leben sie anscheinend besser.


SMA kann nur in seinem Universum laufen. Obwohl ich einen alten SMA WR habe, könnte ich aber ohne große und teure Umbauten, den SMA Lader nicht einsetzen. Ich glaube Kostal hat gerade seinen Lader verschoben. Zappi kann noch keine automatische 1p 3p....

Bei openWB hast du schon sehr viel sinnvolles drin und für die Sonderfälle zumindest die Möglichkeit, über MQTT deine individuellen Anforderungen zu implementieren.

Der Smarthome Bereich kann auch schon sehr viele Anforderungen erfüllen, aber die Flexibilität eines openHAB, iobroker oder FHEM... kann es nicht bieten. In diesen Systemen stecken viele Mannjahre an Entwicklung drin.

Mir ist es gerade wichtiger, dass die V2.0 auf die Beine kommt. Hier sind Features drin, die die Ladung des Fahrzeugs noch weiter verbessert (Ladestrom im mA Bereich regeln), Regelsprünge vermeiden...
Das sind Verbesserungen, die dem Produkt und den Kunden insgesamt helfen.

Nur meine Meinung als zahlender Kunde und Freizeit SoC Modul Programmierer.

VG
Det

Yup - v2 hat mWn. nun oberste Prio.

Interne Scripte sehe ich gesamtheitlich betrachtet leider auch kritisch. Bereits die normale Konfig stellt manche Anwender:innen vor eine Herausforderung. Da v2 noch mehr als v1.9 kann, wird es dort also auch nicht weniger.

Eine zusätzliche Scriptingoption geht dort garantiert nach hinten los. Man würde die Büchse der Pandora öffnen.
Besser weniger Spezialoptionen, dafür das Grundsystem stabil, funktionierend und für viele Nutzer:innen gut bedienbar.

Ich denke die freaks hier können gut die spezielleren Lösungen mit NR + MQTT bauen. Irgendwann wird's auch wieder RPi's geben und der kann mit seinen 3 Watt auch bei ggf. Nicht-freaks parallel mitlaufen. Die Freaks packen NR gleich mit auf oWB v2.

derNeueDet hat geschrieben: ↑So Aug 14, 2022 8:22 am Das ist schon eine Möglichkeit, aber auch sehr aufwändig, das sicher und sinnvoll zu implementieren. Und den Support Aufwand der da entstehen kann, kannst du vermutlich als kleine Firma gar nicht leisten.

Ist das wirklich so? Es könnte ja per mqtt kommunizieren, dann ist die Schnittstelle klar definiert und sollte keine Probleme machen. Vermutlich könnte man doch da sogar was einbauen, was es open source schon gibt. Es ginge ja nur darum, dass es kein extra Gerät dafür braucht. Support Aufwand sehe ich nicht wirklich. Wenn das ein eigener Lademodus ist, der erst mal gar nichts tut und den man programmieren kann, dann wäre es aus meiner Sicht völlig legitim, dass dessen Funktionalität logischerweise nicht von openwb supportet wird, wie ja jetzt auch externe Steuerungen nicht supportet werden. Dafür könnte man aber Ideen, die nur für Einzelne interessant sind recht schnell per Skript und gegenseitiger Hilfe im Forum umsetzen.

aiole hat geschrieben: ↑So Aug 14, 2022 1:49 pm Yup - v2 hat mWn. nun oberste Prio.

Interne Scripte sehe ich gesamtheitlich betrachtet leider auch kritisch. Bereits die normale Konfig stellt manche Anwender:innen vor eine Herausforderung. Da v2 noch mehr als v1.9 kann, wird es dort also auch nicht weniger.

Eine zusätzliche Scriptingoption geht dort garantiert nach hinten los. Man würde die Büchse der Pandora öffnen.
Besser weniger Spezialoptionen, dafür das Grundsystem stabil, funktionierend und für viele Nutzer:innen gut bedienbar.

Ich denke die freaks hier können gut die spezielleren Lösungen mit NR + MQTT bauen. Irgendwann wird's auch wieder RPi's geben und der kann mit seinen 3 Watt auch bei ggf. Nicht-freaks parallel mitlaufen. Die Freaks packen NR gleich mit auf oWB v2.

Aber das ist doch ökonomisch und ökologisch Schwachsinn, dass ich mir einen zweiten Raspi hinstellen soll für eine Funktionalität, die auf dem einen sicher drin wäre. Und wenn es Anfragen wie diesen Thread gibt, wäre es ein Leichtes, zu sagen (natürlich nicht offiziell und supportet sondern als Hilfe von Anwender zu Anwender): hier, nimm dieses Skript als Lademodus, das tut, was du willst. Wenn du hingegen sagst, kauf dir einen Raspi für 100 Euro, richte ihn ein, installiere ein Programm drauf und programmiere es, dann wird der durchschnittliche Kunde (der ja denkt, man kann seinen Wunsch ja sicher erfüllen, er hat ja extra eine open source box gekauft) enttäuscht sein.

therobbot hat geschrieben: ↑So Aug 14, 2022 6:37 pm Aber das ist doch ökonomisch und ökologisch Schwachsinn, dass ich mir einen zweiten Raspi hinstellen soll für eine Funktionalität, die auf dem einen sicher drin wäre.

nope (und "Schwachsinn" ist in Diskussionen eher kontraproduktiv)
Versetzte Dich einfach in den Support des Herstellers und bedenke, dass nicht jede(r) mit Deinem Wissen gesegnet ist. Du kannst Dir dann ansatzweise ausmalen, was das für Aufwand generieren wird.

therobbot hat geschrieben: ↑So Aug 14, 2022 6:37 pm Und wenn es Anfragen wie diesen Thread gibt, wäre es ein Leichtes, zu sagen (natürlich nicht offiziell und supportet sondern als Hilfe von Anwender zu Anwender): hier, nimm dieses Skript als Lademodus, das tut, was du willst.

Wenn etwas "fest" integriert ist, wird es auch genutzt. Ist eine ganz normale Kosten/Nutzen-Abwägung. Wenn <1% der Nutzer:innen davon Gebrauch machen, aber 10% des Gesamtsupportes verbrauchen, ist das aus Herstellersicht nicht unbedingt sinnvoll bzw. sogar gefährlich.

therobbot hat geschrieben: ↑So Aug 14, 2022 6:37 pm Wenn du hingegen sagst, kauf dir einen Raspi für 100 Euro, richte ihn ein, installiere ein Programm drauf und programmiere es, dann wird der durchschnittliche Kunde (der ja denkt, man kann seinen Wunsch ja sicher erfüllen, er hat ja extra eine open source box gekauft) enttäuscht sein.

Er/sie kauft eine closed source Hardware mit open source-Software .
Ich bin sicher - der durchschnittliche Kunde kommt locker mit der gebotenen Funktionalität aus (zumal v2.0 nochmal einen großen push bietet).

Vielleicht könnte man als Kompromiss einfach nodeRED mit auf's Image packen und genauso wie die SoC-Module vom Support her ausschließen.

Ich weiß aber natürlich nicht, was man sich damit alles kaputt machen kann. Aber je nachdem was man da für nodes nachinstalliert kann man sich bestimmt auch was endgültig zerschießen. Gut, neue SD-Karte rein und aufs neue loslegen, sollte ja klappen. Aber es ist ja durchaus fraglich, ob der Durchschittsanwender so etwas auch wirklich braucht und explizit nachfragen würde. Könnte man ja vielleicht optional anbieten. Obwohl ja die Leute, die sich intensiver mit der Materie beschäftigen, wegen smarthome und so 'eh schon irgendwo einen Rapspi rumliegen.

Eine eigene Skriptsprache zu implementieren halte ich auch für übertrieben.

Das ist ein bisschen so, als würde ein Autohersteller jetzt mal eben so bidirektionales Laden für den Akku freigeben. Es gibt eine Mehrbeanspruchung des Systems (von 0 bis open end alles möglich) und keine Gegenleistung. Ich hätte da erhebliche Bauchschmerzen.

Getrennte Systeme haben m.E. auch Vorteile. Es wird einfach redundanter und bei Problemen zerstört man sich nicht auch noch mitlaufende Systeme. Es gibt gute Gründe oWB auf eigener HW laufen zu lassen.

Es ist immer wieder witzig zu sehen wo sich ein Thema hin entwickelt. Ich frage nach eurer Meinung zu einer bestimmen Funktion:

„Ist es eurer Meinung nach sinnvoll, dass bei der Einstellung: PV-Ladung +zusätzlicher mindestSOC der mindestSOC soweit Vorrang hat das die OpenWB trotz höher möglicher PV Leistung auf die eingestellte mindestSOC Amperezahl reduziert zum Laden, oder seit ihr wie ich der Meinung das wenn ich PV laden einstelle ich auch in erster Linie PV Laden möchte und nur für den Fall das zu wenig vom Dach kommt das Auto eben dann mit der mindest eingestellten Stromstärke läd?
Ihr könnt mir gerne auch erklären warum es gut sein soll, die MindestSOC Einstellung so zu bevorzugen. Klar kann ich wie der Support sagen: Stell halt die maximal mögliche Amperezahl ein, dann bekommst auch das maximale was vom Dach möglich ist, aber ich will eben mein Netzbezug auf ein mindestmas reduzieren. Und wenn ich die Zeit zum Laden habe finde ich das auch richtig. Daher kommt bei mir auch Nachtladen nicht in Frage.

Und das Thema artet aus zu einem generellem hinterfragen des Produktumfangs und was alles noch möglich sein sollte und was nicht usw. usw.
Das war ja aber gar nicht die Frage
Also nochmal, wenn ihr eine Meinung zu diesem Thema habt und sie auch los werden wollt, schreibt sie gerne hier rein. Ich sehe das nämlich demokratisch wenn es viele so wie ich sehen dann kann man das den Programmierern gerne auch mal weiterleiten. Wenn allerdings die Mehrheit die Funktion so richtig programmiert sieht (aus welchen Gründen auch immer, wie gesagt wenn ihr hier welche habt schreibt mir die) dann kann ich das natürlich auch sehr gut akzeptieren und wer weiß, vielleicht ändert sich ja dann sogar meine Meinung zu dem Thema

Ich bin deiner Meinung, habe aber die Hoffnung aufgegeben, dass solche Sachen berücksichtigt werden.

Ich bin auch Deiner Meinung - vermutlich wird es in der 1.9 aber nichts mehr werden. Und als Grundausstattung der 2.0 sicherlich auch nicht.