[gelöst] Victron Energy CerboGX

Begonnen von SebastianStorb, 10 April 2023, 16:15:40

Vorheriges Thema - Nächstes Thema

SebastianStorb

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

Romoker

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 GetValue

Dann 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 ist die D-Bus-API dokumentiert. Ist eben etwas Handarbeit, aber FHEM dankt es dir mit besserer Performance.

Viele Grüße

BeagleBoneBlack & Raspberry Pi 4; FB7490; div. Homematic Komponenten; CUL433: CUL_TX, Conbee II, SOMFY, 1-Wire, Z-Wave, Zigbee, SmartPlugs von Sonoff und Shelly mit MQTT

SebastianStorb

#2
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)?

sledge

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?
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

SebastianStorb

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.

sledge

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.


FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

SebastianStorb

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!!!

sledge

Hi Sebastian,

ist doch super, wenn es geklappt hat. Freut mich.

Dann viel Erfolg mit der weiteren Victron-Integration.

Gruß, Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

SebastianStorb

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".

rudolfkoenig

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.

sledge

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.



FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

SebastianStorb

#11
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.

sledge

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
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

SebastianStorb

#13
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_Poll
Was 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)

rudolfkoenig

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.