OpenWB plötzlich keine Werte mehr

[dan11hh]

Nimm Balena Etcher, nicht dem Pi Imager. Letzterer ändert beim Schreiben noch ein paar Einstellungen.

Ich werde es probieren und dann berichten.

Bleibt mein MQTT Problem und die OpenWB. So firm bin ich nicht mit MQTT. Wenn ich die Brücke in OpenWB konfigurieren und dann dort den Standalone Broker konfiguriere, empfängt die OpenWB dann auch alle Topics, oder kann sie auch nur senden, das würde mir ja schon reichen.

[Gero]

In einem Broker hast du alle mögllchen Topics in einem Baum. HomeAssistant kann sich nur einen Broker connecten, bei NodeRed gehen mehrere. Um nun einen zentralen Broker mit allen Topics aller Broker zu haben, setzt man einen als Bridge auf und konfiguriert die anderen so, dass sie ihre Topics auf einen Teilbaum des einen replizieren.

Und da ahnst du vielleicht schon, was man da falsch konfigurieren kann: wenn der eine Broker sich in einen Teilbaum repliziert, der wiederum zu einem repliziert, der dann wieder dahin repliziert, woner herkommt, hast du den Salat.

[rleidner]

mosquitto bridge verhält sich gegen einen remote broker wie ein mqtt-client, d.h. die bridge subscribed topics fürs Empfangen (in) und published zum Senden (out).
Solange in der bridge nur die in-Richtung aktiv ist, kann eigentlich nicht viel passieren.
Wenn allerdings die Richtung out oder both aktiviert sind, kann allerlei unerwünschtes passieren.
Man sollte aber auch die in-Richtung auf die notwendigen topics beschränken um unnötigen traffic zu vermeiden.

[dan11hh]

Man sollte aber auch die in-Richtung auf die notwendigen topics beschränken um unnötigen traffic zu vermeiden.

Und das ist leider bei der 2.0 nicht leichter geworden. Total schade.

Sowas hier dürfte aber der OpenWB ja nicht wehtun, oder? Also ich will nur Daten anzeigen.

Code: Alles auswählen

connection openwb
address 192.168.179.110:1883
start_type automatic
topic openWB/# in 0 openWB/
local_clientid openwb.mosquitto
try_private true
cleansession true

[rleidner]

Um alles zu subscriben nutze ich

Code: Alles auswählen

topic # in  0 openWB/

Ansonsten sieht die Bridge conf OK aus, so ähnlich mache ich das auch, wenn ich beginne Anbindungen zu implementiere.
Wenn dann die notwendigen Topics bekannt sind ersetze ich das generelle

Code: Alles auswählen

topic # in 0 openWB/

durch die detaillierten Topics, evtl. unter Nutzung von wildcards.
Durch das generelle # kommen sehr viele und teilweise große Nachrichten, da ja z.B. auch UI-Daten (Grafik, Reports) durch den Broker gehen.

[Gero]

mosquitto bridge verhält sich gegen einen remote broker wie ein mqtt-client, d.h. die bridge subscribed topics fürs Empfangen (in) und published zum Senden (out).

Vielen Dank für die Erklärung. Aber eine Frage ergibt sich daraus für mich: wenn die Bridge wie ein Client sunscribed, dann wäre die Angabe der Adresse in der openWB ja überflüssig, denn sunscriben kann ja jeder. Und ob da irgendjemand nebendran irgendwelche Topics published, die rein zufällig auch die der openWB sind - ist dem Broker auf der openWB vermutlich ja auch herzlich egal. Warum also die Angabe der IP bei der Bridge-Konfiguration in der openWB?

[dan11hh]

Ist ja auch so. Ich hab in meiner OpenWB keine Bridge laufen, sondern subscribe nur vom Mosquitto Standalone Broker (mit einer Bridge). Das Problem ist aber, wenn du auch published und dann mit mehreren Brokern (in meine Fall der Standalone, die OpenWB und Venus OS von Victron) dann kommt es zum beschriebenen Loop, weil sich die einzelnen Bridges ja nicht kennen und dann von 1 zu 3 die Daten hinundherschieben.
Ich kann für mich auch ehrlich nicht nachvollziehen, wieso es bei mir dazu kam. Jetzt ist es auf jeden Fall weg. Die OpenWB läuft stabil, ob ich die eine Karte noch retten kann? Keine Ahnung, versuche es heute Nachmittag mal.

[derNeueDet]

Also doch nicht so unwahrscheinlich, dass auch eine Austauschkarte defekt ist. Hätte ich das mal eher gewusst, dann hätte ich heute nicht Stunden verplempert.

Ich bin mir ziemlich sicher, dass deine "defekte" industrial SDC mit einem Re-Flash und Standard-Konfig./Nutzung noch ein langes Leben haben wird. Die Teile sind seit sw2 äußerst robust.

Welcher Zusammenhang besteht denn zwischen Software Version 2 und der Robustheit von Industrial SD Karten?
Industrial SDs sind auf Grund der verwendeten Technologie robuster auch gegen ungeplanten Stromausfall oder hartes Abschalten. Aber das sind sie genauso bei Verwendung einer V1.9 oder auch bei Homeassistant oder anderer Software auf einem Raspi.

VG
Det

[Gero]

Welcher Zusammenhang besteht denn zwischen Software Version 2 und der Robustheit von Industrial SD Karten?

Ich denke mal, in der Aussage ging es eher um die zeitliche Koinzidenz von der SD-Karte mit SW2 im Shop und der eingesetzten Kartentechnologie.

...ob ich die eine Karte noch retten kann?

Der Karte als Hardware ist es relativ egal, ob Du da ein Windows, Linux oder deine Fotosammlung drauf speicherst. Oder was meintest Du mit "retten"?

[dan11hh]

Siehe weiter oben. Mit einer Karte meiner zwei Boxen starten beide Boxen nicht mehr (hängen beim Startbildschirm), obwohl ich ein neues Image aufgespielt hab. Deshalb denke ich die Karte ist kaputt. Werde noch mal einen anderen Flash Prozess probieren aber ich denke die Karte ist hin.