Hallo,
nachdem ich meinen zigbee Raumthermostaten erfolgreich in fhem eingebunden (https://forum.fhem.de/index.php?topic=142774.msg1349768#msg1349768) habe, muss ich nun leider feststellen, daß das Ding fhem nach einiger Zeit zum Einfrieren bringt.
Ich kann das Intervall nicht genau beziffern, aber es tritt immer wieder auf, daß das fhem Frontend ewig braucht bis es reagiert, im Log findet sich dann auch sowas hier:
2025-10-22T13:04:24.477923+02:00 knotenkopf node[1401109]: [2025-10-22 13:04:24] #033[31merror#033[39m: #011z2m: Not connected to MQTT server!
2025-10-22T13:04:24.478088+02:00 knotenkopf node[1401109]: [2025-10-22 13:04:24] #033[31merror#033[39m: #011z2m: Cannot send message: topic: 'zigbee2mqtt/lichtsensor', payload: '{"brightness_state":"high","illuminance":420,"linkquality":236}
2025-10-22T13:04:25.158799+02:00 knotenkopf node[1401109]: [2025-10-22 13:04:25] #033[31merror#033[39m: #011z2m: Not connected to MQTT server!
Der Lichtsensor ist hier nur beispielhaft aufgeführt, es werden praktisch alle Zigbee Geräte so aufgeführt, sprich sind nicht ansprechbar, weil die Verbindung zum MQTT Server nicht aufgebaut werden kann.
Das dauert dann ein paar Minuten und es funktioniert wieder.
Wenn ich den RT deaktiviere tritt das Problem nicht auf.
Meine Vermutung, der RT sendet sehr oft die "desired-temp", mehrmals die Minute. Möglicherweise läuft da irgendein Buffer voll, aber welcher und wo?
Da ich in zigbee noch nicht so drin stecke, kann man das Senden irgendwie reduzieren?
Vielleicht habe ich auch einen Fehler im RT gemacht, hier noch das List vom RT, vielleicht fällt jemandem was auf.
Internals:
.FhemMetaInternals 1
CID zigbee_raumthermostat
DEF zigbee_raumthermostat
FUUID 68f39d41-f33f-f310-6bbb-752578106f34ba21
FVERSION 10_MQTT2_DEVICE.pm:0.302520/2025-09-04
IODev mqtt2_server
LASTInputDev mqtt2_server
MSGCNT 3472
NAME zigbee_raumthermostat
NR 804
STATE LOCK
Measured: 19.4 °C | Desired: 18 °C | Preset: manual | Sensor: internal | Mode: heat
STILLDONETIME 0
TYPE MQTT2_DEVICE
eventCount 3473
mqtt2_server_CONN mqtt2_server_192.168.1.12_57526
mqtt2_server_MSGCNT 3472
mqtt2_server_TIME 2025-10-22 09:29:47
.DT:
DEVICETOPIC zigbee2mqtt/zigbee_raumthermostat
.attraggr:
.attreocr:
desired-temp
temperature
.attreour:
desired-temp
.attrminint:
.userReadings:
HASH(0x55ff82ede728)
HASH(0x55ff83071468)
Helper:
DBLOG:
desired-temp:
logdb:
TIME 1761118187.91917
VALUE 18
temperature:
logdb:
TIME 1761112907.6205
VALUE 19.4
JSONMAP:
Battery batteryPercent
child_lock btnLock
current_heating_setpoint desired-temp
frost_protection antiforst
local_temperature temperature
system_mode mode
voltage batterymV
READINGS:
2025-10-21 21:20:41 IODev mqtt2_server
2025-10-22 09:29:47 antiforst ON
2025-10-19 20:49:35 associatedWith zigbee_massi
2025-10-18 17:51:04 attrTemplateVersion 20240402
2025-10-22 09:29:47 backlight_mode low
2025-10-22 09:29:47 btnLock LOCK
2025-10-22 09:29:47 child_lock LOCK
2025-10-22 09:29:47 current_heating_setpoint 18
2025-10-22 09:29:47 deadzone_temperature 1
2025-10-22 09:29:47 desired-temp 18
2025-10-22 09:29:47 factory_reset OFF
2025-10-22 09:29:47 frost_protection ON
2025-10-22 09:29:47 linkquality 228
2025-10-22 09:29:47 local_temperature 19.4
2025-10-22 09:29:47 local_temperature_calibration 0
2025-10-22 09:29:47 max_temperature_limit 60
2025-10-22 09:29:47 mode heat
2025-10-22 09:29:47 preset manual
2025-10-22 09:29:47 running_state idle
2025-10-22 09:29:47 schedule_holiday 08:00/22.0°C 23:00/16.0°C
2025-10-22 09:29:47 schedule_weekday 06:00/20.0°C 08:00/16.0°C 11:30/16.0°C 12:30/16.0°C 17:00/22.0°C 22:00/16.0°C
2025-10-22 09:29:47 sensor internal
2025-10-22 07:00:00 state desired-temp
2025-10-22 09:29:47 system_mode heat
2025-10-22 09:29:47 temperature 19.4
2025-10-19 15:01:47 weekprofile heizprofile Winter:wohnzimmer
2025-10-22 09:29:47 working_day disabled
Attributes:
DbLogExclude .*
DbLogInclude temperature,desired-temp
devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
devicetopic zigbee2mqtt/zigbee_raumthermostat
disable 1
event-on-change-reading desired-temp,temperature
event-on-update-reading desired-temp
genericDeviceType thermostat
icon temp_control
jsonMap current_heating_setpoint:desired-temp local_temperature:temperature Battery:batteryPercent system_mode:mode voltage:batterymV child_lock:btnLock frost_protection:antiforst
model zigbee2mqtt_thermostat_with_weekrofile_5_1_1
readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
zigbee2mqtt/zigbee_raumthermostat:.* { json2nameValue($EVENT) }
zigbee2mqtt/zigbee_raumthermostat/availability:.* { json2nameValue($EVENT) }
room Geräte->Systeme->MQTT2,Geräte->Systeme->ZigBee,Module->Heizung
setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"current_heating_setpoint": $EVTPART1}
btnLock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}
antifrost:OFF,ON $DEVICETOPIC/set {"frost_protection": "$EVTPART1"}
mode:heat,off $DEVICETOPIC/set {"system_mode": "$EVTPART1"}
preset:hold,program $DEVICETOPIC/set {"preset": "$EVTPART1"}
saturday $DEVICETOPIC/set/schedule { "saturday":[$EVTPART1] }
sunday $DEVICETOPIC/set/schedule { "sunday":[$EVTPART1] }
weekdays $DEVICETOPIC/set/schedule { "weekdays":[$EVTPART1] }
weekprofile { no strict 'vars';; FHEM::attrT_z2m_thermostat_Utils::z2t_send_BHT($NAME, $EVTPART1, $EVTPART2) }
x_send_set_payload:textField { my $payload = $EVENT;;$payload =~ s/$EVTPART0 //;; qq($DEVICETOPIC/set $payload)}
backlight:off,low,medium,high $DEVICETOPIC/set {"backlight_mode": "$EVTPART1"}
stateFormat child_lock
Measured: local_temperature °C | Desired: current_heating_setpoint °C | Preset: preset | Sensor: sensor | Mode: system_mode
userReadings batteryState:battery_low.* {ReadingsVal($name,'battery_low','false') eq 'false'?'ok':'low'}, batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}
webCmd desired-temp
Nicht über das "disable = 1" wundern, ich habe den RT im Moment deaktiviert.
Danke!
gm
Vermutlich hat das nichts mit zigbee zu tun => falscher Forenbereich, nach MQTT verschieben und die dort angepinnten Fragen beantworten.
Der doppelte readingList-Eintrag ist unnötig und vielleicht irreführend, aber das ist nicht das eigentliche Problem.
Zitat[...] es tritt immer wieder auf, daß das fhem Frontend ewig braucht bis es reagiert,
Das liegt entweder daran, dass FHEM zu viele Aufgaben abarbeiten muss (z.Bsp. weil die Nachrichten Folgeaktionen ausloesen), oder weil ein FHEM Modul auf irgendetwas wartet.
Welcher der beiden Faelle vorliegt, kann man an dem CPU-Verbrauch feststellen.
Ich wuerde "attr global verbose <X>" schrittweise erhoehen, und parallel zu einem Seitenaufruf das Log beobachten.
O.K., danke, dann werde ich nochmal forschen und evtl. noch mal im MQTT Board nachfragen.
ZitatDer doppelte readingList-Eintrag ist unnötig
Meinst Du das hier? Weil der obere den unteren Eintrag schon mit einschließt?
zigbee2mqtt/zigbee_raumthermostat:.* { json2nameValue($EVENT) }
zigbee2mqtt/zigbee_raumthermostat/availability:.* { json2nameValue($EVENT) }
Zitat von: grossmaggul am 22 Oktober 2025, 15:28:28Meinst Du das hier? Weil der obere den unteren Eintrag schon mit einschließt?
zigbee2mqtt/zigbee_raumthermostat:.* { json2nameValue($EVENT) }
zigbee2mqtt/zigbee_raumthermostat/availability:.* { json2nameValue($EVENT) }
Nein. Die ersten beiden Zeilen. Da werden nur unterschiedliche Readings erzeugt...
O.K., da hing noch ein anderes Template drin. ::)
Ich habe das Device nochmal neu angelegt, bringt aber leider keine Besserung.
Die CPU Auslastung von fhem liegt beim Hänger bei 0.2-0.9
Kannst du mal aus dem Z2M-Log eine der MQTT-Nachrichten rauskopieren, die Z2M über zigbee2mqtt/zigbee_raumthermostat sendet? Quasi so wie oben, nur da war es ja lichtsensor. Und nicht im Fehlerfall, sondern einfach im Normalbetrieb.
Und dann auch über einen Klick auf Show MQTT Traffic im MQTT2_SERVER-Device das, was bei FHEM ankommt?
Bitte poste auch mal (falls definiert) ein list von deinem zigbee2mqtt-Bridge-Device in FHEM.
Hallo,
danke für Euren Einsatz!
Hier mal die Zeile aus dem z2m Log:
MQTT publish: topic 'zigbee2mqtt/zigbee_raumthermostat', payload '{"backlight_mode":"low","child_lock":"LOCK","current_heating_setpoint":18,"deadzone_temperature":1,"factory_reset":"OFF","frost_protection":"OFF","linkquality":228,"local_temperature":21,"local_temperature_calibration":0,"max_temperature_limit":60,"preset":"manual","running_state":"idle","schedule_holiday":"08:00/22.0°C 23:00/16.0°C","schedule_weekday":"06:00/20.0°C 08:00/16.0°C 11:30/16.0°C 12:30/16.0°C 17:00/22.0°C 22:00/16.0°C","sensor":"internal","system_mode":"heat","working_day":"disabled"}'
Und hier aus dem MQTT Server:
20:35:47.425
zigbee_massi
zigbee2mqtt/zigbee_raumthermostat
{"backlight_mode":"low","child_lock":"LOCK","current_heating_setpoint":18,"deadzone_temperature":1,"factory_reset":"OFF","frost_protection":"OFF","linkquality":228,"local_temperature":21,"local_temperature_calibration":0,"max_temperature_limit":60,"preset":"manual","running_state":"idle","schedule_holiday":"08:00/22.0(194)(176)C 23:00/16.0(194)(176)C","schedule_weekday":"06:00/20.0(194)(176)C 08:00/16.0(194)(176)C 11:30/16.0(194)(176)C 12:30/16.0(194)(176)C 17:00/22.0(194)(176)C 22:00/16.0(194)(176)C","sensor":"internal","system_mode":"heat","working_day":"disabled"}
Eine zigbee2mqtt Bridge habe ich nicht.
Ziemlich sicher ist es immer noch kein ZigBee-Problem (im Sinne der Forenstruktur).
Imo solltest du zigbee2mqtt mal deaktivieren, und dann nachsehen, was du überhaupt an MQTT-Konfiguration hast (anfangen mit "list TYPE=MQTT.*") und wie viele Events FHEM ohne das zu verarbeiten hat. Siehe dazu auch Rudis Hinweis.
Ich habe den Verdacht, dass irgendwas via MQTT unbeabsichtigt im Kreis herumgeschickt wird...
O.K., ich habe gerade festgestellt, daß ich doch ein Bridge Device habe, weil ich dem aber einen uneindeutigen Namen gegeben habe, habe ich nicht gleich gefunden.
Wenn ich zigbee2mqtt stoppe und list TYPE=MQTT.* mache gibt's das hier:
DVES_64A27E
Laserdrucker
Stromzaehler
bz.kinoanlage
mqtt2_server
mqtt2_server_192.168.1.175_58122
mqtt2_server_192.168.1.52_64259
mqtt2_server_192.168.1.54_53575
mqtt2_server_192.168.1.55_63803
wz.led_wand
zigbee_Coordinator
zigbee_Heizkoerper
zigbee_Radiator
zigbee_klofenster
zigbee_lichtsensor
zigbee_lichtsensor_aquara
zigbee_massi
zigbee_orchideen
zigbee_plug2
zigbee_raumthermostat
zigbee_server
zigbee_temp_hum_sensor
Warum da allerdings vier MQTT Server auftauchen ist mir schleierhaft.
zigbee_massi ist übrigens die Bridge, man sollte seinen Devices bessere Namen geben, dann findet man sie auch wieder.:-/
Es scheint wohl tatsächlich ein MQTT Problem zu sein, kann man das Thema vielleicht verschieben?
Was macht zigbee_Coordinator? Ist das nicht die Bridge?
Poste bitte mal ein list sowohl von zigbee_Coordinator als auch von zigbee_massi.
Zitat von: grossmaggul am 23 Oktober 2025, 11:15:58Es scheint wohl tatsächlich ein MQTT Problem zu sein, kann man das Thema vielleicht verschieben?
Kannst du selbst, Knopf dazu sollte ganz unten unter dem ersten Beitrag zu finden sein.
Zitat von: grossmaggul am 23 Oktober 2025, 11:15:58Warum da allerdings vier MQTT Server auftauchen ist mir schleierhaft.
Ist wie bei FHEMWEB etc. auch: Jedes verbundene Gerät ergibt eine Instanz.
Wie schaut es mit der Zahl der events (ohne laufendes zigbee2mqtt) aus?
PS: diese "friendly names" sind alles andere als freundlich und nicht selten der Grund für "komische" Probleme. z2m kennt sowas wie ein Kommentarfeld, da kann man reinschreiben, für was die Dinger jeweils da sind, und in FHEM kann man das auch umbenennen, aber die Topics sollten "technisch" bleiben. Just (nicht nur) my2ct.
Thema ist verschoben nach MQTT
List vom Coordinator:
Internals:
.FhemMetaInternals 1
CID zigbee_Coordinator
DEF zigbee_Coordinator
FUUID 67540229-f33f-f310-4f5d-c83911eb25c27e19
FVERSION 10_MQTT2_DEVICE.pm:0.302520/2025-09-04
IODev mqtt2_server
NAME zigbee_Coordinator
NR 775
STATE online
TYPE MQTT2_DEVICE
.DT:
DEVICETOPIC zigbee_Coordinator
READINGS:
2025-10-23 10:39:25 IODev mqtt2_server
2024-12-07 09:07:05 associatedWith zigbee_massi
2025-10-09 21:12:46 state online
Attributes:
DbLogExclude .*
icon scene_cooking
readingList zigbee2mqtt/Coordinator/availability:.* { json2nameValue($EVENT) }
room Geräte->Systeme->ZigBee
Das List von der Bridge ist sehr lang, die Forensoftware streikt dann.:^/
Ich habe es mal als Text angehängt.
Ja, das mit den Friendly names habe ich auch schon gemerkt, daß das durcheinander gibt.
Events sind so um 12 pro Minute ohne zigbee2mqtt.
Zitat von: grossmaggul am 23 Oktober 2025, 12:18:38Events sind so um 12 pro Minute ohne zigbee2mqtt.
Das klingt jetzt nicht so, als wäre der Rechner damit irgendwie bereits grenzwertig ausgelastet...
Die list-Liste sieht danach aus, als gäbe es nur den MQTT2_SERVER (mit diversen Verbindungen) und ein paar wenige MQTT2_DEVICE-Instanzen. Auch das sollte eigentlich kein Problem darstellen.
Du hast auch nicht versehentich parallel einen mosquitto installiert, oder?
Dann würde ich z2m mal wieder aktivieren und dort ins log schauen, ob da was außergewöhnliches drin steht, und das loggen von z2m auf ein "normales" level setzen, falls du da was hochgedreht hattest.
Das "bridge"-Device könnte man entschlacken und v.a. die diversen Status- und log-Einträge schlicht nicht verarbeiten (hinten {} als Pseudo-Perl-Aufruf reinnehmen).
ZitatDas klingt jetzt nicht so, als wäre der Rechner damit irgendwie bereits grenzwertig ausgelastet...
Würde mich auch wundern, daß ein XEON mit 36GB RAM davon ausgelastet wäre, selbst wenn da mehr los sein sollte.
ZitatDu hast auch nicht versehentich parallel einen mosquitto installiert, oder?
Nein, habe ich nicht, weder auf diesem, noch auf anderen Rechnern im Netzwerk.
ZitatDas "bridge"-Device könnte man entschlacken und v.a. die diversen Status- und log-Einträge schlicht nicht verarbeiten
Meinst Du sowas hier aus der 'readingsList'?
$DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices
$DEVICETOPIC/bridge/log:.* log
$DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }Sorry, für die doofen Fragen, aber ich sehe im Moment den Wald vor lauter Bäumen nicht.%-}
Genau diese 3 Zeilen waren gemeint=> zwei draus machen und die dann "nichts" machen lassen.
Trotzdem sehr komisch, dass dein Rechner wegen der paar Bytes in die Knie gehen soll.
Dann muss noch irgendwas anderes fhem komplett aus bremsen => Rudis Hinweis nachgehen und ggf. apptime anwerfen.
Vielleicht ist das auch irgend so ein Sonderzeichenproblem wegen des (mE unüblichen) Grad-Symbols?
Ich sehe nämlich grade, Z2M sendet:
Zitat von: grossmaggul am 22 Oktober 2025, 20:40:54"schedule_holiday":"08:00/22.0°C 23:00/16.0°C","schedule_weekday":"06:00/20.0°C 08:00/16.0°C 11:30/16.0°C 12:30/16.0°C 17:00/22.0°C 22:00/16.0°C"
Und FHEM empfängt:
Zitat von: grossmaggul am 22 Oktober 2025, 20:40:54"schedule_holiday":"08:00/22.0(194)(176)C 23:00/16.0(194)(176)C","schedule_weekday":"06:00/20.0(194)(176)C 08:00/16.0(194)(176)C 11:30/16.0(194)(176)C 12:30/16.0(194)(176)C 17:00/22.0(194)(176)C 22:00/16.0(194)(176)C"
Wobei es im Reading richtig dargestellt wird, vielleicht ist das also auch nur ein Problem von
Show MQTT Traffic ...
Zitat von: grossmaggul am 22 Oktober 2025, 13:39:232025-10-22 09:29:47 schedule_holiday 08:00/22.0°C 23:00/16.0°C
2025-10-22 09:29:47 schedule_weekday 06:00/20.0°C 08:00/16.0°C 11:30/16.0°C 12:30/16.0°C 17:00/22.0°C 22:00/16.0°C
ZitatGenau diese 3 Zeilen waren gemeint=> zwei draus machen und die dann "nichts" machen lassen.
Ähm und welche zwei lasse ich drin. ::)
Ich habe gestern Abend mal alle "(un)Friendly Names" entfernt und die Namen nur in fhem gesetzt. War zwar ein wenig Gepiddel, aber ich musste zumindest nicht die Geräte neu anlegen.
Das Problem scheint gelöst, zumindest hatte ich jetzt mehrere Stunden keine Hänger mehr.
Vielen Dank für Eure Hilfe!!