ElabNET Technik Forum

Hallo zusammen,
hatte gerade ein kleines "Problem" mit MQTT.

Der Timberwolf sammelt Daten über ein VPN von FritzBox zu FritzBox. An der entfernten FritzBox hat sich der Switch aufgehängt.

Nach einem Neustart des Switches kamen wieder Daten von der Hoymiles DTU (HMS-1800-4T Blumenau), jedoch nicht vom Hichi Zählerlesekopf (Zähler Blumenau). Dieser wurde mehrfach neu gestartet, aber weiterhin keine Daten. Ich konnte das Problem erst beheben, als ich den MQTT Service im Timberwolf neu gestartet habe.

Mir scheint es als ob es eine Art Blockade gibt, wenn längere Zeit keine Daten mehr kommen und dann doch wieder.

Falls es für Elabnet interessant ist und ein Fehler vermutet wird kann gerne nachgesehen werden. Für mich hat das nicht die höchste Prio.

Mir ist bewusst das die nicht die aktuellste Insider ist, hatte bisher leider keine Zeit für ein Update.

Der MQTT-Broker läuft wo?

Und waren dort die Hichi Daten nach dem Switch reboot schon zu sehen?

Für dieses MQTT Gerät waren die Broker-Daten identisch zum Open-DTU Gerät eingestellt?

Servus Göran,

danke für die sinnvollen Zusatzfragen.

Nein die Hichi Daten kamen erst an, als ich den MQTT Service neu gestartet habe. Die vom Wechselrichter aber sofort.

Der Broker (für beide Geräte identisch) läuft im Timberwolf nach der Videoanleitung von Stefan und dies auch schon recht lange.

OK ob die Hichi daten aber schon vorher im Broker selbst sichtbar waren (sehr gutes MQTT Checktool ist der MQTT Explorer, gibt es im kostenlosen download für Windows), hattest nicht geprüft. Weil es ist schon komisch wenn der MQTT Gerätemanger den Broker sehen konnte und das eine Topic abgegriffen hat, das andere aber nicht. Da müssten dann unterschiedliche Definitionen zur Kommunikation zum Broker oder Topiceigenschaften anders vorliegen als nur der Pfad des Topics, um dieses Verhalten plausibel zu halten.

Der Hichi hat schon wochenlang einwandfrei gesendet. Kann man auch an den TimeSeries oder in Grafana sehen.

Es wurden auch keine Einstellungen verändert.

So ich skizziere das mal weil wir kommen da so noch nicht zum Ziel in der Analyse.

Erste Instanz
OpenDTU >> Switch >> Fritze1
Hichi >> Switch >> Fritze1

zweite Instanz
Fritze1 >> VPN >> Fritze2

dritte Instanz
Fritze2 >> MQTT-Broker

vierte Instanz
MQTT-Broker >> TWS-MQTT Objektsystem

fünfte Instanz a
TWS-MQTT Objektsystem >> TWS-MQTT Gerätemanager Topic OpenDtu >> TWS-Timeseries Open Dtu
fünfte Instanz b
TWS-MQTT Objektsystem >> TWS-MQTT Gerätemanager Topic Hichi >> TWS-Timeseries Hichi


Du hattest einen Schaden in der ersten Instanz am Switch, wodurch die gesamte Strecke natürlich tot war.
Nach einem reboot des Switch kamen für die Open DTU wieder direkt Daten am TWS-MQTT-Objektsystem an aber für den Hichi blieben die Daten aus.
Und erst ein Neustarten des TWS MQTT Services brachte da wieder eine Heilung, damit auch die Hichi Werte wieder sichtbar waren.

Der MQTT Broker ist für beide Datenströme der selbe oder sind das im TWS zwei getrennte MQTT Sybsysteme?

Als der TWS selbst keine Daten vom Hichi gesehen hat, waren die Daten aber am MQTT-Broker sichtbar? (oben erwähnter Test mit MQTT Explorer)

cheater hat geschrieben: ↑Do Mai 15, 2025 8:01 pm Der Hichi hat schon wochenlang einwandfrei gesendet. Kann man auch an den TimeSeries oder in Grafana sehen.

Die zwei Sätze beziehen sich jetzt nur auf den Zeitpunkt vor dem Crash am Switch in der ersten Instanz?
Anderen falls müsstest da noch einen zweiten MQTT Service und eine andere Instanz Influx und Grafana haben. Das wiederum würde dann den Test mit dem MQTT Explorer nicht mehr erfordern, da die Strecke zum MQTT Broker und die Datenverfügbarkeit dann offensichtlich gesichert sind.

Im Rahmen der oben skizzierten Datenwege wäre es sehr eigenartig, wenn der TWS nach einer gewissen Zeit ausbleibender Daten am MQTT-Explorer zu einem Topic (Gerät) bei wieder erscheinender Daten wieder anspringt aber bei einem anderen Topic (Gerät) nicht.


Bei mir ist da auch immer mal die derzeitige LAN Verbindung zu einem Shelly und der Open-DTU weg. ein DLAN-Adapter kommt da mit allgemeinen Stromausfall auf der Leitung nicht zurecht und findet dann seinen Gegenpart hier im Haus im Keller nicht. Den dann separat einmal raus und rein in die SD behebt das dann bisher zuverlässig. Der MQTT Stream vom Shelly und der DTU ist dann instant am MQTT Broker wieder ersichtlich und damit auch im TWS.

Denn wesentlich ist ja für den TWS eigentlich nur die durchgehende Erreichbarkeit des MQTT Brokers.

In Deinem Szenario wäre es für mich als Laie eine Möglichkeit, dass Du da zwei verschiedene MQTT Broker hast und der eine war für den TWS erst wieder erreichbar nachdem das TWS-Sybsystem rebootet wurde.
Kommen aber beide Signale vom selben MQTT Broker ist es schon sehr ungewöhnlich.

Hallo Göran,
hier nochmal der Netzwerkaufbau:

TW --> Fritzbox 1 --> VPN --> FritzBox 2 --> Switch --> Unifi AP --> Hichi
..................................................... Switch --> DTU

Der MQTT Broker (Mosquito) läuft wie geschrieben im Timberwolf und es gibt nur den einen.

Du hattest einen Schaden in der ersten Instanz am Switch, wodurch die gesamte Strecke natürlich tot war.
Nach einem reboot des Switch kamen für die Open DTU wieder direkt Daten am TWS-MQTT-Objektsystem an aber für den Hichi blieben die Daten aus.
Und erst ein Neustarten des TWS MQTT Services brachte da wieder eine Heilung, damit auch die Hichi Werte wieder sichtbar waren.

Korrekt.

Als der TWS selbst keine Daten vom Hichi gesehen hat, waren die Daten aber am MQTT-Broker sichtbar? (oben erwähnter Test mit MQTT Explorer)

Kann ich nicht sagen, es war schon spät abends und auf die Idee mal in den MQTT Explorer zu sehen kam ich nicht.

Die zwei Sätze beziehen sich jetzt nur auf den Zeitpunkt vor dem Crash am Switch in der ersten Instanz?

Ja. Nach dem Neustart des MQTT Dienstes war auch ich Grafana alles wieder einwandfrei.

Es gibt auch noch andere MQTT Geräte im Netzwerk von Frtizbox 1 und die wurden alle sauber aufgezeichnet.

Ich hoffe ich habe alle Fragen ausreichend beantwortet, sonst bitte nochmal melden. Trotzdem schon mal danke für die Engagement.

Hi Domonic,

das ja dann wirklich eigenartig das beim Wiederanlaufen der Netzwerkinfrastruktur die Topics vom Hichi im Broker wohl da waren aber nicht vom TWS Subsystem erkannt wurden, abweichend der anderen wieder angelieferten Topics.

Und dann der Neustart des Subsystems die Lösung war.

Moin

Zusatzfrage:
Wie finden die Geräte den MQTT-Broker: IP oder url?
(Vielleicht gab es ja ein DNS Problemchen?)

Hi,
ich arbeite eigentlich immer mit IP Adresse, so wie auch in diesem Fall.