Autor Thema: Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE  (Gelesen 26290 mal)

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1095
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #150 am: 10 Januar 2019, 11:03:48 »
Kann leider nichts dazu sagen. eventMap ist ja genau dafür da, warum das bei HM-Device nicht funktioniert müsste man in einem entsprechenden Forum-Zweig fragen.
Ansonsten könnte man das mit der Bridge mit hilfe von 'expression' (s. Commandref) schon bewerkstelligen. Auch wenn das nicht dafür gedacht war.

Danke, mit 'expression' geht was ich möchte. Deckt sich ja auch mit diesem thread.
Frage: Syntax MQTT_GENERIC_BRIDGE value-mapping
https://forum.fhem.de/index.php/topic,93188.msg857849.html#msg857849

mit state:topic=fhem/status/alarm/test_2 state:expression={($value eq 'off')?'stop':'on'} komme ich zum gewünschten Ergebnis!
EDIT: Wie kann ich hier noch das retain flag setzten? ist mir nicht gelungen.

Mit diesem publish
state:topic=fhem/status/alarm/test_2 state:retain=1 state:expression={($value eq 'off')?'stop':'on'}funktioniert auch retain! Super!!!

Billy
« Letzte Änderung: 10 Januar 2019, 15:05:31 von Billy »
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink 13x PCA 301;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 1x KFM100, 3x HM-LC-SW1-PL2, ESP8266, Sonoff, Mqtt*

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4540
    • tech_LogBuch
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #151 am: 10 Januar 2019, 21:10:03 »
Dein Problem scheint gelöst zu sein. Freut mich :)
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline christiantf

  • New Member
  • *
  • Beiträge: 7
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #152 am: 11 Januar 2019, 16:14:11 »
Ehrlich gesagt, halte ich so ein globales 'Setzen' für etwas gefählich, man kann sich damit schnell Sicherheitslücken 'einbauen'.

Den Sicherheitsaspekt kann ich nicht teilen - das ist genauso sicher/unsicher wie wenn ich den Status per HTTP setze. Ist halt nur ein anderes Protokoll, läuft genauso mit Authentifizierung usw.

Vielleicht kann mir trotzdem jemand weiterhelfen um ein Device einzeln zu setzen:

Per Eingabe würde ich die HS100 aktivieren mit:
set Kueche_HS100 on

Geben tut's on und off, und das würde ich per MQTT senden.

Wie würde dazu das mqttSubscribe aussehen?
attr lb_mosquitto mqttSubscribe state:stopic={"command/fhem/Kueche_HS100"} state:expression={Kueche_HS100=$value}
... hätte ich probiert, aber FHEM reagiert nicht darauf nicht.

Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.

lg, Christian
« Letzte Änderung: 11 Januar 2019, 16:21:45 von christiantf »

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1095
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #153 am: 11 Januar 2019, 16:26:41 »
Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.

lg, Christian

Kennst du das? --> Anwendungsfälle und Beispiele für MQTT_GENERIC_BRIDGE
https://forum.fhem.de/index.php/topic,91642.msg841368.html#msg841368
Vielleicht hilfts es dir!

@Hexenmeister --> Der Thread ist leider nur schwer zu finden. Die Idee mit eingängigen Beispielen hat mir schon öfters geholfen.
                              Du solltest vielleicht in der Überschrift "Anwendungsfälle und Beispiele für MQT_GENERIC_BRIDGE" das MQT in MQTT ändern. ;)
dann findet man das leichter.
« Letzte Änderung: 11 Januar 2019, 16:32:32 von Billy »
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink 13x PCA 301;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 1x KFM100, 3x HM-LC-SW1-PL2, ESP8266, Sonoff, Mqtt*

Offline christiantf

  • New Member
  • *
  • Beiträge: 7
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #154 am: 11 Januar 2019, 17:07:49 »
@Billy Jetzt kenn ich's ;-)

Jetzt hab ich
attr Kueche_HS100 mqttSubscribe state:stopic=command/fhem/Kueche_HS100
Sollte das richtig sein? Funktionieren tut's leider nicht. Sollte man im Log nicht irgendwas sehen, dass FHEM das Topic subscribed?
Es ist einfach so, als wäre die Zeile nicht da. Im MQTT-Spy sehe ich mein Publish mit mosquitto_pub an command/fhem/Kueche_HS100 = on, ich bekomme auch alle anderen Readings von der Generic_Bridge, aber meine Subscription wird ignoriert.

Vielleicht könnte jemand die konkrete Lösung posten. Wenn ich's einmal gesehen hab, versteh ich's hoffentlich! ;-)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7174
  • eigentlich eher user wie "developer"
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #155 am: 11 Januar 2019, 17:11:52 »
Mach mal noch testweise einen "/" vor das command.
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline christiantf

  • New Member
  • *
  • Beiträge: 7
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #156 am: 11 Januar 2019, 17:15:30 »
Mach mal noch testweise einen "/" vor das command.
Unüblich, und funktioniert leider auch nicht - hab's in allen Kombinationen durchprobiert (mit/ohne / in FHEM, und mit/ohne / im mosquitto_pub).
Müsste ich das Subscribe des Topics im Log sehen?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7174
  • eigentlich eher user wie "developer"
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #157 am: 11 Januar 2019, 17:29:35 »
Unüblich, [...]
:) Dachte ich auch, aber bei meinen (leider auch - aus anderen Gründen) erfolglosen Tests (mit MQTT2_SERVER) hatte ich wenigstens mit mosquitto_sub den Eindruck, dass das "einen Client mehr" erzeugt, und auch die Beispiele in der cref haben oft ein "einleitendes "/".

@hexenmeister:
Hat es einen Grund, dass das in dem eher unüblichen Format in der commandref steht bzw. sollte man irgendwie erläutern, wann man das warum benötigt?
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Dersch

  • Full Member
  • ***
  • Beiträge: 396
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #158 am: 11 Januar 2019, 17:51:54 »
Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1095
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #159 am: 11 Januar 2019, 18:25:02 »
Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.

Das war für mich zuerst auch ungewöhnlich.

Die MQTT_GENERIC_BRIDGE versorgt bestehende Devices mit MQTT Attributen. Wo es kein Device gibt, musst du ein Dummy definieren und an der
MQTT_GENERIC_BRIDGE anmelden.
Vorteil du hast bei allen Devices das gleiche Umfeld und bekommst mit get mqttGeneric devinfo alle Mqtt Devices in einer Übersicht.

Übrigens ist ein MQTT_DEVICE nichts anderes als ein Dummy mit mqtt Attributen.

Hoffe das hilft.
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink 13x PCA 301;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 1x KFM100, 3x HM-LC-SW1-PL2, ESP8266, Sonoff, Mqtt*

Offline Dersch

  • Full Member
  • ***
  • Beiträge: 396
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #160 am: 11 Januar 2019, 18:29:11 »
Ah ok vielen Dank ! Dann tüftel ich mal weiter um es endlich komplett zu verstehen und Fhem2fhem ersetze :)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7174
  • eigentlich eher user wie "developer"
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #161 am: 11 Januar 2019, 18:42:45 »
Ich finde es immer noch ungewöhnlich.

@hexenmeister: Sollte man nicht neuerdings empfehlen, alles, was nicht in FHEM direkt als Gerät über ein anderes Modul vorhanden ist (CUL_HM usw.) als MQTT2_DEVICE anzulegen?

Hintergrund: Man braucht "irgendwas" dafür, und nach meiner bisherigen Erfahrung gehört MQTT2_DEVICE zu den Geräten, die am einfachsten optisch ansprechend zu konfigurieren sind.

Man braucht halt (ggf. zusätzlich) ein MQTT2-IO (Client, wenn man weiter mosquitto/ext. Broker im Einsatz hat)....
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1095
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #162 am: 11 Januar 2019, 19:09:55 »
Zitat Hexenmeister am: 16 November 2018 hier:
https://forum.fhem.de/index.php/topic,91984.msg859281/topicseen.html#msg859281

Zitat
Ich sehe eigentlich keine Notwendigkeit sowohl die Bridge als auch MQTT2_DEVICE gleichzeitig zu verwenden.
Bridge kann ja das andere komplett ersetzen und auch vice-versa. Die Frage ist nur, wie man es haben möchte.

Hat sich da was verändert? Bei mir deckt die Bridge eigentlich alles ab.
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink 13x PCA 301;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 1x KFM100, 3x HM-LC-SW1-PL2, ESP8266, Sonoff, Mqtt*

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7174
  • eigentlich eher user wie "developer"
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #163 am: 11 Januar 2019, 20:24:21 »
Zum Hintergrund nochmal:
Im Kern ist das Protokoll sehr simpel, alle Lösungen funktionieren irgendwie, die Mischung MQTT2-IO+Gen.-Bridge ist noch etwas hakelig, aber das dürfte eine Frage der Zeit sein.

Wer heute in MQTT einsteigt, sollte (und das ist wohl auch hexenmeisters heutige Tendenz, anders als evtl. noch vor ein paar Wochen) nativ MQTT sprechendes Zeug mit einem MQTT2-IO in FHEM einbinden und MQTT2_DEVICE nutzen. Das ist schlicht und ergreifend für Neulinge am einfachsten zu konfigurieren (funktional und optisch), JSON ist kein Thema und auch die Sendeseite ist da sehr flexibel, was das Basteln nahezu beliebiger Formate angeht.

Die "Lücke" dabei ist die "ver-MQTT-ung" von Nicht-MQTT-Devices. Das kann die Bridge am universellsten, nur eben mit der Einschränkung, dass die nicht zusammen mit autocreate an einem MQTT2-IO genutzt werden kann.
Im Moment ist das die einzige Einschränkung, es dürfte aber auch nur eine Frage der Zeit sein, bis diese behoben ist.

Es gibt aber weder einen Grund, irgendwas umzubauen, schon gleich nicht, wenn man _irgendeinen_ Weg verstanden hat, wie man zu einem bestimmten Ergebnis kommt. Und auch die Aussage ist ok, dass man mit den alten Wegen (fast) alles abdecken kann.

Wer allerdings irgendwann Verschlüsselung will, braucht dann ein MQTT2-IO (es sei denn, das kommt irgendwann auch bei MQTT(1), was ich aber ehrlich gesagt im Moment nicht glaube).
Server: HP-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline christiantf

  • New Member
  • *
  • Beiträge: 7
Antw:Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE
« Antwort #164 am: 12 Januar 2019, 12:58:10 »
Ich hab's jetzt mit Telnet gemacht.
mqttSubscribe funktioniert bei mir nicht, oder die Beispiele (genau genommen Syntaxangaben) sind zu unklar, um das korrekt einzurichten.
Es gibt im Forum leider auch kein Beispiel, wo jemand mqttSubscribe mit einem konkreten Device erfolgreich gemacht hat.
« Letzte Änderung: 12 Januar 2019, 13:06:32 von christiantf »

 

decade-submarginal