mqtt2.tasmota_ir.template: Fragen Anregungen

Begonnen von TomLee, 23 März 2019, 18:33:07

Vorheriges Thema - Nächstes Thema

Beta-User

Danke für die Info und auch das Einfügen ins Wiki!

Es wäre vermutlich hilfreich, einfach in der desc und in comment einen Link aufzunehmen?

Tendenziell würde ich dann eher im attrTemplate die Abfragen jetzt dann ganz ausschalten, und im Wiki könnten wir zur Abrundung noch zeigen, wie man
a) remotecontrol + das generische Device aus dem attrTemplate verwendet und/oder
b) ein separates MQTT2_DEVICE erstellt, das dann eben ein paar "harte" Befehle kennt (vol+/-, on/off, mute?).

Kurze Einführung zu a):
da wären nur die Sequenzen entsprechend anzupassen (bzw. für MQTT2_DEVICE nochmal in anderer notation zu schreiben), also statt
attr Receiver row00 IRNEC32 2122415745:POWEROFF3,[...]
(unterstellt, der gepostete Befehl würde dazu passen)
attr Receiver row00 NEC 32 0x1D00B946:POWEROFF3,[...]Zu b) siehe den verlinkten RF-Thread.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Motivierte linke Hände

Die attr-Befehle gehen für das MQTT2_DEVICE nicht, oder? Scheinen jedenfalls keine bekannten/validen Attribute zu sein, die Du im Beispiel da setzt.

Ich habe das im Wiki mit setList beschrieben. Das funktioniert zumindest  :)
FHEM 6 in einer KVM VM mit Ubuntu
HM-CFG-USB2, 2xHM-CFG-HMLAN, HM-HMUARTLGW mit 100+ HomeMatic Devices, Geofencing, Fritzbox, Unifi, HUE, Harmony-Hub, Denon-Receiver-Modul, Calendar, GardenaSmartDevice, Shelly, MQTT (zigbee2mqtt, Tasmota und Shelly) und ein wenig 1Wire.

Beta-User

nein, diese attr gehören zum nächsten Abschnitt mit "remotecontrol", und es ist auch noch etwas verwirrend, dass da (thematisch/coding-mäßig) wieder auf das MQTT_DEVICE Bezug genommen wird.
Tendenziell wäre eher die Frage, ob MQTT_DEVICE da überhaupt noch was verloren hat oder ganz raus kann (es gibt einen IR-Teil für MQTT_DEVICE im "Tasmota-Großartikel", den ich aber lieber nicht weiter anfassen will, es geht dann also (fast) nichts verloren)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TomLee

Die gezeigten attr-Befehle haben sich auf ein eventuell auch zu erwähnendes remotecontrol-Beispiel im Wiki bezogen

So ein remotecontrol-Device hab ich auch mal genutzt, das war am einfachsten damals um die Befehle über das hier erwähnte Script auszuführen, da hat es für mich auch Sinn gemacht:

https://forum.fhem.de/index.php/topic,67316.msg589561.html#msg589561

Aber wozu soll man jetzt im MQTT2_DEVICE Kontext eine zusätzliche remotecontrol-Definition mit einem notify im Wiki erwähnen ?

TomLee

OK mit MQTT_DEVICE gabs auch ein Beispiel zu remotecontrol aber wozu braucht man sowas in FHEM ?

Es geht doch alles mit dem Device (MQTT_DEVICE|MQTT2_DEVICE) selbst ?

Beta-User

...ist eine Geschmacksfrage...

Ich habe auch meine remotecontrol-Definitionen zwischenzeitlich alle beseitigt, aber an sich ist es eine feine Sache, damit optisch eine "normale" Fernbedienung nachzubasteln, und evtl. baue ich die auch irgendwie anders wieder ein, ist ja nicht auf IR beschränkt. Und wenn man unterschiedliche Belegungsebenen hat, kann man das uU. damit am einfachsten umsetzen. Ich fand es damals (noch mit MYSENSORS_DEVICE) am Schwierigsten, die ersten paar Zeilen zu schreiben und das Zusammenwirken von IO (jetzt MQTT2_DEVICE), remotecontrol und diesem ominösen notify zu verstehen.
Von daher wäre ich dankbar, wenn es jemand "umpflegen" könnte :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors