go-e Charger Wallbox über MQTT (neuer Versuch (2025)

[Sany]

Hallo go-e Charger User,

nachdem die Anbindung der Box per HTTPMOD an fhem echt gut läuft habe ich mich trotzdem dran gemacht, einen Weg zu finden, die MQTT-Schnittstelle zu nutzen. Warum MQTT? Ich bevorzuge Events statt Abfragen.
Zuerst möchte ich mich aber generell hier beim Forum bedanken für all die hilfreichen Inputs, die mir auch hier gut geholfen haben.

Ganz am Anfang hat die Box, soweit ich mich erinnere, im Prinzip ALLES an Daten sekündlich rausgehauen und war so für fhem eigentlich nicht nutzbar. Seit einiger Zeit scheinen aber wohl hauptsächlich Änderungen gesendet zu werden. Das sind zwar schon einige Daten weniger, aber immer noch recht viel. Man sieht es, wenn man am Charger MQTT freigibt (nachdem es konfiguriert wurde) und dann z.B. MQTT-Explorer laufenläßt.
eocr (event-on-change-reading) ist zwar eine große Hilfe, ändert aber nichts daran, dass viele Readings angelegt werden und bei Änderung dann auch Events Richtung fhem durchgelassen werden.
MQTT2_SERVER hat aber noch eine nette Einstellung: das Attribut
ignoreRegexp
if $topic:$message matches ignoreRegexp, then it will be silently ignored

Die Erkärung sagt es bereits: die Daten kommen zwar übers (MQTT-)Netz, werden aber am Eingang zum MQTT2_SERVER ignoriert. Hier kann man nun nach Herzenslust die topics eintragen, die man nicht möchte.
Ich habe mich drangesetzt und einen vergleichbaren Umfang vom HTTPMOD realisiert, es werden also nur die Daten durchgelassen, die die HTTPMOD-Version auch kennt. OK, abzüglich der LED Daten. (mein Prinzip dahinter: alle Daten zum Laden des Autos sind relevant, firmware habe ich trotzdem mal dringelassen. Die Readings sind so wie im HTTPMOD, also die Readingbezeichnungen und der größte Teil der set.. Möglichkeiten.
Weil die Sonne gerade hartnäckig NICHT scheint habe ich nur ein wenig mit manuellem Laden umd Umschalten der Möglichkeiten getestet, das lief bisher problemlos.
Zur Belastung von fhem: Ich habe das auf einem Raspi4 Testsystem eingerichtet, htop gibt ohne go-e via MQTT 0..8% cpu-Last aus, wenn ich MQTT im go-e enable bewegt sich das bei 1..9%. Das scheint also nicht allzuviel Kraft zu kosten, die Daten an der "Pforte" zum Server aufzuhalten....

Das schöne ist, man kann ja beides nutzen (MQTT und HTTPMOD). Eben auch um diese Möglichkeit einfach mal auszutesten, oder für eine Ladeautomatik per MQTT und ein Konfigurieren z.B. der LEDs per HTTPMOD.

Vorgehensweise: damit man nicht hunderte Readings wieder löschen muss empfehle ich folgenden Weg: (Voraussetzung: man hat einen MQTT2_SERVER in fhem am laufen und kennt die Zugangsdaten!!)
Ich habe aktuell die App-Version 4.7.1 (Android) sowie Firmware 58.1 Beta auf einem go-E Charger homefix 11kW HardwareVersion v3.

go-e App:
unter Einstellungen->Verbindung->MQTT schaltet man MQTT aus und gibt die Daten ein:

URL:    mqtt://ip.vom.fhem|mqtt.server:1883
Prefix: zb go-eCharger/    (dieser Prefix Eintrag ist später noch wichtig!)
MQTT readonly aus (sonst kann man nicht an den go-e senden)
MQTT homeassistant aus, alles danach auf deaktiviert



MQTT2_SERVER:

das Attribut ignoreRegexp befüllen mit

go-eCharger/(amt|ara|att|att|avgfhz|awcp|awcp|awc|awe|awp|bac|bac|cards|cbl|ccd|cch|ccw|cdi|cfi|cid|cll|clp|csa|ctrls|cwc|deltap|di1|die|dii|din|dll|dns|dsrc|evt|fhz|fmt|frm|fzf|gw|hai|hla|la1|la3|lbl|lbp|lbr|lcs|lmsc|loa|loc|lrc|lri|lrr|lto|lwf|mca|mcr|men|mpswt|mptwt|msb|msp|msr|nmo|ocu|oem|pco|pdi|pgr|psmd|rbc|rbt|rde|sh|sumd|tab|tcl|tpa|tsi|typ|ufa|ufe|ufm|ufs|ust|utc|var|wb|wg|whb|whg|who|whs|wo|ws|zfo)

oder falls schon was drinsteht dann am Ende ein | und danach das für den go-e eintragen.
autocreate muss OFF sein!!
das o.a. "go-eCharger/" ist das Prefix aus der App

fhem:

das Device per RAW-Imoprt anlegen, wer einen anderen Namen möchte entweder im RAW vorher abändern oder per rename wenn es angelegt ist.
ins Attribut devicetopic kommt das gleiche, wie in der App bei Prefix, ohne den Backslash.


Am Besten auch hier den MQTT-Explorer o.ä. mitlaufen lassen mit Filter auf go-e, um das Prefix zu checken und auch um zu sehen, was vom go-e kommt.

Code Auswählen Erweitern

defmod go_echarger MQTT2_DEVICE go_echarger
attr go_echarger DbLogExclude P_(L1|L2|L3|N).*,U_.*,I_.*
attr go_echarger autocreate 0
attr go_echarger devicetopic go-eCharger
attr go_echarger event-min-interval car:900,energy:21600
attr go_echarger event-on-change-reading temperature_.*:1,U_.*:5,rssi:10,.*
attr go_echarger icon electric_car_charger
attr go_echarger jsonMap nrg_1:U_L1 nrg_2:U_L2 nrg_3:U_L3 nrg_4:U_N nrg_5:I_L1 nrg_6:I_L2 nrg_7:I_L3 nrg_8:P_L1 nrg_9:P_L2 nrg_10:P_L3 nrg_11:P_N nrg_12:power nrg_13:pf_L1 nrg_14:pf_L2 nrg_15:pf_L3 nrg_16:pf_N tma_1:temperature_box tma_2:temperature_cable psm_0:auto psm_1:force_1 psm_2:force_3
attr go_echarger readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/acs:.* {my %acs = ( '0' => 'open', '1' => 'authentication');;;; return { 'charge_auth' => $acs{$EVENT}}}\
$DEVICETOPIC/acu:.* current_allowed\
$DEVICETOPIC/alw:.* {my %alw = ( '0' => 'no', '1' => 'yes');;;; return { 'charge_allowed' => $alw{$EVENT}}}\
$DEVICETOPIC/ama:.* current_limit\
$DEVICETOPIC/amp:.* current_requested\
$DEVICETOPIC/ate:.* nexttrip_energy\
$DEVICETOPIC/car:.* car_num\
$DEVICETOPIC/car:.* {my %car=( '0' => 'unknown', '1' => 'idle', '2' => 'charging', '3' => 'wait', '4' => 'finished', '5' => 'error');;;; return { 'car' =>$car{$EVENT}}}\
$DEVICETOPIC/cus:.* lock_num\
$DEVICETOPIC/cus:.* {my %cus=( '0' => 'unknown', '1' => 'unlocked', '2' => 'unlock_failed', '3' => 'locked', '4' => 'lock_failed', '5' => 'unlock_powerout');;;; return { 'lock' =>$cus{$EVENT}}}\
$DEVICETOPIC/dwo:.* energy_stop\
$DEVICETOPIC/err:.* error_num\
$DEVICETOPIC/err:.* {my %err = ('0' => 'none',  '1' => 'FiAc',  '2' => 'FiDc',  '3' => 'Phase', '4' => 'OverVolt', '5' => 'OverAmp', '6' => 'Diode', '7' => 'PpInvalid', '8' => 'GndInvalid', '9' => 'ContactorStuck', '10' => 'ContactorMiss', '11' => 'FiUnknown', '12' => 'Unknown', '13' => 'OverTemp', '14' => 'NoComm', '15' => 'LockStuckOpen', '16' => 'LockStuckLocked');;;; return { 'error' => $err{$EVENT}}}\
$DEVICETOPIC/eto:.* energy\
$DEVICETOPIC/frc:.* {my %frc = ( '0' => 'neutral', '1' => 'off', '2' => 'on');;;; return { 'forceState' => $frc{$EVENT}}}\
$DEVICETOPIC/fst:.* starting_power\
$DEVICETOPIC/fup:.* usePvSurplus\
$DEVICETOPIC/fwv:.* goe_firmware\
$DEVICETOPIC/lmo:.* {my %lmo = ( '3' => 'default', '4' => 'eco', '5' => 'nexttrip');;;; return { 'charge_mode' => $lmo{$EVENT}}}\
$DEVICETOPIC/modelStatus:.* charge_num\
$DEVICETOPIC/modelStatus:.* {my %modstat = ( '0' => 'NotChargingBecauseNoChargeCtrlData', '1' => 'NotChargingBecauseOvertemperature', '2' => 'NotChargingBecauseAccessControlWait', '3' => 'ChargingBecauseForceStateOn', '4' => 'NotChargingBecauseForceStateOff', '5' => 'NotChargingBecauseScheduler', '6' => 'NotChargingBecauseEnergyLimit', '7' => 'ChargingBecauseAwattarPriceLow', '8' => 'ChargingBecauseAutomaticStopTestLadung', '9' => 'ChargingBecauseAutomaticStopNotEnoughTime', '10' => 'ChargingBecauseAutomaticStop', '11' => 'ChargingBecauseAutomaticStopNoClock', '12' => 'ChargingBecausePvSurplus', '13' => 'ChargingBecauseFallbackGoEDefault', '14' => 'ChargingBecauseFallbackGoEScheduler', '15' => 'ChargingBecauseFallbackDefault', '16' => 'NotChargingBecauseFallbackGoEAwattar', '17' => 'NotChargingBecauseFallbackAwattar', '18' => 'NotChargingBecauseFallbackAutomaticStop', '19' => 'ChargingBecauseCarCompatibilityKeepAlive', '20' => 'ChargingBecauseChargePauseNotAllowed', '22' => 'NotChargingBecauseSimulateUnplugging', '23' => 'NotChargingBecausePhaseSwitch', '24' => 'NotChargingBecauseMinPauseDuration', '26' => 'NotChargingBecauseError', '27' => 'NotChargingBecauseLoadManagementDoesntWant', '28' => 'NotChargingBecauseOcppDoesntWant', '29' => 'NotChargingBecauseReconnectDelay', '30' => 'NotChargingBecauseAdapterBlocking', '31' => 'NotChargingBecauseUnderfrequencyControl', '32' => 'NotChargingBecauseUnbalancedLoad', '33' => 'ChargingBecauseDischargingPvBattery', '34' => 'NotChargingBecauseGridMonitoring', '35' => 'NotChargingBecauseOcppFallback' );;;; return { 'charge' =>  $modstat{$EVENT}}}\
$DEVICETOPIC/nrg:.* { json2nameValue($EVENT,'nrg_',$JSONMAP) }\
$DEVICETOPIC/pakku:.* pAkku\
$DEVICETOPIC/pgrid:.* pGrid\
$DEVICETOPIC/pgt:.* pGridTarget\
$DEVICETOPIC/pha:.* { json2nameValue($EVENT,'pha_',$JSONMAP) }\
$DEVICETOPIC/pnp:.* phases\
$DEVICETOPIC/po:.* prioOffset\
$DEVICETOPIC/ppv:.* pPv\
$DEVICETOPIC/psh:.* phaseSwitchHysteresis\
$DEVICETOPIC/psm:.* {my %psm=( '0' => 'auto', '1' => 'force_1', '2' => 'force_3');;;; return { 'phase_switchmode' =>$psm{$EVENT}}}\
$DEVICETOPIC/rssi:.* rssi\
$DEVICETOPIC/spl3:.* pThreePhaseSwitchLevel\
$DEVICETOPIC/tma:.* { json2nameValue($EVENT,'tma_',$JSONMAP) }\
$DEVICETOPIC/trx:.* transaction\
$DEVICETOPIC/wh:.* energy_connect\

attr go_echarger room MQTT2_DEVICE
attr go_echarger setList current_requested:slider,6,1,16 $DEVICETOPIC/amp/set $EVTPART1\
charge_allowed:on,off { my %hash = ( 'on' => '1', 'off' => 'null');;qq($DEVICETOPIC/trx/set $hash{$EVTPART1}) }\
charge_mode:default,eco,nexttrip { my %hash = ( 'default' => '3', 'eco' => '4', 'nexttrip' => '5');;qq($DEVICETOPIC/lmo/set $hash{$EVTPART1}) }\
usePvSurplus:yes,no { my %hash = ( 'yes' => 'true', 'no' => 'false');;qq($DEVICETOPIC/fup/set $hash{$EVTPART1}) }\
forceState:neutral,off,on { my %hash = ( 'neutral' => '0', 'off' => '1', 'on' => '2');;qq($DEVICETOPIC/frc/set $hash{$EVTPART1}) }\
phase_switchmode:auto,force_1,force_3 { my %hash = ( 'auto' => '0', 'force_1' => '1', 'force_3' => '2');;qq($DEVICETOPIC/psm/set $hash{$EVTPART1}) }\
goe_reboot:noArg $DEVICETOPIC/rst/set true\

attr go_echarger stateFormat { my $c=ReadingsVal($name,"car_num",5);;\
  my $ca=ReadingsVal($name,"charge_allowed","no");;\
  my $ch=ReadingsVal($name,"charge_num",0);;\
  my $p=ReadingsVal($name,"power",0);;\
  my $l=ReadingsVal($name,"energy",0);;\
  my $e=(ReadingsVal($name,"connection","") ne "ok");;\
  my $ret;;\
  if($ca eq "no"){\
     $ret="<p align=\"left\">\nnot_allowed\n<br/>not authenticated\n</p>";;\
  }elsif($c==1){\
    $ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car (idle)\n<p/>");;\
  }elsif($c==2){\
    $ret=sprintf("<p align=\"left\">\ncharging_car\n<br/>charging %.1f kW\n<p/>",$p);;\
  }elsif($ch==12){\
      $ret=sprintf("<p align=\"left\">\ncharging paused\n<br/>charging PvSurplus %.1f kW\n</p>",$p);;\
  }elsif($ch==17){\
      $ret=sprintf("<p align=\"left\">\ncharging pausedrn<br/>charging PvSurplus paused\n</p>");;\
  }elsif($c==3){\
    $ret=sprintf("<p align=\"left\">\nwaiting_car\n<br/>waiting for car\n<p/>");;\
  }elsif($c==4){\
    $ret=sprintf("<p align=\"left\">\nfinished_car\n<br/>finished %.2f\n<p/>",$l);;\
  }else{\
    $ret="unknown";;\
 }\
 $ret}
attr go_echarger userReadings state:car.* {my $c=ReadingsVal($NAME,"car_num",5);;\
  my $n=(ReadingsVal($NAME,"charge_allowed","no") ne "yes");;\
  ($n)?"not_allowed":(($c==1)?"ready_no_car":(($c==2)?"charging":(($c==3)?"wait_for_car":(($c==4)?"finished":"unknown"))))},\
nexttrip_distance:nexttrip_energy.* {sprintf("%.1f",ReadingsVal($name,"nexttrip_energy",0)/ReadingsVal($NAME,"nexttrip_energy_100km",1)*100)},\
energy_today:energy.* monotonic {ReadingsVal($NAME,"energy",0)},\
phases:pha_(1|2|3).* {((ReadingsVal($NAME,"pha_1","-") eq "true")? 1 : 0) + ((ReadingsVal($NAME,"pha_2","-") eq "true")? 1 : 0) + ((ReadingsVal($NAME,"pha_3","-") eq "true")? 1 : 0)}

setstate go_echarger <p align="left">\
not_allowed\
<br/>not authenticated\
</p>
setstate go_echarger 2025-02-13 14:15:19 IODev myMQTT2Server
setstate go_echarger 2025-02-15 14:49:19 I_L1 0
setstate go_echarger 2025-02-15 14:49:19 I_L2 0
setstate go_echarger 2025-02-15 14:49:19 I_L3 0
setstate go_echarger 2025-02-15 14:49:19 P_L1 0
setstate go_echarger 2025-02-15 14:49:19 P_L2 0
setstate go_echarger 2025-02-15 14:49:19 P_L3 0
setstate go_echarger 2025-02-15 14:49:19 P_N 0
setstate go_echarger 2025-02-15 14:49:19 U_L1 228
setstate go_echarger 2025-02-15 14:49:19 U_L2 229
setstate go_echarger 2025-02-15 14:49:19 U_L3 230
setstate go_echarger 2025-02-15 14:49:19 U_N 0
setstate go_echarger 2025-02-15 14:39:23 car idle
setstate go_echarger 2025-02-15 14:39:23 car_num 1
setstate go_echarger 2025-02-15 14:39:23 charge NotChargingBecauseAccessControlWait
setstate go_echarger 2025-02-13 17:44:42 charge_allowed no
setstate go_echarger 2025-02-15 14:39:23 charge_auth authentication
setstate go_echarger 2025-02-15 14:39:22 charge_mode default
setstate go_echarger 2025-02-15 14:39:23 charge_num 2
setstate go_echarger 2025-02-15 14:39:22 current_allowed null
setstate go_echarger 2025-02-15 14:39:22 current_limit 16
setstate go_echarger 2025-02-15 14:39:23 current_requested 10
setstate go_echarger 2025-02-15 14:39:22 energy 1556746
setstate go_echarger 2025-02-15 14:39:23 energy_connect 92.43148762
setstate go_echarger 2025-02-15 14:39:22 energy_stop null
setstate go_echarger 2025-02-15 14:39:22 energy_today 0
setstate go_echarger 2025-02-15 14:39:23 error none
setstate go_echarger 2025-02-15 14:39:23 error_num 0
setstate go_echarger 2025-02-15 14:39:23 forceState neutral
setstate go_echarger 2025-02-13 23:02:23 fup true
setstate go_echarger 2025-02-15 14:39:23 goe_firmware "58.1"
setstate go_echarger 2025-02-15 14:39:23 lock unlocked
setstate go_echarger 2025-02-15 14:39:23 lock_num 1
setstate go_echarger 2025-02-13 17:34:31 nexttrip_distance 4000000.0
setstate go_echarger 2025-02-15 14:39:23 nexttrip_energy 40000
setstate go_echarger 2025-02-15 14:39:23 pAkku null
setstate go_echarger 2025-02-15 14:39:23 pGridTarget -200
setstate go_echarger 2025-02-15 14:39:23 pPv null
setstate go_echarger 2025-02-15 14:39:23 pThreePhaseSwitchLevel 4300
setstate go_echarger 2025-02-15 14:49:19 pf_L1 0
setstate go_echarger 2025-02-15 14:49:19 pf_L2 0
setstate go_echarger 2025-02-15 14:49:19 pf_L3 0
setstate go_echarger 2025-02-15 14:49:19 pf_N 0
setstate go_echarger 2025-02-15 14:39:23 pha_1 false
setstate go_echarger 2025-02-15 14:39:23 pha_2 false
setstate go_echarger 2025-02-15 14:39:23 pha_3 false
setstate go_echarger 2025-02-15 14:39:23 pha_4 true
setstate go_echarger 2025-02-15 14:39:23 pha_5 true
setstate go_echarger 2025-02-15 14:39:23 pha_6 true
setstate go_echarger 2025-02-15 14:39:23 phaseSwitchHysteresis 500
setstate go_echarger 2025-02-15 14:39:23 phase_switchmode auto
setstate go_echarger 2025-02-14 15:15:02 phases 0
setstate go_echarger 2025-02-15 14:49:19 power 0
setstate go_echarger 2025-02-15 14:39:23 prioOffset -300
setstate go_echarger 2025-02-15 14:49:16 rssi -40
setstate go_echarger 2025-02-15 14:39:23 starting_power 1400
setstate go_echarger 2025-02-15 14:39:23 state not_allowed
setstate go_echarger 2025-02-15 14:49:16 temperature_box 6.25
setstate go_echarger 2025-02-15 14:49:16 temperature_cable 10.25
setstate go_echarger 2025-02-15 14:39:23 transaction null
setstate go_echarger 2025-02-15 14:39:23 usePvSurplus false

Jetzt in der App MQTT aktivieren und einen Neustart vom go-e auslösen. Das ist auch als set eingebaut, sollte also von fhem aus gehen, falls nicht dann über die App, damit in fhem die entsprechenden Readings gefüllt werden.


weitere Unterschiede dum HTTPMOD:
- power:
HTTPMOD nutzt "tpa" als Wert, was ein 30sec Power-average liefert und im go-e nach Ladeende nicht 0 wird. Das wird zwar abgefangen und zu 0 wenn nicht mehr geladen wird, ich nutze total Power aus dem energy-array "nrg", weshalb Spannung, Ströme und Leistungen aller Phasen und z.T. als Gesamtwert ausgegeben werden.
- phases:
HTTPMOD nutzt "pnp", in der API mit numberOfPhases beschrieben. Ich habe den Eindruck, hier kommen nur Werte !=0 im eco-Betrieb. Da mich die Anzahl der genutzten Phasen aber immer interessiert werte ich das array "pha" aus und addiere per userReadings die Phasen 1 bis 3, die "true" sind.

alle Energie-werte sind in WH, nicht kWH! Wer das anders möchte kann es im attr ReadingList bei den Readings entsprechend einbauen

Im HTTPMOD hatte ich ja mal set-Befehle hinzugefügt für Presets (a_setPvUebMax etc) um auf einmal mehrere Werte an den go-e zu schicken, das geht wohl in MQTT nicht, jedenfalls habe ich dazu nix gefunden, auch werden die Werte in MQTT ja geschrieben, indem man /set ans topic hängt, da wird schwer mehrere anzugeben. Bin da aber nicht so der MQTT-Held, deshalb sage ich mal so: ICH habs nicht hinbekommen, weshalb es die set a_... hier eben nicht gibt.

Sonne scheint immer noch keine....



Viel Spaß damit.




Sany

[Prof. Dr. Peter Henning]

Netter Versuch.

Allerdings ist die Geschwätzigkeit nicht gut für FHEM, ich habe dazu in der MQTT-Ecke des Forums meine Kämpfe mit dem VW ID7 beschrieben. Auch wenn man nicht interessierende Topics ausfiltert, muss der MQTT-Server ziemlich viel rödeln.

LG

pah

[Sany]

Netter Versuch.

eben, ein Versuch, der bisher funktioniert. Und jeder kann den Versuch versuchen, wenn er will. Wie beschrieben habe ich lieber Events statt Abfragen, weshalb ich es mal (wieder) versucht habe.

ich habe dazu in der MQTT-Ecke des Forums

Meinst Du
Wieder mal: 100% CPU-Last durch MQTT
?

Habs mal durchgelesen und keine Hinweise auf ignoreRegexp gefunden....
Rudi bezieht sich auf readingList Einträge. Was da ankommt ist aber am ignoreRegexp schon längst vorbei und wird in fhem abgearbeitet. So verstehe ich das. Vielleicht gibts irgendwo eine ausführlichere Beschreibung über die Funktion von ignoreRegexp.

Die nächsten Tage soll die Sonne ja mal wieder scheinen, dann werde ich das Device in mein Produktiv-System übernehmen und die Last beobachten. Mal sehen, ich werde berichten.


Gruß


Sany

[Prof. Dr. Peter Henning]

am ignoreRegexp schon längst vorbei

Wieso vorbei? Jeder reguläre Ausdruck in diesem Attribut muss mit jeder einlaufenden Nachricht verglichen werden, das ist das Problem.

Ich sehe noch nicht, dass das substanziell anders ist, als jeden regulären Ausdruck in der readingList mit jeder einlaufenden Nachricht zu vergleichen.

LG

pah

[Sany]

ich sehe das "it will be silently ignored" aus meiner User-Perspektive halt so, dass recht früh im MQTT2_SERVER bereits aussortiert wird und diese Daten gar nicht mehr bis zu einem MQTT2_DEVICE durchkommen und dort in der readingList abgearbeitet werden. Und daher würde ich sagen, dass das halt weniger Last im System verursacht. Das es Last bedeutet ist klar, ich vermute auf diesem Weg halt die geringst mögliche.
Ich kann da aber auch völlig falsch liegen.
Rudi wird es wissen, mir reicht im Moment das "ausprobieren und beobachten".

Gruß


Sany

[Prof. Dr. Peter Henning]

Nun, das ist ein freies Land, und jeder kann das ausprobieren. Aber noch einmal: "silently ignored" heißt nicht, dass der MQTT-Server damit keine Arbeit hat. Diese Arbeit wächst quadratisch mit der Anzahl der Regulären Ausdrücke, die entweder in der readingList oder in der ignoreRegexp stehen.

Im Übrigen gibt es das ignoreRegexp_Attribut nur für den FHEM-internen MQTT2_SERVER. Wenn man einen externen MQTT-Server verwendet, liegt bei dem die volle Geschwätzigkeit der Wallbox.

LG

pah