NEWS
iobroker.js-con 100% cpu
-
Ich finde in dieser Forensoftware nichtmal den PN Knopf
eine Ahnung woher die Dachrollo Meldungrn kommen.
Kann es sein, dass die seit Monaten in einem Cache liegen?Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
Ich finde in dieser Forensoftware nichtmal den PN Knopf
eine Ahnung woher die Dachrollo Meldungrn kommen.
Kann es sein, dass die seit Monaten in einem Cache liegen?@spicer said in iobroker.js-con 100% cpu:
Ich finde in dieser Forensoftware nichtmal den PN Knopf
ID: xxxxxxeine Ahnung woher die Dachrollo Meldungrn kommen.
Kann es sein, dass die seit Monaten in einem Cache liegen?Bitte lösch deine Teamviewer ID ASAP, die ist m.W. nach fix und das ist ne Einladung dich zu besuchen.
@Homoran - ev. via MODEDIT löschen?
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@spicer said in iobroker.js-con 100% cpu:
Ich finde in dieser Forensoftware nichtmal den PN Knopf
ID: xxxxxxeine Ahnung woher die Dachrollo Meldungrn kommen.
Kann es sein, dass die seit Monaten in einem Cache liegen?Bitte lösch deine Teamviewer ID ASAP, die ist m.W. nach fix und das ist ne Einladung dich zu besuchen.
@Homoran - ev. via MODEDIT löschen?
-
@homoran
Mit debug bekomme ich Tausende:mqtt.1 2024-11-02 12:43:00.657 debug stateChange mqtt.1.info.clients.mosqsub|19238-Dachrollo: {"val":false,"ack":true,"ts":1730547780656,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730083491295} mqtt.1 2024-11-02 12:43:00.656 debug stateChange mqtt.1.info.clients.mosqsub|12126-Dachrollo: {"val":false,"ack":true,"ts":1730547780655,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730232875058} mqtt.1 2024-11-02 12:43:00.654 debug stateChange mqtt.1.info.clients.mosqsub|12442-Dachrollo: {"val":false,"ack":true,"ts":1730547780653,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730233184883} mqtt.1 2024-11-02 12:43:00.652 debug stateChange mqtt.1.info.clients.mosqsub|12072-Dachrollo: {"val":false,"ack":true,"ts":1730547780651,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730232844483} mqtt.1 2024-11-02 12:43:00.643 debug stateChange mqtt.1.info.clients.mosqsub|19176-Dachrollo: {"val":false,"ack":true,"ts":1730547780642,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730083430513} mqtt.1 2024-11-02 12:43:00.641 debug stateChange mqtt.1.info.clients.mosqsub|7642-Dachrollos: {"val":false,"ack":true,"ts":1730547780641,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730044408190} mqtt.1 2024-11-02 12:43:00.639 debug stateChange mqtt.1.info.clients.mosqsub|19174-Dachrollo: {"val":false,"ack":true,"ts":1730547780638,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1730083430386} mqtt.1 2024-11-02 12:43:00.635 debug stateChange mqtt.1.info.clients.mosqsub|12385-Dachrollo:MOD-EDIT: Code in code-tags gesetzt!
ich verstehe nicht, weil ich nur alle 2 Minuten etwas publishe an den iob server.
@spicer sagte in iobroker.js-con 100% cpu:
ich verstehe nicht, weil ich nur alle 2 Minuten etwas publishe an den iob server.
und genau deshalb ist der debug log so wichtig.
Da sieht man was passiert.was sagt denn die Mosquitto dazu.
den kenne ich nicht -
@spicer said in iobroker.js-con 100% cpu:
Ich finde in dieser Forensoftware nichtmal den PN Knopf
ID: xxxxxxeine Ahnung woher die Dachrollo Meldungrn kommen.
Kann es sein, dass die seit Monaten in einem Cache liegen?Bitte lösch deine Teamviewer ID ASAP, die ist m.W. nach fix und das ist ne Einladung dich zu besuchen.
@Homoran - ev. via MODEDIT löschen?
@mcm1957 erledigt!
war leider bis jetzt afk -
also bei mir hat das Adapterupdate MQTT Broker/Client 6.1.1 auf 6.1.2 permanent bis zu 100% CPU Auslastung bewirkt. Zurück auf 6.1.1 und alles war gut....
Grüße
@edwin40 said in iobroker.js-con 100% cpu:
also bei mir hat das Adapterupdate MQTT Broker/Client 6.1.1 auf 6.1.2 permanent bis zu 100% CPU Auslastung bewirkt. Zurück auf 6.1.1 und alles war gut....
Grüße
Hast du das Problem mit den entsprechenden Infos in einem Issue erfasst? Bitte hier verlinken.
Zwischen 6.1.1 und 6.1.2 wurde eigentlich nur genau eine Zeile geändert die ein Problem beheben soll wenn Clients keine Id haben / senden...
-
also bei mir hat das Adapterupdate MQTT Broker/Client 6.1.1 auf 6.1.2 permanent bis zu 100% CPU Auslastung bewirkt. Zurück auf 6.1.1 und alles war gut....
Grüße
@edwin40 sagte in iobroker.js-con 100% cpu:
also bei mir hat das Adapterupdate MQTT Broker/Client 6.1.1 auf 6.1.2 permanent bis zu 100% CPU Auslastung bewirkt. Zurück auf 6.1.1 und alles war gut....
Grüße
Hier läuft der MQTT 6.1.2 ohne Auffälligkeiten.
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@edwin40 sagte in iobroker.js-con 100% cpu:
also bei mir hat das Adapterupdate MQTT Broker/Client 6.1.1 auf 6.1.2 permanent bis zu 100% CPU Auslastung bewirkt. Zurück auf 6.1.1 und alles war gut....
Grüße
Hier läuft der MQTT 6.1.2 ohne Auffälligkeiten.
@darkiop sagte in iobroker.js-con 100% cpu:
Hier läuft der MQTT 6.1.2 ohne Auffälligkeiten.
Hier auch.
-
@darkiop sagte in iobroker.js-con 100% cpu:
Hier läuft der MQTT 6.1.2 ohne Auffälligkeiten.
Hier auch.
-
@thomas-braun , mein Senf auch dazu, PI 5 hier ohne Auffälligkeiten.
Letzter Beta Stand.
Hats der Themenersteller nun gelöst ? ....keine Anwort mehr.
@esp8266
Sorry für die späte Antwort (hatte auch nicht auf "beobachtet").
Status: Jein.
Ich habe alle MQTT-Pub's auf das altehrwürdige RPI1, welches für die Dachfenster und Sonnenstore zuständig ist, geleitet.
Dieses sendet nur alle 10min MQTT-Daten an das ioBroker RPI5. So hält die CPU-Auslastung die Füsse für 10min still.Es fällt auf, dass das RPI5 bei nur einem einzigen MQTT-Sub für 30s auf 100% CPU geht.
Das auch, wenn ich den Javascript Adapter deaktiviert habe.
Es kann also kein Loop sein.Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@esp8266
Sorry für die späte Antwort (hatte auch nicht auf "beobachtet").
Status: Jein.
Ich habe alle MQTT-Pub's auf das altehrwürdige RPI1, welches für die Dachfenster und Sonnenstore zuständig ist, geleitet.
Dieses sendet nur alle 10min MQTT-Daten an das ioBroker RPI5. So hält die CPU-Auslastung die Füsse für 10min still.Es fällt auf, dass das RPI5 bei nur einem einzigen MQTT-Sub für 30s auf 100% CPU geht.
Das auch, wenn ich den Javascript Adapter deaktiviert habe.
Es kann also kein Loop sein.@spicer sagte in iobroker.js-con 100% cpu:
Es fällt auf, dass das RPI5 bei nur einem einzigen MQTT-Sub für 30s auf 100% CPU geht.
Das auch, wenn ich den Javascript Adapter deaktiviert habe.
Es kann also kein Loop sein.Als ich von einer Schleife sprach, meinte ich eigentlich keine Javascript- sondern eine MQTT-Schleife, die entstehen kann, wenn es eine ungute Kombination aus Subscriptions, Publish und Einstellungen des Adapters gibt. Bitte mal die Einstellungen des Adapters zeigen.
Seltsam finde ich auch das Topic
mqtt.1.info.clients.mosqsub, welches ja scheinbar die Last erzeugt. Soweit ich es kenne, legt der MQTT Adapter dieses Topic nicht automatisch an, obwohl der Zweig "info" dem Adapter gehört. Hast du eine Idee, wo es herkommt?
Und macht die Instanz mqtt.0 noch irgend etwas?
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@spicer sagte in iobroker.js-con 100% cpu:
Es fällt auf, dass das RPI5 bei nur einem einzigen MQTT-Sub für 30s auf 100% CPU geht.
Das auch, wenn ich den Javascript Adapter deaktiviert habe.
Es kann also kein Loop sein.Als ich von einer Schleife sprach, meinte ich eigentlich keine Javascript- sondern eine MQTT-Schleife, die entstehen kann, wenn es eine ungute Kombination aus Subscriptions, Publish und Einstellungen des Adapters gibt. Bitte mal die Einstellungen des Adapters zeigen.
Seltsam finde ich auch das Topic
mqtt.1.info.clients.mosqsub, welches ja scheinbar die Last erzeugt. Soweit ich es kenne, legt der MQTT Adapter dieses Topic nicht automatisch an, obwohl der Zweig "info" dem Adapter gehört. Hast du eine Idee, wo es herkommt?
Und macht die Instanz mqtt.0 noch irgend etwas?
@marc-berg , scheint vielleicht eine zusätzliche Mosquitto Installation zu sein.
Ich habe wegen ebusd zwar auch eine, aber da kommt bei mir nichts ins Gehege.
Davon wird mir nichts gemeldet.
Doppelte Port Belegung !? Warum meldet das Rollo überhaupt stetig Nachrichten.
Bei meinen wird nichts gemeldet. Die laufen über sonoff. Die melden nur zurück was gerade passiert, oder auch die Procent. -
@spicer sagte in iobroker.js-con 100% cpu:
Es fällt auf, dass das RPI5 bei nur einem einzigen MQTT-Sub für 30s auf 100% CPU geht.
Das auch, wenn ich den Javascript Adapter deaktiviert habe.
Es kann also kein Loop sein.Als ich von einer Schleife sprach, meinte ich eigentlich keine Javascript- sondern eine MQTT-Schleife, die entstehen kann, wenn es eine ungute Kombination aus Subscriptions, Publish und Einstellungen des Adapters gibt. Bitte mal die Einstellungen des Adapters zeigen.
Seltsam finde ich auch das Topic
mqtt.1.info.clients.mosqsub, welches ja scheinbar die Last erzeugt. Soweit ich es kenne, legt der MQTT Adapter dieses Topic nicht automatisch an, obwohl der Zweig "info" dem Adapter gehört. Hast du eine Idee, wo es herkommt?
Und macht die Instanz mqtt.0 noch irgend etwas?
-
@marc-berg , scheint vielleicht eine zusätzliche Mosquitto Installation zu sein.
Ich habe wegen ebusd zwar auch eine, aber da kommt bei mir nichts ins Gehege.
Davon wird mir nichts gemeldet.
Doppelte Port Belegung !? Warum meldet das Rollo überhaupt stetig Nachrichten.
Bei meinen wird nichts gemeldet. Die laufen über sonoff. Die melden nur zurück was gerade passiert, oder auch die Procent.@esp8266
Das RPI5 ist ja neu installiert. Also keine weitere mosquitto Installation drauf.
Das Dachrollo sendet aktuell nur noch alle 3min, seit ich die oben genannten veränderungen gemacht habe.Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@esp8266
Das RPI5 ist ja neu installiert. Also keine weitere mosquitto Installation drauf.
Das Dachrollo sendet aktuell nur noch alle 3min, seit ich die oben genannten veränderungen gemacht habe. -
@spicer sagte in iobroker.js-con 100% cpu:
Eine Instanz mqtt.0 gibt es nicht.
Dann ist da was faul. Lösch mal den Adapter und installiere ihn neu und zwar mit Auto.
Ich habe hier 2 Mqtt Instanzen laufen. Die erste ist 0 die zweite ist 1 für die Wetterstation.Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@spicer sagte in iobroker.js-con 100% cpu:
Eine Instanz mqtt.0 gibt es nicht.
Dann ist da was faul. Lösch mal den Adapter und installiere ihn neu und zwar mit Auto.
Ich habe hier 2 Mqtt Instanzen laufen. Die erste ist 0 die zweite ist 1 für die Wetterstation.@esp8266
Ungern, weil dann alle eCharts und Blockly-Scripte die mqtt-Datenpunkte verlieren.
Gibt's eine Möglichkeit, alle installierten Instanzen in der Konsole anzuzeigen?Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@esp8266
Ungern, weil dann alle eCharts und Blockly-Scripte die mqtt-Datenpunkte verlieren.
Gibt's eine Möglichkeit, alle installierten Instanzen in der Konsole anzuzeigen? -
$ iob list instances + system.adapter.admin.0 : admin : iobroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.backitup.0 : backitup : iobroker - enabled + system.adapter.deconz.0 : deconz : iobroker - enabled, port: 80 system.adapter.discovery.0 : discovery : iobroker - disabled + system.adapter.echarts.0 : echarts : iobroker - enabled system.adapter.email.0 : email : iobroker - disabled system.adapter.flot.0 : flot : iobroker - disabled system.adapter.heizoel24-mex.0 : heizoel24-mex : iobroker - enabled + system.adapter.history.0 : history : iobroker - enabled + system.adapter.javascript.0 : javascript : iobroker - enabled + system.adapter.mqtt.1 : mqtt : iobroker - enabled, port: 1883, bind: 0.0.0.0 system.adapter.openweathermap.0 : openweathermap : iobroker - enabled system.adapter.ping.0 : ping : iobroker - disabled system.adapter.shelly.0 : shelly : iobroker - disabled, port: 1882, bind: 0.0.0.0 system.adapter.solarmanpv.0 : solarmanpv : iobroker - enabled + system.adapter.telegram.0 : telegram : iobroker - enabled, port: 8443, bind: 0.0.0.0 + system.adapter.tr-064.0 : tr-064 : iobroker - enabled system.adapter.vis-timeandweather.0 : vis-timeandweather : iobroker - disabled system.adapter.vis.0 : vis : iobroker - enabled + system.adapter.web.0 : web : iobroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin + instance is aliveSehe nichts ungewöhnliches. Du etwa?
Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz)
240
Online32.4k
Users81.4k
Topics1.3m
Posts