Mein FHEM-System ist kaum noch zu bedienen (extrem langsam), weil ich mit über MQTT mit meinem CerboGX verbunden habe (daher steht hier disconnected).
1.) Zunächst verbinde ich mich mit dem CerboGX über
Internals:
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.250:1883
DeviceName 192.168.1.250:1883
FUUID 639780f6-f33f-ec85-0545-a43ff5e704ebb57a
FVERSION 00_MQTT2_CLIENT.pm:0.274100/2023-04-07
NAME CerboGxClient
NR 926
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId CerboGxClient
eventCount 155
lastMsgTime 1681135548.85178
nextOpenDelay 10
nrConnects 118
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-04-10 16:16:58 lastPublish R/c0619ab1e261/keepalive:
2023-04-10 16:05:48 state disconnected
helper:
bm:
MQTT2_CLIENT_Attr:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 10.04. 15:47:22
max 8.60691070556641e-05
tot 8.60691070556641e-05
mAr:
set
CerboGxClient
event-on-update-reading
.*
MQTT2_CLIENT_Read:
cnt 392
dmx -1000
dtot 0
dtotcnt 0
mTS 10.04. 16:04:09
max 0.141295909881592
tot 12.4313578605652
mAr:
HASH(0x562d05e12198)
MQTT2_CLIENT_Set:
cnt 143
dmx -1000
dtot 0
dtotcnt 0
mTS 10.04. 15:56:58
max 0.0896868705749512
tot 0.447796821594238
mAr:
HASH(0x562d05e12198)
CerboGxClient
publish
R/c0619ab1e261/keepalive
MQTT2_CLIENT_connect:
cnt 10
dmx -1000
dtot 0
dtotcnt 0
mTS 10.04. 15:59:50
max 0.00205302238464355
tot 0.00787186622619629
mAr:
HASH(0x562d05e12198)
Attributes:
event-on-change-reading .*
event-on-update-reading .*
room MQTT
2.) Dann rufe ich die Daten für FHEM ab:
Internals:
CID CerboGxClient
CerboGxClient_MSGCNT 85154
CerboGxClient_TIME 2023-04-10 16:05:48
DEF CerboGxClient
FUUID 63978863-f33f-ec85-5104-28d6006baa21d3df
FVERSION 10_MQTT2_DEVICE.pm:0.268600/2022-12-16
IODev CerboGxClient
LASTInputDev CerboGxClient
MSGCNT 85154
NAME MQTT2_CerboGxClient
NR 927
STATE Batterie: 97 %
TYPE MQTT2_DEVICE
eventCount 74403
READINGS:
2023-04-10 16:01:16 276_SystemBattery_Enabled_value 1
2023-04-10 16:05:19 276_SystemBattery_Name_value Multi+
2023-04-10 16:05:15 276_SystemBattery_Service_value com.victronenergy.vebus/276
2023-04-10 16:05:29 512_BatteryLowVoltage_value 44.5
2023-04-10 16:04:22 512_Capacity_value 394
2023-04-10 16:01:03 512_CellImbalance_value 0
2023-04-10 16:01:03 512_ChargeBlocked_value 0
2023-04-10 16:05:25 512_ChargeRequest_value 0
2023-04-10 16:01:03 512_Connected_value 1
2023-04-10 16:01:04 512_Connection_value CAN-bus
2023-04-10 16:05:45 512_Current_value 2.700000047683716
2023-04-10 16:05:20 512_CustomName_value
2023-04-10 16:05:23 512_DeviceInstance_value 512
2023-04-10 16:05:37 512_DischargeBlocked_value 0
2023-04-10 16:05:18 512_FirmwareVersion_value 26368
2023-04-10 16:01:03 512_HighChargeCurrent_value 0
2023-04-10 16:05:42 512_HighChargeTemperature_value 0
2023-04-10 16:01:03 512_HighDischargeCurrent_value 0
2023-04-10 16:05:39 512_HighTemperature_value 0
2023-04-10 16:01:03 512_HighVoltage_value 0
2023-04-10 16:01:04 512_InstalledCapacity_value 399
2023-04-10 16:05:23 512_InternalFailure_value 0
2023-04-10 16:05:43 512_LowChargeTemperature_value 0
2023-04-10 16:01:03 512_LowTemperature_value 0
2023-04-10 16:05:28 512_LowVoltage_value 0
2023-04-10 16:05:18 512_MaxCellTemperature_value 21.0
2023-04-10 16:05:43 512_MaxCellVoltage_value 3.378000020980835
2023-04-10 16:05:35 512_MaxChargeCurrent_value 50.0
2023-04-10 16:05:21 512_MaxChargeVoltage_value 56.79999923706055
2023-04-10 16:01:04 512_MaxDischargeCurrent_value 200.0
2023-04-10 16:05:21 512_MaxTemperatureCellId_value 0000
2023-04-10 16:05:15 512_MaxVoltageCellId_value 0200
2023-04-10 16:05:40 512_MinCellTemperature_value 19.0
2023-04-10 16:05:15 512_MinCellVoltage_value 3.365000009536743
2023-04-10 16:05:45 512_MinTemperatureCellId_value 1000
2023-04-10 16:05:15 512_MinVoltageCellId_value 0200
2023-04-10 16:05:31 512_NrOfModulesBlockingCharge_value 0
2023-04-10 16:05:18 512_NrOfModulesBlockingDischarge_value 0
2023-04-10 16:05:38 512_NrOfModulesOffline_value 0
2023-04-10 16:05:42 512_NrOfModulesOnline_value 4
2023-04-10 16:05:15 512_Power_value 161
2023-04-10 16:05:37 512_ProductId_value 45063
2023-04-10 16:05:43 512_ProductName_value PYTES
2023-04-10 16:01:04 512_Redetect_value 0
2023-04-10 16:05:15 512_Serial_value LC0B010402120268
2023-04-10 16:05:31 512_Soc_value 98
2023-04-10 16:05:16 512_Soh_value 100
2023-04-10 16:01:16 512_SystemBattery1_Enabled_value 0
2023-04-10 16:05:19 512_SystemBattery1_Name_value
2023-04-10 16:05:30 512_SystemBattery1_Service_value com.victronenergy.battery/512/1
2023-04-10 16:05:41 512_SystemBattery2_Enabled_value 0
2023-04-10 16:01:16 512_SystemBattery2_Service_value com.victronenergy.battery/512
2023-04-10 16:05:48 512_SystemBattery_2Name_value Pytes
2023-04-10 16:01:03 512_Temperature_value 20.299999237060547
2023-04-10 16:05:40 512_Voltage_value 53.900001525878906
2023-04-10 16:01:37 Absorption_value 0
2023-04-10 16:01:05 Alarm_Audible_value 0
2023-04-10 16:05:28 Alarm_GridLost_value 1
2023-04-10 16:01:05 Alarm_LowBattery_value 1
2023-04-10 16:05:24 Alarm_TemperatureSenseError_value 1
2023-04-10 16:01:06 Ble_Pincode_value 000000
2023-04-10 16:05:35 Bms_BmsParameters_value 0
2023-04-10 16:00:59 Buzzer_State_value 0
2023-04-10 16:05:40 CGwacs_AcPowerSetPoint_value 50.0
2023-04-10 16:01:06 CGwacs_BatteryLife0_Day_value 7
2023-04-10 16:05:20 CGwacs_BatteryLife0_Duration_value 64740
2023-04-10 16:01:06 CGwacs_BatteryLife0_Soc_value 95
2023-04-10 16:05:18 CGwacs_BatteryLife0_Start_value 32400
2023-04-10 16:05:16 CGwacs_BatteryLife1_Day_value -7
2023-04-10 16:05:17 CGwacs_BatteryLife1_Duration_value 0
2023-04-10 16:01:06 CGwacs_BatteryLife1_Soc_value 100
2023-04-10 16:05:18 CGwacs_BatteryLife1_Start_value 0
2023-04-10 16:05:16 CGwacs_BatteryLife2_Day_value -7
2023-04-10 16:05:16 CGwacs_BatteryLife2_Duration_value 0
2023-04-10 16:01:06 CGwacs_BatteryLife2_Soc_value 100
2023-04-10 16:05:18 CGwacs_BatteryLife2_Start_value 0
2023-04-10 16:05:16 CGwacs_BatteryLife3_Day_value -7
2023-04-10 16:05:16 CGwacs_BatteryLife3_Duration_value 0
2023-04-10 16:01:06 CGwacs_BatteryLife3_Soc_value 100
2023-04-10 16:05:18 CGwacs_BatteryLife3_Start_value 0
2023-04-10 16:05:16 CGwacs_BatteryLife4_Day_value -7
2023-04-10 16:05:16 CGwacs_BatteryLife4_Duration_value 0
2023-04-10 16:01:06 CGwacs_BatteryLife4_Soc_value 100
2023-04-10 16:05:18 CGwacs_BatteryLife4_Start_value 0
2023-04-10 16:05:46 CGwacs_BatteryLife_SocLimit_value 5.0
2023-04-10 16:05:40 CGwacs_BatteryLife_State_value 4
2023-04-10 16:05:36 CGwacs_DeviceIds_value BW2560014001D
2023-04-10 16:05:41 CGwacs_DischargedTime_value 1678501231
2023-04-10 16:05:48 CGwacs_Flags_value 3
2023-04-10 16:05:38 CGwacs_Hub4Mode_value 1
2023-04-10 16:01:06 CGwacs_MaxChargePercentage_value 100.0
2023-04-10 16:05:36 CGwacs_MaxChargePower_value 1000.0
2023-04-10 16:05:32 CGwacs_MaxDischargePercentage_value 100.0
2023-04-10 16:05:23 CGwacs_MaxDischargePower_value -1.0
2023-04-10 16:01:06 CGwacs_MaxFeedInPower_value 1000.0
2023-04-10 16:05:36 CGwacs_MinimumSocLimit_value 10.0
2023-04-10 16:05:33 CGwacs_OvervoltageFeedIn_value 1
2023-04-10 16:05:17 CGwacs_PreventFeedback_value 0
2023-04-10 16:05:28 CGwacs_RunWithoutGridMeter_value 0
2023-04-10 16:05:47 CanBms1_CustomName_value
2023-04-10 16:01:07 CanBms1_ProductId_value 45063
2023-04-10 16:05:16 Canbus_0_Profile_value 1
2023-04-10 16:01:07 Canbus_1_Profile_value 3
2023-04-10 16:05:13 Current_value -2.4000000953674316
2023-04-10 16:05:43 DigitalInput1_AlarmSetting_value 0
2023-04-10 16:05:18 DigitalInput1_Count_value 0
2023-04-10 16:05:16 DigitalInput1_CustomName_value
2023-04-10 16:05:48 DigitalInput1_InvertAlarm_value 0
2023-04-10 16:01:11 DigitalInput1_InvertTranslation_value 0
2023-04-10 16:05:19 DigitalInput1_Multiplier_value 0.001
2023-04-10 16:05:37 DigitalInput1_Type_value 0
2023-04-10 16:01:11 DigitalInput2_AlarmSetting_value 0
2023-04-10 16:01:11 DigitalInput2_Count_value 0
2023-04-10 16:05:36 DigitalInput2_CustomName_value
2023-04-10 16:05:39 DigitalInput2_InvertAlarm_value 0
2023-04-10 16:01:11 DigitalInput2_InvertTranslation_value 0
2023-04-10 16:05:21 DigitalInput2_Multiplier_value 0.001
2023-04-10 16:05:31 DigitalInput2_Type_value 0
2023-04-10 16:05:48 DigitalInput3_AlarmSetting_value 0
2023-04-10 16:05:48 DigitalInput3_Count_value 0
2023-04-10 16:01:11 DigitalInput3_CustomName_value
2023-04-10 16:05:21 DigitalInput3_InvertAlarm_value 0
2023-04-10 16:05:44 DigitalInput3_InvertTranslation_value 0
2023-04-10 16:05:37 DigitalInput3_Multiplier_value 0.001
2023-04-10 16:05:18 DigitalInput3_Type_value 0
2023-04-10 16:05:20 DigitalInput4_AlarmSetting_value 0
2023-04-10 16:01:11 DigitalInput4_Count_value 0
2023-04-10 16:01:11 DigitalInput4_CustomName_value
2023-04-10 16:05:40 DigitalInput4_InvertAlarm_value 0
2023-04-10 16:01:11 DigitalInput4_InvertTranslation_value 0
2023-04-10 16:05:33 DigitalInput4_Multiplier_value 0.001
2023-04-10 16:05:41 DigitalInput4_Type_value 0
2023-04-10 16:05:21 Dvcc_value 0
2023-04-09 13:30:16 EffectiveChargeVoltage_value 56.79999923706055
2023-04-10 16:01:00 ExtraBatteryCurrent_value 1
2023-04-10 16:05:27 FischerPanda0_AcLoad_AccumulatedDaily_value
2023-04-10 16:05:21 FischerPanda0_AcLoad_AccumulatedTotal_value 0
2023-04-10 16:05:41 FischerPanda0_AcLoad_Enabled_value 0
2023-04-10 16:01:11 FischerPanda0_AcLoad_Measurement_value 0
2023-04-10 16:01:11 FischerPanda0_AcLoad_QuietHoursStartValue_value 1900
2023-04-10 16:05:48 FischerPanda0_AcLoad_QuietHoursStopValue_value 1200
2023-04-10 16:05:41 FischerPanda0_AcLoad_StartTimer_value 20
2023-04-10 16:05:47 FischerPanda0_AcLoad_StartValue_value 1600
2023-04-10 16:01:12 FischerPanda0_AcLoad_StopTimer_value 20
2023-04-10 16:05:42 FischerPanda0_AcLoad_StopValue_value 800
2023-04-10 16:05:22 FischerPanda0_Alarms_NoGeneratorAtAcIn_value 0
2023-04-10 16:05:38 FischerPanda0_AutoStartEnabled_value 0
2023-04-10 16:05:48 FischerPanda0_BatteryCurrent_Enabled_value 0
2023-04-10 16:01:12 FischerPanda0_BatteryCurrent_QuietHoursStartValue_value 20.5
2023-04-10 16:05:38 FischerPanda0_BatteryCurrent_QuietHoursStopValue_value 15.5
2023-04-10 16:01:12 FischerPanda0_BatteryCurrent_StartTimer_value 20
2023-04-10 16:05:48 FischerPanda0_BatteryCurrent_StartValue_value 10.5
2023-04-10 16:01:12 FischerPanda0_BatteryCurrent_StopTimer_value 20
2023-04-10 16:05:43 FischerPanda0_BatteryCurrent_StopValue_value 5.5
2023-04-10 16:05:19 FischerPanda0_BatteryService_value default
2023-04-10 16:05:15 FischerPanda0_BatteryVoltage_Enabled_value 0
2023-04-10 16:05:38 FischerPanda0_BatteryVoltage_QuietHoursStartValue_value 11.9
2023-04-10 16:01:12 FischerPanda0_BatteryVoltage_QuietHoursStopValue_value 12.4
2023-04-10 16:05:15 FischerPanda0_BatteryVoltage_StartTimer_value 20
2023-04-10 16:01:12 FischerPanda0_BatteryVoltage_StartValue_value 11.5
2023-04-10 16:01:12 FischerPanda0_BatteryVoltage_StopTimer_value 20
2023-04-10 16:01:12 FischerPanda0_BatteryVoltage_StopValue_value 12.4
2023-04-10 16:05:44 FischerPanda0_InverterHighTemp_Enabled_value 0
2023-04-10 16:05:44 FischerPanda0_InverterHighTemp_StartTimer_value 20
2023-04-10 16:01:12 FischerPanda0_InverterHighTemp_StopTimer_value 20
2023-04-10 16:05:38 FischerPanda0_InverterOverload_Enabled_value 0
2023-04-10 16:05:43 FischerPanda0_InverterOverload_StartTimer_value 20
2023-04-10 16:05:28 FischerPanda0_InverterOverload_StopTimer_value 20
2023-04-10 16:01:12 FischerPanda0_MinimumRuntime_value 0
2023-04-10 16:01:12 FischerPanda0_OnLossCommunication_value 0
2023-04-10 16:05:25 FischerPanda0_QuietHours_Enabled_value 0
2023-04-10 16:05:25 FischerPanda0_QuietHours_EndTime_value 21600
2023-04-10 16:05:16 FischerPanda0_QuietHours_StartTime_value 75600
2023-04-10 16:05:34 FischerPanda0_Soc_Enabled_value 0
2023-04-10 16:05:25 FischerPanda0_Soc_QuietHoursStartValue_value 90
2023-04-10 16:05:27 FischerPanda0_Soc_QuietHoursStopValue_value 90
2023-04-10 16:01:12 FischerPanda0_Soc_StartValue_value 80
2023-04-10 16:01:12 FischerPanda0_Soc_StopValue_value 90
2023-04-10 16:01:13 FischerPanda0_TestRun_Duration_value 7200
2023-04-10 16:01:13 FischerPanda0_TestRun_Enabled_value 0
2023-04-10 16:05:23 FischerPanda0_TestRun_Interval_value 28
2023-04-10 16:05:20 FischerPanda0_TestRun_RunTillBatteryFull_value 0
2023-04-10 16:05:40 FischerPanda0_TestRun_SkipRuntime_value 0
2023-04-10 16:05:33 FischerPanda0_TestRun_StartDate_value 1483228800
2023-04-10 16:01:13 FischerPanda0_TestRun_StartTime_value 54000
2023-04-10 16:05:47 FischerPanda0_TestRun_StopWhenAc1Available_value 0
2023-04-10 16:05:42 Fronius_AutoScan_value 1
2023-04-10 16:01:13 Fronius_IPAddresses_value 192.168.1.252
2023-04-10 16:01:13 Fronius_InverterIds_value
2023-04-10 16:05:21 Fronius_KnownIPAddresses_value
2023-04-10 16:05:23 Fronius_PortNumber_value 80
2023-04-10 16:05:36 GPS_Format_value 0
2023-04-10 16:01:14 GPS_SpeedUnit_value km/h
2023-04-10 16:01:13 Generator0AcLoad_AccumulatedDaily_value
2023-04-10 16:05:38 Generator0AcLoad_AccumulatedTotal_value 0
2023-04-10 16:01:13 Generator0AcLoad_Enabled_value 0
2023-04-10 16:05:18 Generator0AcLoad_Measurement_value 0
2023-04-10 16:01:13 Generator0AcLoad_QuietHoursStartValue_value 1900
2023-04-10 16:05:22 Generator0AcLoad_QuietHoursStopValue_value 1200
2023-04-10 16:05:46 Generator0AcLoad_StartTimer_value 20
2023-04-10 16:01:13 Generator0AcLoad_StartValue_value 1600
2023-04-10 16:05:48 Generator0AcLoad_StopTimer_value 20
2023-04-10 16:05:18 Generator0AcLoad_StopValue_value 800
2023-04-10 16:05:20 Generator0Ac_AutoStartEnabled_value 0
2023-04-10 16:05:19 Generator0Alarms_NoGeneratorAtAcIn_value 0
Leider ist der Code scheinbar zu lang und konnte hierüber nur zu 1/10tel eingefügt werden.
Auch die Readingslist hierunter hat schon 998 Zeilen, hier nur ein Auszug:
CerboGxClient:R/c0619ab1e261/keepalive:.* keepalive
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_1/Function:.* { json2nameValue($EVENT, 'builtin0_1_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_1/Label:.* { json2nameValue($EVENT, 'builtin0_1_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_2/Function:.* { json2nameValue($EVENT, 'builtin0_2_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_2/Label:.* { json2nameValue($EVENT, 'builtin0_2_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_3/Function:.* { json2nameValue($EVENT, 'builtin0_3_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_3/Label:.* { json2nameValue($EVENT, 'builtin0_3_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_4/Function:.* { json2nameValue($EVENT, 'builtin0_4_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_4/Label:.* { json2nameValue($EVENT, 'builtin0_4_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_5/Function:.* { json2nameValue($EVENT, 'builtin0_5_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_5/Label:.* { json2nameValue($EVENT, 'builtin0_5_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_6/Function:.* { json2nameValue($EVENT, 'builtin0_6_Function_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_6/Label:.* { json2nameValue($EVENT, 'builtin0_6_Label_', $JSONMAP) }
CerboGxClient:N/c0619ab1e261/adc/0/Devices/adc_builtin0_7/Function:.* { json2nameValue($EVE
Was muss ich ändern, damit ich die Daten bekomme und mein System wieder schneller wird?
Mit freundlichen Grüßen
Du musst die angebotenen Topics eingrenzen auf die, die du wirklich in FHEM haben möchtest. VenusOS liefert standardmäßig weit über 1000 Topics.
Ich habe das bei mir so umgesetzt:
- zuerst im MQTT2_CLIENT autocreate auf "no" setzen
- im MQTT2_DEVICE das ReadingList löschen
- die Topics identifizieren, die einem interessieren und neu als ReadingList definieren
Wie identifiziert man die Topics?
Das geht am einfachsten über die D-Bus-Abfrage mit dem dbus-Befehl im VenusOS:
dbus -y
dbus -y com.victronenergy.system / GetValue
dbus -y com.victronenergy.system /Dc GetValueDann baut man sich das gewünschte Topic für die ReadingList zusammen, z.B.
CerboGxClient:N/c0619ab1e261/system/0/Dc/Battery/Soc:.* {json2nameValue($EVENT, 'SysActiveInL1Current_', $JSONMAP)}Hier (https://github.com/victronenergy/venus/wiki/dbus-api) ist die D-Bus-API dokumentiert. Ist eben etwas Handarbeit, aber FHEM dankt es dir mit besserer Performance.
Viele Grüße
Vielen Dank für Deine Antwort! Jetzt habe ich gelernt, das der CerboGX auch nur ein eigenes Linux ist (wie hätte es anders sein können), und ich darauf zugreifen kann.
Bei mir verursacht u.a. ein at Befehl, dass das System so langsam wird:
+*00:01:00 set CerboGxClient publish R/c061XXXXXXXX/keepalive
Ohne dieses at kommen nach kurzer Zeit vom CerboGX keine Daten mehr.
Diesen habe ich so programmiert, weil mir nicht klar ist wie ich es wo anders lösen kann?
Zum testen habe ich mein at deaktiviert und dann nur 10 Einträge im MQTT2_CerboGxClient hinterlegt, was das FHEM System trotzdem wieder extrem langsam werden lässt.
Kann es noch eine andere Ursache geben (wenn der CerboGxClient deaktiviert ist, läuft alles sehr schnell)?
Mal von den Basics her gedacht: apptime, um auf die Suche zu gehen?
Hier auch ein VenusOS angebunden, vergleichbarer "at-Befehl", um die MQTT Nachrichten vom VenusOS zu empfangen.
Ich empfange "sogar" alle MQTT-werte aus dem Victron-Universum.
Aber keine Trägheit im System, keine Freezes in den Logfiles.
Auf welcher Hardware läuft denn FHEM bei Dir?
Ok meine Frage war schlecht formuliert:
APPTIME, Perfmon (und optional MyFreezmon) weisen eindeutig auf MQTT/CerboGX hin (wie oben formuliert, wenn abgeschaltet ist das System schnell).
An der Hardware kann es eigentlich daher auch nicht liegen:
Date: 16.04.2023 12:03:28
CPU frequency: 1600 MHz
CPU model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
System up time: 6 days, 03 hours, 58 minutes
FHEM up time: 0 days, 00 hours, 09 minutes
Load average: 0.78 4.02 5.32
RAM: Total: 1982.00 MB, Used: 1041.59 MB, 52.55 %, Free: 163.38 MB
swap: Total: 2046.00 MB, Used: 715.91 MB, 34.99 %, Free: 1330.08 MB
Ethernet1: RX: 85511.02 MB, TX: 3656.10 MB, Total: 89167.12 MB
Ethernet2: RX: 85233.29 MB, TX: 3707.89 MB, Total: 88941.18 MB
Filesystem /boot: Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
Root: Total: 231631 MB, Used: 154780 MB, 71 %, Available: 65014 MB at /
Was muss ich Wo / Wie einstellen, damit VenusOS dauerhaft MQTT Daten sendet? Mein AT scheint das System langsamer zu machen.
Hi Sebastian,
also ich verwende seit September letzten Jahres das identische "at"-Kommando in FHEM, um die MQTT-Nachrichten von VenusOS (ook, läuft bei mir auf einem RaspBerry, aber das sollte keinen Unterschied machen?) zu abonnieren. Das sollte es also nicht sein.
+*00:00:15 set victron_mqtt publish R/b8XXXXXXXX/keepalive
Du siehst, sogar alles 15 Sekunden. Laut Victron gibt es keine andere Möglichkeit.
Auch die generelle Anbindung über über die Generic Bridge ist identisch - IP-Adresse + Port.
Und derzeit greife ich in verschiedenen mqtt2_devices jeweils die MQTT-Messages ab, die ich für die jeweiligen Devices benötige - ein weiteres betreibe ich als "Datengrab", um mir dort alle /Pfade/... anzeigen zu lassen.
Netzwerkproblem zum Cerbo kannst Du ausschließen? Vielleicht mal versuchen, die Zeit von einer Minute auf 30 Sekunden zu senken? Beim ersten aktivieren rauschen schließlich alle Messages rein - vielleicht gibt es da eine ungünstige Race-Condition seitens Victron.
Mehr fällt mir adhoc auch nicht ein - sry.
Unfassbar: ich habe das "at"-Kommando wie Du gesagt hast aauf 30 Sekunden gestellt und FHEM ist wieder ganz normal schnell !?!?!?!!!
Ich werde noch ein paar Tage beobachten und dann ggf. berichten.
Besten Dank bis hier!!!
Hi Sebastian,
ist doch super, wenn es geklappt hat. Freut mich.
Dann viel Erfolg mit der weiteren Victron-Integration.
Gruß, Tom
Leider habe ich mich zu früh gefreut:
Wenn der "at"-Befehl eingeschaltet ist, wird das System sehr langsam und das Log-File besteht fast nur noch aus Perfmon Nachrichten.
Zitat2023.04.18 20:37:10 1: Perfmon: possible freeze starting at 20:37:07, delay is 3.19
2023.04.18 20:37:14 1: Perfmon: possible freeze starting at 20:37:11, delay is 3.124
2023.04.18 20:37:17 1: Perfmon: possible freeze starting at 20:37:15, delay is 2.862
2023.04.18 20:37:19 1: Perfmon: possible freeze starting at 20:37:18, delay is 1.636
2023.04.18 20:37:23 1: Perfmon: possible freeze starting at 20:37:20, delay is 3.437
2023.04.18 20:37:27 1: Perfmon: possible freeze starting at 20:37:24, delay is 3.02
2023.04.18 20:37:30 1: Perfmon: possible freeze starting at 20:37:28, delay is 2.219
2023.04.18 20:37:34 1: Perfmon: possible freeze starting at 20:37:31, delay is 3.303
2023.04.18 20:37:38 1: Perfmon: possible freeze starting at 20:37:35, delay is 3.431
2023.04.18 20:37:43 1: Perfmon: possible freeze starting at 20:37:39, delay is 4.044
2023.04.18 20:38:12 1: Perfmon: possible freeze starting at 20:38:09, delay is 3.191
2023.04.18 20:38:16 1: Perfmon: possible freeze starting at 20:38:13, delay is 3.31
2023.04.18 20:38:20 1: Perfmon: possible freeze starting at 20:38:17, delay is 3.704
2023.04.18 20:38:24 1: Perfmon: possible freeze starting at 20:38:21, delay is 3.805
2023.04.18 20:38:29 1: Perfmon: possible freeze starting at 20:38:25, delay is 4.051
2023.04.18 20:38:33 1: Perfmon: possible freeze starting at 20:38:30, delay is 3.568
2023.04.18 20:38:37 1: Perfmon: possible freeze starting at 20:38:34, delay is 3.026
2023.04.18 20:38:39 1: Perfmon: possible freeze starting at 20:38:38, delay is 1.368
Auch das Hochsetzen auf 01:30 im "at"-Befehl bringt leider keine Änderung. Nach dem Deaktivieren wieder alles ganz schnell und Logfile wieder "sauber".
Womoeglich koennte man dem Raetsel naeher kommen, wenn man fuer eine Zeit "attr global verbose 5" setzt, und das FHEM-Log inspiziert.
Weiterhin gab es hier Berichte, wo perfmon selbst Ursache der Verlangsamung war.
Was mich hier wundert (bei freezemon): Die Meldung kommt ja alle 3-4 Sekunden, also deutlich häufiger als der AT-Befehl.
Reagierst Du denn mittels Notify auf eine der Nachrichten, die da einlaufen?
Mir fällt es sehr schwer, MQTT als den Schhuldigen anzusehen. Ich wickel hier einen signifikanten Teil meiner Hausautomation via MQTT ab (>50 shelly, Victron, openWB), da kommt schon einiges zusammen. Aber noch nie war MQTT bei mir der ANlass für Performance-Probleme.
Daher wiederhole ich die Frage nochmal: Kann es am Netzwerk liegen? Wifi oder LAN?
Neben Rudis Rat: Vielleicht kannst Du mal die apptime maxDly-Ausgaben posten, wenn Du damit nochmal analysieren möchtest.
attr global verbose 5
bringt Ergebnisse, die ich nicht mehr einordnen kann. Hier ein Auszug:
2023.04.19 22:16:11 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/ConsumptionOnOutput/L2/Current => { json2nameValue($EVENT, 'SystemAcActiveInConsumptionOnOutputL2_Current_', $JSONMAP) }
2023.04.19 22:16:11 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemAcActiveInConsumptionOnOutputL2_Current_value: 2.200000047683716
2023.04.19 22:16:11 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:11 4: CerboGxClient received PUBLISH
2023.04.19 22:16:11 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/ConsumptionOnInput/L2/Power\000{"value": 30.900000000000006}
2023.04.19 22:16:11 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/ConsumptionOnInput/L2/Power => { json2nameValue($EVENT, 'SystemAcActiveInConsumptionOnInputL2_Power_', $JSONMAP) }
2023.04.19 22:16:11 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemAcActiveInConsumptionOnInputL2_Power_value: 30.900000000000006
2023.04.19 22:16:11 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:11 4: CerboGxClient received PUBLISH
2023.04.19 22:16:11 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/Consumption/L1/Power\000{"value": 116}
2023.04.19 22:16:11 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/Consumption/L1/Power => { json2nameValue($EVENT, 'L1_Power_', $JSONMAP) }
2023.04.19 22:16:11 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is L1_Power_value: 116
2023.04.19 22:16:11 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:11 4: CerboGxClient received PUBLISH
2023.04.19 22:16:11 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/Consumption/L2/Power\000{"value": 160.9}
2023.04.19 22:16:11 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/Consumption/L2/Power => { json2nameValue($EVENT, 'L2_Power_', $JSONMAP) }
2023.04.19 22:16:11 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is L2_Power_value: 160.9
2023.04.19 22:16:11 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:11 4: CerboGxClient received PUBLISH
2023.04.19 22:16:11 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/Consumption/L3/Power\000{"value": 27}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/Consumption/L3/Power => { json2nameValue($EVENT, 'L3_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is L3_Power_value: 27
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/Consumption/L1/Current\000{"value": 1.8290000500679016}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/Consumption/L1/Current => { json2nameValue($EVENT, 'L1_Current_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is L1_Current_value: 1.8290000500679016
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/Consumption/L2/Current\000{"value": 2.200000047683716}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/Consumption/L2/Current => { json2nameValue($EVENT, 'L2_Current_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is L2_Current_value: 2.200000047683716
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Dc/Vebus/Current\000{"value": -7.400000095367432}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Dc/Vebus/Current => { json2nameValue($EVENT, 'SystemDcVebus_Current_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemDcVebus_Current_value: -7.400000095367432
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Dc/Vebus/Power\000{"value": -280}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Dc/Vebus/Power => { json2nameValue($EVENT, 'SystemDcVebus_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemDcVebus_Power_value: -280
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Dc/System/Power\000{"value": -42.64401522254957}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Dc/System/Power => { json2nameValue($EVENT, 'SystemDc_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemDc_Power_value: -42.64401522254957
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/ActiveIn/L1/Power\000{"value": 16.3}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/ActiveIn/L1/Power => { json2nameValue($EVENT, 'SystemAcActiveInL1_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemAcActiveInL1_Power_value: 16.3
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/ActiveIn/L2/Power\000{"value": 69.9}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/ActiveIn/L2/Power => { json2nameValue($EVENT, 'SystemAcActiveInL2_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemAcActiveInL2_Power_value: 69.9
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Ac/ActiveIn/L3/Power\000{"value": -94.30000000000001}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Ac/ActiveIn/L3/Power => { json2nameValue($EVENT, 'SystemAcActiveInL3_Power_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemAcActiveInL3_Power_value: -94.30000000000001
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/grid/31/Ac/Current\000{"value": 0.7170000000000001}
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/grid/31/Ac/L1/Current\000{"value": 0.8190000000000001}
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/grid/31/Ac/L2/Current\000{"value": 0.978}
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/grid/31/Ac/L3/Current\000{"value": -1.08}
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/system/0/Timers/TimeOnGrid\000{"value": 816295}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/system/0/Timers/TimeOnGrid => { json2nameValue($EVENT, 'SystemState_TimeOnGrid_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is SystemState_TimeOnGrid_value: 816295
2023.04.19 22:16:12 5: End notify loop for MQTT2_CerboGxClient
2023.04.19 22:16:12 4: CerboGxClient received PUBLISH
2023.04.19 22:16:12 5: CerboGxClient: dispatch autocreate=no\000CerboGxClient\000N/c0619ab1e261/battery/512/System/MaxCellVoltage\000{"value": 3.3239998817443848}
2023.04.19 22:16:12 4: MQTT2_DEVICE_Parse: MQTT2_CerboGxClient N/c0619ab1e261/battery/512/System/MaxCellVoltage => { json2nameValue($EVENT, '512_MaxCellVoltage_', $JSONMAP) }
2023.04.19 22:16:12 5: Starting notify loop for MQTT2_CerboGxClient, 1 event(s), first is 512_MaxCellVoltage_value: 3.3239998817443848
Es war für mich ein Wunder, dass ich es geschafft hatte, dass das Ding überhaupt irgendwelche Daten ausspuckt, als ich es eingerichtet habe.
Ich bin da wirklich total überfordert (Notify habe ich aber nicht eingerichtet, weil ich es bis heute nicht verstanden habe, wie das gehen würde - brauche ich wahrscheinlich nicht). Warum da ein Notify Loop ist (und was das ist) kann ich nicht erklären.
Das Netzwerk ist ausgeschlossen 1GB Leitung, LAN.
Entschuldigung ich muss erst wieder nachlesen, was das alles bedeutet.
Hallo Sebastian,
falls Du bei Gelegenheit nochmal die Sache mit dem apptime ausprobierst?
Hierzu einfach mal apptime eingeben, dann ein paar Minuten warten, dann apptime maxDly eingeben und den Output hier posten.
Gruß, Tom
Ja Hallo,
ich musste mich aber zuerst wieder in FHEM "einlesen", weil ich vieles wieder vergessen habe.
zunächst: Ich habe herausgefunden woran es liegt, dass mein FHEM so langsam wird:
Wahrscheinlich habe ich zu viele Geräte (für FHEM)? Die MQTT Geräte senden bei mir zunächst zu mosquitto, der auf der gleichen Hardware läuft. Wenn ich diese Daten des mosquitto über eine MQTT-Explorer überprüfe läuft alles schnell und problemlos.
So auch in Fhem wenn ich den MQTT2_CLIENT, der mit dem mosquitto verbunden ist "disconnect"e. In diesem Fall läuft FEHM reibungslos. "Connect"e ich diese Datenabfrage ist FHEM nicht mehr zu bedienen.
Internals:
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.100:1883
DeviceName 192.168.1.100:1883
FUUID 61328b51-f33f-ec85-c679-496d36cf8f8d07a0
FVERSION 00_MQTT2_CLIENT.pm:0.274680/2023-04-20
NAME mosquitto
NR 704
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId mosquitto
eventCount 774
lastMsgTime 1682431589.98807
nextOpenDelay 10
nrConnects 502
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
OLDREADINGS:
READINGS:
2023-04-25 17:05:00 lastPublish tasmota/Praxis/Klimaanlage2/cmnd/IRhvac:{"Vendor":"DAIKIN216","Power":"Off","Mode":"Cool","FanSpeed":3,"Temp":18}
2023-04-25 16:06:30 state disconnected
Attributes:
autocreate no
event-on-change-reading .*
event-on-update-reading .*
room MQTT
subscriptions setByTheProgram
username XXXXXXXXXXX
Ich nutze auch HomeAssistant (HASS) als Zubringer für FHEM (weil ich einige Geräte nicht in FHEM eingebunden bekomme), und sende mir die Daten dieser Geräte von HASS über MQTT zu mosquitto. Ich hatte gehofft, dass FHEM über diesen Umweg flotter läuft und habe daher auch den CerboGX über die HACS in HomeAssistant eingebunden.
Resultat:
Obwohl HASS nur in der Core-Version als VM in meinem debian-server läuft, und umfängliche Daten liefert, laufen HASS und auch der mosquitto weiterhin blitzschnell und problemlos.
Sobald ich die Daten über MQTT->mosquitto->FHEM in einen MQTT2_CLIENT sende, geht FHEM in die Knie und wird genauso "unbedienbar" wie in diesem Thread als Problem beschrieben.
Meine gelplante Notlösunbg:
Weil ich keinen anderen Lösungsweg kenne (und ohne Hilfe nicht in der Lage bin etwas anderes zu testen), habe ich im Moment vor HASS so zu beschränken, dass HASS nur bestimmte, von mir gewünschte, Daten an den mosquitto sendet, die FHEM dann abfragen soll.
Alternativ könnte ich einige Anteile auf ein weiteres FHEM auf ein RPi "auslagern".
apptime ist zur Zeit nicht realistisch, weil mosquitto "disconnect"et war:
apptime maxDly
tmr-FBAHAHTTP_PollWas nicht verwunderlich ist: Ich habe im LAN fünf FritzBoxen über VPN nochmal drei und weitere zwei mit weiteren Repeatern.
apptime max
tmr-__ANON__ 147 18418 594576.43 32.28 0.00 0.00 25.04. 19:30:26 HASH(mosquitto)Was zu erwarten war - hier nur 2-3 Minuten gelaufen (sonst ja zur Zeit abgeschaltet).
dann x-verschiedene Shellys
tmr-Shelly_status
Außerdem ist mir aufgefallen:
Hardware-seitig läuft FHEM (auf meinem debian-bullseye-server) nur auf einem CPU-Kern. Warum das so ist und ob das normal ist, kann ich nicht beantworten. Dieser CPU-Kern ist dann teilweise zu 100% mit FHEM Prozessen ausgelastet, während die anderen CPU-Kerne mit wenigen %en arbeiten. Ich habe da keine Ahnung, vermute aber, dass FHEM eher für RPi programmiert und ausgelegt ist. Auch hier fällt die CPU auf wenige %te, wenn die Verbindung des FHEM-mosquitto-MQTT2_CLIENT ausgeschaltet wird.
So sieht zur Zeit mein Logfile (Auszug) aus:
023.04.25 20:05:02 1: 192.168.1.100:1883 reappeared (mosquitto)
2023.04.25 20:05:02 1: 192.168.1.250:1883 reappeared (CerboGxClient)
2023.04.25 20:05:07 1: Perfmon: possible freeze starting at 20:05:03, delay is 4.959
2023.04.25 20:05:12 1: Perfmon: possible freeze starting at 20:05:08, delay is 4.321
2023.04.25 20:05:19 1: Perfmon: possible freeze starting at 20:05:13, delay is 6.987
2023.04.25 20:05:23 1: Perfmon: possible freeze starting at 20:05:20, delay is 3.347
2023.04.25 20:05:28 1: Perfmon: possible freeze starting at 20:05:24, delay is 4.246
2023.04.25 20:05:33 1: Perfmon: possible freeze starting at 20:05:29, delay is 4.333
2023.04.25 20:05:36 5: FeuerAlarmSIP, listen process 908287 found
2023.04.25 20:05:39 1: Perfmon: possible freeze starting at 20:05:34, delay is 5.928
2023.04.25 20:05:43 1: Perfmon: possible freeze starting at 20:05:40, delay is 3.575
2023.04.25 20:05:50 1: Perfmon: possible freeze starting at 20:05:44, delay is 6.541
2023.04.25 20:05:56 1: Perfmon: possible freeze starting at 20:05:51, delay is 5.978
2023.04.25 20:06:00 1: Perfmon: possible freeze starting at 20:05:57, delay is 3.261
2023.04.25 20:06:07 1: Perfmon: possible freeze starting at 20:06:01, delay is 6.006
2023.04.25 20:06:10 1: 192.168.1.100:1883 disconnected, waiting to reappear (mosquitto)
2023.04.25 20:06:10 1: 192.168.1.250:1883 disconnected, waiting to reappear (CerboGxClient)
2023.04.25 20:06:10 1: Perfmon: possible freeze starting at 20:06:08, delay is 2.417
2023.04.25 20:06:10 1: 192.168.1.100:1883 reappeared (mosquitto)
2023.04.25 20:06:10 1: 192.168.1.250:1883 reappeared (CerboGxClient)
2023.04.25 20:06:14 1: Perfmon: possible freeze starting at 20:06:11, delay is 3.741
2023.04.25 20:06:19 1: Perfmon: possible freeze starting at 20:06:15, delay is 4.907
2023.04.25 20:06:25 1: Perfmon: possible freeze starting at 20:06:20, delay is 5.249
2023.04.25 20:06:30 1: Perfmon: possible freeze starting at 20:06:26, delay is 4.163
2023.04.25 20:06:35 1: Perfmon: possible freeze starting at 20:06:31, delay is 4.036
2023.04.25 20:06:43 1: Perfmon: possible freeze starting at 20:06:36, delay is 7.168
2023.04.25 20:06:43 5: FeuerAlarmSIP, listen process 908287 found
2023.04.25 20:06:50 1: Perfmon: possible freeze starting at 20:06:44, delay is 6.417
2023.04.25 20:06:57 1: Perfmon: possible freeze starting at 20:06:51, delay is 6.046
2023.04.25 20:07:03 1: Perfmon: possible freeze starting at 20:06:58, delay is 5.611
2023.04.25 20:07:10 1: Perfmon: possible freeze starting at 20:07:04, delay is 6.322
2023.04.25 20:07:17 1: Perfmon: possible freeze starting at 20:07:11, delay is 6.165
2023.04.25 20:07:17 1: 192.168.1.100:1883 disconnected, waiting to reappear (mosquitto)
2023.04.25 20:07:17 1: 192.168.1.250:1883 disconnected, waiting to reappear (CerboGxClient)
2023.04.25 20:07:17 1: 192.168.1.250:1883 reappeared (CerboGxClient)
2023.04.25 20:07:17 1: 192.168.1.100:1883 reappeared (mosquitto)
2023.04.25 20:07:23 1: Perfmon: possible freeze starting at 20:07:18, delay is 5.821
2023.04.25 20:07:27 1: Perfmon: possible freeze starting at 20:07:24, delay is 3.559
2023.04.25 20:07:32 4: FeuerAlarmSIP[908287], register new expire : 2023-04-25 20:12:32
2023.04.25 20:07:33 1: Perfmon: possible freeze starting at 20:07:28, delay is 5.136
2023.04.25 20:07:33 5: FeuerAlarmSIP, readingB:state Val:listen_wfp
2023.04.25 20:07:33 5: FeuerAlarmSIP, readingB:listen_alive Val:908287
2023.04.25 20:07:33 5: FeuerAlarmSIP, readingB:expire Val:300
2023.04.25 20:07:40 1: Perfmon: possible freeze starting at 20:07:34, delay is 6.296
2023.04.25 20:07:47 1: Perfmon: possible freeze starting at 20:07:41, delay is 6.243
2023.04.25 20:07:47 5: FeuerAlarmSIP, listen process 908287 found
2023.04.25 20:07:53 1: Perfmon: possible freeze starting at 20:07:48, delay is 5.614
2023.04.25 20:07:59 1: Perfmon: possible freeze starting at 20:07:54, delay is 5.289
2023.04.25 20:08:05 1: Perfmon: possible freeze starting at 20:08:00, delay is 5.571
2023.04.25 20:08:11 1: Perfmon: possible freeze starting at 20:08:06, delay is 5.813
2023.04.25 20:08:18 1: Perfmon: possible freeze starting at 20:08:12, delay is 6.465
2023.04.25 20:08:25 1: Perfmon: possible freeze starting at 20:08:19, delay is 6.466
2023.04.25 20:08:25 1: 192.168.1.250:1883 disconnected, waiting to reappear (CerboGxClient)
2023.04.25 20:08:25 1: 192.168.1.100:1883 disconnected, waiting to reappear (mosquitto)
2023.04.25 20:08:26 1: 192.168.1.100:1883 reappeared (mosquitto)
2023.04.25 20:08:26 1: 192.168.1.250:1883 reappeared (CerboGxClient)
2023.04.25 20:08:32 1: Perfmon: possible freeze starting at 20:08:27, delay is 5.24
2023.04.25 20:08:39 1: Perfmon: possible freeze starting at 20:08:33, delay is 6.773
2023.04.25 20:08:47 1: Perfmon: possible freeze starting at 20:08:40, delay is 7.949
2023.04.25 20:08:51 5: FeuerAlarmSIP, listen process 908287 found
2023.04.25 20:08:51 1: Perfmon: possible freeze starting at 20:08:48, delay is 3.919
2023.04.25 20:08:55 1: Perfmon: possible freeze starting at 20:08:52, delay is 3.469
2023.04.25 20:09:02 1: Perfmon: possible freeze starting at 20:08:56, delay is 6.398
2023.04.25 20:09:08 1: Perfmon: possible freeze starting at 20:09:03, delay is 5.58
2023.04.25 20:09:14 1: Perfmon: possible freeze starting at 20:09:09, delay is 5.67
2023.04.25 20:09:19 1: Perfmon: possible freeze starting at 20:09:15, delay is 4.858
2023.04.25 20:09:23 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/72_FRITZBOX.pm line 2219.
2023.04.25 20:09:23 1: PERL WARNING: Argument "" isn't numeric in division (/) at ./FHEM/72_FRITZBOX.pm line 2220.
2023.04.25 20:09:25 1: Perfmon: possible freeze starting at 20:09:20, delay is 5.106
2023.04.25 20:09:29 1: Perfmon: possible freeze starting at 20:09:26, delay is 3.388
2023.04.25 20:09:34 1: Perfmon: possible freeze starting at 20:09:30, delay is 4.846
2023.04.25 20:09:38 1: 192.168.1.100:1883 disconnected, waiting to reappear (mosquitto)
2023.04.25 20:09:38 1: 192.168.1.250:1883 disconnected, waiting to reappear (CerboGxClient)
2023.04.25 20:09:38 1: Perfmon: possible freeze starting at 20:09:35, delay is 3.329
2023.04.25 20:09:38 1: 192.168.1.100:1883 reappeared (mosquitto)
2023.04.25 20:09:38 1: 192.168.1.250:1883 reappeared (CerboGxClient)
2023.04.25 20:09:43 1: Perfmon: possible freeze starting at 20:09:39, delay is 4.049
2023.04.25 20:09:48 1: Perfmon: possible freeze starting at 20:09:44, delay is 4.582
2023.04.25 20:09:54 1: Perfmon: possible freeze starting at 20:09:49, delay is 5.579
2023.04.25 20:09:58 5: FeuerAlarmSIP, listen process 908287 found
2023.04.25 20:10:01 1: Perfmon: possible freeze starting at 20:09:55, delay is 6.767
2023.04.25 20:10:02 4: FeuerAlarmSIP[908287], register new expire : 2023-04-25 20:15:02
2023.04.25 20:10:05 1: Perfmon: possible freeze starting at 20:10:02, delay is 3.481
2023.04.25 20:10:05 5: FeuerAlarmSIP, readingB:state Val:listen_wfp
2023.04.25 20:10:05 5: FeuerAlarmSIP, readingB:listen_alive Val:908287
2023.04.25 20:10:05 5: FeuerAlarmSIP, readingB:expire Val:300
2023.04.25 20:10:12 1: Perfmon: possible freeze starting at 20:10:06, delay is 6.686
2023.04.25 20:10:20 1: Perfmon: possible freeze starting at 20:10:13, delay is 7.109
2023.04.25 20:10:27 1: Perfmon: possible freeze starting at 20:10:21, delay is 6.378
2023.04.25 20:10:33 1: Perfmon: possible freeze starting at 20:10:28, delay is 5.863
2023.04.25 20:10:40 1: Perfmon: possible freeze starting at 20:10:34, delay is 6.637
2023.04.25 20:10:47 1: Perfmon: possible freeze starting at 20:10:41, delay is 6.79
2023.04.25 20:10:47 1: 192.168.1.100:1883 disconnected, waiting to reappear (mosquitto)
2023.04.25 20:10:47 1: 192.168.1.250:1883 disconnected, waiting to reappear (CerboGxClient)
ZitatWarum da ein Notify Loop ist (und was das ist) kann ich nicht erklären.
Notify ist die interne Bezeichnung fuer den Benachrichtigungsmechanismus.
Das wird verwendet fuer notify, aber auch fuer DOIF, FileLog, DbLog, etc.
Auch jedes Browserfenster will benachrichtigt werden.
ZitatSobald ich die Daten über MQTT->mosquitto->FHEM in einen MQTT2_CLIENT sende, geht FHEM in die Knie und wird genauso "unbedienbar" wie in diesem Thread als Problem beschrieben.
Ich gehe davon aus, dass dieses Problem nicht direkt mit MQTT zu tun hat, sondern indirekt: durch die MQTT Anbindung werden viele Events (== Nachrichten) erzeugt, die wiederum weitere Aktionen (in DOIF/notify/FileLog/etc) ausloesen.
Das Produkt aus Anzahl der Events, FHEM-Instanzen die darauf reagieren, und die Zeit in diesen Instanzen ist zu hoch.
ZitatHardware-seitig läuft FHEM (auf meinem debian-bullseye-server) nur auf einem CPU-Kern.
Das ist normal, es gibt einige wenige Langlaeufer (wie Plots-Erzeugen) die auf mehrere Prozesse ausgelagert werden.
Was nicht normal ist, dass FHEM 100% CPU verwendet.
Neben der "typischen" Ursache "(zu) viele Events" (samt unsauberem Event-Handling) könnte es hier auch sein, dass sich der TE unbeabsichtigt eine Schleife via MQTT gebaut hat.
Falls es sowas ist (und FHEM selbst nicht mehr zur Anzeige zu gebrauchen ist), sollte das auch mit einem externen Tool wie mosquitto_sub feststellbar sein.
Allerdings ist die Zahl der Events in dem List nicht besonders hoch. "Komsich" finde ich aber diese drei Zeilen:
event-on-change-reading .*
event-on-update-reading .*
subscriptions setByTheProgram
Die ersten beiden machen in dieser Kombination m.E. gar keinen Sinn (=> Löschen!), und die letztere klingt danach, als wäre MQTT_GENERIC_BRIDGE im Spiel (was für die Schleifen-Theorie spräche, aber dann passen wieder andere Dinge nicht so recht, wie die Client-Prio).
event-on-change-reading .*
event-on-update-reading .*
subscriptions setByTheProgram
-> habe ich gelöscht, was leider nicht zur Beschleunigung beigetragen hat.
Ich habe dann auch mal sämtliches Logging deaktiviert, auch alle Plots in FHEM gelöscht, ohne dass die CPU unter 98% (eher weiterhin dauernd bei 100%) gefallen wäre. Dann habe ich ALLE MQTT2_DEVICE und die MQTT_GENERIC_BRIDGE deaktiviert. Hierdurch ist die CPU dann nur noch bei im Schnitt 50-60%, schwankt jedoch sehr stark und geht auch immer wieder auf kurz 100%.
Wahrscheinlich hat es wirklich damit zu tun, dass auch noch zu viele interne Abhängigkeiten bei meinem FHEM (Thema Notify Loop) bestehen.
Kann es etwas bringen wenn ich den Arbeitsspeicher vergrößere? Neue CPU wird ja wahrscheinlich wenig bringen, weil nur ein Kern genutzt wird.
Ich bin dabei alle MQTT über HomeAssistant umzuschreiben und FHEM nur das nötigste zur Verfügung zu stellen - ich verstehe nicht warum HomeAssistant so viel mehr Informationen verarbeiten, darstellen und weitergeben kann, obwohl nur als CORE bei mir läuft. Der Umweg über HASS ist leider sehr lästig. Oder gibt es eine bessere Lösung, als die ich zur Zeit nutze direkt in FHEM?
Vielen Dank!
Ich habe einen Rpi neu mit FHEM aufgesetzt. Außer dem CerboGxClient und dem MQTT2_CerboGxClient läuft nur der at-Befehl.
Sobald die Verbindung zum CerbroGX hergestellt ist und FHEM Daten empfängt geht der RPi in die Knie. Von ca 25% CPU Leistung auf 100% Dauerleistung und ist kaum noch zu bedienen.
Ich denke, das schließt den Großteil der für mich behebbaren Überlegungen leider aus.
Vielen Dank an Alle - ich denke das Thema kann damit geschlossen werden.
Kann es sein, dass es ein weiteres System gibt, das mit derselben ClientID arbeitet?
2023.04.25 20:05:02 1: 192.168.1.250:1883 reappeared (CerboGxClient)
Ändere das mal auf dem Pi, im Prinzip kann diese ID beliebig sein, es muss nur anders sein wie alle andere ID's, die auf den mosquitto zugreifen.
Und: Welche Version von mosquitto ist auf dem Hauptserver? Seit 2.0 braucht man eigentlich Zugangsdaten.
Weiter (andere/alte Baustelle): Wenn du auf dem Hauptsystem warst, lief der mosquitto ja auf derselben Maschine. Warum bist du da eigentlich über die externe IP gegangen und nicht über localhost?
Ja etwas stimmt tatsächlich nicht:
1684041366: mosquitto version 2.0.12 starting
1684041366: Using default config.
1684041366: Starting in local only mode. Connections will only be possible from clients running on this machine.
1684041366: Create a configuration file which defines a listener to allow remote access.
1684041366: For more details see https://mosquitto.org/documentation/authentication-methods/
1684041366: Opening ipv4 listen socket on port 1883.
1684041366: Error: Address already in use
1684041366: Opening ipv6 listen socket on port 1883.
1684041366: Error: Address already in use
Auch die Änderung in FHEM auf 127.0.0.1 hat da nicht geholfen (ich hatte es zum testen umgestellt, und dann vergessen wieder auf localhost zu setzen).
Wenn ich die Client-Verbindung zu mosquitto deaktiviere, wird das System plötzlich auf deutlich flotter.
Unter der Bezeichnung CerboGxClient wird mit list folgendes angezeigt:
Internals:
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.250:1883
DeviceName 192.168.1.250:1883
FUUID 6457e000-f33f-af37-d2a3-9a2a3f3b8c77ea9c
FVERSION 00_MQTT2_CLIENT.pm:0.274680/2023-04-20
NAME CerboGxClient
NR 769
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId CerboGxClient
eventCount 68
lastMsgTime 1684040715.13978
nextOpenDelay 10
nrConnects 6
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-05-14 07:22:49 lastPublish R/c0619ab1e261/keepalive:
2023-05-14 07:05:15 state disconnected
helper:
bm:
MQTT2_CLIENT_Attr:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 07:04:16
max 4.41074371337891e-05
tot 7.20024108886719e-05
mAr:
set
CerboGxClient
Internals:
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.250:1883
DeviceName 192.168.1.250:1883
FUUID 6457e000-f33f-af37-d2a3-9a2a3f3b8c77ea9c
FVERSION 00_MQTT2_CLIENT.pm:0.274680/2023-04-20
NAME CerboGxClient
NR 769
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId CerboGxClient
eventCount 68
lastMsgTime 1684040715.13978
nextOpenDelay 10
nrConnects 6
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-05-14 07:22:49 lastPublish R/c0619ab1e261/keepalive:
2023-05-14 07:05:15 state disconnected
helper:
bm:
MQTT2_CLIENT_Attr:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 07:04:16
max 4.41074371337891e-05
tot 7.20024108886719e-05
mAr:
set
CerboGxClient
event-on-change-reading
.*
MQTT2_CLIENT_Read:
cnt 168
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:58:12
max 0.104403972625732
tot 3.25332355499268
mAr:
HASH(0x56550bbc4c00)
MQTT2_CLIENT_Set:
cnt 192
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:58:27
max 0.0814881324768066
tot 0.441740989685059
mAr:
HASH(0x56550bbc4c00)
CerboGxClient
disconnect
MQTT2_CLIENT_connect:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:55:35
max 0.000626087188720703
tot 0.00127315521240234
mAr:
HASH(CerboGxClient)
Attributes:
event-on-change-reading .*
event-on-update-reading .*
room MQTT
.*
MQTT2_CLIENT_Read:
cnt 168
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:58:12
max 0.104403972625732
tot 3.25332355499268
mAr:
HASH(0x56550bbc4c00)
MQTT2_CLIENT_Set:
cnt 192
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:58:27
max 0.0814881324768066
tot 0.441740989685059
mAr:
HASH(0x56550bbc4c00)
CerboGxClient
disconnect
MQTT2_CLIENT_connect:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 14.05. 06:55:35
max 0.000626087188720703
tot 0.00127315521240234
mAr:
HASH(CerboGxClient)
Attributes:
event-on-change-reading .*
event-on-update-reading .*
room MQTT
Ich habe die event Attribute wieder reingenommen, weil ich meine festgestellt zu haben, dass die Performance ein klein wenig besser wurde. Komisch ist, dass ich die MQTT_GENERIC_BRIDGE meines Wissens gar nicht aktiv installiert habe - wahrscheinlich automatisch an Board?
Fhem verliert ständig die Verbindung zu mosquitto und baut diese wieder auf. Das kostet wahrscheinlich sehr viel Performance. Ich hatte mal auf verbose 5 über nach gestellt und parktisch nur noch Einträge dieserseits bekommen:
023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)1homeassistant/sensor/ecosys_p6130cdn/state_reasonnull
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/state_reason\000null
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)0homeassistant/sensor/ecosys_p6130cdn/command_set"PCLXL,PostScript Emulation,PCL5C,PJL"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/command_set\000"PCLXL,PostScript Emulation,PCL5C,PJL"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)2homeassistant/sensor/ecosys_p6130cdn/uri_supported["ipps://192.168.1.50:443/ipp/print", "ipp://192.168.1.50:631/ipp/print"]
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/uri_supported\000["ipps://192.168.1.50:443/ipp/print", "ipp://192.168.1.50:631/ipp/print"]
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0)2homeassistant/sensor/ecosys_p6130cdn/friendly_name"ECOSYS P6130cdn"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/friendly_name\000"ECOSYS P6130cdn"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0))homeassistant/sensor/ecosys_p6130cdn/icon"mdi:printer"
2023.05.14 00:00:00 5: mosquitto: dispatch autocreate=no\000mosquitto\000homeassistant/sensor/ecosys_p6130cdn/icon\000"mdi:printer"
2023.05.14 00:00:00 4: mosquitto received PUBLISH
2023.05.14 00:00:00 5: mosquitto: received PUBLISH (0);homeassistant/sensor/ecosys_p6130cdn_magenta_tk_5140m/state87
((Darüber hinaus bin in noch (bisher vergeblich) dabei in Homassistant nur das nötigste an mosquitto zu senden, um dort auch die Last für FHEM zu senken.))
Ernsthaft - dein Beitrag liest sich wie ein "Honigtopf"... Da ist gefühlt einfach alles schräg, was schräg sein kann, und man hat auch das Gefühl, dass du selbst überhaupt keine Mühe darauf verwendest, zu recherchieren, was im Einzelnen hinter Problemen aus dem Log und Empfehlungen steckt!
Vor dem Hintergrund ein letzter Versuch:
a) Es läuft auf dieser Maschine offenkunding noch was auf Port 1883! Das KANN so nicht klappen mit Mosquitto...
Vermutlich bekommst du raus, was das ist, wenn du "list mosquitto" über das FHEM-Kommandofeld ausführst - das sieht mir nach einer MQTT2_SERVER-Instanz mit diesem Namen aus, oder du versuchst irgendwie krampfhaft, eine zweite mosquitto-Instanz aufzumachen?... Oder du hast zwischenzeitlich die ClientID von deiner MQTT2_CLIENT-Instanz geändert, aber ein "veraltetes" log gezeigt - alles diffus, vermutlich, weil du zu viel auf einmal änderst und dabei den Überblick verlierst? (Die IP ist nämlich auch wieder eine externe, was vermutlich nicht so zu sein braucht).
b) Die "event"-Attribute KÖNNEN in dieser Zusammenstellung NIE zu einer Verbesserung führen! Ganz egal, was du "fühlst", es ist unlogisch. Es werden dadurch nämlich einfach MEHR Prüfungen OHNE Änderung des Endergebnisses...
c) Dass ausgerechnet die "homeassistant"-Zweige dispatcht werden, zeigt mir, dass du das Wiki zu MQTT2_CLIENT/ignoreRegexp nicht gelesen hast.
Kurzfassung:
Finde raus, was das für ein anderer MQTT-Server ist, der schon gestartet ist. Mehr wie einen MQTT-Server brauchst du vermutlich nicht, und wenn, muss der (und alle seine Clients!) einen anderen Port nutzen!
Lösche den event-Attribut-Unfug!
PS: Für einen schnellen Überblick über das, was in FHEM im MQTT-Bereich vorhanden ist, gibts du ins Kommandofeld ein:
list TYPE=MQTT.*Evtl. etwas weniger Geräte, aber mehr Infos gibt es mit
list TYPE=MQTT.* DEF
Hallo zusammen,
in einem benachbarten Thread (https://forum.fhem.de/index.php?topic=129688.0) kam das Thema mit der massiven Datenflut aus dem Cerbo/Venus auch schon mal auf. Ganz wichtig ist, dass man seine Subscriptions auf das nötigste eingrenzt, weil sonst der Venus jedesmal seinen kompletten DBus Speicher auf MQTT einkippt, teilweise im Sekundentakt!
Beispiel, hier verbindet sich FHEM direkt als Client an den Cerbo und abonniert nur wenige Datenpunkte:
define CerboClient MQTT2_CLIENT 10.102.1.201:8883
attr CerboClient SSL 1
attr CerboClient clientId FHEMServer
attr CerboClient keepaliveTimeout 10
attr CerboClient room Technik->PV
attr CerboClient subscriptions N/vrm-id/battery/+/Dc/# N/vrm-id/battery/512/Info/# N/vrm-id/battery/512/Soc N/vrm-id/solarcharger/# N/vrm-id/dcsystem/278/History/EnergyIn N/vrm-id/dcsystem/278/Dc/#
im oben verlinkten Thread habe ich auch schon weitere Informationen zu Keepalive und zum zerlegen der Datenblöcke geschrieben.
MfG
Zitat von: Beta-User am 14 Mai 2023, 08:11:13keine Mühe darauf verwendest
naja - 4-5 h jeden Abend, ob das nicht genug ist kann ich nicht beurteilen. Ich habe leider wirklich keine Ahnung und bin immer noch Anfänger.
Zitat von: Beta-User am 14 Mai 2023, 08:11:13Es läuft auf dieser Maschine offenkunding noch was auf Port 1883
Fast korrekt. Weil ich es selber nicht geschafft habe die Lösung zu finden, habe ich einen Experten und Programmierer `engagiert` sich mein Problem anzuschauen.
Ursache ist die Art und Weise wie FHEM mit der clientId (in diesem Fall mosquitto) umgeht. Es gibt in meinem Netzwerk noch ein weiteres FHEM (192.168.1.20) und über VPN weitere FHEM, welche sich auch am mosquitto Server (192.168.1.100) angemeldet haben. Dies hat dazu geführt, dass mosquitto wegen der identischen clientId nicht unterscheiden konnte, dass es sich um ein anderes System handelt (obwohl jeweils eine andere IP, was aber nicht von mosquitto überprüft wird).
Nachdem die clientId im lokalen FHEM geändert wurde (von mosquitto in mosquitto22) war der "disconnect/reconnect" Fehler schlagartig beseitigt und die CPU läuft nur noch auf 20-50%.
Zitat von: Beta-User am 14 Mai 2023, 08:11:13"event"-Attribute KÖNNEN in dieser Zusammenstellung NIE zu einer Verbesserung führen
Habe ich gelöscht. Meine Vermutung war, dass weniger Logging zu weniger CPU Last bzw. Auslastung der SSD führt, was richtiger Weise sich nicht bestätigt hat.
Zitat von: Beta-User am 14 Mai 2023, 08:11:13dass du das Wiki zu MQTT2_CLIENT/ignoreRegexp nicht gelesen hast
Ich habe den Wiki Text mehrfach gelesen und mehrfach nicht verstanden. Jetzt wurde mir der Text an Beispielen erklärt.
Hiermit möchte ich mich herzlich für die Große Mühe und Unterstützung hier im Forum bedanken! Ich werde das System noch ein paar Tage beobachten und dann als "gelöst" einstellen.
Nochmals VIELEN HERZLICHEN DANK!!!
ZitatUrsache ist die Art und Weise wie FHEM mit der clientId (in diesem Fall mosquitto) umgeht. Es gibt in meinem Netzwerk noch ein weiteres FHEM (192.168.1.20) und über VPN weitere FHEM, welche sich auch am mosquitto Server (192.168.1.100) angemeldet haben.
Anders formuliert, die Ursache ist nicht, dass man FHEM mit dem CerboGX mosquitto Server verbunden hat, sondern dass man das mehrfach, mit jeweils identischen MQTT2_CLIENT Definitionen gemacht hat.
Die Loesung war unterschiedliche ClientIDs zu verwenden, entweder durch unterschiedliche MQTT2_CLIENT Namen, oder unterschiedliche clientID Attribute.
Letztlich gelöst wurde das Problem durch die Ermittlung dieser einen Ursache (s. Zusammenfassung von rudolfkoenig im Beitrag über diesem) leider nicht. FHEM war weiterhin noch immer extrem langsam und kaum bedienbar, die CPU ständig bei 75% und oft bei 100%, (jedoch nicht mehr dauerhaft bei 100%).
"Gelöst" habe ich das Problem mit einem weiteren FHEM auf einem RPi, der flott und problemlos alle Daten vom CerboGX empfängt. Auf diesem RPi läuft nur der CerboClient, das AT und die Verbindung zum mosquitto. Zusätzlich habe ich FHEM2FHEM installiert, wodurch die vom RPi generierten Daten an den debian-server mit der Hauptinstanz von FHEM weitergeleitet werden. Die CPU Auslastung dieses Hauptservers liegt jetzt wieder im Bereich 3-25%.
hallo.
hat schon jemand mqtt mit klartext verwendet? gibts in den settings.
freund will fhem jetzt für steuerung seines cerbo einsetzen .