Modul-Vorstellung: MQTT_GENERIC_BRIDGE

Begonnen von hexenmeister, 31 August 2018, 20:53:56

Vorheriges Thema - Nächstes Thema

Billy

#30
Zitat von: hexenmeister am 06 September 2018, 10:54:32
@Billy
Es funktionier also auch mit der Version aus heutigem Update auch nicht? Wie sieht die Konfiguration für deine Helligkeitswerte aus?

Nein, es funktioniert mit der Version aus heutigem Update nicht!

Ich hatte einfach die Bridge auf meinem Produktiv System mit einem Homematic Motion/Helligkeitssensor verbunden und

diese attr aktiviert
attr BM_1A8215 mqttDefaults base={"/$device/$name"}
attr BM_1A8215 mqttPublish attr sensor mqttPublish brightness:topic={$base} motion:topic={$base}


Die Werte wurden dann bis zum gestrigen update auch gesendet.
Habe jetzt aber die MQTT_GENERIC_BRIDGE  auf meinem Produktivstem gelöscht, mein attr global userattr bereinigt und die
10_MQTT_BRIDGE.pm wieder aktiviert. Jetzt sendet der Sensor wieder Helligkeits und Motion Werte über Mqtt an den Brooker.

Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

inesa394

Das ist meine Bridge
Internals:
   DEF        TYPE=TASMOTA_DEVICE,TYPE=XiaomiSmartHome,TYPE=XiaomiSmartHome_Device,TYPE=YeeLight,TYPE=dummy,TYPE=MilightDevice,TYPE=MilightBridge,TYPE=WifiLight
   IODev      mqtt
   NAME       mqttGeneric
   NR         179
   NTFY_ORDER 50-mqttGeneric
   STATE      outgoing publish sent
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     TYPE=TASMOTA_DEVICE,TYPE=XiaomiSmartHome,TYPE=XiaomiSmartHome_Device,TYPE=YeeLight,TYPE=dummy,TYPE=MilightDevice,TYPE=MilightBridge,TYPE=WifiLight
   READINGS:
     2018-09-06 09:27:42   device-count    0
     2018-09-06 09:27:39   incoming-count  0
     2018-09-06 09:27:39   outgoing-count  0
     2018-09-06 09:26:59   transmission-state outgoing publish sent
     2018-09-06 09:27:39   updated-reading-count 0
     2018-09-06 09:27:39   updated-set-count 0
   devices:
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     FHEMWEB    *
     Global     *
     MQTT       transmission-state
     MQTT_BRIDGE transmission-state
     MQTT_DEVICE transmission-state
     MQTT_GENERIC_BRIDGE *
     telnet     *
   message_ids:
   subscribe:
   subscribeExpr:
   subscribeQos:
Attributes:
   IODev      mqtt
   icon       mqtt
   room       MQTT
   stateFormat transmission-state

version 0.9.5
Dann hab ich wohl die funktionweise deines Moduls falsch interpretiert. Wollte über mein lokales lan
like fhem2fhem mein licht schalten mit hilfe deiner Bridge. Dazu habe ich dieses mqtt-device auf meinen
entfernten fhem Server definiert ???. Hat ja irgenwie auch alles funktioniert bis ich dein Modul geupdatet
hatte.Na ja dann muss wohl erst mal bei der kombination Mqtt-Device Mqtt-Bridge bleiben.


hexenmeister

Problem gefunden, Lösung noch nicht.
Nach einem Restart geht nichts. Definiert man die Bridge im laufendem Betrieb, oder disconnected man kurz die MQTT-Instanz mit anschliessendem connect, geht wieder alles. Irgendwo habe ich da ein Problem in der Initialisierung eingebaut. Ich gehe malk auf die Suche...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Zitat von: hexenmeister am 07 September 2018, 20:52:05
Problem gefunden, Lösung noch nicht.
Ich gehe mal auf die Suche...

Lass dir Zeit. Eine Frage hätte ich noch.
Ich würde wenn es wieder läuft MQTT_GENERIC_BRIDGE nur für die Anbindung bestehender FHEM-Devices
benutzen in Verbindung mit Mqtt-Device für Anbindung externer MQTT Quellen. (Wie Sonoff etc.)
Das müsste doch problemlos gehen?
Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

SamNitro

Gibt es hier schon was neues? Rudi plant ein FHEM 5.9 Release.

Da hier eine Version eingecheckt ist die nicht richtig läuft wollte ich mal nachfragen..

Gruß Patrick
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

hexenmeister

Habe gerade eine Version eingecheckt, die bei mir ganz gut läuft. Kann gern getestet werden ;)
Im Anhang für alle Fälle nochmal.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

SamNitro

(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

hexenmeister

Sehr gut! Jetzt muss ich nur noch keine Fehler mehr einbauen, bei den Restarbeiten, die ich noch machen will ;D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

aisberg

#38
funktioniert bei mir leider nicht.
Das habe ich eingegeben (korrigiert):
defmod  mqttGeneric MQTT_GENERIC_BRIDGE mqtt licht_aussen,licht_kueche,licht_terrasse,BewegungT,BewegungV
attr mqttGeneric IODev myBroker


myBroker ist so definiert:
define myBroker MQTT 127.0.0.1:1883
attr myBroker room Kommunikation,MQTT


Wenn ich im mqttGeneric die devinfo oder devlist aufrufe, bekomme ich nur: "no devices found"
Wo ist jetzt mein Denkfehler? Muss das in den Geräten erst noch jeweils aktiviert werden?

ergerd

Hallo aisberg

hier meine Difiniton bei einem Device:


attr denise_hms100tf mqttPublish *:topic={"/SmartHome/$device/$reading"}


Grüße
Rainer
FHEM auf RasPi 4, CUNO, ZigBee, 1Wire2WLAN, DS2423, C-Control II, Buderus KM200, LaCrosseGateway, PCA301, ConBee II, LuftdatenInfo, OneWireGW, Div. ESPs u. Shellys

aisberg

ah, dann habe ich es jetzt verstanden, ich stelle das dann bei den jeweiligen Geräten ein!
Teste ich gleich mal.

aisberg

Ich bin ja voll begeistert!!!! Das funktioniert ja wie am Schnürchen! Perfekt!
Vielen Dank.

aisberg

eine dumme Anfänger-Frage habe ich nun aber doch noch:
Es war ein Denkfehler von mir, ein Reading meiner Schalter zu ändern, denn dadurch werden die Schalter nicht geschaltet. Ich denke, die Schalter benötigen ein explizites set on oder set off oder alternativ set toogle. Wie mache ich das über MQTT?
Also das hier ist falsch:
attr licht_aussen mqttSubscribe *:topic={"/SmartHome/$device/$reading/value"}
denn dann wird ja nur das Reading geändert, ohne dass sich der Homematic-Schalter wirklich ändert.

ergerd

Ich habe in kleines Problem:

Mein Dymmy-Device:

defmod tempGefrierschrank dummy
attr tempGefrierschrank userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
attr tempGefrierschrank genericDeviceType thermometer
attr tempGefrierschrank mqttSubscribe state:topic={"/Esp1wire@14211345/28.ff9b3b811402.f1/Temperature"}


Im Log steht:

2018.09.16 18:42:36 1: PERL WARNING: Possible unintended interpolation of @14211345 in string at (eval 19888) line 1.


Offensichtlich gibt es eine Unschärfe wenn ein Ampersand im Topic verwendet wird. Kann ich das selbst korrigieren ohne meine Esp's neu flashen  zu müssen?

Hinweis: Wenn ich das Device als MQTT_DEVICE definiere funktioniert alles klaglos.

Grüße
Rainer
FHEM auf RasPi 4, CUNO, ZigBee, 1Wire2WLAN, DS2423, C-Control II, Buderus KM200, LaCrosseGateway, PCA301, ConBee II, LuftdatenInfo, OneWireGW, Div. ESPs u. Shellys

SamNitro

Zitat von: aisberg am 16 September 2018, 18:55:45
...
attr licht_aussen mqttSubscribe *:topic={"/SmartHome/$device/$reading/value"}
denn dann wird ja nur das Reading geändert, ohne dass sich der Homematic-Schalter wirklich ändert.

versuche mal:
attr licht_aussen mqttSubscribe *:stopic={"/SmartHome/$device/$reading/value"}
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)