Fehlermeldung "HMLAN1 does not support CUL_HM" IOList VCCU

Begonnen von dancatt, 08 September 2021, 10:24:03

Vorheriges Thema - Nächstes Thema

frank

schräge idee:
wird Clients eventuell gar nicht angelegt?
vielleicht wegen den doppelpunkten?
vielleicht gibt da es einen unterschied zwischen _Initialized und _Define?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

wie wird in fhem eigentlich festgelegt welche hash elemente unter Internals erscheinen?
cul_hm sucht in den Internals und nicht unter hash->{Clients} vom io.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

#17
Es gibt zumindest einen Unterschied zwischen _Initialized und _Define...

Habe dann auch gleich Matchlist verschoben. Damit sind diese Internals/Hashes dann zwar da, aber scheinbar reicht das alleine noch nicht aus, damit iolist in der VCCU erhalten bleibt (letztere ist jetzt weiter nach dem HMLAN definiert). Eventuell liegt es aber an meiner "attr dummy"-Konstruktion, daher hier mal die "verschobene" HMLAN zum Testen.

@frank: Alle Keys, die der jeweilige Modulautor als SCALAR unter $hash belegt, sind "Internals". Da kann man auch alles mögliche reinschreiben, solange es keine strukturierten Daten sind (HASH oder ARRAY) - die sieht man nur in list. Die Doppelpunkte sind daher völig i.O..

EDIT: Anhang gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dancatt

Zitat von: Beta-User am 09 September 2021, 11:57:27
Es gibt zumindest einen Unterschied zwischen _Initialized und _Define...

Habe dann auch gleich Matchlist verschoben. Damit sind diese Internals/Hashes dann zwar da, aber scheinbar reicht das alleine noch nicht aus, damit iolist in der VCCU erhalten bleibt (letztere ist jetzt weiter nach dem HMLAN definiert). Eventuell liegt es aber an meiner "attr dummy"-Konstruktion, daher hier mal die "verschobene" HMLAN zum Testen.

@frank: Alle Keys, die der jeweilige Modulautor als SCALAR unter $hash belegt, sind "Internals". Da kann man auch alles mögliche reinschreiben, solange es keine strukturierten Daten sind (HASH oder ARRAY) - die sieht man nur in list. Die Doppelpunkte sind daher völig i.O..

Also so wie du das im Anhang hast hatte ich heute morgen schon probiert. nur ein paar Zeilen untendrunter. Nach dem Neustart ging garnichts mehr.
Bin so tief in fhem leider nicht drin. Ich vermute mal dass die Funktion HMLAN_Define nur beim define aufgerufen wird. Meine Devices gibt es ja schon.

In der VCCU waren dann beide HMLANs weg und fast alle Devices haben Fehlermeldungen gebracht. Nachdem ich die Änderungen wieder rückgängig gemacht habe steht im Reading IODev auch nur noch HMUART2, wobei dieser deaktiviert/closed ist.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Hmm, die Stelle im Code hatte ihren Grund darin, dass danach irgendwelche Checks kommen, von denen mir auf die Schnelle nicht klar war, ob die reibungslos durchlaufen. Von daher _könnte_ es einen Unterschied machen.

Das "define" wird bei jedem FHEM-Start gemacht, bei "rereadcfg" oder wenn du die DEF anfasst (=defmod), indem du z.B. ein Leerzeichen ergänzt. Purer Reaload hilft dagegen nicht (auch nicht in Initialize, btw). HMUARTLGW macht diesen Teil mit Clients etc. auch in Define, das sollte also nicht alles aus dem Tritt bringen...

Irgendwas ist an dem HMLAN-Code offenbar speziell. Nach wie vor völlig unklar ist mir v.a., warum das Auswirkungen auf alle haben sollte, wenn ein IO irgendein Problem hat...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ich habe in meiner 00_HMLAN.pm den clients-block jetzt ebenfalls entsprechend verschoben wie beta-user.
das zusätzliche return allerdings nicht übernommen.

nach fhem restart läuft der hmlan immer noch bestens und zeigt nun das internals Clients.
cul_hm ist aber immer noch nicht aktuell.  ;)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Na ja, das "return" sorgt nur für Klarheit, ein eventuell vorhandener impliziter Rückgabewert würde nur das define (zumindest aus FHEMWEB heraus) verhindern...

Das Problem ist, dass jetzt zwar das Clients-Internal da ist, aber die VCCU den HMLAN - jedenfalls mein "Pseudogerät" immer noch nicht als IO akzeptiert und weiter die iolist leert. Ich nehme an, dass du eine CUL_HM-Version von vor 24irgendwas hast?

Weiter ist unklar, warum das Internal überhaupt gelöscht wird, wenn man es via Initialize macht; eigentlich sollte das keinen Unterschied machen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

#22
# $Id: 10_CUL_HM.pm 24374 2021-05-02 18:16:52Z martinp876 $
# noansi: modified for testing

spezialversion von https://forum.fhem.de/index.php/topic,121139.msg1158983.html#msg1158983


in der aktuellen cul_hm habe ich 4 such codes nach "Clients" gefunden:
1.
my @IOnames = devspec2array("Clients=:CUL_HM:");

2.
foreach my $nIO (@newIO){
  return "$nIO does not support CUL_HM" if(InternalVal($nIO,"Clients","") !~ m /:CUL_HM:/);
}

3.
return "$io no suitable for CUL_HM" if(scalar(grep{$_ eq $io}
                                              grep{$defs{$_}{Clients} =~ m/:CUL_HM:/}
                                              keys %defs));

4.
my @IOs = devspec2array("Clients=:CUL_HM:");


1. und 4. finden zb auch nicht meinen cul. der zeigt nämlich im internal Clients ":CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:"

edit: 1 und 4 sind nicht erfolgreich.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

#23
Hmm, jetzt habe ich mal ganz "dumm" einfach ein paar Sternpunkte vergeben, um die devspec2array-Anweisungen auch für CUL-Geräte passend zu machen...

Habe leider versäumt, vorher mal in meinem Echtsystem nachzuschauen, was da vorher stand, aber jetzt ist bei der VCCU die ioList auch leer, obwohl nur CUL und HMUART TYPE IO's gelistet sind :o . Weiß nicht, ob das ein Fortschritt ist oder nicht, und vermute eher nicht.

Es will mir aber immer noch nicht einleuchten, wie das Internal verlustigt geht...

EDIT: Anhang gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dancatt

Moin,
also ich habe nun auch den Block

$hash->{Clients} = ":CUL_HM:";
  my %mc = (
    "1:CUL_HM" => "^A......................",
  );
  $hash->{MatchList} = \%mc;

nach HMLAN_Define verschoben (auch ohne return).
Ich bekomme nun in der VCCU bei
attr VCCU IOList  HMLAN1,HMLAN2,HMUART1,HMUART2
keinen Fehler mehr. Als mir gestern alles um die Ihren flog lag das vermutlich an dem return.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

frank

ZitatEs will mir aber immer noch nicht einleuchten, wie das Internal verlustigt geht...
meinst du noch, wenn hash/Clients in _Initialize() angelegt wird? oder passiert das jetzt auch noch?

wird clients wirklich zunächst angelegt?
hast du den eintrag schon gesehen?
in hmlan_initialize werden ja auch weitere hashelemente (funktionsnamen) angelegt, die auch nicht im list auftauchen.

hast du vielleicht ein beispiel, wo ein hash element ausserhalb von _Define() angelegt wird und dann in den internals auftaucht?

wie kann ich am einfachsten einen kompletten hash "sichtbar" machen? möglichst über die fhen-cmd-eingabe.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

dancatt

Wenn der Code in "HMLAN_Initialize" steht wird das Internal "Clients" nicht angelegt.
Nun da ichs in "HMLAN_Define" verschoben habe wird es im HMLAN angelegt:
list:

Internals:
   .FhemMetaInternals 1
   Clients    :CUL_HM:
   DEF        192.168.178.101:1000
   DeviceName 192.168.178.101:1000
   FD         47
   FUUID      5c54236f-f33f-cf0a-9bda-965b4050856856b9
   FVERSION   00_HMLAN.pm:0.181520/2019-01-05
   HMLAN1_MSGCNT 459
   HMLAN1_TIME 2021-09-10 10:35:32
   IFmodel    LAN
   NAME       HMLAN1
   NR         17
   NTFY_ORDER 50-HMLAN1
   PARTIAL   
   RAWMSG     E30923D,0000,49BE8288,FF,FFBB,1F861030923D0000000A24DC090040
   RSSI       -69
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDsCnt 15
   msgKeepAlive dlyMax:124.226 bufferMin:0
   msgLoadCurrent 5
   msgLoadHistoryAbs 5min steps: 6/6/6/6/6/6/6/6/6/6/6/6
   msgParseDly min:11 max:5571 last:223 cnt:394
   owner      23A38D
   owner_CCU  VCCU
   uptime     014 343:40:22.024
   .attraggr:
   .attrminint:
   .clientArray:
     CUL_HM
   Helper:
     DBLOG:
       D-HMIdAssigned:
         dbLog:
           TIME       1631259554.78936
           VALUE      23A38D
       D-HMIdOriginal:
         dbLog:
           TIME       1631259554.78936
           VALUE      23A38D
       D-firmware:
         dbLog:
           TIME       1631259554.78936
           VALUE      0.965
       D-serialNr:
         dbLog:
           TIME       1631259554.78936
           VALUE      KEQ0851774
       Xmit-Events:
         dbLog:
           TIME       1631259571.62026
           VALUE      disconnected:2 ok:2 init:2
       cond:
         dbLog:
           TIME       1631259571.62026
           VALUE      ok
       loadLvl:
         dbLog:
           TIME       1631262930.15101
           VALUE      low
       prot_disconnected:
         dbLog:
           TIME       1631259561.72865
           VALUE      last
       prot_init:
         dbLog:
           TIME       1631259567.14921
           VALUE      last
       prot_ok:
         dbLog:
           TIME       1631259571.62026
           VALUE      last
       state:
         dbLog:
           TIME       1631259567.25757
           VALUE      CONNECTED
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2021-09-10 09:39:14   D-HMIdAssigned  23A38D
     2021-09-10 09:39:14   D-HMIdOriginal  23A38D
     2021-09-10 09:39:14   D-firmware      0.965
     2021-09-10 09:39:14   D-serialNr      KEQ0851774
     2021-09-10 09:39:31   Xmit-Events     disconnected:2 ok:2 init:2
     2021-09-10 09:39:31   cond            ok
     2021-09-10 10:35:30   loadLvl         low
     2021-09-10 09:39:21   prot_disconnected last
     2021-09-10 09:39:27   prot_init       last
     2021-09-10 09:39:31   prot_ok         last
     2021-09-10 09:39:27   state           opened
   helper:
     assIdCnt   15
     assIdRep   15
     info       03C5,KEQ0851774,23A38D,23A38D
     setTime    49782
     cnd:
       0          2
       253        2
       255        2
     dly:
       cnt        394
       lst        223
       max        5571
       min        11
     ids:
       24CF10:
         cfg        +24CF10,00,00,00
         name       2_02_KL_Fensterkontakt
       29801F:
         cfg        +29801F,00,00,00
         chn        01
         flg        0
         msg       
         name       2_03_SZ_Rauchmelder
         to         1631259598.96558
       2982C2:
         cfg        +2982C2,00,00,00
         chn        01
         flg        0
         msg       
         name       2_02_KL_Rauchmelder
         to         1631259597.87646
       2AD870:
         cfg        +2AD870,00,00,00
         name       2_03_SZ_Fensterkontakt
       2ADB09:
         cfg        +2ADB09,00,00,00
         name       2_05_BZ_Fensterkontakt
       2B3D70:
         cfg        +2B3D70,00,00,00
         chn        01
         flg        0
         msg       
         name       2_01_KM_Rauchmelder
         to         1631259596.89858
       2B3FF2:
         cfg        +2B3FF2,00,00,00
         chn        01
         flg        0
         msg       
         name       1_07_FL_Rauchmelder
         to         1631259593.55276
       2B8CCE:
         cfg        +2B8CCE,00,00,00
         chn        01
         flg        0
         msg       
         name       1_01_EZ_Nachtlicht
         to         1631259574.50539
       2CA54E:
         cfg        +2CA54E,00,00,00
         name       1_04_GT_Fensterkontakt
       365D85:
         cfg        +365D85,00,00,00
         chn        01
         flg        0
         msg       
         name       2_06_FL_Nachtlicht
         to         1631259600.72575
       365D87:
         cfg        +365D87,00,00,00
         name       0_99_Keller_Schalter_Pumpe
       3EBF3E:
         cfg        +3EBF3E,02,00,00
         name       1_06_KU_Schalter
       3FBEE0:
         cfg        +3FBEE0,00,00,00
         name       2_01_KM_Fensterkontakt
       42E272:
         cfg        +42E272,00,00,00
         chn        01
         flg        0
         msg       
         name       1_06_KU_Rollladen
         to         1631259590.84658
       4EC5BA:
         cfg        +4EC5BA,00,00,00
         name       1_06_KU_Tuerkontakt
     k:
       BufMin     0
       DlyMax     124.226
       Next       1631262955.13509
       Start      1631262930.13509
     loadLvl:
       bl         40
       a:
         99
         90
         40
         0
       h:
         0          low
         40         batchLevel
         90         high
         99         suspended
     log:
       all        0
       sys        0
       ids:
         ARRAY(0xbbd40bc8)
     q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLastMax 5
       loadNo     7
       scnt       2
       ald:
         6
         6
         6
         6
         6
         6
         6
         6
         6
         6
         6
         6
       apIDs:
     ref:
       drft       -0.000176297747306562
       hmtL       1237220371
       kTs        0
       offL       1630025709768
       sysL       1631262930139
Attributes:
   group      Geräte
   hmId       23A38D
   hmLanQlen  1_min
   icon       hm_lan
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       9_00_System
   wdTimer    25

Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Zitat von: dancatt am 10 September 2021, 09:53:33
keinen Fehler mehr. Als mir gestern alles um die Ihren flog lag das vermutlich an dem return.
Das mit der Diskussion über "return" und dessen Wirkungen sollten wir lassen. Vermutlich habe ich mir mit dieser Thematik schon deutlich öfter FHEM abgeschossen wie du...

Zitat von: frank am 10 September 2021, 10:13:43
meinst du noch, wenn hash/Clients in _Initialize() angelegt wird? oder passiert das jetzt auch noch?
Vermutlich ist $hash nicht gleich $hash, einmal bezieht sich das auf den Code, das andere Mal auf die Modulinstanz.

Um sowas sichtbar zu machen, kann man Data::Dumper benutzen, aber für eine Anleitung dazu müßte ich auch erst mal das Internet befragen ::) ...

Habe aber grade noch was interessantes festgestellt (wieder mit meinen dummy-Instanzen, kann also sein, dass reale Hardware andere Ergebnisse zeitigt):
Startet man FHEM (mit meinen Modulfassungen, v.a. mit der bzgl. der regexe berichtigten (?) Fassung von gestern abend) mit einer IOList aus CUL, HMUARTLGW und HMLAN Instanz, ist io->ioList erst mal LEER.
Hatte weiter HMLAN in Verdacht, also gelöscht. io->ioList enthält dann den CUL+HMUARTLGW. Soweit die Übereinstimmung mit RTL.

ABER:
Dann habe ich wieder den HMLAN dazugepackt, also nach $init_done. Und siehe da, ich bekomme eine Rückmeldung, dass IOList jetzt alle drei enthalten würde (Dialogfelder sind normalerweise ein Zeichen, dass die letzte Anweisung nicht ausgeführt wurde (!)). Und: Das Attribut ist (unter Veränderung der Reihenfolge) gesetzt, und ioList enthält alle drei...!  :)

@dancatt: Kannst du mal (mit den aktuellen Fassungen HMLAN+"Beta-User"-CUL_HM) dieses Verhalten mit realer Hardware gegechecken?
Um die IOList dann zu ändern, genügt es, ein Leerzeichen anzufügen.

Falls jemand aus dem AES-Thread mitliest und auch einen HMLAN als "Spielverderber" im Setup hat, würde mich interessieren, ob das wieder klappt, wenn man durch diesen Trick ioList wieder füllt. Dann hätten wir nämlich "einfach nur" ein Initialisierungsproblem...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dancatt

Zitat von: Beta-User am 10 September 2021, 11:11:03
@dancatt: Kannst du mal (mit den aktuellen Fassungen HMLAN+"Beta-User"-CUL_HM) dieses Verhalten mit realer Hardware gegechecken?
Um die IOList dann zu ändern, genügt es, ein Leerzeichen anzufügen.
Kann gerne checken. Weiß nun nur nicht welche Fassungen ich nun benötge.
- Also meine 00_HMLAN.pm ist so geändert dass ich den Clients-Teil von HMLAN_Initialize nach HMLAN_Define verschoben habe.
- Dann habe ich deine 10_CUL_HM.pm aus dem Thread https://forum.fhem.de/index.php/topic,122422.msg1172009.html#msg1172009
- Und die 00_HMUARTLGW.pm habe ich aus https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

#29
Ich glaube, einen Lösungsansatz gefunden zu haben:
In CUL_HM_updateConfig() (wird nach $init_done ausgeführt) fehlt mAn. eine Zeile, die IOList checkt und die ioList füllt, bevor IOgrp etc. getestet wird (bei mir #244):
CUL_HM_Attr("set",$name,"IOList",AttrVal($name,"IOList","")) if(AttrVal($name,"IOList","") ne "");
Mit dieser Ergänzung ist io->ioList auch nach einem FHEM-Start ohne Anwendereingriff da.

(Das Coding würde ich eigentlich anders notieren, bitte nicht wundern, das ist nur ein "as is"-Klon mit Minimalstanpassungen).

Anbei die betreffende vollständige Modulfassung, damit da keine Verwirrung eintritt, und der Vollständigkeit halber auch noch "meine" HMLAN (wobei es nur darauf ankommt, dass das Internal vorhanden ist).
Der Link zu HMUARTLGW müßte passen.

EDIT: Habe jetzt auch (hoffentlich vollständig) die patches für HMLAN aus https://forum.fhem.de/index.php/topic,120600.0.html übernommen.

EDIT: Anhänge gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files