Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

Begonnen von Master_Nick, 11 Oktober 2018, 17:23:24

Vorheriges Thema - Nächstes Thema

frankreed

Nee, geht nicht. Ich habe mqtt2fhem/guestwlan/state/set off abgesetzt, aber das Ding reagiert nicht..... :-(

OdfFhem

@frankreed

Das Problem ist im Zweifel recht schwierig einzukreisen. Du müsstest einmal ermitteln, wo Deine MQTT-Nachricht verschwindet:
- Hast Du mosquitto_sub, o.ä. zum Prüfen verwendet, um festzustellen, welche Nachricht vom  MQTT-Server tatsächlich versendet wird ...
- Ist Dein FHEM-MQTT-Client (MQTT oder MQTT2) richtig konfiguriert ...
- Ist die MQTT_GENERIC-BRIDGE richtig konfiguriert (Ist der Wert vom Reading incoming-count > 0) ...


frankreed

Ich schau' morgen nochmal nach. Bett ruft bzw. Wecker um 04:15 Uhr...

OdfFhem

@frankreed

Im Zusammenhang mit MQTT2 ist mir übrigens noch aufgefallen, dass u.U. nach einer Änderung der MQTT_GENERIC_BRIDGE-Definition ein FHEM-Neustart notwendig war ...

hexenmeister

Die Klammern mit Anführungszeichen sind nur notwendig, wenn Topic als Expression bejandelt werden soll, z.B. wenn Variablen enthalten sind.
Auf den ersten Blick sehe ich den Fehler nicht. Kann leider auch nicht nachstellen, umzugsbegingt habe ich gerade keine Server am Laufen.
GenericBridge kann Informationen zu den angemeldeten Geräte anzeigen. Setze mal "get devinfo" an der Bridge ab, da sollte dein Device auftauchen und die subscribe-Topic angezeigt werden.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

frankreed

Hallo,

jetzt funktioniert es. Ich habe mir mit Hilfe der Awendungsbeispiele "Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten" einen Dummy Switch angelegt und die Topics daraus 1:1 sowohl in den Gast-Wlan-Schalter als auch in den Dummy kopiert (zum Testen ist das ja egal)

Sowohl über den Dummy als auch über NodeRed kann ich jetzt schalten.
Da muss was mit meinen subscribe/publish-Topics nicht gestimmt haben.

Problem ist also gelöst.
Danke an alle

Grml

Hi zusammen,
ich habe aktuell das Problem, dass in einem Dummy-Device nicht alle Werte per MQTT published werden.

Das Dummy-Device bekommt per Notify zwei zusätzliche Readings (lastset, lastunset) per setreading angepappt. state habe ich außerdem. Klar, ist standard.
Wenn sich der state ändert springt (je nachdem) eins von zwei Notifys an, macht das setreading (erstellt bzw. updated das reading) und schreibt darin die aktuelle Uhrzeit + Datum. Das funktioniert soweit auch. Auch sehe ich im Event-Monitor einen entsprechenden Eintrag.

Und genau diesen Inhalt (Datum + Zeit) möchte ich per MQTT rausschicken um ihn in Node Red weiter zu bearbeiten bzw. darzustellen.

Aber egal was ich mache, state wird gepublished, die beiden setreadings "lastset" und "lastunset" kommen nicht raus.
Ich habe mir auch schon alle Topics in MQTT.fx per "#" aboniert. Aber selbst da kommen die beiden readings "lastset" und "lastunset" nicht mit. Die werden also definitiv nicht published. Aber warum? Fehler von mir oder ein Bug? statt $name habe ich auch schon $reading versucht ohne damit mehr Erfolg zu haben.

Internals:
   FUUID      5c4adb72-f33f-b8cb-e949-c81481837a34c5c0
   NAME       Alarmanlage.Status
   NR         92
   STATE      Unscharf
   TYPE       dummy
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1556142356.28454
           VALUE      Unscharf
   READINGS:
     2019-04-24 23:45:16   lastset         2019-04-24 23:45:16
     2019-04-24 23:45:56   lastunset       2019-04-24 23:45:56
     2019-04-24 23:45:56   state           Unscharf
Attributes:
   DbLogExclude .*
   DbLogInclude state
   devStateIcon Scharf:secur_locked@red Unscharf:secur_open@grey Warten:hourglass@orange
   icon       building_security
   mqttPublish *:topic={"$base/Alarmanlage/$device/$name"}
   room       Alarm,Eingang


hexenmeister

Kann gerade nicht ausprobieren, habe keine Testumgebung. Möglicherweise schlägt der Schutz von Endlos-Loops zu.
Probiere das Attribut mqttForward auf all zu setzen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Grml


D3ltorohd

Ich würde mich hier mal mit anhängen. Ich hatte mir den Hauptthread mal ein wenig durchgelesen aber so wirklich kapiert was ich machen muss hab ich nicht, liegt da dran das ich Smarthome Einsteiger bin und dazu dann auch noch FHEM Neuling. Folgendes möchte ich gerne tun und denke das die MQTT Generic Bridge das richtige dafür ist.

Aktuelles Szenario ::

FHEM <-> Signalduino Stick <-> Jarolift Modul -> Jarolift Rollos.

Soweit läuft alles, eingerichtet, angelernt und die Rollos lassen sich in Fhem wunderbar steuern. So mein Problem was ich jetzt habe, ich hatte mich davor ein wenig in OpenHab eingearbeitet und die Rollos mit einem anderen Gateway gesteuert, da ich damit nicht zufrieden bin und das neue Gateway viel stabiler läuft dies aber leider nur für FHEM gibt, würde ich das gerne weiterhin per OH steuern mit einer MQTT Bridge über FHEM.

Da ich in OH soweit schon alles eingerichtet habe wie Räume, Astro Funktion, Random runter fahrende Rollos usw und ich mich dort wenigstens schon ein wenig auskenne, würde ich dies gerne als Steuerzentrale weiter nutzen.

Nun bräuchte ich hier vllt mal Hilfe an einem konkreten Beispiel meiner Komponenten, wie ich das ganze miteinander verbinde. Leider komm ich hierbei überhaupt nicht klar. Würde mir da jemand helfen und ich würde einen Rollo erfolgreich durchreichen können, würde ich den Rest selber hinbekommen.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

D3ltorohd

Das ganze sieht wie folgt aus. @hexenmeister

In FHEM habe ich die MQTT Verbindung hergestellt. Siehe Screen 1

So dann habe ich eine Bridge zu einem FHEM Device eingerichtet, aber ich glaube hier stimmt schon was nicht oder ? Unter State habe ich nur ???
Siehe Screen 2

Ich kann das ganz auch nicht über z.b. MQTT fx ansteuern, was es aber machen sollte :
Dort habe ich unter published Jaro_FB/Set eingegeben und im Fenster darunter down 1. So sollte der Rollo eigentlich fahren, passieren tut nichts.

In der FHEM Config sieht es so aus.

# MQTT Brdige zu OpenHab
define openhab MQTT 127.0.0.1:1883
setuuid openhab 5ccb0b33-f33f-fc62-2405-25098b868b494548
define MQTT_Jarolift MQTT_BRIDGE Jaro_FB
setuuid MQTT_Jarolift 5ccca400-f33f-fc62-b91c-3511e543a7d05148
attr MQTT_Jarolift IODev openhab
attr MQTT_Jarolift publishReading_LastAction_Channel_01 /Jaro_FB/LastAction_Channel_01
attr MQTT_Jarolift publishReading_LastAction_Channel_02 /Jaro_FB/LastAction_Channel_02
attr MQTT_Jarolift publishReading_LastAction_Channel_03 /Jaro_FB/LastAction_Channel_03
attr MQTT_Jarolift publishReading_LastAction_Channel_04 /Jaro_FB/LastAction_Channel_04
attr MQTT_Jarolift publishReading_LastAction_Channel_05 /Jaro_FB/LastAction_Channel_05
attr MQTT_Jarolift publishReading_LastAction_Channel_06 /Jaro_FB/LastAction_Channel_06
attr MQTT_Jarolift publishReading_LastAction_Channel_07 /Jaro_FB/LastAction_Channel_07
attr MQTT_Jarolift publishReading_LastAction_Channel_08 /Jaro_FB/LastAction_Channel_08
attr MQTT_Jarolift publishReading_LastAction_Channel_09 /Jaro_FB/LastAction_Channel_09
attr MQTT_Jarolift publishReading_LastAction_Channel_10 /Jaro_FB/LastAction_Channel_10
attr MQTT_Jarolift publishReading_LastAction_Channel_11 /Jaro_FB/LastAction_Channel_11
attr MQTT_Jarolift publishReading_LastAction_Channel_12 /Jaro_FB/LastAction_Channel_12
attr MQTT_Jarolift publishReading_button /Jaro_FB/button
attr MQTT_Jarolift publishReading_channel /Jaro_FB/channel
attr MQTT_Jarolift publishReading_channel_control /Jaro_FB/channel_control
attr MQTT_Jarolift publishReading_counter_receive /Jaro_FB/counter_receive
attr MQTT_Jarolift publishReading_counter_send /Jaro_FB/counter_send
attr MQTT_Jarolift publishReading_last_digits /Jaro_FB/last_digits
attr MQTT_Jarolift publishReading_serial_receive /Jaro_FB/serial_receive
attr MQTT_Jarolift publishReading_state /Jaro_FB/state
attr MQTT_Jarolift publishReading_user_info /Jaro_FB/user_info
attr MQTT_Jarolift publishReading_user_modus /Jaro_FB/user_modus
attr MQTT_Jarolift publishState 1
attr MQTT_Jarolift subscribeSet Jaro_FB/set


Irgendwo mache ich was falsch, ich weiß aber momentan leider nicht wo. Ich denke irgendwas mit dem Bridge Device

Im letzten Screen noch das Device an sich zu sehen, mit was man die Rollos steuert.



Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

OdfFhem

Kennst Du folgenden Beitrag https://forum.fhem.de/index.php/topic,91642.0.html?

In Deinen Ausführungen verwendest Du übrigens MQTT_BRIDGE und nicht MQTT_GENERIC_BRIDGE.

D3ltorohd

Shit, das ist dann wieder zweierlei. Was ist da der Unterschied und reicht die normale auch?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

OdfFhem

MQTT_BRIDGE kenne ich nicht - bin mir auch nicht sicher, ob die noch wirklich unterstützt wird.

Ich nutze MQTT_GENERIC_BRIDGE, um "normale" FHEM-Geräte (z.B. HUE-Lampen, Homematic-Thermostate) MQTT-fähig zu machen.

Beta-User

M.E. sollte man IMMER die Generic-Bridge nehmen, wenn man in das Thema einsteigt. Einmal verstanden, kann man beliebig viele Devices "vermqtten", und die erforderlichen Attribute sind überall verfügbar.
(Die Einzel-Bridge sollte eigentlich nach Contrib, just my2ct...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files