openWB software2 2.1.4 Beta 1, 2 und 3

[spooky82]

und setzte bei mir nach ca. 1h die Arbeit aus.

So etwas kenne ich von meiner homematic CCU, wenn das dortige node red ein unerreichbares WLAN-Gerät pollt. Da ist dann nach soundsovielen Timeouts die untendruterliegende busybox (ein embedded Linux) so morsch, dass der node red prozess stirbt. So eine CCU ist aber auch deutlich wackeliger als ein Raspi.

Von der reinen Softwareseite her gesehen, erscheint mir sehr unwahrscheinlich. Wenn Software irgendwann stirbt, ist meist irgendwas mit der Speicherverwaltung faul. Das würde ich bei genau einer Implementierung eines Huawei-Moduls eigentlich ausschließen wollen.

Mein auf dem ioBroker laufendes ModBus Skript, welches den Huawei WR ausliest, läuft problemlos.

[Pendragon]

und setzte bei mir nach ca. 1h die Arbeit aus.

So etwas kenne ich von meiner homematic CCU, wenn das dortige node red ein unerreichbares WLAN-Gerät pollt. Da ist dann nach soundsovielen Timeouts die untendruterliegende busybox (ein embedded Linux) so morsch, dass der node red prozess stirbt. So eine CCU ist aber auch deutlich wackeliger als ein Raspi.

Von der reinen Softwareseite her gesehen, erscheint mir sehr unwahrscheinlich. Wenn Software irgendwann stirbt, ist meist irgendwas mit der Speicherverwaltung faul. Das würde ich bei genau einer Implementierung eines Huawei-Moduls eigentlich ausschließen wollen.

Mein auf dem ioBroker laufendes ModBus Skript, welches den Huawei WR ausliest, läuft problemlos.

Aha!!!

Genau das ist der Fehler und der Grund warum ich das noch nicht nutze.
Huawei hat eine bodenlos langsame Modbus-TCP Integration. Deshalb geht auch nur eine Anfrage pro ca. 20s.
Wenn bei mir eine Anfrage abgebrochen wird oder eine zweite dazwischen spuckt, dann ist der Huawei Dongle beleidigt und macht nichts mehr.

Da ich alle meine Huawei Daten per Solaranzeige auslese (ebenfalls Modbus-TCP), darf niemand anders mehr die Daten auslesen. Somit muss ich die Daten aufbereiten und zur WB schicken.

Probier mal bitte die Abfrage bei iobroker auszuschalten und teste dann die openWB Huawei Integration. Ich wette 0,10€, dass es dann läuft

Beste Grüße
Christian

[spooky82]

So etwas kenne ich von meiner homematic CCU, wenn das dortige node red ein unerreichbares WLAN-Gerät pollt. Da ist dann nach soundsovielen Timeouts die untendruterliegende busybox (ein embedded Linux) so morsch, dass der node red prozess stirbt. So eine CCU ist aber auch deutlich wackeliger als ein Raspi.

Von der reinen Softwareseite her gesehen, erscheint mir sehr unwahrscheinlich. Wenn Software irgendwann stirbt, ist meist irgendwas mit der Speicherverwaltung faul. Das würde ich bei genau einer Implementierung eines Huawei-Moduls eigentlich ausschließen wollen.

Mein auf dem ioBroker laufendes ModBus Skript, welches den Huawei WR ausliest, läuft problemlos.

Aha!!!

Genau das ist der Fehler und der Grund warum ich das noch nicht nutze.
Huawei hat eine bodenlos langsame Modbus-TCP Integration. Deshalb geht auch nur eine Anfrage pro ca. 20s.
Wenn bei mir eine Anfrage abgebrochen wird oder eine zweite dazwischen spuckt, dann ist der Huawei Dongle beleidigt und macht nichts mehr.

Da ich alle meine Huawei Daten per Solaranzeige auslese (ebenfalls Modbus-TCP), darf niemand anders mehr die Daten auslesen. Somit muss ich die Daten aufbereiten und zur WB schicken.

Probier mal bitte die Abfrage bei iobroker auszuschalten und teste dann die openWB Huawei Integration. Ich wette 0,10€, dass es dann läuft

Beste Grüße
Christian

Natürlich habe ich die Abfrage im ioB deaktiviert, als ich das Huawei Modul in der oWB getestet habe. Bekomme ich jetzt die 0,10€?
Ich bin ja erst auf den ioB umgestiegen, als die oWB SW 2 rauskam und das Lastmanagement das Laden aufgrund fehlerhafter Daten vom WR gestoppt hatte.
Auf SW 1.9 war das kein Problem, weil das Lastmanagement dort anders funktioniert hatte.

[LutzB]

Warum sehe ich in "Auswerungen-Diagramm" einen PV-Ertrag, obwohl ich keinen habe und auch keinen schicke? Also Werte schicke ich schon, aber nicht in der Höhe.

PV_Ertrag_obwohl_keine_Werte_geschickt_werden.jpg
PV_Ertrag_obwohl_keine_Werte_geschickt_werden_grafana.jpg

Du vergleichst verschiedene Daten. In Deinem Grafana Diagramm wird die Leistung angezeigt, openWB verwendet in den Auswertungen ausschließlich Zählerstände.

[LutzB]

und setzte bei mir nach ca. 1h die Arbeit aus.

So etwas kenne ich von meiner homematic CCU, wenn das dortige node red ein unerreichbares WLAN-Gerät pollt. Da ist dann nach soundsovielen Timeouts die untendruterliegende busybox (ein embedded Linux) so morsch, dass der node red prozess stirbt. So eine CCU ist aber auch deutlich wackeliger als ein Raspi.

Von der reinen Softwareseite her gesehen, erscheint mir sehr unwahrscheinlich. Wenn Software irgendwann stirbt, ist meist irgendwas mit der Speicherverwaltung faul. Das würde ich bei genau einer Implementierung eines Huawei-Moduls eigentlich ausschließen wollen.

Mein auf dem ioBroker laufendes ModBus Skript, welches den Huawei WR ausliest, läuft problemlos.

Dann wäre mal interessant, wie das Skript so aussieht und was es anders macht als das Modul in openWB.

[Pendragon]

Bekomme ich jetzt die 0,10€?

Schick deine Paypal Adresse per PN

Welches Script nutzt du da? Würde mich genau wie Lutz interessierten. Der Modbus TCP ist halt sehr wackelig, weshalb ich auch schon überlegt habe auf die 485-Lösung von Alex umzusteigen. Benötigt dann halt nur weitere Hardware.

Wie sind denn jeweils die Abfragezeiten? Was ist bei IObroker eingestellt und wie oft fragt openWB den Wechselrichter ab? Meiner kneift den Arsch zwischen 15s und 30s Abfrageinterval zu. Nicht sofort, aber nach einiger Zeit.
Ich probiere auch gerade noch mal einen neuen Wert aus.

[tcat]

Version: 2024-04-26 12:07:01 +0200 [682ffadf4]; 2.1.4-Beta.2
WB: openWB pro
Lademodus: PWM mit Fahrzeugerkennung und SoC Auslesung
SoC Auslesung bei manchen Fahrzeugen unterbinden: aktiviert


Ich beobachte mit der Beta Version unerwartet viele Zick-Zacks. Dies ist im Screenshot zwischen 09:02 und 09:19 Uhr gut zu sehen. Nachdem dieses Verhalten mit der Release-Version bisher nicht beobachtet habe könnte es ggf. mit der neuen 2.1.4-Beta.2 zusammen hängen. Jedenfalls ergeben für mich die Auf-und Abs bei nahezu konstanten PV-Leistung und Hausverbrauch keinen Sinn. In den Logs habe ich auf Anhieb nichts Brauchbares gefunden - kann aber diese natürlich trotzdem zur Verfügung stellen.

[zut]

Um den openWB-MQTT-Broker für andere Geräte wieder nutzbar zu machen, habe ich im PR#1598 einen Zweig "others/#" als readwrite eingeführt. Damit ist die openwb-Konfiguration weiterhin sicher, aber andere Geräte können den genannten Pfad nutzen, um ohne separaten Broker zu arbeiten.

Siehe auch viewtopic.php?p=106827

Es wäre schön, wenn der PR es noch ins Release schaffen könnte.

[spooky82]

So etwas kenne ich von meiner homematic CCU, wenn das dortige node red ein unerreichbares WLAN-Gerät pollt. Da ist dann nach soundsovielen Timeouts die untendruterliegende busybox (ein embedded Linux) so morsch, dass der node red prozess stirbt. So eine CCU ist aber auch deutlich wackeliger als ein Raspi.

Von der reinen Softwareseite her gesehen, erscheint mir sehr unwahrscheinlich. Wenn Software irgendwann stirbt, ist meist irgendwas mit der Speicherverwaltung faul. Das würde ich bei genau einer Implementierung eines Huawei-Moduls eigentlich ausschließen wollen.

Mein auf dem ioBroker laufendes ModBus Skript, welches den Huawei WR ausliest, läuft problemlos.

Dann wäre mal interessant, wie das Skript so aussieht und was es anders macht als das Modul in openWB.

Ich nutze das Script aus diesem Thread - etwas abgewandelt:

https://forum.iobroker.net/topic/53005/ ... oniert/471

Ob und wenn ja, was das Script anders macht, vermag ich nicht zu sagen - ich habe mich nicht mit dem Huawei Modul der oWB in der Tiefe auseinandergesetzt.

[spooky82]

Bekomme ich jetzt die 0,10€?

Schick deine Paypal Adresse per PN

Welches Script nutzt du da? Würde mich genau wie Lutz interessierten. Der Modbus TCP ist halt sehr wackelig, weshalb ich auch schon überlegt habe auf die 485-Lösung von Alex umzusteigen. Benötigt dann halt nur weitere Hardware.

Wie sind denn jeweils die Abfragezeiten? Was ist bei IObroker eingestellt und wie oft fragt openWB den Wechselrichter ab? Meiner kneift den Arsch zwischen 15s und 30s Abfrageinterval zu. Nicht sofort, aber nach einiger Zeit.
Ich probiere auch gerade noch mal einen neuen Wert aus.

Siehe meinen vorherigen Post: Ich nutze ein Java Script aus dem ioB Forum in etwas abgewandelter (abgespeckter) Form.
Das Script fragt 5 sec nach einer Abfragerunde erneut.
Ja, ab und an liefert der WR einen Error, aber bei der nächsten Runde kommen die Werte dann.

Ich lese auch nur wenige Werte wie StringSpannungen bzw Ströme, Akku SOC und Leistung sowie die Frequenz und AC Spannungen/Ströme, da ich diese Werte für die oWB benötige. Der Rest ist somit ausgegraut.

Das Skript läuft sehr stabil. Lediglich muss ich das Skript mal neustarten, wenn ich etwas am Netzwerk mache und die Verbindung kurzzeitig unterbricht - damit das Script sich neu verbinden kann.