moin.
anfang des jahres hatte ich folgenden cmdalias definiert:
defmod c_update_hmtools cmdalias updatehmtools AS update all http://192.168.1.31/fhem/controls_HMtools.txt
und dafür diesen menüeintrag im web device angelegt:
attr WEB menuEntries update_HMtools,cmd=updatehmtools
alles funktionierte tadellos.
auch "normale" update cmds in der eingabezeile waren davon unberührt.
vermutlich durch einen zwischenzeitlichen fhem restart war am wochenende auf einmal kein update cmd mehr möglich.
keine fehlermeldungen. der browser hat ggf einfach nur auf die fhem startseite gewechselt.
mit global verbose=5 und einem at zum testen wurde deutlich, dass der "update" cmd durch den cmdalias ersetzt wurde, da der anfang vom cmdalias übereinstimmt:
2022.01.16 16:00:34.763 5: exec at command a_test
2022.01.16 16:00:34.765 5: Cmd: >{
fhem("update all http://192.168.1.31/fhem/controls_hminfotools.txt");
Log(1,"----- update ----- =>");
}<
2022.01.16 16:00:34.767 5: Cmd: >update all http://192.168.1.31/fhem/controls_hminfotools.txt<
2022.01.16 16:00:34.769 5: AnalyzeCommand: trying updatehmtools for update
2022.01.16 16:00:34.770 1: ----- update ----- =>
2022.01.16 16:00:34.771 5: redefine at command a_test as +*00:05 {
fhem("update all http://192.168.1.31/fhem/controls_hminfotools.txt");
Log(1,"----- update ----- =>");
}
nach dem ändern des cmdalias von "updatehmtools" zu "updhmtools" funktionierte es wieder.
ist dieses verhalten so vorgesehen?
oder sollte nicht besser bei einer ersetzung der vollständige cmdalias übereinstimmen?
warum wurde dieses verhalten erst nach einem fhem restart wirksam?
seit der update cmd wieder funktioniert, erzeugt das at nun immer folgenden fehler:
2022.01.16 16:11:02.025 5: Cmd: >update all http://192.168.1.31/fhem/controls_hminfotools.txt<
2022.01.16 16:11:02.026 5: Loading ./FHEM/98_update.pm
2022.01.16 16:11:02.074 0: Strange call for nonexistent <undefined>: ActivateInformFn
2022.01.16 16:11:02.075 1: stacktrace:
2022.01.16 16:11:02.076 1: main::CallFn called by ./FHEM/98_update.pm (84)
2022.01.16 16:11:02.077 1: main::CommandUpdate called by fhem.pl (1265)
2022.01.16 16:11:02.077 1: main::AnalyzeCommand called by fhem.pl (1116)
2022.01.16 16:11:02.078 1: main::AnalyzeCommandChain called by fhem.pl (3935)
2022.01.16 16:11:02.078 1: main::fhem called by (eval 2499) (2)
2022.01.16 16:11:02.079 1: (eval) called by fhem.pl (1160)
2022.01.16 16:11:02.080 1: main::AnalyzePerlCommand called by fhem.pl (1189)
2022.01.16 16:11:02.080 1: main::AnalyzeCommand called by fhem.pl (1116)
2022.01.16 16:11:02.081 1: main::AnalyzeCommandChain called by ./FHEM/90_at.pm (287)
2022.01.16 16:11:02.081 1: main::at_Set called by fhem.pl (3890)
2022.01.16 16:11:02.082 1: main::CallFn called by fhem.pl (1939)
2022.01.16 16:11:02.083 1: main::DoSet called by fhem.pl (1971)
2022.01.16 16:11:02.083 1: main::CommandSet called by fhem.pl (1265)
2022.01.16 16:11:02.084 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2777)
2022.01.16 16:11:02.084 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (1006)
2022.01.16 16:11:02.085 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (598)
2022.01.16 16:11:02.086 1: main::FW_Read called by fhem.pl (3895)
2022.01.16 16:11:02.086 1: main::CallFn called by fhem.pl (773)
2022.01.16 16:11:02.105 4: BlockingCall (doUpdateInBackground): created child (11989), uses telnetPort to connect back
2022.01.16 16:11:02.110 3: update all http://192.168.1.31/fhem/controls_hminfotools.txt : Executing the update the background.
Zitatist dieses verhalten so vorgesehen?
Mehr oder weniger ja.
Der Parser sucht ein Befehl, was mit dem eingegebenen Text anfaengt.
Dabei werden erst die eingebauten und definierten Befehle durchgesucht, und danach Module mit passenden Namen geladen.
Da update ein Modul ist was nicht automatisch geladen wird, und cmdalias per define vorher bakanntgemacht wurde, gewinnt cmdalias.
ZitatMehr oder weniger ja.
danke für die erklärung.