Moin zusammen,
in meiner VCCU stehen im Attribut IOList die Werte:
HMLAN1,HMLAN2,HMUART1
Ich wollte nun das Attribut mit
attr VCCU IOList HMLAN1,HMLAN2,HMUART0,HMUART1
ergänzen aber da kommt die Fehlermeldung "HMLAN1 does not support CUL_HM".
Was ist denn hier falsch?
Vielen Dank.
MfG
Daniel Cattarius
...sollte mit https://forum.fhem.de/index.php/topic,122422.msg1172009.html#msg1172009 zu lösen sein.
Zitat von: Beta-User am 08 September 2021, 10:33:05
...sollte mit https://forum.fhem.de/index.php/topic,122422.msg1172009.html#msg1172009 zu lösen sein.
Habe die Datei "10_CUL_HM.pm" heruntergeladen, eingespielt und einen Neustart gemacht.
Der Fehler ist noch der gleiche. Im Log kommt leider nichts.
Hmm, hast du mal ein list von dem HMLAN1?
Zitat von: Beta-User am 08 September 2021, 13:25:10
Hmm, hast du mal ein list von dem HMLAN1?
Internals:
.FhemMetaInternals 1
DEF 192.168.178.101:1000
DeviceName 192.168.178.101:1000
FD 14
FUUID 5c54236f-f33f-cf0a-9bda-965b4050856856b9
FVERSION 00_HMLAN.pm:0.181520/2019-01-05
HMLAN1_MSGCNT 354
HMLAN1_TIME 2021-09-08 13:48:45
IFmodel LAN
NAME HMLAN1
NR 17
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E269DAD,0000,4022562E,FF,FFD3,C38610269DAD0000000A24DA0B0040
RSSI -45
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 21
msgKeepAlive dlyMax:125.397 bufferMin:0
msgLoadCurrent 5
msgLoadHistoryAbs 5min steps: 5/5/5/5/5/5/5/5/0/0/0/0
msgParseDly min:12 max:5498 last:220 cnt:291
owner 23A38D
owner_CCU VCCU
uptime 012 298:53:12.110
.attraggr:
.attrminint:
.clientArray:
CUL_HM
Helper:
DBLOG:
D-HMIdAssigned:
dbLog:
TIME 1631099238.5684
VALUE 23A38D
D-HMIdOriginal:
dbLog:
TIME 1631099238.5684
VALUE 23A38D
D-firmware:
dbLog:
TIME 1631099238.5684
VALUE 0.965
D-serialNr:
dbLog:
TIME 1631099238.5684
VALUE KEQ0851774
Xmit-Events:
dbLog:
TIME 1631099238.85754
VALUE init:1 disconnected:1 ok:1
cond:
dbLog:
TIME 1631099238.85754
VALUE ok
loadLvl:
dbLog:
TIME 1631101720.941
VALUE low
prot_ok:
dbLog:
TIME 1631099238.85754
VALUE last
READINGS:
2021-09-08 13:07:18 D-HMIdAssigned 23A38D
2021-09-08 13:07:18 D-HMIdOriginal 23A38D
2021-09-08 13:07:18 D-firmware 0.965
2021-09-08 13:07:18 D-serialNr KEQ0851774
2021-09-08 13:07:18 Xmit-Events init:1 disconnected:1 ok:1
2021-09-08 13:07:18 cond ok
2021-09-08 13:48:40 loadLvl low
2021-03-31 10:12:10 prot_ERROR-Overload last
2021-03-31 10:12:09 prot_Warning-HighLoad last
2021-09-08 13:04:21 prot_disconnected last
2021-09-08 13:04:21 prot_init last
2021-09-01 12:41:58 prot_keepAlive last
2021-09-08 13:07:18 prot_ok last
2017-03-03 07:30:17 prot_timeout last
2021-09-08 13:04:21 state opened
helper:
assIdCnt 21
assIdRep 21
info 03C5,KEQ0851774,23A38D,23A38D
setTime 49777
cnd:
0 1
253 1
255 1
dly:
cnt 291
lst 220
max 5498
min 12
ids:
24CF10:
cfg +24CF10,00,00,00
name 2_02_KL_Fensterkontakt
269DAD:
cfg +269DAD,00,00,00
name 2_05_BZ_Heizungsthermostat
29801F:
cfg +29801F,00,00,00
chn 01
flg 0
msg
name 2_03_SZ_Rauchmelder
to 1631099275.89781
2982C2:
cfg +2982C2,00,00,00
chn 01
flg 0
msg
name 2_02_KL_Rauchmelder
to 1631099271.5004
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 1631099263.94899
2B3FF2:
cfg +2B3FF2,00,00,00
chn 01
flg 0
msg
name 1_07_FL_Rauchmelder
to 1631099260.73246
2B8CCE:
cfg +2B8CCE,00,00,00
chn 01
flg 0
msg
name 1_01_EZ_Nachtlicht
to 1631099243.15173
2CA54E:
cfg +2CA54E,00,00,00
name 1_04_GT_Fensterkontakt
30A0D7:
cfg +30A0D7,00,00,00
name 3_02_M1_Heizungsthermostat
365D85:
cfg +365D85,00,00,00
chn 01
flg 0
msg
name 2_06_FL_Nachtlicht
to 1631099278.56771
3D7201:
cfg +3D7201,00,00,00
chn 01
flg 0
msg
name 1_02_WZ_Tablet
to 1631099252.68477
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 1631099255.66021
4D265B:
cfg +4D265B,00,00,00
name 1_02_WZ_Tuerkontakt
4EC5BA:
cfg +4EC5BA,00,00,00
name 1_06_KU_Tuerkontakt
4F30AE:
cfg +4F30AE,00,00,00
chn 01
flg 0
msg
name 1_02_WZ_Rollladen_r
to 1631099249.053
4F320B:
cfg +4F320B,00,00,00
chn 01
flg 0
msg
name 1_02_WZ_Rollladen_l
to 1631099247.02214
54C03D:
cfg +54C03D,00,00,00
name 1_05_SK_Sensor
k:
BufMin 0
DlyMax 125.397
Next 1631101745.81413
Start 1631101720.81413
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0xbae611e0)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 5
loadNo 9
scnt 1
ald:
5
5
5
5
5
5
5
5
0
0
0
0
apIDs:
ref:
drft -0.000137230684781117
hmtL 1075987481
kTs 0
offL 1630025733337
sysL 1631101720818
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
Hmm, ok...
Folgendes: Für alle anderen IO-Typen scheint es das Internal "Clients" zu geben, nicht aber für den HMLAN. Danach unterscheidet aber CUL_HM, ob es überhaupt ein gültiges IO ist.
Es sollte helfen, ans Ende der "Initialize" noch eine Zeile einzufügen - hier jetzt mal die m.E. "saubere" Fassung ab einschl. $readingFnAttributes:
$readingFnAttributes;
$hash->{Clients} = ":CUL_HM:";
return;
}
Falls das so paßt, würde ich die vollständige Datei dann noch an die "patchliste" aaO. anhängen.
EDIT: Zur Klarstellung - es geht um die Moduldatei 00_HMLAN.pm
Das Internal "Clienst" wird trotz der Änderung immer noch nicht hinzugefügt.
In der Zeile 65 von 00_HMLAN.pm ist aber auch schon folgender Eintrag enthalten:
$hash->{Clients} = ":CUL_HM:";
my %mc = (
"1:CUL_HM" => "^A......................",
);
$hash->{MatchList} = \%mc;
FHEM ist neu gestartet oder du hast die DEF angefasst? Und einen reload der Detailansicht gemacht?
Habe nach der Änderung erst ein reload HMLAN gemacht.
Nachdem dann alle HMLANs disconnected wurden und sich dieser Status nicht mehr geändert hat, habe ich einen Neustart gemacht.
:o öhm...
Du hast natürlich recht mit dem Hinweis, dass die betreffende Anweisung einmalig völlig ausreichen wäre und mein Vorschlag nicht passen kann.
Aber warum & wo geht das Internal verloren...?!?
Da fehlt mir im Moment jede Idee...
v.a. @frank &/oder noansi:
Habt ihr irgendeine Idee, warum/wo "Clients" verloren geht?
Ergänzend:
Soweit ich das templList-Attribut-Thema (z.B. https://forum.fhem.de/index.php/topic,122726.0.html) verstanden habe, geht das v.a. deswegen verloren, weil vermeintlich der entsprechende Setter für den Gerätetyp nicht da ist - was nach Abschluss der Konfiguration nicht (mehr) zutrifft, der ist vorhanden.
Wenn diese Analyse stimmt, ist es ein Reihenfolge-Problem beim Aufruf der diversen Konfigurationsebenen - woher aber genau, habe ich aber bisher nicht gefunden. Vielleicht hat einer von euch eine Idee?
ZitatHabt ihr irgendeine Idee, warum/wo "Clients" verloren geht?
nicht wirklich.
editieren der fhem.cfg plus fhem restart funktioniert ja scheinbar wie immer anstandslos.
nur das ändern übers frontend wird "verhindert", macht probleme.
weiß nicht...
Folgender Schnelltest: Zwei gültige IO's (CUL+HMUARTLGW-TYPE).
Auszug aus dem List der VCCU:
io: vccu vccu ioList: CUL1 myHMUART prefIO:
Ergänze ich einen (fake) HMLAN via cfg-Edit und starte neu, ist io->ioList LEER. Darauf greift aber zumindest CUL_HM_assignIO() wiederum (nur in Teilen?) zurück. Kann sein, dass es dann doch keine Lücke gibt, weil die folgende Abfrage (ca. ab #10819) das wieder abfängt, aber irgendwie ist es nicht sauber, weil jedenfalls die darauf wieder folgende Auffanglösung dann mangels passendem "Clients" einen Bogen um den HMLAN macht...
Im Modul 00_HMUARTLGW.pm wird das im define gesetzt und da scheint es ja zu funktionieren.
Ja. Deswegen ist ja auch die Frage, wo bzw. warum es verloren geht.
Habe mal nach "Clients" in HMLAN, HMInfo, fhem.pl, DevIo und CUL_HM gefahndet und nirgends einen Anpack gefunden, warum das passiert...
schräge idee:
wird Clients eventuell gar nicht angelegt?
vielleicht wegen den doppelpunkten?
vielleicht gibt da es einen unterschied zwischen _Initialized und _Define?
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.
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
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.
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...
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. ;)
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...
# $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 (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.
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
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.
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.
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
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...
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
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 (https://forum.fhem.de/index.php/topic,120600.0.html) übernommen.
EDIT: Anhänge gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
Nachbrenner noch:
Eigentlich müßte mAn. der Check der IOList für alle VCCU vorgezogen werden, also eine Schleife vor der Schleife eingebaut werden. Damit wäre sichergestellt, dass auch der Teil "cfg-Reihenfolge-fest" wäre?
Angepaßter Code anbei...
(Nicht wundern, dass ich da nicht eine eigene devspec2array verwendet habe; da wir genau wissen, dass wir bei der vorhandenen Auswahl genau ein Argument checken müssen, dürfte das so herum schneller sein...)
EDIT: Anhang gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
Alles drin, Neustart gemacht.
Nun schauen wir mal. Bis jetzt scheint alles ok.
Hoffe dass die ganzen Patches auch mal ins SVN kommen.
Danke für die Rückmeldung.
Hast du irgendwo aes aktiviert?
Wäre nett, wenn jemand noch Rückmeldung geben könnte, der das feature nutzt.
Ich mach' dann bei Gelegenheit mal einen Gesamtpatch fertig (ohne HMUARTLGW, das betrifft mgernoth) und bin mal optimistisch, dass Martin sich dazu auch irgendwann melden wird (und sei es nur, dass er "ok" meldet und ein anderer Maintainer das dann für ihn ins svn schubst...).
bei HMLAN wird Clients im Modul gesetzt (wie bei manchen anderen auch) - aber nicht in die Entity kopiert.
Ich ändere das Verhalten nicht, da es mit usus erscheint.
in CUL_HM hatte ich das nicht berücksichtigt: wenn die Entity kein Internal Clients hat muss ich in Modul nachsehen.
Ist jetzt drin.
Also workaround hättet ihr einfach erzwingen können
{$defs{HMLAN1}{Clients} = ":CUL_HM:"}
Danke für die Rückmeldung, wieder was gelernt :) .
Bzgl. des HMLAN-patches: Da war neben dieser - nunmehr mit 24961 obsoleten - Verschiebung dann auch noch der ältere Patchvorschlag von frank ([hmlan] patch: keepAlive mechanismus ursache für gelegentliche hmlan reboots (https://forum.fhem.de/index.php/topic,120600.msg1172136.html#msg1172136)) drin. Hat sicher nicht die hohe Prio wie die anderen aktuellen Problemchen, es wäre aber nett, wenn es nicht unterginge (oder frank eine Rückmeldung bekäme, warum nicht).
Moin,
die HMLAN kommt aber noch nicht mit dem Update.
Gruß Daniel
Zitat von: dancatt am 14 September 2021, 07:36:19
die HMLAN kommt aber noch nicht mit dem Update.
...muss sie ja auch nicht, Martin hat das bzgl. des Clients-Themas etwas anders (=eleganter) gelöst.
Bzgl. HMLAN wären m.E. zwei Dinge wünschenswert:
- eine Rückmeldung zum Patchvorschlag von frank
- eine Aktualisierung der commandref in Richtung "id". Du kannst ja letzteres gerne als patch beisteuern, das ist nichts großes, siehe z.B. auch die Änderungen (nach =pod bzw. =html) in https://svn.fhem.de/trac/changeset/24963/trunk/fhem/FHEM/98_weekprofile.pm
Ich hänge mich mal hier dran. Wollte bei einem neuen System jetzt eine VCCU anlegen und den HMLAN1 dazu packen in die IOList aber der Fehler does not ... kommt immer noch. Ist das Problem immer noch nicht behoben, oder habe ich was übersehen? FHEM habe ich eben gerade ein Update unterzogen aber es bleibt dabei.
Kannst du mal "version" von CUL_HM ausdrücklich gegenchecken?
Mit der letzten aus dem svn (24961) müßte das eigentlich klappen.
# $Id: 10_CUL_HM.pm 24961 2021-09-12 06:46:07Z martinp876 $
Habe auch noch einige andere Fehler gehabt, die ich hier in den letzten Tagen gesehen habe. DeviceRename hat dazu geführt, dass erst nach einem Restart die Internals entsprechend angepasst wurden.
Hmm, komisch. Zumindest das sollte eigentlich mit der svn klappen...
Aber du kannst gerne "meine" gepatchte Fassung aus dem Nachbarthread mal testen, wobei die diesen Punkt eigentlich auch nicht (mehr) anders macht als die svn-Fassung.
Hatte gestern alles per Hand angelegt und geändert gehabt, da ich voran kommen musste. Wenn ich die Tage Zeit habe, dann schaue ich nochmal nach.
Ich bekomme bei der Einrichtung der VCCU den Fehler
VCCU: unknown attribute IOList. Type 'attr VCCU ?' for a detailed list
Folgendes PM ist aktiv:
10_CUL_HM.pm 25059 2021-10-10 07:50:22Z martinp876
Def der VCCU:
defmod VCCU CUL_HM xxxxxx
attr VCCU .mId FFF0
attr VCCU DbLogExclude .*
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
setstate VCCU CUL868:UAS,
setstate VCCU 2021-10-16 18:55:40 IOopen 0
setstate VCCU 2021-10-16 18:55:40 state CUL868:UAS,
Mach ich etwas falsch?
Viele Grüße
Karlheinz
speichere, was du schon hast, mach fhem restart und probiere erneut.
Danke für den Hinweis. Hat funktioniert. Nur warum braucht es da einen Neustart?
dein anwendungsfall wurde wohl einfach nicht bedacht.
Hmmm, hab eigentlich, wie im Wiki beschrieben ganz normal die VCCU definiert.
du hast alles richtig gemacht.
ich war schon immer dafür, dass cul_hm automatisch eine vccu anlegt, wenn keine existiert.
Das wäre sicherlich der beste Weg.
Viele Grüße und nochmals danke für die Hilfe.
Karlheinz
mit den aktuellen patches von https://forum.fhem.de/index.php/topic,123436.0.html (https://forum.fhem.de/index.php/topic,123436.0.html) habe ich jedenfalls keine probleme beim anlegen einer 2. vccu das attribut IOList über das frontend zu setzen.
Zitat von: frank am 17 Oktober 2021, 12:06:57
mit den aktuellen patches von https://forum.fhem.de/index.php/topic,123436.0.html (https://forum.fhem.de/index.php/topic,123436.0.html) habe ich jedenfalls keine probleme beim anlegen einer 2. vccu das attribut IOList über das frontend zu setzen.
Auch mit nur einer bzw. der ersten VCCU ist das IOList-Attribut grundsätzlich setzbar. "Problematisch" ist "nur noch", wenn man das IO erst nach der VCCU definiert und NICHT für CUL_HM vorbereitet wird (indem man rfmode setzt).
Aber "einfach so" den rfmode zu ändern, sollte man m.e. nicht automatisch machen!
(VCCU automatisch anlegen wäre m.E. überlegenswert, aber dann wissen die User vermutlich genausowenig wie beim ACTIONDETECTOR, was das soll...)