Startreihenfolge der Adapter

[Marc Berg]

@mkaiser96 sagte in Startreihenfolge der Adapter:

Wenn der NodeRED Adapter schneller gestartet ist als meine CCU, stürzt NodeRED ab, da es die Zentrale nicht findet.

Mal abgesehen von der Diskussion um die Startreihenfolge. Was ich nicht verstehe ist, warum NodeRed abstürzt. Ich habe etliche Systeme über NodeRed angebunden, wenn zwischenzeitlich eines dieser Systeme (noch) nicht da ist, passiert einfach ein Reconnect. Einen Absturz wegen nicht verfügbarer Schnittstellen habe ich noch nie erlebt.

[Thomas Braun]

@da_woody sagte in Startreihenfolge der Adapter:

klar, aber das hat doch nix mit einem adapter zu tun.

Aber die Adapter starten nicht ohne den iobroker. Wenn der also verzögert startet, dann die Adapter natürlich auch...

[MKaiser96]

@thomas-braun

Prinzipiell stimmt das soweit. Die CCU ist ein externer Dienst. Ich habe aber auch noch weitere Adapter laufen, die ich gerne in einer gewissen Reihenfolge mit Verzögerung starten möchte.

Eine Diskussion über die Sinnhaftigkeit hilft mir hier leider nicht weiter. Eine Lösung des Problems wäre sehr hilfreich und kann sicher auch weitere Nutzer weiterhelfen.

[DJMarc75]

@mkaiser96 sagte in Startreihenfolge der Adapter:

Ich habe aber auch noch weitere Adapter laufen

Bist Du da jetzt sicher dass Du ioBroker-Adapter meinst?
Ich meine speziell Dein NodeRed. Läuft das als Adapter auf ioBroker oder als NodeRed auf einem eigenen System ?

[Thomas Braun]

@mkaiser96

Rudimentär kann man das hier steuern:

Gibt aber nur 3 Stufen.

[MKaiser96]

@djmarc75
Ja, ich habe NodeRED als Adapter auf meinem ioBroker laufen.

@Thomas-Braun
Da kann ich aber leider keine Zeit einstellen. Das hilft mir hier leider nicht direkt weiter.

[paul53]

@mkaiser96 sagte: NodeRED Adapter erst nach einer gewissen Zeit starten

Weise die Node-Red-Instanz in der Startreihenfolge nach hinten (3), stoppe die Instanz bei Neustart von Javascript (Startfolge: 1) und starte sie verzögert wieder.

const idNR = 'system.adapter.node-red.0';
const objNR = getObject(idNR);
objNR.common.enabled = false;
setObject(idNR, objNR); 
setTimeout(function() {
    objNR.common.enabled = true;
    setObject(idNR, objNR);
}, 30000);

[peterfido]

@da_woody @MKaiser96 Ich hatte das so vesrtanden, dass da auf einen externen Server (CCU) gewartet werden soll.

Meine CCU ist eine VM unter Proxmox. Diese braucht mit einem zugewiesenen CPU Kern eine deutliche Zeit länger, bis diese hochgefahren ist. Mit zwei CPU Kernen fährt die wesentlich flotter hoch.

Die Frage könnte im Bezug auf Node-Red hier im Forum unter Node-Red evtl. besser aufgehoben sein. Ich nutze Node-Red auch für vieles. Abstürze kommen da allerdings nicht vor. Wenn ein Gerät nicht erreichbar ist, startet Node-Red die Verbindung dorthin einfach neu.

Ansonsten:

• CCU kann iobroker selbst mit den HMxxx-Adaptern. Node-Red kann da auf die Objekte lauschen.
• Fehler kann man in Node-Red mit den Catch-Nodes abfangen.

[MKaiser96]

Dass NodeRED abstürzt, lassen wir jetzt am besten mal außen vor. Ich habe auch sämtliche Programme in NodeRED, die zeitgesteuert sind. Diese werden beim Start immer getriggert, um im richtigen Zeitplan zu sein. Wenn jetzt meine CCU noch nicht erreichbar ist, gibt es Fehler und meine sämtlich zeitgesteuerten Programme sind nicht im richtigen Zeitplan. Daher soll eben erst die CCU online sein, bevor meine Logikebene dazukommt und alle Programme richtig triggern kann.

Der gezeigte Ansatz mit dem Stoppen der Adapter und erneuten Starten ist schonmal ein guter Ansatz. Kann man denn nicht festlegen, dass bestimmte Adapter erst gar nicht gestartet werden und man diese per Skript manuell startet?

[peterfido]

@mkaiser96

Quick´Dirty: Am Anfang eine Schleife drehen, welche die CCU solange anpingt, bis diese antwortet. Zwischendurch den Ping immer wieder abfragen, falls da was unterbricht.

Wenn Node-Red allerdingsdabei so aus dem Ruder gerät, dass es abstürzt, hilft das nur bedingt.

Sauberer ist es, Fehler / Unerwartetes sauber abzufangen.

[Wildbill]

@mkaiser96 sagte in Startreihenfolge der Adapter:

Eine Lösung des Problems wäre sehr hilfreich und kann sicher auch weitere Nutzer weiterhelfen.

Ich würde empfehlen, anstatt an den Symptomen herumzumachen, die Ursache zu beseitigen. Hol Dir eine oder zwei kleine USV, die kurze Stromausfälle puffern und bei längeren die Systeme auch sauber runterfahren. Kosten nicht die Welt, ersparen aber viel Ärger. Wenn die Systeme runtergefahren wurden, kannst Du sie gezielt in Wunschreihenfolge wieder starten. Und die Dateisysteme werden es Dir danken, wenn sie nicht einfach hart vom Strom gehen sondern vorher einen sauberen Shutdown erleben dürfen...

Gruss, Jürgen

[mickym]

@marc-berg sagte in Startreihenfolge der Adapter:

@mkaiser96 sagte in Startreihenfolge der Adapter:

Wenn der NodeRED Adapter schneller gestartet ist als meine CCU, stürzt NodeRED ab, da es die Zentrale nicht findet.

Mal abgesehen von der Diskussion um die Startreihenfolge. Was ich nicht verstehe ist, warum NodeRed abstürzt. Ich habe etliche Systeme über NodeRed angebunden, wenn zwischenzeitlich eines dieser Systeme (noch) nicht da ist, passiert einfach ein Reconnect. Einen Absturz wegen nicht verfügbarer Schnittstellen habe ich noch nie erlebt.

Na das kann schon passieren, wenn man Nodes verwendet, die direkt mit der Hardware kommunizieren. Ich nutze beispielsweise direkt die Harmony Nodes - da die wesentlich performanter sind, als der entsprechende iobroker-Adapter. (Für Lautstärke ist er einfach unbrauchbar) Es gibt allerdings auch das Problem, dass wenn diese Harmony Nodes nicht richtig initialisiert sind, stürzt NodeRed ab, weil diese Node einfach einen Fehler hat - bzw. irgendetwas nicht berücksichtigt. Das liegt nicht an Node-Red an sich, sondern an den speziellen Nodes in bestimmten Konstellationen. Das ist das gleiche, wenn ein Adapter den ganzen iobroker zum Erliegen bringt.

Gut was sehe ich für Möglichkeiten:

1. Du stellst auf den Homematic Adapter um, dann brauchst Du diese Nodes nicht.
2. Du blockierst entsprechende Flows über eine globale oder flow- Variable, die Du über eine Inject-Node steuerst - und nach dem Start des Adapters (bzw. Node-Red) in einer bestimmten Zeit frei gibst. Die Idee mit dem ping ist auch nicht schlecht - entweder über Ping Node oder Adapter.
3. Du stellst sicher - dass der ganze iobroker erst nach dem CCU-Service startet. - Ist aber nicht zu empfehlen, da wohl bei jedem Update oder iobroker fix - evtl. Abhöngigkeiten wieder verloren gehen.

[mickym]

@peterfido sagte in Startreihenfolge der Adapter:

...
Ansonsten:

CCU kann iobroker selbst mit den HMxxx-Adaptern. Node-Red kann da auf die Objekte lauschen.
Fehler kann man in Node-Red mit den Catch-Nodes abfangen.

Ja ersten Vorschlag habe ich auch schon gemacht.
Mit Catch kann man versuchen - das funktioniert aber nicht immer.

[mickym]

@mkaiser96 sagte in Startreihenfolge der Adapter:

Dass NodeRED abstürzt, lassen wir jetzt am besten mal außen vor. Ich habe auch sämtliche Programme in NodeRED, die zeitgesteuert sind. Diese werden beim Start immer getriggert, um im richtigen Zeitplan zu sein. Wenn jetzt meine CCU noch nicht erreichbar ist, gibt es Fehler und meine sämtlich zeitgesteuerten Programme sind nicht im richtigen Zeitplan. Daher soll eben erst die CCU online sein, bevor meine Logikebene dazukommt und alle Programme richtig triggern kann.

Der gezeigte Ansatz mit dem Stoppen der Adapter und erneuten Starten ist schonmal ein guter Ansatz. Kann man denn nicht festlegen, dass bestimmte Adapter erst gar nicht gestartet werden und man diese per Skript manuell startet?

Ausserdem würde ich trotzdem mal meine Logik überprüfen. Über Zeit zu triggern ist in meinen Augen immer die schlechteste Lösung.

Wenn Du die CCU Nodes selbst triggern lassen würdest, dann bist Du auch sicher, dass die CCU da ist. Und wenn Du über Zeit triggerst - dann wäre das erstes über die CCU Nodes deren Verfügbarkeit triggern zu lassen und vorher über Variablen den Trigger zu blockieren.

Das aber mal so ganz ALLGEMEIN gesprochen, ohne Dir jetzt zu nahe treten zu wollen.

[MKaiser96]

@mickym
Dann erkläre mir mal bitte, wie du Zeitpläne programmierst, ohne über die Zeit zu triggern. Einfachstes beispiel 08:00 Uhr sollen die Rollläden hochfahren. Meiner Meinung nach kann man sowas nur über die Zeit steuern.

[mickym]

@mkaiser96 Ja da hast Du natürlich Recht.