CUL_HM Bedeutung von noArg im Logfile?

Begonnen von rih, 30 November 2020, 23:04:56

Vorheriges Thema - Nächstes Thema

rih

Hallo,

ich habe nach längerer Zeit (halbes Jahr?) ein Update von FHEM durchgeführt. Seit dem sehe ich im Logfile bei allen CUL_HM-Einträgen das Anhängsel "noArg". Hier Auszug aus dem Logfile:

2020.11.30 19:30:00 3: CUL_HM set KZ_Heizung_Sw off noArg
2020.11.30 20:26:06 3: EnOcean set PSC234 off
2020.11.30 22:00:00 2: set SZ_Heizung_Set desired 16
2020.11.30 22:00:00 3: CUL_HM set SZ_Heizung_Sw on noArg
2020.11.30 22:30:00 2: set SZ_Heizung_Set desired 0
2020.11.30 22:30:00 3: CUL_HM set SZ_Heizung_Sw off noArg


Was bedeutet dieses noArg?

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

rih

Hallo Joachim,

danke für Deine Antwort. Den Thread des ersten Links hatte ich schon gelesen. Schien mir aber ein anderes Problem zu sein. Der zweite Link passt jedoch von der Frage- bzw. Problemstellung. Nur gibt es auch hier leider noch keine Antwort:

ZitatWenn du wissen willst warum das gekommen ist und die "Antworten" in den Threads nicht geholfen haben: dann musst du wohl warten bis Martin antwortet...
und der hat bis jetzt nicht geantwortet ...

Zitatmeine spekulation: ...

Also gibt es hier noch keine klare Antwort, warum und wieso das eingeführt wurde. Bitte nicht falsch verstehen. Funktioniert ja alles nach wie vor. Und das Anhängsel im Log stört eigentlich ja auch nicht weiter. Ich wollte nur wissen, ob es sich hier um einen Fehler oder ein Feature handelt. Oder was es sonst damit auf sich hat. Aber das kann wohl nur der Modulentwickler beantworten.

Gruß, Hans

MadMax-FHEM

Naja ich denke die "Spekulation" ist die Antwort.

Ob das nun ein "Feature" ist muss jeder selbst entscheiden ;)

Ich denke auch, dass es eben wegen generischer Programmierung gekommen ist und da wo es eben kein Argument gibt/braucht, wird eben ausgegeben, dass es da kein Argument gab... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

rih

#4
Heute klappt die Suche im Forum irgendwie besser  ;D. Meine Frage wurde wohl schon öfter gestellt.
Gut, die generische Programmierung wäre eine mögliche Erklärung. Ich teile da aber eher @betateilchens Antwort bzw. Meinung:

https://forum.fhem.de/index.php/topic,114704.msg1089338.html#msg1089338

Gezwungenermaßen halte ich mich nun auch an seinen Vorschlag: einfach ignorieren.

MadMax-FHEM

Naja unsaubere Modulprogrammierung ist eine Ansicht...

Wenn der Aufwand es für alle Kommandos (auch welche ohne Argumente) zu implementieren einfach ist und dabei lediglich so eine Logmeldung "abfällt"...
...die man ja ausschalten oder ignorieren kann ;)

Der Aufwand sich aber alle Kommandos (und bei CUL_HM sicher so einiges) individuell zu programmieren (ohne Mledung im Log) aber dafür mit der (potentiellen) Gefahr eines "Fehlers"...

Da nehme ich dann lieber die "unsaubere" Programmierung ;)

Es kommt aber (egal wie man es bezeichnen mag) auf dasselbe raus: einfach ignorieren...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)