Autor Thema: Frage zu attrTemplate  (Gelesen 325 mal)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2951
    • HMCCU
Frage zu attrTemplate
« am: 15 September 2019, 18:24:41 »
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))
« Letzte Änderung: 15 September 2019, 19:11:28 von zap »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7872
  • eigentlich eher user wie "developer"
Antw:Frage zu attrTemplate
« Antwort #1 am: 15 September 2019, 19:24:05 »
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
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2951
    • HMCCU
Antw:Frage zu attrTemplate
« Antwort #2 am: 15 September 2019, 20:37:37 »
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 ...).
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7872
  • eigentlich eher user wie "developer"
Antw:Frage zu attrTemplate
« Antwort #3 am: 16 September 2019, 07:49:42 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20983
Antw:Frage zu attrTemplate
« Antwort #4 am: 16 September 2019, 09:07:39 »
Ich sehe noch in mqtt2.template eine Zeile, die ich mit der primitiven Suche (grep '^par:' *.template | grep -v undef) gefunden habe:
Zitat
mqtt2.template:par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
Ansonsten habe ich den Vorschlag von zap uebernomen.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7872
  • eigentlich eher user wie "developer"
Antw:Frage zu attrTemplate
« Antwort #5 am: 16 September 2019, 09:46:59 »
Danke, (auch für den grep- Hinweis :) ), das korrigiere ich bei Gelegenheit noch, es sollte erst mal keine unmittelbare Gefahr darstellen ::) ...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}