Integration Tasmota Sonoff RF-Bridge "Portisch" über MQTT2

[KnutWuchtig]

Hallo zusammen,
ich habe mir die o. g. Bridge installiert.
Leider gibt es dafür kein Template, das sich nutzen könnte.
Die Templates für die RF-Bridges (o. Keys / m. Keys) funktionieren nicht.
Die Bridge wurde von meiner MQTT2-Bridge ordnungsgemäss erkannt und empfängt auch Readings.
(s. Anlage)
Was mir fehlt, ist die Möglichkeit, Signale zu senden.
Ich suche schon seit ca. 4 Wochen (sporadisch) nach einer Möglichkeit

Die beiden  Readings:
   -RESULT_RfCode
   und
   -RESULT_RfReceived_Data
bilden die Schnittstelle.

Ich habe es hierüber versucht, es gibt aber in meiner Tasmota-Version nicht das Kommando "cmd" um Codes zu
senden.
https://haus-automatisierung.com/hardware/fhem/2018/03/22/fhem-tutorial-reihe-part-56-sonoff-rf-bridge.html

Bei der Auslösung des Funktionsteiles: fhem("set BridgeSonoff cmd RfCode #" . $bridgeOn);
gibt es die Fehlermeldung "cmd" nicht bekannt

Der RF-Code lässt sich über die Tasmota-Konsole der Tasmota_RF_Bridge per "rfcode #144554" versenden und
schaltet dadurch auch die zugehörigen Funkmodule, das funktioniert also.
Auch über die Adresszeile des Browsers mittels: "<Meine-IP>/cm?cmnd=rfcode%20%23144554" wird der Schaltvorgang ausgelöst.
(%20=Leerzeichen / %23=#)
Nur für FHEM finde ich keine Lösung

Hat jemand ein Lösung in der Schublade?

[Beta-User]

Eine "fertige Lösung" ist es nicht, aber es gibt ein attrTemplate für Tasmota mit RF, das beispielhaft auch ein paar Sende-Kommandos zusammenbaut: tasmota_rf

Ggf. mal in den Quelltext zu tasmota_rf schauen (das Tutorial werde ich mir nicht ansehen, das ist m.E. völlig überholt!). Gerne können wir das RF-Ding auch verbessern, das ist nur ein unfertiger Transfer von einer (getesteten) Infrarot-Lösung (die aber prinzipiell dasselbe macht).
Als Ziel sollte es möglich sein, pro "Zielgerät" je ein MQTT2_DEVICE zu bauen, das die passenden RF-Codes kennt und "on" und "off" versteht.

[KnutWuchtig]

Hallo Beta-User,
danke für die schnelle Rückmeldung.

An einer gemeinsamen Lösung wäre ich sehr interessiert.
Ich bin leider nicht so fit in der FHEM-Programmierung.

Das Decvice benötigt kein on/off nur ein Reading für eingehende Signale (Reading gibt es: RESULT_RfReceived_Data) und zum Senden das Codes (Rfcode)

Wie wollen wir vorgehen?

Achim

[Beta-User]

Gemeinsam = ich gebe Hinweise, du arbeitest? Gut!

Also: autocreate am IO gehört auf "simple". Deine Readingnamen  klingen nach "complex".

Zeig ein RAW-List (von dem M2-Device, einschl. Readings, bitte!), dann können wir das fixen.

Dann trägst du mal zusammen, was es zu Tasmota-RF und MQTT2 gibt (sind ca. 4-5 Threads) und schaust dir auch den Anfang des "Rolling Code"-Threads zum OpenMQTTGateway an (da ist der JSON etwas anders, aber ansonsten ist das vermutlich fast am einfachsten zu übernehmen). Evtl. sind auch die Tasmota-IR-Threads (MQTT2) noch interessant; ob jetzt IR oder RF nimmt sich nicht viel.

Wie viele verschiedene RfCode hast du denn, die du senden willst und was tun die jeweils am Zielgerät?

[KnutWuchtig]

Moin und ein frohes neues Jahr,

anbei das RAW-Listing. (ich hoffe, das ist das was gemeint war)

Zu den Codes: Ich will dies nicht auf bestimmet Codes begrenzen.
Ich hatte auf die Seite von Matthias Kleine verwiesen, wo er eine generische Lösung entwickelt hat, die alle möglichen Codes senden kann.
Dieser Part ist aber für mich nicht das Hauptproblem.

M. E. ist die, bei meiner "Sonoff- Portisch-Variante", fehlende Übertragunsgmöglichkeit (cmd??) über das MQTT2-Protokoll das Problem.
(Es gibt bei MQTT2 kein "publishSet")
Beim Mosquitto z. B. gibt es auch die Möglichkeit ein Kommando direkt and den MQTT-Client zu senden:
z. B.: "mosquitto_pub -h 192.168.178.67 --quiet -t /Smarthome/Buero/sonoffrf/cmnd/RfCode -m '$mqttcode'";

Bei MQTT2 leider nicht?!

P.S. Ich hatte die RFBridhge zwischenzeitlich temp. in IO-Broker ausprobiert - funktioniert einwandfrei! (Lesen und Senden)
Warum ist das bei FHEM mal wieder ein Problem?!

[Beta-User]

Ebenfalls willkommen im neuen Jahr.

Ich hätte noch ein paar Bitten:
- Code einfach in Code-Tags-packen (#-Button);
- lamentier nicht rum, meine im Wiki veröffentlichte und veraltete Version für generisches Senden bzw. auch die Zusammenarbeit mit Remote-Control für Infrarot ist älter als das, was dein Held als Video anzubieten hatte. Ich werde das Video nicht ansehen, und du solltest sowas auch bestenfalls als Anregung verstehen. Im Detail steckt in den Videos praktisch immer der Wurm drin, also VERGISS es...
- Man kann über MQTT2_SERVER bequem alles mögliche direkt publishen, und man kann auch alle möglichen Clients verwenden, auch mosquitto_pub. Man muss nur beachten, was seit neuestem auch im Wiki steht: autocreate wird nur aktiv, wenn man den "-i"-Parameter verwendet... (autocreate => simple hatte ich schon erwähnt, oder...?!?).
- Und Sätze wie "Warum ist das bei FHEM mal wieder ein Problem?!" motivieren mich nicht eben, dir zu helfen, zumal du nicht mal ansatzweise versucht hast, sowas wie eine setList zu bauen, und stattdessen verwundert die Augen reibst, weil es eben kein "publishSet" gibt... (Das ist funktional im Prinzip dasselbe wie das, was sich bei MQTT2_DEVICE hinter setList und getList verbirgt).

Hier mal die ersten Änderungen (für die RAW-Eingabe):

Code Auswählen Erweitern

attr MQTT2_RFBridge_C3AB1C readingList /SmartHome/Interface/Bridge/tele/LWT:.* LWT\
  /SmartHome/Interface/Bridge/cmnd/POWER:.* {}\
  /SmartHome/Interface/Bridge/cmnd/RfCode:.* {}\
  /SmartHome/Interface/Bridge/tele/RESULT_RfReceived_Data:.* RESULT_RfReceived_Data\
  /SmartHome/Interface/Bridge/tele/INFO2:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /SmartHome/Interface/Bridge/tele/INFO3:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /SmartHome/Interface/Bridge/tele/STATE:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }\
  /SmartHome/Interface/Bridge/stat/RESULT:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr MQTT2_RFBridge_C3AB1C setList \
  rfsend:textField /SmartHome/Interface/Bridge/cmnd/RFsend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}\
  rfcode:textField /SmartHome/Interface/Bridge/cmnd/RfCode $EVTPART1
deletereading -q MQTT2_RFBridge_C3AB1C (?!associatedWith).*
Das haut dir erst mal die unnötig langen Readings weg und erstellt ggf. dann neue, wenn was empfangen wird.
Weiter kannst du jetzt zum einen

Code Auswählen Erweitern


set MQTT2_RFBridge_C3AB1C rfsend <protocol> <bits> <data>
aus der Kommandozeile aufrufen, die Angaben zu <protocol>, <bits> und <data> musst du halt aus dem JSON jeweils rausfieseln, und zum anderen sollte auch RfCode direkt so gehen:

Code Auswählen Erweitern

set MQTT2_RFBridge_C3AB1C rfcode #144554

Wenn du von woanders her noch publishes ausführst, solltest du den cmnd-Zweig via ignoreRegexp am MQTT2_SERVER "ausschalten".

[KnutWuchtig]

Nabend,
sorry, dass ich nicht dem User mit dem großen KnowHow entspreche.

Ich beschäftige mich seit 2014 mit FHEM, habe sehr viel Zeit investiert und möchte einfach nur mein Haus steuern (Jalousien, Steckdosen, etc.)
Mit DOIFS, Timern, Wetterabhängig usw.

Die Ableitung von Readings über Events, Erstellung von "setlist-en" war bisher nicht mein Thema und ist m. E. für Laien wie mich sehr kryptisch.
(bin Maschinenbauer und kein IT-ler)
Deshalb ist solch ein Forum mitunter eine Hilfe, um Laien wie mir Codeschnipsel zu geben, die weiterhelfen.
Also erste einmal auf sachlicher Ebene klären, welches WISSEN hat der Anfragende?!

Zurück zu meiner Anfrage:

Vielen Dank für Deine fundierte Hilfe, Dein Setlist-Code hat mir geholfen, ich konnte die FM-Codes über die Bridge senden, der Aktor hat geschaltet.
Darauf kann ich aufbauen.

Also Problem von Dir gelöst.