Feedback 2.0 Alpha 1

[LenaK]

Der Broker mit Port 1886 ist nur von localhost aus erreichbar, ist also "intern". Der andere Broker mit dem Standardport ist vom UI und der Cloud erreichbar. Die beiden Broker sind über eine Brücke verbunden.
Alle Topics werden an openWB/set gepublished und dann im setdata-Modul validiert und an den internen Broker gepublished. Topics, die nur vom Algorithmus benötigt werden, zB Zwischenergebnisse, werden nicht auf den öffentlichen Broker gepublished. Einstellungen und Modulwerte werden über die Brücke auf den öffentlichen Broker gepublished, damit sie im UI entsprechend angezeigt werden können. Der Algorithmus arbeitet nur mit dem internen Broker. Von "außen", also nicht vom Algorithmus selbst, kann dorthin nur über openWB/set gepublished werden. So wird sicher gestellt, dass auf dem internen Broker nur gültige Werte für den Algorithmus liegen.

[hhoefling]

Also alle Externen Module die via MQTT Daten einliefern erzeugen die doppelte Last
extern->MQTT(1883)->Prüfung->MQTT(1886)

Alles was sichtbar werden soll ebenfalls
Algo->MQTT(1886)->Bridge->MQTT(1833)

Schon getestet on das die 3B+ mitmachen?

Hm... gibts keine möglichkeit die "internen" Daten anders zu schützen
z.b mit einer Art Read-Only Zweig im MQTT

Fehlersuche und "Reparaturen" via MQTT-Desktop sind dann aber stark erschwert.
Das muss denn eine SSH Portweiterleitung her die den intern Port freigibt.
Geht, ist aber unnütze Arbeit.

[yankee]

Also alle Externen Module die via MQTT Daten einliefern erzeugen die doppelte Last[..]Schon getestet on das die 3B+ mitmachen?

Die Idee auf die Auswirkungen auf die Hardware zu tracken ist gut. Die großen Startup-times von Python für die oWB1 zu übersehen war ein Fehler. Fein. Aber hier reden für über MQTT-Nachrichten, die über eine persistente Verbindung gehen. Bei tausenden von Nachrichten pro Sekunde mag das auch mal ein Problem werden, aber davon ist oWB weit entfernt.

Allerdings stellt sich mir schon die Frage wofür der "interne" Broker dann nützlich ist, wenn der nur innerhalb eines lokalen Prozesses gebraucht wird...

[hhoefling]

Er ersetzt die Ramdisk und dient der internen Kommunikation zwischen den Task des Regler's (schätze ich)

[hhoefling]

So wird sicher gestellt, dass auf dem internen Broker nur gültige Werte für den Algorithmus liegen.

Das konnte bedeuten das die ewigen Parameterprüfungen in den Modulen einfacher werden
da ja nur "geprüftes" dort hineinkommt.

[yankee]

Er ersetzt die Ramdisk und dient der internen Kommunikation zwischen den Task des Regler's (schätze ich)

Die Ramdisk dient in der oWB1 der IPC (interprocess communication). Sofern ich das richtig verstanden habe gibt es in oWB2 nurnoch einen Prozess. Da braucht man dann auch keine IPC mehr.

[derNeueDet]

Wenn ich es richtig sehe, gibt es in der Alpha noch keine Anzeige für den Tagesertrag der PV oder?
Mir ist auch aufgefallen, dass meine openWB Standard+ und die Alpha unterschiedliche Werte beim EVU Bezug anzeigt. Gesten hatte ich über den Tag ca. 1kWh Differenz. Das habe ich darauf geschoben, dass ich die Standard+ für kurze Zeit herunter gefahren hatte. Aber heute wurde noch nichts gemacht und ich habe ca. 0,5kWh Differenz zwischen den Boxen. Nur Bezug, Einspeisung ist auf beiden Systemen identisch.

VG
Det

[vuffiraa]

Wenn ich es richtig sehe, gibt es in der Alpha noch keine Anzeige für den Tagesertrag der PV oder?
Mir ist auch aufgefallen, dass meine openWB Standard+ und die Alpha unterschiedliche Werte beim EVU Bezug anzeigt. Gesten hatte ich über den Tag ca. 1kWh Differenz. Das habe ich darauf geschoben, dass ich die Standard+ für kurze Zeit herunter gefahren hatte. Aber heute wurde noch nichts gemacht und ich habe ca. 0,5kWh Differenz zwischen den Boxen. Nur Bezug, Einspeisung ist auf beiden Systemen identisch.

VG
Det

Doch gibt es. Leider wird bei mir die PV-Konfiguration nicht automatisch auf aktiv gesetzt. Da habe ich aber noch nicht gesehen, woran es liegt. Im MQTT kann man das aber nachholen `publish openWB/set/pv/config/configured=true`. Und der Tagesertrag selber wird nach `openWB/pv/get/daily_yield` geschrieben.

Nachtrag: Der PV-Ertrag wird mit der Einheit kWh angezeigt, obwohl es nur Wh sind. Die Genauigkeit entspricht aber Bezug und Einspeisung, daher denke ich, dass die Einheit in "Status.vue" angepasst werden sollte.

VG und einen guten Rutsch!

[Isi]

Ladepunkt gesperrt, da keine Werte vom EVU-Zähler empfangen wurden und deshalb kein Lastmanagement durchgeführt werden kann. Falls Sie dennoch laden möchten, können Sie als EVU-Zähler 'Virtuell' auswählen und einen konstanten Hausverbrauch angeben.

Ich habe einen virtuellen Zähler angelegt mit Hausverbrauch 1000 Watt, aber Dieser wird bei den Zählern nicht angezeigt und der LP wird auch nicht freigegeben. Der Hausverbrauch auf der Hauptseite steht fest bei 600 Watt. (im Graph scheinen die 1000 Watt anzukommen)
Funktioniert das bei euch?
Ich habe leider einen SMA-HM als EVU-Zähler und das Modul ist noch nicht integriert...

[electron]

Ich versuche eine Minimalkonfiguration einzurichten. Leider geht gerade gar nichts mehr. Ich kann weder neue Geräte/Komponenten anlegen, noch alte löschen. Im Log findet sich das folgende:

Code: Alles auswählen

2022-01-03 15:17:22,284 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Warten auf das Ende des Boot-Prozesses
2022-01-03 15:17:22,285 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Boot-Prozess abgeschlossen
2022-01-03 15:17:22,285 - {/var/www/html/openWB/packages/helpermodules/log.py:35} - DEBUG - Broker-Konfiguration aktualisieren
2022-01-03 15:17:22,296 - {/var/www/html/openWB/packages/helpermodules/log.py:47} - ERROR - Fehler im Main-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/main.py", line 166, in <module>
    update_config.UpdateConfig().update()
  File "/var/www/html/openWB/packages/helpermodules/update_config.py", line 302, in update
    client.connect(mqtt_broker_ip, 1886)
  File "/usr/local/lib/python3.9/dist-packages/paho/mqtt/client.py", line 914, in connect
    return self.reconnect()
  File "/usr/local/lib/python3.9/dist-packages/paho/mqtt/client.py", line 1044, in reconnect
    sock = self._create_socket_connection()
  File "/usr/local/lib/python3.9/dist-packages/paho/mqtt/client.py", line 3685, in _create_socket_connection
    return socket.create_connection(addr, timeout=self._connect_timeout, source_address=source)
  File "/usr/lib/python3.9/socket.py", line 843, in create_connection
    raise err
  File "/usr/lib/python3.9/socket.py", line 831, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

Hat jemand eine Idee, was da schief läuft?