MQTT_GENERIC_BRIDGE und subscribe

Begonnen von user1, 24 November 2021, 21:31:25

Vorheriges Thema - Nächstes Thema

user1

In meiner FHEM-Config habe ich eine MQTT_GENERIC_BRIDGE:

(und ja, ich weiss, es steht MQQT-bridge beim Raum, aber wenigstens konsequent ;) )


defmod mqqtClient MQTT2_CLIENT 127.0.0.1:1883
attr mqqtClient clientId fhem
att r mqqtClient keepaliveTimeout 60
attr mqqtClient msgAfterConnect -r fhem/connection/status connected
attr mqqtClient msgBeforeDisconnect -r fhem/connection/status disconnected
attr mqqtClient qosMaxQueueLength 100
attr mqqtClient room MQTT2

defmod mqttBridge MQTT_GENERIC_BRIDGE mqtt room=MQQT-bridge
attr mqttBridge IODev Mosquitto
attr mqttBridge room MQTT
attr mqttBridge IODev ha_MQTT2
attr mqttBridge globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttBridge globalPublish *:topic={"fhem/$device/$reading"}
attr mqttBridge icon mqtt_bridge_2
attr mqttBridge stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttBridge verbose 0


Gleichzeitig habe ich ein paar MAX-Heizkörperthermostate:


define MAX_Bad MAX HeatingThermostatPlus 0f7ea1
attr MAX_Bad IODev cm
attr MAX_Bad room MAX,MQQT-bridge
attr MAX_Bad mqttSubscribe desiredTemperature:stopic={"fhem-write/$device/$reading/set"}


Was klappt:
- die Statusänderungen werden an den Broker kommuniziert

Was ich nicht hinkriege:
- gemäss diversen Beiträgen sollte es ja möglich sein, das Attribut mqttSubscribe zu setzen:

Zitat von: hexenmeister am 01 Oktober 2018, 10:57:50
Vorab:
eine Reading an einem beliebigen Device per MQTT setzen (für State-Reading soll state verwendet werden)
attr <device-name> mqttSubscribe <reading-name>:topic=<topic>
(anstatt 'topic' kann für eine bessere Lesbarkeit 'readings-topic' verwendet werden)

ein Set-Befehl an einem beliebigen Device mit dem per MQTT gesendeten Wert ausführen
(für set ohne namen (set on, set off) soll state verwendet werden)
attr <device-name> mqttSubscribe <set-befehl>:stopic=<topic>
(anstatt 'stopic' kann für eine bessere Lesbarkeit 'set-topic' verwendet werden)

Das verstehe ich aber nicht. Wenn ich dies versuche, kommt bei mir die Meldung (eigentlich nicht überraschend), dass das Gerät kein solches Attribut besitze.

Das zweite, was ich nicht verstehe, ich dass hier `set-topic` steht, in anderen Beispielen im Thread aber dann einfach `topic` verwendet wird. Ich dachte, das sei für den lesenden Zugriff.

Ist wahrscheinlich einfach ein blöder Fehler meinerseits, ich komme da aber nicht weiter und die Infos zu MQTT sind - finde ich jedenfalls - nicht einfach zu überblicken...

hexenmeister

Ob 'lesend' oder 'schreibend' entscheidet das Attribut: mqttPublish vs. mqttSubscribe.
topic ist für Readings zuständig, stopic (set-topic) für das Absetzen des Set-Befehls (geht nur mit mqttSubscribe).
Das, was Du versuchst, müsste eingentlich funktionieren (habe gerade ein entsprechendes SetUp in meinem Test-FHEM ausprobiert).
Was liefert den eine Fehlermeldung? Dieses Befehl? "attr MAX_Bad mqttSubscribe desiredTemperature:stopic={"fhem-write/$device/$reading/set"}"
Was bietet GUI als Attribut-Auswahl für mqtt?
Entferne mal probeweise devspec 'room=MQQT-bridge' aus der Bridge-Definition.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

user1

#2
Zitat von: hexenmeister am 24 November 2021, 22:31:15
Das, was Du versuchst, müsste eingentlich funktionieren (habe gerade ein entsprechendes SetUp in meinem Test-FHEM ausprobiert).

Gut, dann mache ich irgendetwas anderes falsch. Das Problem scheint zu sein, dass ich keine Attribute erzeugen kann. Setzen kann ich nur die, die bereits existieren.

Zitat
Was liefert den eine Fehlermeldung? Dieses Befehl? "attr MAX_Bad mqttSubscribe desiredTemperature:stopic={"fhem-write/$device/$reading/set"}"

MAX_Bad: unknown attribute mqttSubscribe. Type 'attr MAX_Bad ?' for a detailed list.

Zitat
Was bietet GUI als Attribut-Auswahl für mqtt?

Eben kein solches Attribut...

Zitat
Entferne mal probeweise devspec 'room=MQQT-bridge' aus der Bridge-Definition.

Werde ich versuchen, aber das Problem ist wohl, dass ich das Attribut nicht erzeugen kann. An was könnte das liegen?

Update: Habe jetzt 'attr global userattr ...' hinzugefügt, und der Fehler ist weg. Ich dachte nicht, dass das notwendig ist. Mal sehen, ob sonst aller läuft

user1

Funktioniert leider immer noch nicht.

Jetzt habe ich zwar das Attribut mqttSubscribe setzen können, aber wenn ich ein Kommando via mosquitto_pub absetzte, passiert leider nichts:


$ mosquitto_pub -t 'fhem-write/MAX_Bad/desiredTemperature/set' -m '21' -h 127.0.0.1


Das statement sieht dann so aus:


$ mosquitto_sub -t '#' -v -h 127.0.0.1
fhem/MAX_Bad/desiredTemperature 16.0       # die 'publish' Meldung via Bridge
...
fhem-write/MAX_Bad/desiredTemperature/set 20
fhem-write/MAX_Bad/desiredTemperature/set 21


In FHEM direkt kann ich die Temperatur mit 'set MAX_Bad desiredTemperature 21' aber setzen.

Beta-User

Zitat von: user1 am 25 November 2021, 07:29:06
Update: Habe jetzt 'attr global userattr ...' hinzugefügt, und der Fehler ist weg. Ich dachte nicht, dass das notwendig ist. Mal sehen, ob sonst aller läuft
Auf diesem Weg wird es nicht (zuverlässig) funktionieren.
ZitatEntferne mal probeweise devspec 'room=MQQT-bridge' aus der Bridge-Definition.
ist der "richtige Weg".

MQTT_GENERIC_BRIDGE wird nur Geräte steuern (und publishes erzeugen), die von der devspec erfasst sind - und an genau die verteilt es auch "seine" Attribute...

PS:
attr mqttBridge globalPublish *:topic={"fhem/$device/$reading"}solltest du auch überdenken. Das ist m.E. zu unspezifisch, publishes sollten mAn. auch nur direkt am jeweiligen Gerät zielgerichtet verteilt werden.
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

user1

Zitat von: Beta-User am 25 November 2021, 08:43:58
Auf diesem Weg wird es nicht (zuverlässig) funktionieren.

MQTT_GENERIC_BRIDGE wird nur Geräte steuern (und publishes erzeugen), die von der devspec erfasst sind - und an genau die verteilt es auch "seine" Attribute...

Das verstehe ich jetzt leider nicht. 'room=MQQT-bridge' dient ja als devspec, und funktioniert für das Publishing der Änderungen (diese sehe ich auch beim Broker ankommen und kann diese dann weiter verarbeiten).

Aber die Attribute werden trotzdem nicht an die Geräte in diesem Raum 'verteilt' (jedenfalls kann ich diese nicht setzen und sehe sie im Interface auch nicht).

Was mache ich hier falsch?


Beta-User

Hmm, da hast du nun auch wieder recht...

Auf welcher Version bist du aktuell im MQTT-Umfeld ("version MQTT.*")?

Und wird die devspec in den Internals sauber angezeigt?
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

user1

Hier die MQTT-Version, sollte nach dem update auf dem neusten Stand sein.

File                      Rev   Last Change

00_MQTT2_CLIENT.pm        24982 2021-09-16 16:25:40Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 25117 2021-10-25 11:05:19Z hexenmeister


Jetzt läuft alles wie es soll. Es scheint, dass ich die Bridge erst nach den Devices definieren muss. Dann tauchen die Attribute auch im Device auf.
Die MQTT-spezifischen Attribute der MAX-Devices setze ich jetzt eben nicht bei der Definition des Devices selbst, sondern erst am Ende nachdem die Bridge generiert wurde.

Falls jemand ein ähnliches Problem haben sollte, hier die relevanten Teile der Config, in der Reihenfolge des Auftauchens.


defmod MAX_Bad MAX HeatingThermostatPlus 0f7ea1
attr MAX_Bad IODev cm
attr MAX_Bad room MAX,MQQT-bridge

defmod mqqtClient MQTT2_CLIENT 127.0.0.1:1883
attr mqqtClient clientId fhem
attr mqqtClient keepaliveTimeout 60
attr mqqtClient msgAfterConnect -r fhem/connection/status connected
attr mqqtClient msgBeforeDisconnect -r fhem/connection/status disconnected
attr mqqtClient qosMaxQueueLength 100
attr mqqtClient room MQTT2

defmod mqttBridge MQTT_GENERIC_BRIDGE mqtt room=MQQT-bridge
attr mqttBridge room MQTT
attr mqttBridge IODev mqqtClient
attr mqttBridge globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttBridge globalPublish state|desiredTemperature|valveposition|state|battery|mode:topic={"fhem/$device/$reading"}
attr mqttBridge icon mqtt_bridge_2
attr mqttBridge stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttBridge verbose 0

attr MAX_Bad mqttSubscribe mode|desiredTemperature:stopic={"fhem-write/$device/$reading/set"}



Beta-User

M.E. ist das mit der Reihenfolge nicht relevant...
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

hexenmeister

Sehe ich auch so, dass Reihenfolge keine Rolle spielen soll.

Es kann eigentlich nicht sein, dass publish-Attribute da sind und für subscribe nicht. Wird beides gleich behandelt.
Bei Dir wird jedoch publish global an der Bridge selbst definiert (globalPublish),  da gibt es kein Attribut an dem Gerät selbst.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy