mqtt_generic_bridge publish funktioniert, aber kein Subscibe (Set befehl)

Begonnen von kotaro, 08 Januar 2021, 09:56:02

Vorheriges Thema - Nächstes Thema

kotaro

Hallo

ich habe das Problem, das ich gerne ein IT-Schalter mqtt fähig machen möchte.
Dazu habe ich eine mqtt-generic-bridge erstellt, und im Gerät die entsprechenden Parameter erstellt:

defmod WZ_Licht_renkforce_Schrankwand IT FF0FFF0F FFFF 0000
attr WZ_Licht_renkforce_Schrankwand userattr Licht Licht_map lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr WZ_Licht_renkforce_Schrankwand DbLogExclude .*
attr WZ_Licht_renkforce_Schrankwand IODev SIGNALduino
attr WZ_Licht_renkforce_Schrankwand ITrepetition 5
attr WZ_Licht_renkforce_Schrankwand alias Schrankwandbeleuchtung
attr WZ_Licht_renkforce_Schrankwand assistantName Licht Schrankwand
attr WZ_Licht_renkforce_Schrankwand cmdIcon on:general_an off:general_aus dimDown:dimdown dimUp:dimup
attr WZ_Licht_renkforce_Schrankwand genericDeviceType light
attr WZ_Licht_renkforce_Schrankwand group Licht
attr WZ_Licht_renkforce_Schrankwand icon light_cabinet
attr WZ_Licht_renkforce_Schrankwand mqttDefaults retain=1
attr WZ_Licht_renkforce_Schrankwand mqttPublish state:topic="FHEM/EG/WZ/Licht/WZ_Licht_renkforce_Schrankwand/state"
attr WZ_Licht_renkforce_Schrankwand mqttSubscribe state:stopic={"FHEM/EG/WZ/Licht/WZ_Licht_renkforce_Schrankwand/set"]
attr WZ_Licht_renkforce_Schrankwand realRoom Wohnzimmer
attr WZ_Licht_renkforce_Schrankwand room EG->Wohnzimmer,GoogleAssistant,Homekit,IT
attr WZ_Licht_renkforce_Schrankwand siriName Schrankwand
attr WZ_Licht_renkforce_Schrankwand sortby 3

setstate WZ_Licht_renkforce_Schrankwand on
setstate WZ_Licht_renkforce_Schrankwand 2019-12-19 22:05:11 protocol SBC_FreeTec
setstate WZ_Licht_renkforce_Schrankwand 2021-01-08 09:36:42 state on


Außerdem hier meine mqtt_generic_bridge:
defmod mqtt_generic_bridge MQTT_GENERIC_BRIDGE mqtt room=EG->Wohnzimmer
attr mqtt_generic_bridge DbLogExclude .*
attr mqtt_generic_bridge IODev Mosquitto2
attr mqtt_generic_bridge alias mqtt_generic_bridge
attr mqtt_generic_bridge disable 0
attr mqtt_generic_bridge room Devices->MQTT2_DEVICE
attr mqtt_generic_bridge verbose 5

setstate mqtt_generic_bridge 2021-01-07 11:25:33 device-count 2
setstate mqtt_generic_bridge 2021-01-08 09:53:08 incoming-count 5969
setstate mqtt_generic_bridge 2021-01-08 09:36:43 outgoing-count 132
setstate mqtt_generic_bridge 2021-01-08 09:36:43 transmission-state outgoing publish sent
setstate mqtt_generic_bridge 2021-01-07 11:25:21 updated-reading-count 0
setstate mqtt_generic_bridge 2021-01-07 11:25:21 updated-set-count 0


Und mein MQTT-Client:
defmod Mosquitto2 MQTT2_CLIENT mqtt:1883
attr Mosquitto2 DbLogExclude .*
attr Mosquitto2 alias Mosquitto2
attr Mosquitto2 autocreate complex
attr Mosquitto2 icon mqtt
attr Mosquitto2 lwt system/FHEM/connection/status connection lost
attr Mosquitto2 lwtRetain 1
attr Mosquitto2 msgAfterConnect retain:1 {Log3("mqtt",3,"connected to MQTT server");;;;1} system/FHEM/connection/status connected
attr Mosquitto2 msgBeforeDisconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;;;1} system/FHEM/connection/status disconnected
attr Mosquitto2 room Interfaces
attr Mosquitto2 verbose 5

setstate Mosquitto2 opened
setstate Mosquitto2 2021-01-08 09:49:41 lastPublish /SmartHome/EG/Wohnzimmer/HM_HKT_Buero/0.OPERATING_VOLTAGE:2.5
setstate Mosquitto2 2021-01-07 19:37:48 state opened


könnt ihr mir helfen?
Wie gesagt, wenn ich in FHEM die Schrankwand schalte, wird dies in MQTT gepublished, wenn ich manuell über mqtt-Explorer einen Befehl in den entsprechenden Pfad absende, wird die Schrankwand leider nicht geschaltet....

Beta-User

Das "Problem" dürfte "autocreate" sein:
attr Mosquitto2 autocreate complex
Das verträgt sich nicht ohne weiteres mit MQTT_GENERIC_BRIDGE, man muss dafür sorgen, dass die Infos NICHT von MQTT2_DEVICE verarbeitet werden, es gibt dazu auch einen längeren Thread mit Rudi und hexenmeister, in dem näher erläutert ist, warum das so ist....
Zitat von: Beta-User am 08 Januar 2021, 08:17:51
Wegen der CID/autocreate-Thematik neige ich allerdings dazu, den "set"-Anteil am topic eher nach vorne zu ziehen und eindeutiger FHEM zuzuordnen:
defmod <max-device-name> MAX <was auch immer hierher gehört>
attr <max-device-name> mqttSubscribe desired-temp:topic=toFHEM/haus/wohnzimmer/<max-device-name>/desired-temp disable:atopic=toFHEM/haus/wohnzimmer/<max-device-name>/disable

Dann kann man das leichter über eine bridgeRegexp auf MQTT_GENERIC_BRIDGE "ableiten"...
Im MQTT-Workshop findest du bei Interesse auch weitere Infos, wie das mit der bridgeRegexp zu verstehen ist.

(Und warum "complex"?)

(EDIT:Syntax für mqttSubscribe korrigiert)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kotaro

Wow, danke dir Beta-User,

das war genau das Problem.. das noch zusätzlich die Klammer am ende von Subscribe falsch war, war nur das I-Tüpfelchen, das hatte ich zwar schon geändert, und probiert, aber vergessen zu speichern, und dann hatte ich mal neu gestartet, und da war die eckige Klammer wieder drinn  8)
Es ist manchmal ärgerlich, wenn man wirklich versucht, das es klappt, aber nicht weiß, woran es hapert. da findet man auch so schnell nicht die Lösung, außer man weiß (wie fast immer) wonach man suchen muss...

Jetzt funktioniert es.
Und Wo finde ich den MQTT-Workshop??? Dies würde mich tatsächlich interessieren.

Zitat von: Beta-User am 08 Januar 2021, 10:04:58
(Und warum "complex"?)

dies ist tatsächlich eine gute Frage... kann ich nichtmal genau beantworten. Vermutlich aus Unwissenheit.

Beta-User

Diese Fragen hier sind v.a. in https://forum.fhem.de/index.php/topic,116162.msg1104338.html#msg1104338 zu finden.

Zu "complex": Meistens braucht man das nicht, das macht tendenziell lange Readingnamen, die nur dann sinnvoll sind, wenn ausnahmsweise gleichartige JSON-Infos über verschiedene Zweige kommen. Hier ist evtl. ein schönes Beispiel zu finden, wo "complex" tatsächlich gewisse Irritationen vermieden hätte: https://forum.fhem.de/index.php/topic,116188.msg1119187.html#msg1119187; da ist auch zu finden, wie man es "hinterher" fixt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors