Anwendungsfälle und Beispiele für MQTT_GENERIC_BRIDGE

Begonnen von hexenmeister, 01 Oktober 2018, 10:57:38

Vorheriges Thema - Nächstes Thema

hexenmeister

Ich habe eine ähnliche Definition

defmod OG_BZ_TT01_Clima CUL_HM xxx
attr OG_BZ_TT01_Clima alias HKThermostat: Bad
attr OG_BZ_TT01_Clima group Klima
attr OG_BZ_TT01_Clima icon hm-cc-rt-dn
attr OG_BZ_TT01_Clima model HM-CC-RT-DN
attr OG_BZ_TT01_Clima mqttDefaults base={"$base/og/bz"}
attr OG_BZ_TT01_Clima mqttPublish measured-temp|desired-temp|ValvePosition|controlMode:topic={"$base/klima/$name"}
attr OG_BZ_TT01_Clima mqttSubscribe desired-temp|controlMode:stopic={"$base/klima/$reading/set"}
attr OG_BZ_TT01_Clima peerIDs 00000000,
attr OG_BZ_TT01_Clima room Badezimmer


Damit $base in mqttDefaults funktioniert, muss diese in der Bridge selbst definiert werden:
globalDefaults base=ha

Damit entstehen folgende pub/subscriptions (Befehl an der Bridge: get devinfo):
OG_BZ_TT01_Clima
  publish:
    ValvePosition    => ha/og/bz/klima/ValvePosition (mode: R; qos: 0)
    controlMode      => ha/og/bz/klima/controlMode (mode: R; qos: 0)
    desired-temp     => ha/og/bz/klima/desired-temp (mode: R; qos: 0)
    measured-temp    => ha/og/bz/klima/measured-temp (mode: R; qos: 0)
  subscribe:
    controlMode      <= ha/og/bz/klima/+/set (mode: S)
    desired-temp     <= ha/og/bz/klima/+/set (mode: S)


Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

desmoloch

Zitat von: hexenmeister am 27 Januar 2019, 10:27:24
Ich habe eine ähnliche Definition

defmod OG_BZ_TT01_Clima CUL_HM xxx
attr OG_BZ_TT01_Clima alias HKThermostat: Bad
attr OG_BZ_TT01_Clima group Klima
attr OG_BZ_TT01_Clima icon hm-cc-rt-dn
attr OG_BZ_TT01_Clima model HM-CC-RT-DN
attr OG_BZ_TT01_Clima mqttDefaults base={"$base/og/bz"}
attr OG_BZ_TT01_Clima mqttPublish measured-temp|desired-temp|ValvePosition|controlMode:topic={"$base/klima/$name"}
attr OG_BZ_TT01_Clima mqttSubscribe desired-temp|controlMode:stopic={"$base/klima/$reading/set"}
attr OG_BZ_TT01_Clima peerIDs 00000000,
attr OG_BZ_TT01_Clima room Badezimmer


Damit $base in mqttDefaults funktioniert, muss diese in der Bridge selbst definiert werden:
globalDefaults base=ha

Damit entstehen folgende pub/subscriptions (Befehl an der Bridge: get devinfo):
OG_BZ_TT01_Clima
  publish:
    ValvePosition    => ha/og/bz/klima/ValvePosition (mode: R; qos: 0)
    controlMode      => ha/og/bz/klima/controlMode (mode: R; qos: 0)
    desired-temp     => ha/og/bz/klima/desired-temp (mode: R; qos: 0)
    measured-temp    => ha/og/bz/klima/measured-temp (mode: R; qos: 0)
  subscribe:
    controlMode      <= ha/og/bz/klima/+/set (mode: S)
    desired-temp     <= ha/og/bz/klima/+/set (mode: S)


also ich hab jetzt hier eine Stunde probiert warum das subscribe bei mir nicht klappt.
Folgendes habe ich probiert:
mqttSubscribe desired-temp|controlMode:stopic={"$base/klima/$reading/set"}
und
mqttSubscribe desired-temp:stopic={"$base/klima/solltemp/set"}

Ich kann einfach keine Temp einstellen...
Aber hiermit klappt es:
mqttSubscribe desired-temp:stopic={"$base/klima/temperature/set"}
Warum um alles in der Welt klappt es nur mit "temperature"?!

Ich hau mich jetzt hin...

hexenmeister

Gute Frage, bei mit hat mit deiner Einstllung funktioniert. Vlt. ein Tippfehler irgendwo?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

desmoloch

Zitat von: hexenmeister am 01 Februar 2019, 17:42:26
Gute Frage, bei mit hat mit deiner Einstllung funktioniert. Vlt. ein Tippfehler irgendwo?

Ich verstehe die Welt nicht...ich habe die Einstellungen gestern aus fhem ins Forum kopiert. Es ging nicht. Nun nochmal zurückkopiert und nun geht's. Keine Ahnung was das soll, aber nun geht's ja :)
Danke!

tomleitner

#19
Hallo und Danke für MQTT_GENERIC_BRIGE -- geniale Idee.

Mein Anwendungsfall wäre: Einzelne Sensoren an MQTT publishen sowie einzelne Schalter ebenso publishen und beim setzen des "state" werts über MQTT entsprechend reagieren.  Dazu hätte ich die Bridge wie folgt definiert:

define MQTT_BRIDGE MQTT_GENERIC_BRIDGE fhem room=MQTT_BRIDGE_DEVICES
attr MQTT_BRIDGE IODev MQTT2_Server
attr MQTT_BRIDGE globalPublish *:topic={"fhem/$device/$reading"}
attr MQTT_BRIDGE mqttSubscribe *:topic={"fhem/$device/$reading"}
attr MQTT_BRIDGE
attr MQTT_BRIDGE room MQTT
attr MQTT_BRIDGE stateFormat dev: device-count in: incoming-count out: outgoing-count


Alle Devices die ich monitoren will sind im Raum MQTT_BRIDGE_DEVICES. Ebenso die Schalter.

Ach ja: Mein IODEV ist ein MQTT2_CLIENT (heißt hier, mißverständlicherweise MQTT2_Server).

Die Probleme/Auffälligkeiten:

a.) Das reading "device-count" bleibt immer auf 0 obwohl incoming-count und outgoing-count brav hinauf zählen und es funktioniert auch!
b.) Aber das Hauptproblem ist -- ich kann nicht subscriben:

MQTT_BRIDGE: unknown attribute mqttSubscribe. Type 'attr MQTT_BRIDGE ?' for a detailed list. Usage: attr [-a|-r] [] where is a single device name, a list separated by comma (,) or a regexp. See the devspec section in the commandref.html for details.

Das Attribut "mqttSubscribe" existiert gar nicht??

Nicht einmal die Fehlermeldung stimmt, wenn ich

fhem> attr MQTT_BRIDGE ?

eingebe kommt:

fhem> attr MQTT_BRIDGE ?
MQTT_BRIDGE: unknown attribute ?, choose one of alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 IODev globalDefaults:textField-long globalAlias:textField-long globalPublish:textField-long globalTypeExclude:textField-long globalDeviceExclude:textField-long disable:1,0 debug:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading DbLogExclude DbLogInclude cmdIcon devStateIcon devStateIcon:textField-long devStateStyle fhem_widget_channels fm_fav fm_groups fm_name fm_order fm_type fm_view genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon siriName sortby webCmd webCmdLabel:textField-long widgetOverride userattr


Bin um jeden Hinweis dankbar.

Ciao // Tom

hexenmeister

Die Erklärung ist einfach.

a) beim device-count werden nur Geräte gezählt, die mit eigenen mqtt*-Attributen versehen sind. Bei einer globalen Definition 'globalPublish' kann die Bridge nicht (ohne weiteres) wissen, welche Geräte angesprochen werden sollen. Daher wird auch nichts gezählt.

b) mqttSubscribe ist gedach für diejenigen Geräte, die per MQTT 'versorgt' werden sollen. Die Bridge selbst gehört nicht dazu. Aus technischen Gründen kann es sein, dass diese Attribute trotzdem vom FHEM angeboten werden, gesetzt werden können sie jedoch nicht, die Bridge  'währt' sich dagegen.
Ein 'globalSubscribe' gibt es nicht. Ich habe mich entschieden, diese Festure nicht anzubieten. Bei unbedachten Verwendung könnte ein großes Sicherheitsrisiko entstehen. Einfach diese Attribute an den gewünschgten Devices erstellen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

tomleitner

Danke, Dir -- klingt logisch.

Allerdings wird das Attribut mqttSubscribe nicht bei meinen Devices angeboten, nicht im User-Interface aber auch nicht wenn ich es im fhem.cfg einbaue:
RotLicht: unknown attribute mqttSubscribe. Type 'attr RotLicht ?' for a detailed list.

RotLicht ist ein ZWave Schalter bei mir ...

Und ja: Ich habe die aktuellste Software Version laufen ....

Was kann dafür der Grund sein?

Danke.




tomleitner

#22
.... noch ein komisches Problem.  Nach einem FHEM restart mit "shutdown restart" funktioniert die Bridge nicht. Es kommen meldungen rein
aber es geht nichts hinaus. Erst wenn ich im Web Interface auf "DEF" klicke, dort die Definition:

fhem room=MQTT_BRIDGE_DEVICES

nochmal bestätige und "modify MQTT_BRIDGE" klicke ... dann geht es plötzlich??

Ideen dazu?

Danke.

hexenmeister

ZitatWas kann dafür der Grund sein?
Könnte das übliche 'NichtGeleseneDokumentation' sein ;D
Die Definition lautet 'fhem room=MQTT_BRIDGE_DEVICES'. Der erste Parameter (wie im Commandref steht) ist der Prefix für die Optionsattribute. Ist für Sonderfälle gedacht, wenn mehr als eine Bridge im System vorhanen ist. Deine Parameter heißen also 'fhemSubscribe' etc.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zitat von: tomleitner am 03 Februar 2019, 22:01:29
.... noch ein komisches Problem.  Nach einem FHEM restart mit "shutdown restart" funktioniert die Bridge nicht. Es kommen meldungen rein
aber es geht nichts hinaus. Erst wenn ich im Web Interface auf "DEF" klicke, dort die Definition:

fhem room=MQTT_BRIDGE_DEVICES

nochmal bestätige und "modify MQTT_BRIDGE" klicke ... dann geht es plötzlich??
Ist wohl ein Bug.
Die Unterstützung von MQTT2*-Geräten ist noch recht jung. Die Bridge ist auf MQTT als DevIO optimiert. Ist wohl ein Bug, nachzustellen klappt bei mir jedoch nicht. Möglicherweise meldet sich die Bridge zu früh für DevIO. Ich muss probieren, ob es hilft, wenn die Bridge wartet, bis IO 'connected' ist.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

tomleitner

Danke. Mit dem fhemSubscribe funktioniert es nun. An sich habe ich die Doku gelesen, aber das war mir nicht so bewusst.

Wegen dem Bug: bei mir ist es reproduzierbar Immer so. Der Fehler tritt immer auf. Was ich bemerke ist dass bei Klick auf "modify MQTT_Bridge" im log file ein disconnect und reconnect auf den MQTT Server erfolgt. Offenbar ist er nach einem restart gar nicht richtig connected ?

Tom

hexenmeister

Zitat von: tomleitner am 04 Februar 2019, 07:51:34
Wegen dem Bug: bei mir ist es reproduzierbar Immer so. Der Fehler tritt immer auf. Was ich bemerke ist dass bei Klick auf "modify MQTT_Bridge" im log file ein disconnect und reconnect auf den MQTT Server erfolgt.
Das ist bei MQTT2*-Module so gewollt. Beim Anmelden von subscriptions wird ein reconnect durchgeführt.

Zitat von: tomleitner am 04 Februar 2019, 07:51:34
Offenbar ist er nach einem restart gar nicht richtig connected ?
Gute Frage, sollte nicht so sein. Schau doch mal nach dem Start das state von dem IO-Device an.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

tomleitner

Bin nun draufgekommen das dieses fehlerhafte Verhalten (Bridge geht nicht nach restart so lange bis man im User Interface DEF und "modify" geklickt hat)  nur dann auftritt wenn device-count = 0 ist.  Nun hab ich ein Device mit einem "fhemSubscribe" Attribut ausgestattet ... und nun lebt die Bridge auch nach einem Restart.

Ich denke das ist trotzdem ein Bug weil es mag ja Anwendungen geben wo jemand über die Bridge nur Dinge publishen will und nichts subscriben will ....

Danke.

hexenmeister

Auch fürs publishen gibt es Attribute für die einzelnen Geräte. Die globalPublish war eigentlich nicht für alleinigen Einsatz gedacht. Eher eine nicht ausgebaute Test-Methode.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

tomleitner

Oh ... aber mit globalPublish ist es wohl am einfachsten!

Heißt das, dass globalPublish wieder verschwinden kann und nicht supported ist?