fhem2mqtt2fhem über MQTT Server im Internet

Begonnen von TomLee, 17 April 2024, 17:09:27

Vorheriges Thema - Nächstes Thema

TomLee

Hallo,

weil ich es gestern in den Raum geworfen hab, das man das über einen Server im Internet lösen könnte, versuch ich das gerade selbst mal aus. Für die Erfahrung, bis jetzt brauch ich das noch nicht.

Test-FHEM:
edit: qosMaxQueueLength nonzero necessary
defmod fhem2fhem MQTT2_CLIENT bliblablub.s1.eu.hivemq.cloud:8883
attr fhem2fhem SSL 1
attr fhem2fhem autocreate no
attr fhem2fhem clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr fhem2fhem room fhem2fhem
attr fhem2fhem subscriptions setByTheProgram
attr fhem2fhem username TomLi

setstate fhem2fhem opened
setstate fhem2fhem 2024-04-17 16:29:57 lastPublish mqttGenericBridge/d/state:off
setstate fhem2fhem 2024-04-17 16:39:50 state opened


defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev fhem2fhem
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge globalDefaults sub:base=mqttGenericBridge/set pub:base=mqttGenericBridge
attr mqttGenericBridge group MQTT
attr mqttGenericBridge room fhem2fhem
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

setstate mqttGenericBridge dev: 2 in: 0 out: 12
setstate mqttGenericBridge 2024-04-17 15:28:47 IODev fhem2fhem
setstate mqttGenericBridge 2024-04-17 15:27:40 attrTemplateVersion 20211208_MQTT
setstate mqttGenericBridge 2024-04-17 16:39:50 device-count 2
setstate mqttGenericBridge 2024-04-17 15:28:46 incoming-count 0
setstate mqttGenericBridge 2024-04-17 16:15:42 outgoing-count 12
setstate mqttGenericBridge 2024-04-17 16:15:42 transmission-state outgoing publish sent
setstate mqttGenericBridge 2024-04-17 15:28:46 updated-reading-count 0
setstate mqttGenericBridge 2024-04-17 15:28:46 updated-set-count 0

defmod d dummy
attr d mqttPublish state:topic={"$base/$device/$name"}
attr d mqttSubscribe state:stopic={"$base/$device/$name"}
attr d room fhem2fhem
attr d setList on off

setstate d off
setstate d 2024-04-17 16:15:42 state off

Haupt-FHEM:
defmod f2f MQTT2_CLIENT bliblablub.s1.eu.hivemq.cloud:8883
attr f2f SSL 1
attr f2f autocreate simple
attr f2f clientId f2f
attr f2f room IOs
attr f2f username TomLu

setstate f2f opened
setstate f2f 2024-04-17 15:43:08 state opened

defmod MQTT2_CLIENT_general_bridge MQTT2_DEVICE f2f
attr MQTT2_CLIENT_general_bridge autocreate 1
attr MQTT2_CLIENT_general_bridge bridgeRegexp (tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"\
  (shellyp(lus|ro4pm)[^/:_]{4,}+)/.*:.* "$1"\
  zigbee2mqtt/bridge/.*:.* "zigbee2mqtt"\
  sonos/connected.* "sonos"\
  tvheadend/[^/:]+.* "tvheadend"\
  milight/LWT:.* "milight"\
  (ESPClient_[^/]+)/.*:.* "$1"\
  (ebusd[^/]*)/global/.*:.* "$1"\
  [^/]+/(ems-esp[^/]+)/start:.* "$1"\
  (mygateway[\d]+)-(in|out)/.* "$1"\
  (wallpanel|wled|instar)/([^/]+)/.*:.* "$1_$2"\
  (nuki)/[^/]+/.* "$1"\
  go-eCharger/([^/]+)/.*:.* "go_eCharger_$1"\
  owntracks/[^/]+/([^/:]+).* "owntracks_$1"\
  home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"\
  homeassistant/.*/config:.* ""\
  tasmota/discovery/[^/:]+/(config|sensors):.* ""\
  mqttGenericBridge/([^/]+)/.*:.* "$1"
attr MQTT2_CLIENT_general_bridge comment Do not use very open bridgeRegexp expressions! This might lead to irritating results... Especially make sure to not have two regexpes that may both match!
attr MQTT2_CLIENT_general_bridge icon mqtt_bridge_2
attr MQTT2_CLIENT_general_bridge model MQTT2_CLIENT_general_bridge
attr MQTT2_CLIENT_general_bridge room MQTT2_DEVICE
attr MQTT2_CLIENT_general_bridge setList clear_all:noArg {fhem("deleteattr $NAME readingList;; deletereading -q $NAME (?!associatedWith|IODev).*");;return undef}
attr MQTT2_CLIENT_general_bridge setStateList on off

defmod MQTT2_d MQTT2_DEVICE d
attr MQTT2_d readingList mqttGenericBridge/d/state:.* state
attr MQTT2_d room MQTT2_DEVICE
attr MQTT2_d setList on:noArg mqttGenericBridge/d/state on\
off:noArg mqttGenericBridge/d/state off

setstate MQTT2_d off
setstate MQTT2_d 2024-04-17 16:07:03 IODev f2f
setstate MQTT2_d 2024-04-17 16:07:05 associatedWith MQTT2_f2f
setstate MQTT2_d 2024-04-17 16:40:20 state off

Wenn ich im Test-FHEM den dummy schalte kommt das im Haupt-FHEM an. Allerdings nicht andersrum, wenn ich im Haupt-FHEM schalte sehe ich das am Server was ankommt (im Web Client von hivemq), aber im Traffic-Monitor der MQTT2-CLIENT des Test-FHEM nicht.

Sieht jemand einen Konfigurationsfehler ?
Ist der Topic der setter in MQTT2_d mglw. falsch ?
Mach ich was falsch bei mqttSubscribe bzw. muss was das subscriben angeht nach was ergänzt werden ?

Gruß

Thomas

TomLee

Ah, es geht mit:   

on:noArg mqttGenericBridge/set/d/state on
Dann wird aber ein neues Device im Haupt-FHEM angelegt, wegen dem set in dem Topic:

defmod MQTT2_set MQTT2_DEVICE set
attr MQTT2_set readingList mqttGenericBridge/set/d/state:.* state
attr MQTT2_set room MQTT2_DEVICE

setstate MQTT2_set on
setstate MQTT2_set 2024-04-17 17:29:27 IODev f2f
setstate MQTT2_set 2024-04-17 17:29:27 associatedWith MQTT2_CLIENT_general_bridge
setstate MQTT2_set 2024-04-17 17:29:27 state on

Wie löst man das am besten ? Mit einem bridgeRegexp in MQTT2_CLIENT_general_bridge ?
mqttGenericBridge/set/.*/.*:.* ""

TomLee

#2
Zitatatopic (Langform: attr-topic) schließlich dient dazu, Attributwerte zu ändern. atopic kann auch in mqttPublish eingesetzt werden, um Änderungen der Attribut-Werte an den MQTT-Server zu übermitteln.

Das würd ich gerne mal umsetzen, gepeilt hab ich aber leider noch nicht alle Zusammenhänge. Man kann über MQTT Attribute ändern ? Das geht dann doch nur wenn ich auf beiden Systemen eine MGB habe, oder ?

Wenn ich auf dem Test-Pi-dummy den atopic (für bspw. das Attribut alexaName, hier userattr !!! weil keine alexa-Definition vorhanden) mit in mqttPublish aufnehme:
defmod d dummy
attr d userattr alexaName
attr d alexaName sonne
attr d mqttPublish state:topic={"$base/$device/$name"} alexaName:atopic={"$base/$device/alexaName"}
attr d mqttSubscribe state:stopic={"$base/$device/$name"}
attr d room fhem2fhem
attr d setList on off

setstate d on
setstate d 2024-04-18 13:41:57 state on

kommt das auf dem Haupt-FHEM (wo ich zum testen jetzt auch eine MGB definiert habe) als Reading an:

defmod MQTT2_d MQTT2_DEVICE d
attr MQTT2_d mqttSubscribe alexaName:atopic={"$base/$device/alexaName"}
attr MQTT2_d readingList mqttGenericBridge/d/state:.* state\
mqttGenericBridge/d/alexaName:.* alexaName
attr MQTT2_d room MQTT2_DEVICE
attr MQTT2_d setList on:noArg mqttGenericBridge/set/d/state on\
off:noArg mqttGenericBridge/set/d/state off

setstate MQTT2_d on
setstate MQTT2_d 2024-04-17 16:07:03 IODev f2f
setstate MQTT2_d 2024-04-18 13:41:45 alexaName sonne
setstate MQTT2_d 2024-04-17 18:29:29 associatedWith MQTT2_CLIENT_general_bridge
setstate MQTT2_d 2024-04-18 13:41:57 state on

Kann mir wer zeigen/erklären wie man das mit der "Attributübergabe" richtig macht/gedacht ist ?

edit:

MGB auf dem Haupt-System:
defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev f2f
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge globalDefaults sub:base=mqttGenericBridge/set pub:base=mqttGenericBridge
attr mqttGenericBridge group MQTT
attr mqttGenericBridge room fhem2fhem
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

setstate mqttGenericBridge dev: 1 in: 0 out: 0
setstate mqttGenericBridge 2024-04-18 12:56:15 IODev f2f
setstate mqttGenericBridge 2024-04-18 13:54:57 device-count 1
setstate mqttGenericBridge 2024-04-18 12:56:14 incoming-count 0
setstate mqttGenericBridge 2024-04-18 12:56:14 outgoing-count 0
setstate mqttGenericBridge 2024-04-18 12:56:15 transmission-state IO device initialized (mqtt2)
setstate mqttGenericBridge 2024-04-18 12:56:14 updated-reading-count 0
setstate mqttGenericBridge 2024-04-18 12:56:14 updated-set-count 0

TomLee

Wenn Petrus mich morgen fragen würde ob die MGB Attribute setzen kann, dann müsste ich mit dem derzeitigen Kenntnisstand antworten: Die commandref hab ich so verstanden:
ZitatmqttSubscribe
This attribute configures the device to receive MQTT messages and execute corresponding actions.
The configuration is similar to that for the 'mqttPublish' attribute. Topics can be defined for setting readings ('topic' or 'readings-topic') and calls to the 'set' command on the device ('stopic' or 'set-topic').
Also attributes can be set ('atopic' or 'attr-topic').
The result can be modified before setting the reading or executing of 'set' / 'attr' on the device with additional Perl expressions ('expression').

angelegt wurden bei meinen ersten Gehversuchen mit atopic in dem zu "spiegelnden" Device aber keine Attribute sondern Readings.
Weiter war ich mit testen nicht gekommen und im Forum hat mir bis dato keiner geantwortet. ¯\_(ツ)_/¯



Hat mich denn keiner verstanden oder hab ich es so schlecht erklärt, das mir keiner die Frage beantworten kann wie das mit dem Attribut setzen genau zu verstehen bzw. (wenn das überhaupt gehen soll, ich finde es merkwürdig) umzusetzen ist ?

frober

Ich weiß es zwar auch nicht, aber evtl. ist das das Problem:
Zitatattr MQTT2_d readingList mqttGenericBridge/d/state:.* state\
mqttGenericBridge/d/alexaName:.* alexaName

Hast du mal versucht es wegzulassen?
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

TomLee

Hi,

hmm, ich hab eine bridgeRegexp in dem Bridge-Device (auf dem Hauptsystem) ergänzt:

Zitatdefmod MQTT2_CLIENT_general_bridge MQTT2_DEVICE f2f
attr MQTT2_CLIENT_general_bridge autocreate 1
attr MQTT2_CLIENT_general_bridge bridgeRegexp (tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"\
  (shellyp(lus|ro4pm)[^/:_]{4,}+)/.*:.* "$1"\
  zigbee2mqtt/bridge/.*:.* "zigbee2mqtt"\
  sonos/connected.* "sonos"\
  tvheadend/[^/:]+.* "tvheadend"\
  milight/LWT:.* "milight"\
  (ESPClient_[^/]+)/.*:.* "$1"\
  (ebusd[^/]*)/global/.*:.* "$1"\
  [^/]+/(ems-esp[^/]+)/start:.* "$1"\
  (mygateway[\d]+)-(in|out)/.* "$1"\
  (wallpanel|wled|instar)/([^/]+)/.*:.* "$1_$2"\
  (nuki)/[^/]+/.* "$1"\
  go-eCharger/([^/]+)/.*:.* "go_eCharger_$1"\
  owntracks/[^/]+/([^/:]+).* "owntracks_$1"\
  home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"\
  homeassistant/.*/config:.* ""\
  tasmota/discovery/[^/:]+/(config|sensors):.* ""\
  mqttGenericBridge/([^/]+)/.*:.* "$1"\
  mqttGenericBridge/set/.*/.*:.* ""

attr MQTT2_CLIENT_general_bridge comment Do not use very open bridgeRegexp expressions! This might lead to irritating results... Especially make sure to not have two regexpes that may both match!
attr MQTT2_CLIENT_general_bridge icon mqtt_bridge_2
attr MQTT2_CLIENT_general_bridge model MQTT2_CLIENT_general_bridge
attr MQTT2_CLIENT_general_bridge room MQTT2_DEVICE
attr MQTT2_CLIENT_general_bridge setList clear_all:noArg {fhem("deleteattr $NAME readingList;; deletereading -q $NAME (?!associatedWith|IODev).*");;return undef}
attr MQTT2_CLIENT_general_bridge setStateList on off

verstehe es so das darum der Zweig
mqttGenericBridge/d/alexaName:.* alexaName
in MQTT2_d automatisch ergänzt wird. So entsteht das "Attribut-Reading".

Wenn überhaupt muss es ja was mit der Konfiguration der Attribute die mit der MGB zur Verfügung stehen zu tun haben.
Das die irgendwie verursachen das ein Attribut erstellt wird, auf welcher Basis kann ich mir einfach nicht vorstellen, über MQTT wird doch nix sonderliches übertragen das irgendwie davon abgeleitet werden könnte das ein Attribut erstellt werden soll.

19:18:50.848 RCVD mqttGenericBridge/d/state on
19:19:06.512 RCVD mqttGenericBridge/d/state off
19:19:44.116 RCVD mqttGenericBridge/d/alexaName \0  #kommt wenn man im entfernten System alexaName löscht
19:19:55.898 RCVD mqttGenericBridge/d/alexaName sonne #aleaName ergänzt

frober

Hier ab #55

Er schreibt auch
ZitatDas Device muss natürlich einen entsprechenden Attribut überhaupt zulassen.

D.h. du müsstest das userattr zuerst senden!?
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

TomLee

Es klappt tatsächlich Attribute zu setzen und wie vermutet sind die Attribute der MGB der Schüssel dafür. Verstanden hab ich es aber noch nicht bis ins Detail, muss mich noch weiter mit beschäftigen.
Ohne jetzt weit auszuholen wie ich es umgesetzt habe, es ist aber dann nicht das was ich gerne gehabt hätte. Mein Gedanke war, im entfernten System wird ein Attribut gesetzt oder geschalten und dieses Device wird dann automatisch Eins-zu-Eins im Haupt-System gespiegelt.
Wie ich es jetzt verstehe:
Die MGB erstellt nix automatisch ?
Zu spiegelnde Devices muss man immer händisch anlegen ?
Oder man nutzt wie ich oben zeige autocreate hier bei MQTT2_CLIENT ?
Damit ein Attribut vom entfernten System auf das Haupt-System übertragen werden kann, muss ich immer händisch das Attribut mqttSubscribe bei dem zu spiegelnden Device setzen ?
MQTT2_DEVICE kann ich dazu missbrauchen Topics zu abonnieren und Befehle abzusetzen ohne die Verwendung von mqttSubscribe und mqttPublish ?
Übersehe ich evtl. die Möglichkeit das abonnieren des atopic Pfad in dem zu spiegelnden Device automatisch zu setzen ?