Hi,
seit einiger Zeit legt FHEM immer automatisch ein ALIAS für meine Devices an. Das passiert, wenn ich ein neues Device anlerne und auch bei jedem Neustart von FHEM wenn ich das Alias Attribut vorher gelöscht habe.
Ich bin mir sicher, es gibt einen guten Grund dafür, das so zu machen, aber es nervt auch gewaltig weil man dann mittlerweile zusätzlich zu einem rename auch noch das Attribut ändern muss.
Meine Fragen:
a) Muss das so sein (ein alias zwingend für jedes Device)? Wenn ja, warum?
b) Kann man das durch irgendeinen Parameter abschalten (automatisches Anlegen des alias Attributs bei Neuanlage eines Device bzw. Neustart)?
Ich nutze die Aliases so gut wie nie, weil ich die Weboberfläche von FHEM nicht wirklich für meine "Anwender" (Familie) einsetze, dafür gibt's physische Schalter etc. und vergebe lieber Devicenamen, die mir für die Verwaltung sinnvoll erscheinen.
Vielen Dank im Voraus für Eure Antworten!
Viele Grüße,
Heiko
Hallo Heiko,
das müsstes Du mit einem konkreten Beispiel unterlegen (list von Beispiel Device).
Bei mir wird kein Alias automatisch erstellt, außer bei meinen sonos2mqtt Playern und da liegt es an mir (es ist gewollt) ich habe ein notify dazu gebaut welches dies Funktion enthält.
Gruß Otto
OK, kein Problem:
Wenn ich ein Beispiel-Dummy anlege, wird automatisch ein alias angelegt:
define Beispiel dummy
list Beispiel
Internals:
CFGFN
FUUID 5f2569c1-f33f-8e55-8519-8b2b6f12073bd208
NAME Beispiel
NR 3685
STATE ???
TYPE dummy
Attributes:
alias Beispiel
Auch bei einem existierenden Homematic Objekt wurde der Alias automatisch angelegt und wenn ich ihn lösche, kommt er sofort wieder:
list TempSensor_Heizung_Ruecklauf
Internals:
CFGFN ./config/devices/homematic.cfg
DEF 5468D0
FUUID 5cd13acb-f33f-8e55-7059-a4915e1cd013c5b6
HMLAN1_MSGCNT 103
HMLAN1_RAWMSG E5468D0,0000,184D7D8B,FF,FFB3,3086705468D000000000FF64
HMLAN1_RSSI -77
HMLAN1_TIME 2020-08-01 15:11:55
HMLAN2_MSGCNT 104
HMLAN2_RAWMSG E5468D0,0000,08671DB0,FF,FFBC,3086705468D000000000FF64
HMLAN2_RSSI -68
HMLAN2_TIME 2020-08-01 15:11:55
HMLAN3_MSGCNT 103
HMLAN3_RAWMSG 050000513086705468D000000000FF64
HMLAN3_RSSI -81
HMLAN3_TIME 2020-08-01 15:11:55
HMLAN4_MSGCNT 104
HMLAN4_RAWMSG 050000273086705468D000000000FF64
HMLAN4_RSSI -39
HMLAN4_TIME 2020-08-01 15:11:55
IODev HMLAN4
LASTInputDev HMLAN1
MSGCNT 414
NAME TempSensor_Heizung_Ruecklauf
NOTIFYDEV global
NR 615
NTFY_ORDER 50-TempSensor_Heizung_Ruecklauf
STATE T: 25.5
TYPE CUL_HM
chanNo 01
lastMsg No:30 - t:70 s:5468D0 d:000000 00FF64
protLastRcv 2020-08-01 15:11:55
protRcv 104 last_at:2020-08-01 15:11:55
rssi_at_HMLAN1 cnt:103 min:-80 max:-75 avg:-77.8 lst:-77
rssi_at_HMLAN2 cnt:104 min:-72 max:-68 avg:-68.83 lst:-68
rssi_at_HMLAN3 cnt:103 min:-88 max:-73 avg:-82 lst:-81
rssi_at_HMLAN4 cnt:104 min:-40 max:-39 avg:-39.14 lst:-39
READINGS:
2020-08-01 10:47:45 Activity alive
2017-10-05 19:30:41 CommandAccepted yes
2017-10-05 19:31:07 D-firmware 1.3
2017-10-05 19:31:07 D-serialNr *****
2017-10-05 19:31:07 PairedTo ****
2017-10-05 19:31:07 R-pairCentral *****
2017-10-05 19:31:07 RegL_00. 01:00 02:01 05:00 0A:F1 0B:18 0C:27 0F:00 00:00
2020-08-01 15:11:55 battery ok
2020-08-01 15:11:55 state T: 25.5
2020-08-01 15:11:55 temperature 25.5
helper:
HM_CMDNR 48
mId 003E
peerFriend
peerOpt p:THSensor
regLst 0
rxType 12
supp_Pair_Rep 0
cmds:
TmplKey :no:1596271667.28857
TmplTs 1596271667.28857
cmdKey :1:1:0::003E:01
TmplCmds:
cmdList:
assignHmKey:
clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename:newName
fwUpdate:-filename- -bootTime- ...
getConfig:
getDevInfo:
getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
peerBulk:-peer1,peer2,...- [set|unset]
peerChan:0 -actChn- ... single [set|unset] [actor|remote|both]
raw:data ...
regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
reset:
tplDel:tmplt
unpair:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5468D0,00,00,00
nextSend 1596287515.14432
rxt 2
vccu VCCU
p:
5468D0
00
00
00
prefIO:
HMLAN2
mRssi:
mNo 30
io:
HMLAN1:
-77
-77
HMLAN2:
-68
-68
HMLAN3:
-81
-81
HMLAN4:
-31
-31
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMLAN1:
avg -77.8058252427185
cnt 103
lst -77
max -75
min -80
at_HMLAN2:
avg -68.8365384615385
cnt 104
lst -68
max -68
min -72
at_HMLAN3:
avg -82
cnt 103
lst -81
max -73
min -88
at_HMLAN4:
avg -39.1442307692308
cnt 104
lst -39
max -39
min -40
Attributes:
IODev HMLAN4
IOgrp VCCU:HMLAN2
actCycle 000:10
actStatus alive
alias TempSensor_Heizung_Ruecklauf
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
group Heizung
model HM-WDS30-T-O
peerIDs 00000000,
room KG_Keller,ZZ_Heizung
serialNr ****
subType THSensor
Dann das alias gelöscht:
deleteattr TempSensor_Heizung_Ruecklauf alias
list TempSensor_Heizung_Ruecklauf
...
Attributes:
IODev HMLAN4
IOgrp VCCU:HMLAN2
actCycle 000:10
actStatus alive
alias TempSensor_Heizung_Ruecklauf
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
group Heizung
model HM-WDS30-T-O
peerIDs 00000000,
room KG_Keller,ZZ_Heizung
serialNr OEQ0072370
subType THSensor
Ist also sofort wieder da. Wenn ich auf den Link" deleteattr" im WEB klicke, verschwindet das Attribut aus der Anzeige, wird aber bei einem sofort danach ausgeführten list oder CtrL+R wieder angezeigt.
Irgendwelche Ideen?
Danke!! Viele Grüße,
Heiko
Du hast einen alias Virus :)
Es gibt einen cmdalias grep (Wiki), den würde ich definieren und mal nach grep alias suchen.
Du hast sicher eine Routine definiert die dies tut. Im ausgelieferten FHEM gibt es das nicht. 8)
Gruß Otto
;D "alias Virus", genau danach sieht es aus, sehr gut!
Bei dem grep bin ich mir nicht so sicher wie das funktioniert, aber ich gehe mal davon aus, ich kann auch einfach in der Linux Shell mit "grep alias FHEM/99*.pm" suchen, richtig?
Das führt leider zu keinem Ergebnis, d.h. in den 99_*.pm Dateien findet sich "alias" nicht ein mal ..
Ist ja super merkwürdig, dass das bei Dir nicht so ist. Wenn ich nur wüsste, wonach ich im Perl Code suchen muss...
Danke auf jeden Fall für Deine Mühen, Otto!
naja nach dem alias funktioniert ein grep alias auch in der FHEM Kommandozeile.
Ich würde die fhem.cfg absuchen? Es müsst ja ein attr ... alias geben?
Ähm, es gibt ja hunderte von attr .... alias in der Config (eins für jedes definierte Objekt befürchte ich).
Hatte gerade eben erst gedacht, die Zeile "attr global alias global" könnte was in der Richtung bewirken, scheint aber nur das normale "automatisch" angelegte alias zu sein ...
Ich bin leider ratlos.
Viele Grüße,
Heiko
Bei mir ist das Übersichtlich - aber klar bei Dir. Hatte ich nicht bedacht :(
gibt es sowas wie attr $NAME alias $NAME
so ähnlich müsste der Code ja aussehen...
Idee:
grep nach attr aber nicht am Zeilenanfang -
grep 'attr' /opt/fhem/fhem.cfg|grep -v '^attr'
Gute Idee, aber leider auch kein Treffer, er zeigt nur zwei Zeilen an, die ich mal auskommentiert hatte (#attr ...).
Habe eine verdächtige Zeile in 37_echodevice.pm gefunden:
37_echodevice.pm: print (fhem( "attr " . $devicehash->{NAME} ." alias " .$device->{accountName} )) if( defined($device->{accountName}) );
Allerdings benutze ich das Modul nirgends (habe keinen Amazon Echo) und außerdem sollte das ja keinen Einfluss auf ein Dummy device haben...
OK, ich lebe erstmal damit würde ich sagen, kümmere mich jetzt erstmal um was anderes. Vielen Dank für Deine Unterstützung, Otto! Und falls noch jemand in Zukunft eine Idee hat, woran das liegen könnte, bitte hier antworten. Danke!!!
Viele Grüße,
Heiko
IMHO gibt es nur zwei Möglichkeiten und beide musst du dir selbst reingebastelt haben :
a. via fhem.cfg und z.B. Device global oder b. in einer 99_xxx.pm
Mit archetype gespielt?
Hallo Heiko,
konntest du das Problem lösen? Und wenn ja wie?
Ich hab das gleiche Problem. Bei mir wird nach rauslöschen aller fast 500 alias Einträge innerhalb kurzer Zeit automatisch neue erstellt.
Viele Grüße
Arne
Zitat von: arneg am 24 Januar 2021, 00:27:47
Hallo Heiko,
konntest du das Problem lösen? Und wenn ja wie?
Ich hab das gleiche Problem. Bei mir wird nach rauslöschen aller fast 500 alias Einträge innerhalb kurzer Zeit automatisch neue erstellt.
Viele Grüße
Arne
Hi Arne,
leider nicht. Ich lebe momentan damit, dass ich beim Umbenennen eines Objekts den Alias danach lösche, er wird dann mit dem neuen Namen direkt wieder angelegt. Es ist auf jeden Fall schon mal eine Erleichterung, dass ich doch nicht der Einzige bin. Ich kann mir mittlerweile vorstellen, dass das tatsächlich durch eine 99_xxx ausgelöst wird, die ich mal für das Lösen eines anderen Problems eingespielt habe. Weiß aber nicht, wonach ich suchen soll. Wenn ich etwas mehr Zeit habe, bewege ich die 99_xxx Dateien mal weg (und kommentiere alle Sachen aus, die darauf zugreifen) und schaue dann, ob die alias Attribute trotzdem noch erscheinen.
Viele Grüße,
Heiko
Zitat von: heiko73 am 25 Januar 2021, 10:55:53
Hi Arne,
leider nicht. Ich lebe momentan damit, dass ich beim Umbenennen eines Objekts den Alias danach lösche, er wird dann mit dem neuen Namen direkt wieder angelegt. Es ist auf jeden Fall schon mal eine Erleichterung, dass ich doch nicht der Einzige bin. Ich kann mir mittlerweile vorstellen, dass das tatsächlich durch eine 99_xxx ausgelöst wird, die ich mal für das Lösen eines anderen Problems eingespielt habe. Weiß aber nicht, wonach ich suchen soll. Wenn ich etwas mehr Zeit habe, bewege ich die 99_xxx Dateien mal weg (und kommentiere alle Sachen aus, die darauf zugreifen) und schaue dann, ob die alias Attribute trotzdem noch erscheinen.
Viele Grüße,
Heiko
Bei mir fing es an, seit ich mal wieder im meinem Produktivsystem bastel (ja, als Softwareker weiß ich dass man das niemals machen sollte).
Bei mir könnte ich vorerst abstellen, nachdem ich bei einem testweise installierten ioBroker den FHEM Adapter gelöscht habe. Was da genau passiert weiß ich noch nicht.
Hast du evtl. auch ioBroker oder andere Systeme im Einsatz, die extern auf FHEM zugreifen?
schon mal fhem.log analysiert?
ggf vorher "attr global verbose 5" setzen.
Zitat von: arneg am 25 Januar 2021, 11:02:10
Bei mir fing es an, seit ich mal wieder im meinem Produktivsystem bastel (ja, als Softwareker weiß ich dass man das niemals machen sollte).
Bei mir könnte ich vorerst abstellen, nachdem ich bei einem testweise installierten ioBroker den FHEM Adapter gelöscht habe. Was da genau passiert weiß ich noch nicht.
Hast du evtl. auch ioBroker oder andere Systeme im Einsatz, die extern auf FHEM zugreifen?
Das könnte es sein. Habe auch ioBroker im Einsatz mit FHEM Adapter (hauptsächlich wegen dem WYSIWYG Editor für eine nette Oberfläche für mein Tablet).
Viele Grüße,
Heiko
Google: iobroker fhem alias --> https://forum.iobroker.net/topic/31339/gel%C3%B6st-fhem-adapter-variablenname-aus-iobroker-als-alias/6
Zitat von: Frank_Huber am 25 Januar 2021, 12:36:18
Google: iobroker fhem alias --> https://forum.iobroker.net/topic/31339/gel%C3%B6st-fhem-adapter-variablenname-aus-iobroker-als-alias/6
Super, danke Frank. Dann ist der "Schuldige" ja jetzt gefunden...
Hallo zusammen,
ich habe das Problem mit dem autom. Erstellen von alias auch und auch IOBroker installiert.
Konntet ihr die alias aber in der Zwischenzeit dauerhaft entfernen?
Hi Mario, sorry habe Deine Frage irgendwie verpasst.
Habe das gerade noch mal getestet und wenn ich per deleteattr einen Alias lösche, dann scheint er tatsächlich nicht wiederzukommen.
Viele Grüße,
Heiko