Vielen Dank für die Info. Ich probiere es demnächst aus.
Hast du mal geschaut ob in dem Fall wenn die CPU Auslastung steigt, ein oder sogar mehrere PHP Thread hängt? Ich habe die Erfahrung gemacht dass das die Last massiv nach oben treibt. Nicht das hier was von dem neu installierten Instanzen hängt.
Wenn die CPU-Last am Anschlag ist, kann man erst wieder was machen, wenn das Modul gelöscht ist.
Ich probiere erst einmal beim nächsten Test das HA abzuhängen und schaue, was passiert.
Gorans Hinweis ist berechtigt: Ein Thread, der sich verrannt hat, sieht von außen genauso aus. Deine 50 % in Symcon sind auf dem Dual Core genau ein voll belegter Kern — das passt zu beidem, einem Thread, der Nachricht um Nachricht abarbeitet, wie zu einem, der hängt.
Statt HA abzuhängen gibt es einen Test, der die beiden Fälle sauber trennt: die MQTT-Client-Instanz in Symcon kurz auf inaktiv setzen (Haken „Instanz aktiv" im Formular, dann Übernehmen). Fällt die Last sofort, ist es der Nachrichtenstrom, und die statestream-Filter von oben sind der richtige Hebel. Bleibt sie oben, obwohl nichts mehr hereinkommt, steckt es woanders — dann magst du mir die logfile.txt aus dem logs-Ordner von diesem Zeitraum schicken; darin sollte zu sehen sein, was in dem Moment noch lief.
Hier der Log
8/28/2026 10:40:02 AM | 20539 | NOTIFY | Home Assistant Splitter | Topic-Statistik Fenster 300s | total=10253 (2050.6/min) | Entitäten=25 | Geräte=4 | Top: jackery_* 9814 (1962.8/min), HR2C04000089HH3 246 (49.2/min), rieden_jackery_* 180 (36.0/min), sun 13 (2.6/min)
8/28/2026 10:52:33 AM | 20539 | NOTIFY | Home Assistant Splitter | Topic-Statistik Fenster 300s | total=8968 (1793.6/min) | Entitäten=26 | Geräte=4 | Top: jackery_* 8536 (1707.2/min), HR2C04000089HH3 253 (50.6/min), rieden_jackery_* 166 (33.2/min), sun 13 (2.6/min)
8/28/2026 10:57:33 AM | 20539 | NOTIFY | Home Assistant Splitter | Topic-Statistik Fenster 300s | total=8494 (1698.8/min) | Entitäten=29 | Geräte=7 | Top: jackery_* 7985 (1597.0/min), HR2C04000089HH3 231 (46.2/min), rieden_jackery_* 224 (44.8/min), sun 26 (5.2/min), forecast_home 19 (3.8/min), sm_s931b_battery_level 8 (1.6/min), homeassistant 1 (0.2/min)
Anfangs war der Shelly EM3 als Jackery Smartmeter in HA noch aktiv und die CPU-Last am Anschlag.
Nachdem ich das Smartmeter in HA deaktiviert habe, ist die Last nun wieder bei den üblichen 5-10 %
Obwohl die Zahl der Topics nur um 20 % niedriger wurde
Danke für die Zahlen, die sind aufschlussreich. 2000 Nachrichten pro Minute sind für sich genommen nicht dramatisch — mein Splitter hier verarbeitet ähnliche Raten bei wenigen Prozent Last. Was mich stutzig macht: Das Smartmeter hat nur 20 % der Nachrichten ausgemacht, aber 95 % der Last. Das riecht nach wenigen, dafür großen Nachrichten — etwa einem Attribut, in dem die Jackery-Integration einen ganzen JSON-Block mitschickt, solange das Smartmeter aktiv ist.
Die Statistik hat bisher nur gezählt, nicht gewogen. Seit eben liegt Beta 1.4 #149 im Store, die zusätzlich die Datenmenge und die größte Einzelnachricht je Gerät ausweist (in der Log-Zeile hinten als Bytes-Top). Magst du auf die Beta wechseln, das Smartmeter in HA für ein Statistik-Fenster von 5 Minuten wieder aktivieren und mir die Zeile posten? Damit haben wir den Verursacher beim Namen — und sehr wahrscheinlich reicht dann ein einzelner exclude-Eintrag, statt das Smartmeter ganz abzuschalten.
hier die neuen Werte mit aktiviertem SM
28.08.2026, 13:49:18 | TopicStats | Fenster 300s | total=9205 (1841.0/min) | 335.3 KB (1.1 KB/s, max 1.3 KB) | Entitäten=86 | Geräte=5
28.08.2026, 13:49:18 | TopicStats | jackery_* 7944 (1588.8/min) 180.2 KB max 126 B
28.08.2026, 13:49:18 | TopicStats | rieden_jackery_* 1000 (200.0/min) 37.7 KB max 546 B
28.08.2026, 13:49:18 | TopicStats | HR2C04000089HH3 247 (49.4/min) 116.8 KB max 1.3 KB
28.08.2026, 13:49:18 | TopicStats | sun 13 (2.6/min) 576 B max 68 B
28.08.2026, 13:49:18 | TopicStats | homeassistant 1 (0.2/min) 12 B max 12 B
28.08.2026, 13:49:18 | TopicStats | Top-Entitäten nach Bytes:
28.08.2026, 13:49:18 | TopicStats | hb/device/HR2C04000089HH3 247 (49.4/min) 116.8 KB max 1.3 KB
nach erneutem Deaktivierung des SM in HA dauert es ca 5 Minuten, bis die CPU-Last wieder normal ist
Die Datenmenge ist unschuldig: 1,1 KB/s merkt kein Rechner — meine Vermutung mit den großen Nachrichten war falsch. Auffällig ist trotzdem der dickste Byte-Posten: hb/device/HR2C04000089HH3 liegt gar nicht im Home-Assistant-Baum, kommt also nicht aus dem statestream, sondern von einem Gerät, das direkt auf deinen Broker sendet. Vermutlich abonniert dein MQTT Client # — dann landet auch dieser Fremdverkehr im Splitter. Grenz das auf homeassistant/# ein.
Der Treiber ist die Menge: allein 1589 Nachrichten pro Minute vom Jackery, im Schnitt 23 Byte — Winzigkeiten, aber jede kostet Verarbeitung. Dass die Last nach dem Abschalten noch fünf Minuten nachläuft, zeigt den Rückstau: Deine Maschine liegt knapp an der Grenze, deshalb kippt sie schon bei 8 % mehr Nachrichten von 5 % auf 100 %.
Wirksamster Hebel ist publish_timestamps: false — HA schickt zu jedem Wert noch last_changed und last_updated, beide wirft das Modul ohnehin weg; das spart ein gutes Drittel. Dazu exclude für die Jackery-Werte, die du in Symcon nicht brauchst. Und wenn die Messung durch ist: Topic-Statistik und Performance-Timing wieder abschalten, die kosten selbst etwas.
Aus deinem Fall ist gleich ein Fix geworden: Beta 1.4 #150 ist online. Der Splitter nimmt jetzt nur noch Topics unterhalb seines Base-Topics an — der hb/device/…-Verkehr, den dein #-Abonnement mitbringt, kostet dich damit keine Rechenzeit mehr, auch ohne Änderung am Abonnement.
Die beiden anderen Hebel ersetzt das nicht: Der Löwenanteil sind die 1589 Nachrichten pro Minute vom Jackery, und die kommen aus dem Statestream — dagegen hilft nur publish_timestamps: false und eine exclude-Liste. Magst du die Beta einspielen und danach nochmal ein Statistik-Fenster posten?
Nebenbei hat dein Fall die Doku korrigiert: Dort stand bisher publish_timestamps: true — das verdreifacht die Nachrichtenmenge, ohne dass das Modul etwas davon nutzt.
Die hb/.. kommen, wie auch die homeassistant Werte von der jackery Integration des HA.
Wie kann ich das Ips HA modul auf homeassistant/# eingrenzen?
Vorerst brauche ich die Smartmeterwerte aus HA nicht, da ich die sowieso über Mqtt vom Shelly direkt bekomme.
Wichtig ist für mich u.a. der Wert für den Betriebsmodus der Jackery, da ich damit den Modus umschalten kann, um z.B. von Einspeisung auf Netzladung bei niedrigen Börsenpreisen umzuschalten.
Das Abonnement stellst du nicht im HA-Modul ein, sondern eine Ebene darüber: in der MQTT-Client-Instanz, mit der der Splitter verbunden ist. Du kommst direkt hin, ohne im Objektbaum zu suchen — in der Splitter-Konfiguration oben auf „Schnittstelle konfigurieren" klicken. Dort in der Liste Subscriptions das # durch homeassistant/# ersetzen.
Du hattest recht mit der Nachfrage, im Modul selbst sucht man das vergeblich. Selbsttest und Doku sagen es jetzt dazu.
Bei den statestream-Filtern würde ich in deinem Fall zu include statt exclude raten: Der Betriebsmodus, den du zum Umschalten brauchst, kommt aus derselben Integration wie die Smartmeter-Werte — ein pauschales exclude auf die Jackery-Entitäten nähme ihn dir mit. Mit include listest du die paar Entitäten auf, die du wirklich brauchst. Das Schalten läuft übrigens über REST und ist von den Filtern unberührt; nur die Statusanzeige hinge, wenn die Entität nicht mehr publiziert wird.
Super - Danke für die Infos !
Guten Tag,
ich nutze das Home-Assistant-Modul von bumaas, habe jedoch ein Problem mit der Statusaktualisierung:
-
Befehle von IP-Symcon nach Home Assistant funktionieren einwandfrei.
-
Wenn sich der Status in Home Assistant ändert oder Geräte dort geschaltet werden, wird dieser Status nicht an IP-Symcon zurückgemeldet.
Hat jemand einen Tipp, woran das liegen könnte oder wie sich der Rückkanal korrekt konfigurieren lässt?
Vielen Dank im Voraus!
Gruß, Simon
Hallo Simon,
das ist der Klassiker bei dieser Richtung: Geschaltet wird über REST, die Zustände kommen aber ausschließlich über den mqtt_statestream. Fehlt der oder passt das Abonnement nicht, funktioniert genau eine Richtung.
Der Splitter hat dafür einen Knopf: „Selbsttest ausführen" in seiner Konfiguration. Er prüft Parent, Token, Basis-Topic, ankommende MQTT-Daten und die Subscription und sagt dir als Checkliste, woran es hängt. Magst du den einmal laufen lassen und das Ergebnis hier posten?
Die zwei häufigsten Ursachen vorweg: In Home Assistant ist mqtt_statestream gar nicht aktiviert oder sein base_topic passt nicht zu MQTTBaseTopic im Splitter. Oder der MQTT Client abonniert den Baum nicht — das Abonnement stellst du nicht im Modul ein, sondern in der MQTT-Client-Instanz darüber; du kommst in der Splitter-Konfiguration oben über „Schnittstelle konfigurieren" direkt hin und trägst dort homeassistant/# ein.
Hallo, ich habe jetzt mal einige HUE Lampen von der Bridge in HA per Zigbee2MQTT umgezogen. Allerdings habe ich mit der Farbsteuerung so meine Probleme. Ich dachte Mired wäre das native Format dazu, aber in HA kommt das nicht an. Was ist die beste Variante zur Farbsteuerung ? Am liebsten würde ich die “Farbkreise” aus JS-live von @acer90 verwenden, da schon konfiguriert
gruss Pentti
Mired kennt Home Assistant seit 2026.3 nicht mehr. light.turn_on nimmt für Weißtöne nur noch color_temp_kelvin, in Symcon also die Variable „Farbtemperatur K“. Die Mired-Variable funktioniert ab der Beta 1.4 #162 wieder, das Modul rechnet sie jetzt in Kelvin um.
Für Farben legt das Modul je nach supported_color_modes der Lampe eine eigene Variable an. Hue über Zigbee2MQTT meldet meist xy, dann heißt sie „XY-Farbe“ und bringt in der Kachel-Visu gleich einen Farbwähler mit.
Ob die Farbkreise von @acer90 mit dem xy-Wert umgehen können, weiß ich nicht. Welche Farbvariablen hat das Modul bei dir denn angelegt?
Soweit ich das sehe:
Farbtemperatur Mired
Farbtemperatur K
xy-Farbe
RGB bzw HS Farbe gibts zwar auch noch, sind aber glaube ich Statusvariablen
Ich versuchs mal mit XY-Farbe
Danke und Gruss
Kleine Rückmeldung, betrifft aber eigentlich nicht das Modul hier.
Da ich nur Ipsview als Visu habe und Kacheln dort noch nicht richtig eingebunden werden, habe ich quasi keinen Farbkreis zur Verfügung. Weder Ipsview noch JS Live kann xy-Farbe und die Farbtemperatur Mired funktioniert zumindest bei mir nicht.
Jetzt brauche ich es nicht mehr, für meine Geräte, da die jetzt direkt mit Symcon laufen.
War ein wichtiger Zwischenschritt für mich, Danke für deine Arbeit.
Ich denke, ich kann für mich jetzt HA abschalten.
Thomas 
Es kommt gelegentlich vor, dass Werte, die das Programm angelegt hatte, plötzlich doppelt vorliegen: einemal mit dem Zusatz (veraltet) und einmal ohne. Die mit dem Zusatz werden nicht mehr aktualisiert. Dies ist problematisch bei Verknüpfungen über die ID z.B. bei Heating Contol oder IPS-View. Wie kommt dies Zustande?
Grüße, Gerhard