ioBroker JS killt meine Synology ?

[Humidor]

sobald der mqtt.0 Server läuft, läuft auch J auf Hochtouren

wenn ich mqtt.o stoppe:

es kommuniziert ein bsc (esp, liest die Daten per BT von einer Speicherbatterie ein) und 2 goE Wallboxen
was soll daran so tragisch sein?

Anhand vom Timestamp sehe ich auch, dass sich dort nicht viel bewegt. Mqtt aktualisiert ja nicht zyklisch, nur bei Änderung, das wäre ja der Vorteil....

sobald ich den mqtt.o stoppe, ist die Auslastung = 0%

jetzt habe ich mein javascript gestart, dh das lesen von mqtt1 und 2 ist aktiviert

die Auslastung bleibt gering

[Armilar]

@humidor

Warum laufen alle 3 Instanzen des MQTT auf Port 1883?

[Humidor]

@armilar sollten die unterschiedlich eingestellt werden?

[Armilar]

@humidor

Jap und die Clients entsprechend auch...

[Humidor]

@armilar ändere ich den Port im mqtt.1 und im Cerbo (Mqtt Broker) auf 1884, kommunizieren die Dinger nicht mehr miteinander?

[Thomas Braun]

@humidor

Services dann auch neugestartet?

[Humidor]

@thomas-braun immer natürlich, nein will nicht, weiß da nicht weiter.

[Armilar]

@humidor

Setze die Ports immer in mind. 2er Schritten. Wenn der MQTT.0 auf 1883 steht, dann nutzt der wahrscheinlich ebenfalls den 1884.

Also den MQTT.1 auf 1885 und den MQTT.2 auf 1887

Falls da noch ein Sonoff-Adapter, Shelly-Adapter oder anderer Adapter mit MQTT aktiv ist, dann dort auch abweichende Ports nutzen. Die stören sich sonst gegenseitig.

[Humidor]

@armilar es will nicht, sobald ich den mqtt.0 (Broker) abdrehe, fkt. irgendwie vieles nicht mehr in den Victron Cerbos (Node Red), die Cerbos sind aber Broker.
über die Clients lese ich die Werte der Cerbos aus, eine Änderung des Ports fkt. nicht.
da ist der Wurm drin.

am meisten frisst der JS Controller, ist das Sinn der Sache?
hmm, ist die % Anzeige vom JS die Summe aller Prozesse?

[BananaJoe]

@armilar sagte in ioBroker JS killt meine Synology ?:

@humidor

Warum laufen alle 3 Instanzen des MQTT auf Port 1883?

STOP Warum soll da was an den Ports geändert werden?
mqtt.0 ist ein Broker, und der darf - wenn frei - natürlich auf Port 1883 laufen
mqtt.1 ist ein Client - und natürlich darf der sich zu einen Broker verbinden der auf 1883 läuft. Lokal belegt er damit den Port nicht, das ist der Zielport zu dem er sich verbinden will
mqtt.1 dito, siehe mqtt.0

[Humidor]

@bananajoe mqtt.0 ist der Broker, der hat mit meinen 2 Cerbos nichts zu tun. dennoch fkt. dann einiges auf den Cerbos nicht mehr, wenn ich ihn stoppe. Ich habe echt noch kA warum das so ist. Die Broker und Client Instanzen im ioBroker haben keine Abhängigkeiten zueinander oder? Es verbinden sich aber auch andere Geräte auf diesen Broker.
jede Instanz eines mqtt erzeugt eine Grundlast am ioBroker, denke ein weiterer Broker um die anderen Geräte auf einen anderen Port zu leiten, wird das System weiter an den Rand bringen. Außer durch die Mehrbelegung entsteht ein Problem, dass mehr Rechenleistung verursacht, als gewöhnlich (das weiß ich nicht).

Ich möchte mal rausfinden, warum da Zusammenhänge sind. Das gefällt mir nicht.
Die Victron Cerbos (bessere Raspis) haben einen Mqtt Broker am laufen. (den Port verändern habe ich noch nicht raus bekommen wie). Ich möchte nur per Clients zum ioBroker Daten holen, über die Clients kann dann auch ein Pfad geöffnet werden zur Kommunikation, das mache ich so. dh der ioBroker gibt eine Paar Werte rüber zur Steuerung an die Cerbos. Mehr ist da nicht.
Normalerweise wäre die Topology von Mqtt so, dass sich die Client anmelden und dann schickt der Broker geänderte Daten durch. Warum auch immer, muss ich einen Alive alle 30s machen, dass diese Verbindung aufrecht bleibt sonst beendet der Master diese nach ca.60s. In der Instanz wäre das eigentlich mit "Dauerhafter Session" aktiviert, so meine Interpretation, fkt. leider nicht. Das ist aber meine geringste Sorge.

Das Ziel wäre jetzt den Mqtt Broker im ioBroker zu stoppen (die verbundenen Geräte sind nur Datenlieferanten, die erstmal kalt gestellt werden können), dann rausfinden, warum am Cerbo Funktionen ausfallen.

[Humidor]

@bananajoe ja da dürfte ich was gefunden haben
in den Cerbos gibt es einen Node Red Baustein, der die Cennectivity zum ioBroker (Mqtt Master) abgefragt hat, das dürfte allen Übels sein, denn nun ist die Auslastung gering.

noch die Frage, woher die 8 CPU's ?

[Thomas Braun]

@humidor sagte in ioBroker JS killt meine Synology ?:

noch die Frage, woher die 8 CPU's ?

Das sind 4 Cores / 8 Threads bei der CPU. Siehe:
https://www.cpu-monkey.com/de/cpu-amd_ryzen_embedded_v1500b

[Humidor]

@thomas-braun verstanden, danke, dh das Docker Image gibt die volle Anzahl des Systems frei oder wer macht das?

[Thomas Braun]

@humidor

Die info wird aus der Hardware ausgelesen. Wird z. B. im iob diag auch gemacht:

Systemuptime and Load:
 09:25:36 up 17:14,  2 users,  load average: 0.76, 0.63, 0.55
CPU threads: 4

[Humidor]

@thomas-braun eine Anzeige des aktuellen Zustands, aber wer bestimmt es?

[Thomas Braun]

@humidor sagte in ioBroker JS killt meine Synology ?:

eine Anzeige des aktuellen Zustands, aber wer bestimmt es?

Nein, eine Anzeige der verwendeten Hardware. Wird vom Chip-Design bestimmt.

[Humidor]

@thomas-braun dh ioBroker hat über den Docker der Syno Zugriff auf die HW der Syno?

[Thomas Braun]

@humidor

Logisch. Der Docker hat ja keinen eigenen Kernel, der wird ja beim Wirt angeDOCKt.

[Humidor]

@thomas-braun alles klar, dh ioBroker sieht was da ist an HW (von der Syno) und nimmt was es kriegen kann. Einfluss darauf?