Wemos D1 mini über ESPEasy: fhem mit 100% Auslastung

[gestein]

Hallo,

Ich bin gerade dabei einen Wassermengenzähler mittels eines Wemos D1 mini über ESPEasy in fhem einzubinden.
Sobald ich aber die espbridge "enable", wird fhem über Web extrem träge und "top" zeigt 100% CPU-Auslastung.

Wenn ich die espbridge "disable", wird fhem wieder flott wie immer und "top" zeigt 10-20% CPU-Auslastung.

Kennt das jemand?
Wo könnte ich ansetzen?

Danke im Voraus
lg, Gerhard

[gestein]

Ich bin jetzt von ESP easy auf MQTT umgestiegen.

Zumindest ist die CPU-Last wieder runter auf 20-60%.

lg, Gerhard

[Wernieman]

Fehlende Informationen: z.B. Was für ein System auf welchem Betriebsystem? List von der Bridge?

Ansonsten kann ich das Verhalten so nicht bestätigen ...

[gestein]

Hallo,

Pfuh, da dürfte sich dann bei meinen vielen Devices etwas beißen.
Ich habe einen raspberry 4 und

Code Auswählen Erweitern

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
hier noch ein List von der ESP Brdige:

Code Auswählen Erweitern

Internals:
   DEF        bridge 8383
   FUUID      5d8674fb-f33f-0b7a-0ff5-4102899a72231103
   FVERSION   34_ESPEasy.pm:0.186080/2019-02-16
   HOST       bridge
   IPV        4
   MAX_HTTP_SESSIONS 3
   MAX_QUEUE_SIZE 250
   NAME       espBridge
   NOTIFYDEV  global
   NR         2864
   NTFY_ORDER 50-espBridge
   PORT       8383
   STATE      disabled
   SUBTYPE    bridge
   TYPE       ESPEasy
   VERSION    2.18
   eventCount 2
   stacktrace  TcpServer_Close:2376 ESPEasy_TcpServer_Close:1219 ESPEasy_Notify:3980 CallFn:3892 DoTrigger:3224 CommandAttr:1278 AnalyzeCommand:1129 AnalyzeCommandChain:2851 FW_fC:980 FW_answerCall:609 FW_Read:3980 CallFn:784
   READINGS:
     2023-04-29 16:17:35   state           disabled
   helper:
     bm:
       ESPEasy_Notify:
         cnt        12
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        29.04. 16:20:57
         max        0.000291109085083008
         tot        0.00208091735839844
         mAr:
           HASH(0x7856c28)
           HASH(0x17443c0)
     pm:
       Encode     1
       JSON       1
Attributes:
   allowedIPs 192.168.0.1/24
   authentication 0
   autocreate 1
   combineDevices 0
   disable    1
   group      Empfänger
   room       0_Testing,Bewässerung,Terrasse_West,Z_System->ESPEasy,Zentrale
Bei mir reicht es die Bridge zu "enablen", dann steigt die Last nach kurzer Zeit schon auf 90-100%.
Vielleicht habe ich auch auf dem Wimos was falsch eingestellt?

lg, Gerhard

[Wernieman]

Sieht zwar Grundsätzlich gut aus, aber in Kleingkeiten ...

Warum hast Du das Du eigentlich das Internal stacktrace?

Mal zum Vergleich meine Komplettes List (Habe nur zusätzlich Passwort drin):

Code Auswählen Erweitern

Internals:
   .AttrList  allowedIPs authentication:1,0 autocreate:1,0 autosave:1,0 combineDevices deniedIPs disable:1,0 disabledForIntervals do_not_notify:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading httpReqTimeout maxHttpSessions:0,1,2,3,4,5,6,7,8,9 maxQueueSize:10,25,50,100,250,500,1000,2500,5000,10000,25000,50000,100000 resendFailedCmd
   .bap       Aife0rier5
   .bau       
   CONNECTS   2275
   DEF        bridge 8086
   FD         5
   FUUID      60354c42-f33f-a76c-3988-0a5d9610d41985ea
   HOST       bridge
   IPV        4
   MAX_HTTP_SESSIONS 3
   MAX_QUEUE_SIZE 250
   NAME       ESPEasy
   NOTIFYDEV  global
   NR         115
   NTFY_ORDER 50-ESPEasy
   PORT       8086
   STATE      Initialized
   SUBTYPE    bridge
   TYPE       ESPEasy
   VERSION    2.18
   WARNING_192.168.3.52 read from http://192.168.3.52:80 timed out
   eventCount 1
   .attraggr:
   .attrminint:
   .clientArray:
     ESPEasy
   READINGS:
     2023-04-27 17:12:37   state           Initialized
   helper:
     maxCmdDuration:
       192.168.3.52 1
     pm:
       Encode     1
       JSON       1
     sessions:
       192.168.3.52 0
Attributes:
   allowedIPs 192.168.3.0/24
   authentication 1
   autocreate 1
   combineDevices 1
   group      ESPEasy Bridge
   httpReqTimeout 3
   room       ESPEasy,IO
   verbose    0


[rob]

Auch bei mir arbeitet die Bridge unauffällig. FHEM bekommt man auf 100%, wenn z.B. ein Sensor permanent/ alle Sekunde Daten schickt und so FHEM ununterbrochen zur Verarbeitung zwingt.

Vielleicht habe ich auch auf dem Wimos was falsch eingestellt?

Könnte eine Erklärung sein. Per MQTT hast Du wahrscheinlich was anders eingestellt, sodass es damit klappt.

Lass mal bitte die Bridge noch disabled und teste bitte auf dem Raspi in der cli dieses:

Code Auswählen Erweitern

nc -l 8383Netcat lauscht so anstelle der Bridge, was Deine Sensoren so treiben. Eigenlich sollte es hier gemächlich zugehen, tröpfelnd mal Daten angezeigt werden.
Sollte aber hier richtig Disco und Alarm sein und quasi ununterbrochen Zeugs reinballern, müsstest Du schauen, welche Node und welche Daten genau zu erkennen sind - Du siehst die Rohdaten d. EspEasy-Nodes.

Stimmt meine Annahme, müsstes Du nur im Wemos schauen, was Du als Sendeinterval verwendet hast und/ oder welcher Sensor genau anzupassen ist.

Trifft meine Vermutung nicht zu und es tröpfelt auch dort nur, dann muss wohl FHEM-seitig das Problem gesucht werden.

VG
rob