Ich habe mal testweise meine HMCCUCHN/HMCCUDEV Module um attrTemplates erweitert. Mein erstes Template sieht so aus:
######################################################################
# Door or window sensor
name:HM-Sec-SCo
filter:TYPE=HMCCUCHN|HMCCUDEV:FILTER=ccutype=HM-Sec-SCo
par:CHANNEL;Channel number; { InternalVal("DEVICE","TYPE","") eq "HMCCUDEV" ? "1." : "" }
desc: Door or window sensor
attr DEVICE ccureadingfilter STATE
attr DEVICE statedatapoint CHANNELSTATE
attr DEVICE substitute STATE!(0|false):closed,(1|true):open
Im Prinzip funktioniert das Setzen der Attribute. Allerdings erscheint beim Ausführen des Befehls
set xyDev attrTemplate HM-Sec-SCo
immer die Aufforderung, einen Wert für den Parameter "CHANNEL" einzugeben. Nun habe ich ja bei der Definition dieses Parameters im Template Perl-Code angegeben in der Hoffnung, dass "CHANNEL" automatisch ermittelt wird. Das scheint aber ignoriert zu werden.
Es liegt an Zeile 161 in AttrTemplate.pm:
if($ret) {
$repl{$parname} = $ret;
next;
}
Der Perl-Code in meinem Template liefert ggf. "" zurück, was Perl als "false" wertet und daher den if Zweig oben nicht ausführt.
@Rudi: Wäre es möglich, das so zu ändern?
if (defined ($ret))
Hmm,
erst mal willkommen im Club :) .
Wenn du CHANNEL nur dazu brauchst, statedatapoint aufzulösen, könntest du das auch mit Rückgabewerten von "STATE" bzw. "1.STATE" lösen, oder?
Ansonsten gäbe es auch noch die Möglichkeit, bedingte Zweige zu definieren, also getrennte Anweisungen für beide Device-Typen zu realisieren (siehe die Diskussion zum template für den Eurotronic-Spirit in der zibgee-Variante, oder evtl. zum Thema Sprachsteuerung, müßte ich bei Bedarf suchen...).
Gruß, Beta-User
Danke für den Hinweis, schau ich mir morgen mal im Detail an.
Allerdings ist das im Code trotzdem ein Fehler. eval() liefert im Fehlerfall undef zurück. Das Statement in AttrTemplate prüft aber auf "defined und true". Die Auswertung der Perl-Anweisung geht also auch schief, wenn diese z.B. 0 zurück liefert (oder eben "" oder false ...).
Zur Info: die files mqtt2.template und httpmod.template habe ich eben nochmal darauf durchgesehen, ob es Probleme gäbe, wenn man die Prüfung ändert wie vorgeschlagen.
Wo ggf. Änderungsbedarf hätte sein können, ist das geändert (war in den allermeisten Fällen sowieso "undef").
Auch mysensors.template und huedevice.template sind m.E. unproblematisch.
Ich sehe noch in mqtt2.template eine Zeile, die ich mit der primitiven Suche (grep '^par:' *.template | grep -v undef) gefunden habe:
Zitatmqtt2.template:par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
Ansonsten habe ich den Vorschlag von zap uebernomen.
Danke, (auch für den grep- Hinweis :) ), das korrigiere ich bei Gelegenheit noch, es sollte erst mal keine unmittelbare Gefahr darstellen ::) ...