Wie kann ich das in FHEM umsetzen?
Ereignis:
RFbridge/relay/3 (Zustand 1 oder 0)
Aktion:
sonoffswitchS20b/relay/0/set (1 oder 0)
--
RFbridge und sonoffswitchS20b sind die funktionierenden MQTT Topics.
Mit mosquitto_pub -t sonoffswitchS20b/relay/0/set -m "0" schalte ich die Steckdose in der Befehlszeile direkt.
Mit define WLAN_Steckdose_RFschalten DOIF (A) erstelle ich ein DOIF ohne sinnvollen Inhalt (A) in FHEM, aber hier enden meine Anfängerkenntnisse.
Vielleicht geht es auch ganz anders, ein Denkanstoß wäre hilfreich.
Hmm,
klingt danach, als gäbe es einen externen Broker? Dann ein Interface definieren (TYPE=MQTT oder MQTT2_CLIENT), beide Geräte anlegen (mit MQTT2_CLIENT als MQTT2_DEVICE). Dann im zu schaltenden entsprechende Setter definieren (für den Sonoff-Switch gibt es vermutlich ein attrTemplate).
Dann solltest du (vom ersten Geräte) "Events" bekommen (siehe Event-Monitor), die du mit einem DOIF oder einem notify abgreifen kannst und daraus Aktionen für das 2. Device ableiten (siehe z.B. Commandref zu notify).
Ist aber erst mal sehr theoretisch, ich würde empfehlen, erst mal den Sonoff als "normales" FHEM-Gerät funktional zu machen.
Gruß, Beta-User
Die RFBridge und der Sonoff S20 Switch sind hier als "normale" Geräte in einem funktionierenden FHEM. Der MQTT Broker auch, es funktioniert doch alles.
Wenn ich miit einer RF Fernbedienung einen Befehl an die Bridge sende, schaltet die auch in FHEM, also ich sehe da die Aktionen, ich kann dies auch in FHEM auf der Oberfläche alles schalten. Und die MQTT Topics anschauen etc. Es läuft. Aber ich möchte mit der RF Fernbedienung die Steckdose schalten, das geht bisher nur über die FHEM Oberfläche. Das ich dazu ein DOIF brauche sehe ich auch, aber die Theorie nützt mir dabei wenig. Mit der DOIF Befehlsreferenz kann ich ohne Beispiele in dem Fall eher nichts anfangen.
Ob man ein DOIF braucht, ist eine philosophische Frage. Mir ist das zu kompliziert, ich nutze für solche Aufgaben notify.
Aber unabhängig von der Frage, welche Eventhandler es noch gibt (es gibt mind. noch eines mehr, die diese Aufgabe lösen können): Ohne dass du uns zeigst, wie deine "normalen Geräte" aussehen und ggf. die Events, die da produziert werden von der RF-Bridge, kann man nicht vernünftig helfen, siehe die hier im Anfängerbereich angepinnten Beiträge...
Aber damit du nicht die commandref selbst durchsuchen mußt (falls das Event der RF-Bridge "on" bzw. "off" ist, und sich der sonoff auch mit "on"/"off" schalten läßt?!?), hier mal ein Auszug aus "notify":
ZitatFührt eine oder mehrere Anweisungen aus, wenn ein Event generiert wurde, was dem <Suchmuster> (Gerätename oder Gerätename:Event) entspricht. Die Anweisung ist einer der FHEM Befehlstypen (http://hpthin2:8083/fhem/docs/commandref_DE.html#command). Zum Test dient das trigger (http://hpthin2:8083/fhem/docs/commandref_DE.html#trigger)-Kommando.
Beispiele: define b3lampV1 notify btn3 set lamp $EVENT
Wenn du keine Ahnung hast welche Events so im System "unterwegs sind" bzw. keine Lust hast Notify/DOIF etc. selbst "anzulegen" solltest du hier mal schauen: https://wiki.fhem.de/wiki/Event_monitor
Mehr gibt es ohne weitere Infos (wie bereits geschrieben) nicht zu sagen...
Gruß, Joachim
Die Vorgehensweise mit dem Event-Monitor hilft mir schon sehr.
Ich hab jetzt mal 2 DOIFs erstellt, eins wenn ich die RF Bridge mit RF schalte - und eins wenn ich die Sonoff Steckdose im FHEM schalte.
Wie bringe ich die jetzt zusammen, RF soll die Steckdose schalten.
2019-09-17 10:23:47 MQTT myBroker connection: active
2019-09-17 10:23:50 MQTT_DEVICE RFbridge transmission-state: incoming publish received
2019-09-17 10:23:50 MQTT_DEVICE RFbridge Sensor: 2B7001900410000515
2019-09-17 10:23:50 MQTT_DEVICE intertechno1 transmission-state: incoming publish received
2019-09-17 10:23:50 MQTT_DEVICE intertechno1 on
--
Create DOIF
define RFbridge_DOIF_1 DOIF ([RFbridge:"^Sensor:.2B7001900410000515$"]) ()
2019-09-17 10:29:23 MQTT_DEVICE sonoffswitchS20b ON
2019-09-17 10:29:23 MQTT_DEVICE sonoffswitchS20b transmission-state: outgoing publish sent
2019-09-17 10:29:23 MQTT_DEVICE sonoffswitchS20b transmission-state: incoming publish received
2019-09-17 10:29:23 MQTT_DEVICE sonoffswitchS20b on
---
Create DOIF
define sonoffswitchS20b_DOIF_1 DOIF ([sonoffswitchS20b:"^on$"]) ()
Was dich "eigentlich" interessiert, ist doch, welchen Status der eigentliche Aktor hat (sonoffswitchS20b), oder?
Sollte so gehen:
define RFbridge_notify_1 notify RFbridge.*Sensor.*2B7001900410000515 setreading sonoffswitchS20b state on
Das ließe sich auch ganz ohne externen Eventhandler regeln, wäre das kein MQTT_DEVICE, sondern vom Typ MQTT2_DEVICE. (Kann sein, dass es auch mit MQTT_DEVICE und/oder MQTT_GENERIC_BRIDGE ginge).
(Nur als Anmerkung nch: Und bevor man nicht verstanden hat, wie notify funktioniert, sollte man die Finger von DOIF lassen).
Nein, ich will den Aktor mit RF steuern. Der Staus wird im FHEM einwandfrei angezeigt. Und wenn ich von DOIF "die Finger lasse" werde ich es nie verstehen.
Direktes schalten sollte so gehen:
define RFbridge_notify_1 notify RFbridge.*Sensor.*2B7001900410000515 set sonoffswitchS20b on
Du darfst gerne DOIF lernen, ich sagte ja nur, du solltest _zuerst_ einen anderen Eventhandler kennenlernen. Der hat viel weniger Einstellmöglichkeiten und ist daher m.E. auch leichter zu verstehen. Hast du den "einfacheren" dann verstanden, kannst du meinetwegen lernen, was du willst... ;)
Jetzt bin ich echt baff ;) Das funktioniert ja tatsächlich.
DANKESCHÖN.
Basis zum weiteren lernen.
:)
Aber wieso sollte das nicht funktionieren?
Noch eine Anmerkung zu MQTT: Da du erst in das Thema einsteigst, würde ich empfehlen, statt (Mosquitto (?), MQTT und MQTT_DEVICE) (MQTT2_SERVER+MQTT2_DEVICE) einzusetzen. Das ist von der Einarbeitung her einfacher, siehe auch https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele.
Dann könnte man die entsprechenden Messages auch direkt beim (neuen) sonoffswitchS20b auswerten...
Auf dem Raspi ist Mosquitto.
Ich hab mir bisher mit MQTTfx angeschaut, was so hin- und hergeht.
Die Meldungen werte ich so aus:
define sonoffswitchS20b MQTT_DEVICE
attr sonoffswitchS20b IODev myBroker
attr sonoffswitchS20b publishSet ON OFF sonoffswitchS20b/relay/0/set
attr sonoffswitchS20b subscribeReading_state sonoffswitchS20b/relay/0
Das ist mir klar...
Was mir nicht klar ist: Ist dir klar, dass es in FHEM (mind.) 3 (sehr unterschiedliche) Wege gibt, um eingehende MQTT-Messages zu verarbeiten und noch viel mehr, welche rauszuschicken...?!?
Du hast einen der Wege gewählt, mitteilen wollte ich, dass das m.E. nicht der einsteigerfreundlichste ist. Du wirst das aber erst dann merken, wenn du komplexere Message-Strukturen hast (JSON senden, z.B....), bei Plain Text (wie derzeit _noch_) ist es egal ;) .
Da du dich eh' grade erst einarbeitest, wäre eben die Frage, ob du nicht das Pferd gleich wechselst, bevor das eine größere Aktion wird ;D .
Ich probiere das aus. Leider fehlen meine Espurna-Devices in den MQTT2 Modulen Praxisbeispielen.
:) Interessant, Espurna fehlt in der Tat noch.
Nehme ich gerne auf, aber bisher ist noch keiner hier aufgeschlagen, der das verwendet... (ist keine Kritik an der firmware, die scheint ganz gut zu sein.)
Würde vorschlagen, einfach mal autocreate am MQTT2_SERVER werkeln zu lassen und dann mal ein, zwei list im MQTT-Bereich einzustellen. Wenn du mit der setList und den Beispielen dazu für andere Typen in der attrTemplate-file nicht klarkommst, einfach melden :) und möglichst einen link auf die MQTT-API beifügen, damit man lesen kann, was da per MQTT genau wohin zu senden ist (hier ist ja schon der Hinweis zu finden, dass ON/OFF an einen "set" Pfad unterhalb der Rückmeldung gesendet werden muß. Das dürfte keine große Sache sein, das ist bei Tasmota ähnlich, nur dass dort der topictree anders beginnt ;) .
Bitte ggf. klarmachen, was "default"-Einstellung ist, und wo du selbst was angepaßt hast (betr. die Topic-Struktur, Groß-/Kleinschreibung etc.).