Node-Red MQTT Sendeknoten hört auf zu senden

[iuATERNitg]

Moin, ich sende über Node Red Daten zu meinem IOBroker (meistens im 1s Takt).
Komischerweise hängt sich der Transfer immer mal wieder auf und dann laufen so lange keine Daten ein bis ich übers Webinterface auf den Cerbo zugreife. Es ist dabei egal, ob ich nur den normalten Bildschirminhalt aufrufe oder das Node-Red Interface. Sobald ich das mache trudeln auch wieder die Nachrichten in Iobroker ein.

Wenn ich mir im VRM die Daten ansehe, kommt es nicht zu diesen Verhalten, sprich es laufen weiterhin keine Daten zum iobroker. Da sich im VRM aber diese Daten ständig ändern scheint Node-Red auch zu arbeiten, da ich z.B. die PV Inverterdaten über NodeRed dem VenusOS mitteile und diese in der Übersicht sich ständig anpassen. Das gilt insbesondere für Daten die auch per MQTT für den iobroker kopiert werden.

Ich würde es verstehen, wenn die Verbindung einfach hängen bleibt aber es läuft wieder, sobald man halt sich mit dem Cerbo übers Web verbindet.

Hat jemand ein ähnliches Problem?

[d_ferdi (Dieter Ferdinand)]

hallo,

wie genau greifst du auf den cerbo zu, damit es wieder geht? auf die remote-console oder node-red, ueber das vrm oder direkt?

also bei mir ist noch nie eine datenuebertragung haengen geblieben, egal ob ich daten ueber mqtt vom cerbo abgerufen habe oder sie von node-red verschickt habe.

uebrigends ist es sinnvoller, die daten vom cerbo abzurufen anstatt sie von dort zu verschicken.

ich sende zwar auch daten vom cerbo weg, aber die werden dann meistens vorher noch etwas aufbereitet und dann einen einen mqtt-server gesendet. das ist leider die einzig sinnvolle moeglichkeit, wenn der cerbo 2 netzwerkverbindungen hat und wenn eine ausfaellt, automatisch auf die andere wechseln soll!

tschuess

[busbum]

Das klingt für mich weniger nach „Node-RED rechnet nicht mehr“, sondern eher nach MQTT-Verbindung oder Netzwerkpfad, der einschläft bzw. hängen bleibt. Dass es beim Öffnen der Cerbo-Weboberfläche sofort wieder losläuft, ist ein guter Hinweis: dadurch entsteht lokaler Traffic/ARP und der Cerbo bzw. der WLAN-Pfad wird wieder „angeschubst“.

Ich würde es so eingrenzen:

1. Während der Hänger auftritt, vom ioBroker oder einem anderen Rechner dauerhaft einen Ping auf die Cerbo-IP laufen lassen. Wenn ein permanenter Ping das Problem verhindert, liegt es eher an WLAN/Repeater/Power-Saving/ARP als am Flow selbst.

2. Im Node-RED-Flow direkt hinter dem Sendeknoten eine Debug-/Status-Ausgabe setzen: Wird der MQTT-Node noch als `connected` angezeigt oder reconnectet er?

3. Den 1s-Takt testweise auf 5-10s reduzieren und nur bei Wertänderung senden. 1s Push für viele Werte kann auf dem GX unnötig Last erzeugen.

4. Falls möglich, Daten eher vom ioBroker/MQTT-Client abonnieren bzw. abholen lassen, statt alle Werte vom Cerbo aktiv zu pushen. Das meinte d_ferdi vermutlich auch.

5. Testweise Cerbo per LAN bzw. ohne Repeater betreiben. Wenn das Verhalten dann weg ist, ist der Repeater/WLAN-Client der Hauptverdächtige.

Wenn du noch schreibst, ob der Zugriff direkt lokal auf die Cerbo-IP oder über VRM/Remote Console passiert, kann man es besser einordnen.

[iuATERNitg]

Hallo,

erst nur eine kurze Zusammenfassung der Infrastruktur:

Iobroker-Server-XEN-Instanz - XEN-DomU Dockerserver - XEN-Server - NW-Kabel - Switch - Switch - HeimRouter - VirtLAN - FHausRouter - WLAN-Repeater - NW-Switch - Cerbus

Das Device (OpenDTU) ist mit dem WLAN-Repeater verbunden.

Eine lange Kette von Unterbrechungsmöglichkeiten. Ich nutze nur IP-Adressen für die Kommunikation zwischen Cerbus und Iobroker sowie für das OpenDTU um Probleme mit dem DNS zu vermeiden.

Der Cerbus hat Internet über den FHausRouter (INet geht nicht über das VirtLAN).
Meine WS steht in der Nähe zum HeimRouter (über einen weiteren Switch).

Eine Verbindung zum FH ist nur möglich wenn auch das VirtLAN funktioniert.
Das VirtLAN funktioniert nur wenn beide Router mit dem INet verbunden sind.
Der FHRouter hat eine Dyn. IP, mein Heim-Router eine feste IP.

Aktiv holt IOBroker auch die Werte über MQTT vom Cerbus. Aber es gibt auch einen Pfad um die Werte in NodeRed zu IOBroker zu pushe. Der Grund ist das ein Gerät normalerweise direkt mit IOBroker kommuniziert hat, ich die Werte aber auch auf dem Cerbus brauche.
Daher habe ich den Cerbus einfach “dazwischen gesetzt” indem ich als Ziel den Cerbus statt den IOBroker in dem Device konfiguriere (IP geändert) und im Cerbus nach dem Empfang der Daten diese 1:1 an den IOBroker einfach weiter leite. Daher muss ich nichts weiter im Device anpassen und muss auch in IOBroker nichts anfassen.

Was mich nicht stört, ist das ab und an mal keine Werte im IOBroker ankommen.
Was mich stört ist das nach einem (möglicherweise) Verbindungsabbruch und Neuaufbau keine Werte mehr eintrudeln, also irgendwie der selbständige Reconnect ausbleibt.

Ich überwache die Verbindung des VirtLAN indem ich den FHRouter regelmäßig versuche zu errelchen. So bekomme ich Ausfälle des FHRouters zum Internet mit. Kurze Neuverbindungen sehe ich aber eher selten (z.B. einen nächtlichen Neustart der Internetverbindung).

Wie ich es das Problem entdeckt habe:
In der VRM Konsole kann ich auch sehen, dass die Daten sich aktualisieren, obwohl diese in IOBRoker nicht mehr ankommen. Sobald ich aber von meinem Rechner die Webconsole vom Cerbus oder NodeRed des Cerbus öffne, empfängt auch der IOBroker wieder Daten. Das macht die Analyse schwierig da in dem Moment der MQTT Knoten in NodeRed wieder verbunden ist.

Im Übrigen habe ich das Verhalten auch auf einem 2. System registriert. Dabei stehen hier Cerbus und XEN-Server mit Iobroker im gleichen Netz aber der Cerbus über einen AP-Repeater im gleichen Raum verbunden. Ein echter Verbindungsausfall ist möglich aber hier eher selten:

Iobroker-Server-XEN-Instanz - XEN-DomU Dockerserver - XEN-Server - NW-Kabel - Switch - Repeater - Cerbus

Ich habe aber den Verdacht das es nicht zwingend nur den NodeRed MQTT Knoten betrifft. Möglicherweise werden auch direkt bereits abgefragte MQTT Werte nicht mehr aktualisiert.
Ich muss da nochmal ein Auge drauf werfen wenn mal wieder die Werte nicht mehr in IOBroker einlaufen.

Ich mach auch nochmal nen Diagramm zum besseren Überblick.

[d_ferdi (Dieter Ferdinand)]

hallo,

wenn du die daten an den cerbo-mqtt-server schickst, kannst du sie dort auch vom iobrocker abonnieren, dazu brauchst du kein node-red.

tschuess

[HolgerBle (Holger Bleckwehl)]

Also ich benutze seit Jahren iobroker .. und hole die Daten direkt von GX-Device .. und macht eigentlich nie Probleme… da man auch keine besonderen Treiber braucht und auch kein NodeRed.

[iuATERNitg]

Moin, also falls das nicht durch gedrungen ist:

Ich lasse mir Daten von einem Gerät senden. Diese haben ein bestimmtes Format und sollen 1:1 an iobroker weiter geleitet werden und werden in NodeRed parallel auch verarbeitet.
Daher war der MQTT Sendeknoten hier die schnellste und einfachste Möglichkeit den unveränderten empfangenen Datenstrom einfach zum iobroker zu leiten, ohne etwas am iobroker zu ändern und nur minimale Änderungen (Ziel-IP) am sendenden Gerät vorzunehmen.

Natürlich könnte ich auch andere Maßnahmen vornehmen, um das Ziel zu erreichen. Aber darum geht es hier nicht. Ich habe ein komisches Verhalten beobachtet und stelle dieses Verhalten hier zur Diskussion woran das liegen könnte.

[d_ferdi (Dieter Ferdinand)]

hallo,

wie kommen denn die daten auf den cerbo? ueber ein script, ueber mqtt oder node-red.

uebrigends hat node-red die schlechte angewohnheit, gelegentlich einmal abzustuerzen und mqtt-verbindungen werden auch wieder neu initialisiert, falls die netzverbindung aus irgendeinem grund einmal unterbrochen wird. wenn die unterbrechnung nur kurz ist, bekommt die software davon nicht einmal etwas mit. jedenfalls ist das bei dem mqtt-client so, der mir die daten vom cerbo abholt. der wird nie neu gestartet, selbst dann wenn die netzverbindung mal etwas laenger unterbrochen ist.

und der mqtt-server des cerbos ist eine schlecht wahl, um ihn als relais zu benutzen. dafuer benutze ich dann einen mqtt-server (mosquitto) auf meinem smarthome-system. von dort holen sich dann alle anderen system die daten und senden auch ihre daten dorthin.

dazu kommt noch, dass mqtt nur daten sendet, wenn neue nachrichten ankommen. ob sich der wert aendert oder nicht, spielt keine rolle!

tschuess

[CZvacko]

Did you set up the MQTT keep-alive mechanism? Without it, IOBroker only receives data when you access VRM (if MQTT is used for data transport).

[iuATERNitg]

Vielleicht ist es so ein wenig verständlicher:

Kleiner Fehler, in iobroker muss es heißen:
Empfängt die Daten

Und hier die beiden Knoten in NodeRed:

[d_ferdi (Dieter Ferdinand)]

hallo,

ich gehe einmal davon aus, dass der opendtu-node ein timernode ist und du die daten dynamisch abonnierst.

dann kommt noch hinzu, dass der mqtt-server des cerbos keine daten beim abonieren sendet, sondern nur wenn er selbst daten empfaengt oder man die daten ueber einen 2. mqtt-node anfordert!

der timer nuetzt dir hier also nichts.

ich habe leider keinen flow mit einem refresh bzw. keep alive zur hand, aber dann muss das gesendete topic mit R/ beginnen.

wenn die daten regelmaessig aktualisiert werden, reicht also auch ein statisches abo.

tschuess

[iuATERNitg]

OpenDTU sendet einfach die Daten an den Cerbo mqtt Broker und legt die da ab.
Das ganz links ist ein Timernode der den MQTT-Node links alle 60 s mal antriggert um Daten von dem Cerbo mqtt Broker abzuholen. In OpenDTU ändert sich nicht so häufig was.

Die Daten von OpenDTU werden dann rechts weiter aufgetrennt und in die PV-Injektionnode für den Cerbo bereit gestellt. Da sehe ich dann das sich PV-Werte ändern.

Ich bin auf das Problem eigentlich nur aufmerksam geworden, weil ich in VRM sehe das sich die PV-Werte ändern, aber im IOBroker nicht. Als ich dann eine Direktverbindung zum Cerbo mit dem Webbrowser zur normalen Oberfläche geöffnet habe liefen auch die Daten in iobroker sofort wieder ein. Das gleiche passiert, auch wenn ich direkt die NodeRed-Seite des Cerbo aufrufe. Eine ssh-Verbindung reicht nicht aus.

Wobei mein Rechner, von dem ich die Verbindung öffne, ist ein anderer als der IOBroker-Server, was die Sache noch mysteriöser macht. Daher glaube ich weniger das die Verbindung weniger als das generelle Aufrufen des Displays das Problem vorübergehend beseitigt. Was ich noch nicht geprüft habe ist ob das Problem auch beseitigt, wenn ich das Display selber mal aufwecke.

[d_ferdi (Dieter Ferdinand)]

hallo,

du hast warscheinlich genau das gleiche problem wie ich. und ich habe noch nie daten vom mqtt abgerufen, indem ich das topic an einen node geschickt habe.

installier dir einmal den mqtt-explorer, stell dein node auf einen statischen abruf um und schick den gleichen topic mit R/ mit einem timer anstatt N/ wie beim abruf an den mqtt-server des cerbos. es muessen keine daten gesetzt werden, ein leerer string reicht da als wert aus. dann sendet der cerbo jedesmal den abonierten topic zurueck.

ich mache das aktuell noch auf einem cerbo, weil ich damit alle daten der mppts mit wenigen nodes abrufen und aufbereiten kann. dabei gibt es eine timeout-ueberwachung, so dass werte, die nicht regelmaessig ankommen, angefordert werden.

tschuess

[iuATERNitg]

Also nochmal: Ich mache nix hier mit N oder R oder was auch immer. Ich nutze den lokalen Broker auf dem Cerbo nur als Zwischenspeicher um die Daten von OpenDTU anzunehmen.
Den Rest macht NodeRed mit einem abholenden und einem Sendenden MQTT Knoten.

[d_ferdi (Dieter Ferdinand)]

hallo,

nochmal: der mqtt-server auf dem cerbo sendet aktualisierungen nur, wenn er eine neue nachricht bekommt oder man mit einem keepalive den wert erneut anfordert und ich glaube nicht, dass das dynamische abo, wie du es machst, dafuer geeignet ist!

fuer das dynamische abo muesste node-red jedesmal, wenn es das topic bekommt, ueber einen keepalive die daten neu anfordern und sowas steht nicht in der beschreibung. frueher hat der cerbo, beim verbinden, immer alle abonierten werte geschickt, das ist aber seit irgendeinem update nicht mehr der fall.

und normalerweise sind die topics auf dem cerbo so benannt: N/id/geraet/instanz/werte

will man einen wert aendern, muss man das gleiche topic mit W am anfang schreiben und will man den aktuellen wert abrufen, mit N am anfang und einem leeren string.

beim abonieren eines topics und dem verbindungsaufbau sendet der cerbo KEINE daten bis sich der wert aendert oder der gleiche wert neu geschrieben wird!

deshalb wundert es mich, dass du ueberhaupt daten ueber das node bekommst, wenn keine neue nachricht von opendtu kommt!

und ich sagte es schon einmal, es ist keine gute idee, den cerbo als mqtt-zwischenspeicher zu benutzen, da er andere regeln hat, als z.B. der mqtt-server, der in iobrocker enthalten ist!

du musst dich also entweder an die regeln des mqtt-servers vom cerbo halten oder du schickst die daten zu erst an iobrocker und holst sie dir dann von dort ueber mqtt ab. das waere jedenfalls die bessere loesung! damit wuerde sich am aktualisierungsintervall fuer den cerbo nichts aendern und auch iobrocker haette immer den aktuellen wert!

ich bereite daten fuer meinen mqtt-server auch nur aus einem grund auf dem cerbo auf: die victron daten-nodes senden den wert alle 5 s, diese daten sammle ich und schicke sie dann entweder jedesmal oder in einem festgelegten zeitlichen abstand (meistens 1s) ueber einen timer an meinen mqtt-server.

diese vorgehensweise hat sich auf jeden fall bewaehrt und es gab auch noch nie unterbrechungen bei der datenuebertragung ausser als ich das netzwerk umkonfiguriert hatte und es dann auch mal etwas laenger nicht funktioniert hat, weil noch ein fehler in der konfig war.

tschuess

[iuATERNitg]

Ich sehe aber das Problem gar nicht beim mqtt Broker auf dem Cerbo. Denn da die Daten die ganze Zeit weiter über NodeRed verarbeitet werden obwohl iobroker keine mehr erhält ist die Kette irgendwo vom Sendenden NodeRed-MQTT-Knoten zum iobroker (temporär) unterbrochen.

Also lass uns nicht über den Cerbo MQTT Broker reden sondern warum der Node-Red Knoten die Daten scheinbar nicht an iobroker sendet, bis ich das Display über den Webbrowser aufrufe.
Über funktionierende Dinge muss man sich nicht unterhalten.

Hier nochmal in NodeRed was auf jeden Fall weiter funktioniert (rote Linie)
Und der Pfad der irgendwo ab da nicht funktioniert (blaue Linie)

[iuATERNitg]

Hier nur zur Übersicht, das ich außerhalb der vom Cerbus verwendeten Pfade arbeite:

Generell könnte ich auch einfach einen eigenen mqtt-Broker auf den Cerbo installieren und starten. Aber ich wollte hier einen double point of failure vermeiden.
Außerdem würde es bei einem Upgrade einfach weiter funktionieren.

[d_ferdi (Dieter Ferdinand)]

hallo,

wenn du dir vom debug-knoten die nachrichten ausgeben laesst, fallen die dann auch aus?

also ich benutze wesenlich lieber empfangsknoten als sendeknoten, da ich die auf timeout ueberwachen kann. ich kenne leider keine moeglichkeit, einen sendknoten zu ueberwachen.

ausser du abonierst die daten nochmal bei iobrocker und ueberwachst dieses abo dann auf timeout. probier doch beim sendknoten einmal eine andere qos-einstellung. vieleicht hilft das ja.

faellt die datenuebertragung immer zu einer bestimmten zeit oder nach einer bestimmten dauer aus?

tschuess