Update zur Sommerankündigung

[Stephan86]

Wenn du unbedingt möchtest deaktivieren wir das dann bei Zeiten noch in einem 1.9 Update.

Fände ich nur Konsequent und richtig.

Genau das hatte ich vor einigen Seiten ja bereits zur Diskussion gestellt:
viewtopic.php?p=43926#p43926

[Bastelfrosch]

Ich habe gestern ein etwas längeres Gespräch mit unserem Elektriker geführt. Er konnte keine Vorschrift finden oder benennen, in der steht, dass das Lastmanagement "ein Fehler sicher" ausgeführt werden muss.
Weiterhin bauen wir so, dass immer noch Sicherungselemente vorhanden sind, die auslösen bevor der Hausanschluss den Geist aufgibt.

[aiole]

Ein Elektriker ist allerdings kein EVU. Von letzteren gibt es etliche, wo jeder das LM sicher etwas unterschiedlich handhabt.

Um zukünftige Probleme bei möglichst vielen EVU auszuschließen, ist der nun gewählte Ansatz m.E. gut geeignet. Es ist auf jeden Fall EVU-freundlicher, denn das Risiko des Nichtfunktionierens wird durch das Ausklammern der nichtkompatiblen WB minimiert.

Man sollte auch davon ausgehen, dass die Fähigkeiten bezüglich des LM-Thema bei den EVU zunehmen werden. Dahingehend sind einfache und klare Angaben seitens oWB wichtig, auch wenn das aktuell noch nicht erforderlich scheint.

OWB blickt mit v2.x in die Zukunft und da muss man für neue Anforderungen gerüstet sein. Nur weil ein EVU (aktuell) nicht im Detail durchblickt, kann es oWB nicht dauerhaft für Fremd-WB auf seine Kappe nehmen. Missbrauch sollte auch von Herstellerseite begegnet werden.

Man hat sich gegen die ursprünglich geplante Kostenverrechnung + einhergehendes Ausklammern entschieden. Das ist logisch und konsequent.

[Bastelfrosch]

Grundsätzlich bin ich bei Dir, alles was besser ausgeführt ist, als normativ vorgegeben, erspart eine Menge Diskussion mit dem EVU.
Allerdings mache ich mir ein wenig Sorgen, dass die openWB-Satelliten bei dieser Aktion hinten rüber fallen und das wäre bei mir gar nicht tragbar.

In der Vergangenheit habe ich nämlich extra auf Grund der Stabilität des Systems pro Hausanschluss nur einen Raspi laufen und die Satelliten über Modbus TCP angeschlossen. Damit sind alle Fehler bezgl. Kommunikation unter den einzelnen Raspis (inkl. defekter SD-Karte, fehlgeschlagenes Update, Bootproblem etc )ausgeschlossen.
Auch die Problematik des noch ungelösten Kommunikationsproblems bei 8 LP mit eigenen RPis ist dort nicht gegeben.
die Konfigurationen laufen alle störungs- und wartungsfrei.
Aber die lang erwarteten Features der V2.0 sollen da auf jeden fall mit aufgenommen werden.

[aiole]

Grundsätzlich bin ich bei Dir, alles was besser ausgeführt ist, als normativ vorgegeben, erspart eine Menge Diskussion mit dem EVU.
Allerdings mache ich mir ein wenig Sorgen, dass die openWB-Satelliten bei dieser Aktion hinten rüber fallen und das wäre bei mir gar nicht tragbar.

Satellit ist auch mein Metier - da wird eine Lösung gefunden werden und wenn es etwas zum Austausch/Nachrüsten ist. OWB-HW hat den höchsten Stellenwert.

Bedenklich ist hier der permanente Anspruch eines users, LM kostenfrei und durch oWB abgesichert mit Fremd-WB-Systemen realisieren zu wollen. Das funktioniert nicht, wenn deren Hersteller nicht zusammenarbeiten, die WB nicht kompatibel anpassen und sich am Aufwand beteiligen.

[Bastelfrosch]

Austausch/Nachrüstung für eine bereits bestehende und abgenommene Anlage mit openWB-Satelliten, um auf V2.0 zu gehen, finde ich nicht praktikabel und nicht wünschenswert. Anlagen im Bestand sollten auch mit V2.0 ohne Hardware-Anpassung weiter betrieben werden können.
Alles andere ist kaufmännisch suboptimal

Bzgl. Fremd-Hardware ist ja hier glaube ich schon alles gesagt worden....

[aiole]

Austausch/Nachrüstung für eine bereits bestehende und abgenommene Anlage mit openWB-Satelliten, um auf V2.0 zu gehen, finde ich nicht praktikabel und nicht wünschenswert. Anlagen im Bestand sollten auch mit V2.0 ohne Hardware-Anpassung weiter betrieben werden können.
Alles andere ist kaufmännisch suboptimal

Wir werden sehen, was die effizienteste Lösung ist. Ich gebe nur zu bedenken, dass es bei anderen Herstellern mit größerem update häufig heißt: "Geht nicht - kaufe komplett neu oder bleibe bei der Vorgängerversion." Das ist nicht der oWB-Anspruch. Zaubern können jedoch auch sie nicht, denn nicht alles ist mit "SW-only" machbar.

[Jarry]

Wenn du unbedingt möchtest deaktivieren wir das dann bei Zeiten noch in einem 1.9 Update.

Fände ich nur Konsequent und richtig.

Genau das hatte ich vor einigen Seiten ja bereits zur Diskussion gestellt:
viewtopic.php?p=43926#p43926

Ja und darauf wurde auch seitens des Teams eingegangen. Da du aber scheinbar nur selektiv liest was dir in den Kram passt, scheint das an dir vorüber gegangen zu sein....

[Bastelfrosch]

Wir werden sehen, was die effizienteste Lösung ist. Ich gebe nur zu bedenken, dass es bei anderen Herstellern mit größerem update häufig heißt: "Geht nicht - kaufe komplett neu oder bleibe bei der Vorgängerversion." Das ist nicht der oWB-Anspruch. Zaubern können jedoch auch sie nicht, denn nicht alles ist mit "SW-only" machbar.

sicherlich macht es keinen Sinn hier über ungelegte Eier zu sprechen, allerdings mache ich mir hier Sorgen, da ich einige Installationen in Betrieb habe, die nur "notdürftig" laufen und auf V2.0 warten. Hier war bei Installation der Anlagen schon klar, dass V2.0 benötigt wird, entweder, weil andere Messkonzepte berücksichtigt werden sollen oder es auch mehr als 8 LP sind.
Nach Aussage von openWB sollten sowohl die die Satelliten als auch die alten Duo-Versionen in V2.0 unterstützt werden.

Sicherlich ist die Variante mit der Heartbeat-Erkennung nett, aber wenn das EVU das nicht fordert und die Anlage so in Betrieb gegangen ist, sollte das nicht nachträglich noch umgebaut werden müssen.

btw, wir schreiben hier nun seit gefühlt 200 Seiten über eine Software, die noch keiner gesehen hat
gibt es einen Termin für eine Beta-Version zum testen ??

[aiole]

2021