[anders gelöst] expandJSon expandiert nur numerische Werte?

[mifh]

Moin,
ich versuche gerade, meinen Xiaomi Wassermelder in FHEM einzubinden. Ich nutze zigbee2mqtt,ein MQTT_Device und ein expandJSON:

Code Auswählen Erweitern


define Hzg_Wassermelder MQTT_DEVICE
attr Hzg_Wassermelder IODev MQTT_2
attr Hzg_Wassermelder room Dachboden
attr Hzg_Wassermelder subscribeReading_value zuhause/zigbee2mqtt/WassermelderHeizung
attr Hzg_Wassermelder verbose 5

define Hzg_Wassermelder_ej expandJSON Hzg_Wassermelder:value:.{.*}
attr Hzg_Wassermelder_ej room Dachboden
attr Hzg_Wassermelder_ej verbose 5



Die Kommunikation erfolgt über meinen zentralen Mosquitto. Ich weiß, es gibt auch MQTT2. Nur leider bringe ich nicht genug Geduld dafür auf, das zum Laufen zu bringen. Die Doku ist doch arg knapp..
Daher wollte ich es ganz altmodisch mit MQTT_DEVICE und einem expandJSON machen.
Der Wassermelder generiert folgende Nachrichten:

Code Auswählen Erweitern


9/9/2019, 8:55:37 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/WassermelderHeizung', payload '{"battery":100,"voltage":3065,"linkquality":5,"water_leak":false}'


Die sortiert der expandJSON auch brav ein, nur das relevante Attribut "water_leak" leider nicht:

Code Auswählen Erweitern


Internals:
   FUUID      5d7612fb-f33f-f8db-8493-8fb8c060dfb33d1f
   IODev      MQTT_2
   NAME       Hzg_Wassermelder
   NR         82
   STATE      ???
   TYPE       MQTT_DEVICE
   READINGS:
     2019-09-09 11:17:36   battery         100
     2019-09-09 11:17:36   linkquality     5
     2019-09-09 11:17:36   transmission-state incoming publish received
     2019-09-09 11:17:36   value           {"battery":100,"voltage":3065,"linkquality":5,"water_leak":false}
     2019-09-09 11:17:36   voltage         3065
   message_ids:
   sets:
   subscribe:
     zuhause/zigbee2mqtt/WassermelderHeizung
   subscribeExpr:
     ^zuhause\/zigbee2mqtt\/WassermelderHeizung$
   subscribeQos:
     zuhause/zigbee2mqtt/WassermelderHeizung 0
   subscribeReadings:
     zuhause/zigbee2mqtt/WassermelderHeizung:
       cmd       
       name       value
Attributes:
   IODev      MQTT_2
   room       Dachboden
   subscribeReading_value zuhause/zigbee2mqtt/WassermelderHeizung
   verbose    5



Bei meinem Türkontakt hatte ich das selbe Problem: alle numerischen Werte werden expandiert, die Stringwerte fehlen. Hat jemand eine Idee?
Michael

[Beta-User]

[...] Ich weiß, es gibt auch MQTT2. Nur leider bringe ich nicht genug Geduld dafür auf, das zum Laufen zu bringen. Die Doku ist doch arg knapp..

[OT]
Was fehlt dir denn in der Doku? Insbesondere mit https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele sollte man eigentlich ziemlich schnell starten können, ohne wirklich Doku gelesen zu haben - bereits überfliegen sollte reichen... Wird häufiger als sehr viel einfacher empfunden als die "alte" Methode.
[/OT]
Zu expandJSON kann ich wenig sagen, habe aber gewisse Zweifel, dass der string "false" als string behandelt wird. Eventuell wird das wie ein Wahrheitswert behandelt und da wird aus false auch schon mal ""...

[mifh]

Danke für die schnelle Antwort.
Klingt nicht ganz unwahrscheinlich.  Mal schauen, ob sich noch jemand findet, der da Fachmann ist.

Zu https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele s:
Ich habe das noch mal versucht nachzuvollziehen. Dazu habe ich einen frischen FHEM Docker Container angelegt, einen MQTT2 Client angelegt und dann ein Bridge-Device nach Anletung angelegt:

Code Auswählen Erweitern

define MQTT_T MQTT2_CLIENT 192.168.1.25:1883
setuuid MQTT_T 5d778cf6-f33f-2e1c-c8a6-de1f89af7f868400
attr MQTT_T clientId fhemmqtt
attr MQTT_T username ntzkanal
define MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
setuuid MQTT2_zigbee_pi 5d778de2-f33f-2e1c-fa35-89d0cf0c208d5972
attr MQTT2_zigbee_pi IODev MQTT_T
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi getList devicelist:noArg log zuhause/zigbee2mqtt/bridge/config/devices\
  networkmap_raw:noArg raw zuhause/zigbee2mqtt/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz zuhause/zigbee2mqtt/bridge/networkmap graphviz
attr MQTT2_zigbee_pi model L_01_zigbee2mqtt_bridge
attr MQTT2_zigbee_pi setList log_level:debug,info,warn,error zuhause/zigbee2mqtt/bridge/config/log_level $EVTPART1\
  permit_join:true,false zuhause/zigbee2mqtt/bridge/config/permit_join $EVTPART1\
  remove:textField zuhause/zigbee2mqtt/bridge/config/remove $EVTPART1\
  y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField zuhause/zigbee2mqtt/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField zuhause/zigbee2mqtt/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField zuhause/zigbee2mqtt/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField zuhause/zigbee2mqtt/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField zuhause/zigbee2mqtt/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField zuhause/zigbee2mqtt/bridge/config/elapsed $EVTPART1\
  z_last_seen:textField zuhause/zigbee2mqtt/bridge/config/last_seen $EVTPART1\
  z_ban:textField zuhause/zigbee2mqtt/bridge/config/ban $EVTPART1\
  z_rename:textField zuhause/zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg zuhause/zigbee2mqtt/bridge/config/reset
attr MQTT2_zigbee_pi setStateList on off

Das tut soweit, ist auch lebendig und verbunden:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        zigbee_pi
   DEF        zigbee_pi
   DEVICETOPIC MQTT2_zigbee_pi
   FUUID      5d778de2-f33f-2e1c-fa35-89d0cf0c208d5972
   IODev      MQTT_T
   LASTInputDev MQTT_T
   MQTT_T_MSGCNT 2
   MQTT_T_TIME 2019-09-10 13:52:52
   MSGCNT     2
   NAME       MQTT2_zigbee_pi
   NR         99
   STATE      ???
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      MQTT_T
   bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
   getList    devicelist:noArg log zuhause/zigbee2mqtt/bridge/config/devices
  networkmap_raw:noArg raw zuhause/zigbee2mqtt/bridge/networkmap raw
  networkmap_graphviz:noArg graphviz zuhause/zigbee2mqtt/bridge/networkmap graphviz
   model      L_01_zigbee2mqtt_bridge
   setList    log_level:debug,info,warn,error zuhause/zigbee2mqtt/bridge/config/log_level $EVTPART1
  permit_join:true,false zuhause/zigbee2mqtt/bridge/config/permit_join $EVTPART1
  remove:textField zuhause/zigbee2mqtt/bridge/config/remove $EVTPART1
  y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}
  x_bind:textField zuhause/zigbee2mqtt/bridge/bind/$EVTPART1 $EVTPART2
  x_bind_unbind:textField zuhause/zigbee2mqtt/bridge/unbind/$EVTPART1 $EVTPART2
  x_device_options:textField zuhause/zigbee2mqtt/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}
  x_group_add_to:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/add $EVTPART2
  x_group_rm_from:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/remove $EVTPART2
  x_group_rm_from_all:textField zuhause/zigbee2mqtt/bridge/group/$EVTPART1/remove_all $EVTPART2
  x_group_add_group:textField zuhause/zigbee2mqtt/bridge/config/add_group $EVTPART1
  x_group_rm_group:textField zuhause/zigbee2mqtt/bridge/config/remove_group $EVTPART1
  z_elapsed:textField zuhause/zigbee2mqtt/bridge/config/elapsed $EVTPART1
  z_last_seen:textField zuhause/zigbee2mqtt/bridge/config/last_seen $EVTPART1
  z_ban:textField zuhause/zigbee2mqtt/bridge/config/ban $EVTPART1
  z_rename:textField zuhause/zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}
  z_reset_CC:noArg zuhause/zigbee2mqtt/bridge/config/reset
   setStateList on off

Das Anlegen neuer Devices klappt allerdings nicht. Es geht wohl auch eine Anfrage raus, die ztigbee2mqtt beantwortet, aber dort bekomme ich nur eine Fehlermeldung:

Code Auswählen Erweitern

9/10/2019, 11:56:53 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:53 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:53 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:54 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:54 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:55 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":false,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:55 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":true,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:55 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":true,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:55 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":true,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:56:56 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/DachfensterFlur', payload '{"contact":true,"linkquality":0,"battery":100,"voltage":3025}'
9/10/2019, 11:57:39 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/WassermelderHeizung', payload '{"battery":100,"voltage":3055,"linkquality":2,"water_leak":true}'
9/10/2019, 11:57:57 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/WassermelderHeizung', payload '{"battery":100,"voltage":3055,"linkquality":2,"water_leak":false}'
9/10/2019, 11:58:12 AM - info: Successfully reenabled joining
9/10/2019, 11:58:16 AM - info: MQTT publish: topic 'zuhause/zigbee2mqtt/bridge/log', payload '{"type":"devices","message":[{"ieeeAddr":"0x00124b001936a797","type":"Coordinator"},{"ieeeAddr":"0xd0cf5efffe18d599","type":"Router","model":"LED1545G12","friendly_name":"LED2","nwkAddr":52338,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb E27 WS opal 980lm","hwVersion":1,"swBuildId":"1.2.217","
....

Code Auswählen Erweitern

Timeout reading answer for zuhause/zigbee2mqtt/bridge/config/devices true

Meine configuration.yaml sieht so aus:

Code Auswählen Erweitern

homeassistant: false
permit_join: true
mqtt:
  base_topic: zuhause/zigbee2mqtt
  client_id: zigbee_pi
  server: 'mqtt://pi3'
  user: ntzkanal
  password: yDoGAD66CyehuKtTkLZK
serial:
  port: /dev/ttyACM0
devices:
  '0xd0cf5efffe18d599':
    friendly_name: LED2
    retain: false
  '0x000d6ffffe1eb52f':
    friendly_name: LED1
    retain: false
  '0xd0cf5efffe317c1d':
    friendly_name: fernbedienung
    retain: false
    coordinator_group: 25014
  '0x000b57fffe3993b1':
    friendly_name: LED3
    retain: false
  '0x00158d000325f9f8':
    friendly_name: DachfensterFlur
    retain: false
  '0x00158d0003a01111':
    friendly_name: DachfensterGastZ
    retain: false
  '0x00158d00034ccdc5':
    friendly_name: Bewegungsmelder
    retain: false
  '0x00158d00035a8e75':
    friendly_name: 'WassermelderHeizung'
    retain: false


Was mit in den Praxisbeispielen bisher aufgefallen ist:

Die Zeile

Code Auswählen Erweitern

attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server

taucht zweimal auf,

Code Auswählen Erweitern

attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1" dafür gar nicht.

Die Lösung scheint ja echt eine ganze Menge automatisch zu machen. Ist halt nur blöd, wenn es dann nicht tut. Gibt es irgendwo eine Beschreibung, was dies ganze Attribute bewirken? Kann man das irgendwie sinnvoll debuggen?

[Beta-User]

Hmm, also:

Mit MQTT2_CLIENT ist manches etwas schwieriger, aber trotzdem:
- Das doppelte IO habe ich gelöscht, Danke für den Hinweis. (Ich muß das ggf. bei Gelegenheit nochmal überarbeiten, da ist die vergangenen Monate einfach sehr viel passiert, und nicht alles an allen Stellen zwingend aktuell).

- In dem "Ausgangsdevice" ist erst mal der Ist-Zustand beschrieben vor Anwendung eines template, das paßt also m.E., und auch die bridgeRegexp wird erst dadurch ergänzt.

Wie im Wiki beschrieben, bewirkt das bridgeRegexp-Attribut, dass alles, was den dort eingetragenen regexes entspricht, nicht in dem Device selbst hinzugefügt wird, sondern an ein anderes weitergeleitet wird. Da du eine etwas andere base_id gesetzt hast, muß die bridgeRegexp bei dir auch etwas länger sein, das ist m.E. ein Fehler drin, ebenso bei y_device_setting (Da kommt eventuell der timeout-Fehler her, das 2. ist ein Fehler im template, muß ich bei Gelegenheit fixen...; kann aber auch sein, dass "get ... devicelist" immer in einem timeout endet, weil die Rückgabe "etwas kompliziert" ist und sich nicht sinnvoll anzeigen lassen; hier scheinen die Daten aber effektiv angekommen zu sein - dieses "get" ist allerdings nicht dazu da, neue Devices anzulegen. Das passiert bei aktiviertem autocreate dann, wenn neue topic-Strukturen reinkommen, die nicht zugeordnet werden können; sonst muß man das nach wie vor manuell machen).

Wenn du mehr dazu suchst: es gibt speziell für MQTT2_CLIENT eine ergänzende, vorkonfigurierte bridgeRegexp, die "typische" Topicstrukturen (z.B. von Tasmota) erkennen kann und daraus Devices bastelt, die die zugehörigen Infos enthalten (das erste echte temolate in der Liste, A_00_MQTT2_CLIENT_general_bridge...)

Ansonsten ist die cref zu MQTT2_DEVICE eigentlich knapp, aber gut, und speziell zu zigbee2mqtt gibt es auch einen ziemlich langen thread, in dem vieles erläutert ist ("Läuft, zigbee2mqtt..."), wenn du dazu Hintergrundinfos suchst.

Ansonsten Fragen und gerne Anmerkungen machen, was wo ggf. in der Doku noch ergänzt werden kann, ist nur auf die Schnelle "im Fluß" entstanden, aber evtl. nicht "perfekt"...

Ansonsten: Ja, MQTT2_DEVICE (v.a. iVm. MQTT2_SERVER) macht vieles einfach, und die Konfigurationsmöglichkeiten sind vielfältig (und in den Wechselwirkungen nicht immer gleich zu erfassen). Aber man hat im Prinzip vollen Zugriff auf "alles", und die templates sind zwischenzeitlich ein super "Steinbruch", um Codeschnipsel für alle möglichen Anwendungsfälle zu finden .

[mifh]

Mann, Du gibst ja schnell Antworten

Ok, ich habe jetzt verstanden, dass das Beispiel davon ausgeht, dass das basetopic zigbee2mqtt ist, ohne jede Präfixe.
Ist das evtl. einen Satz in der Doku wert?

Code Auswählen Erweitern

Das folgende Beispiel geht davon aus, dass für zigbe2mqtt das Basetopic "zigbee2mqtt" in der configuration.yaml angelegt worden ist.

Ich kann mir vorstellen, dass es noch mehr Leute gibt, die die Ausgaben von zigbee2mqtt gerne in ihren Namensraum einsortieren wollen.

Ich habe die beiden Regexp in der Bridge angepasst, das hat aber nichts geändert (genau genommen ist ein einzelnes neues DEvie mosquitto angelegt worden:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        mosquitto
   DEF        mosquitto
   DEVICETOPIC mosquitto
   FUUID      5d77a5d7-f33f-2e1c-3368-2af0764f7e2a1db3
   IODev      MQTT_T
   NAME       mosquitto
   NR         124
   STATE      ???
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-09-10 15:34:27   associatedWith  DACH_FLUR_Fenster
Attributes:
   IODev      MQTT_T
   autocreate 1
   bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"
  shellies[/]([^/]+)[/].*:.* "$1"
  (ESPClient_[^/]+)[/].*:.* "$1"
   comment    Do not use very open bridgeRegexp expressions! This might lead to irritating results...
   model      A_00_MQTT2_CLIENT_general_bridge
   room       MQTT2_DEVICE
   setStateList on off


Davor hatte ich noch Deinen Tipp mit A_00_MQTT2_CLIENT_general_bridge ausprobiert:

Code Auswählen Erweitern

nternals:
   DEVICETOPIC DACH_FLUR_Fenster
   FUUID      5d77976d-f33f-2e1c-7828-22de43380073fe68
   FVERSION   10_MQTT2_DEVICE.pm:0.200710/2019-08-27
   IODev      MQTT_T
   NAME       DACH_FLUR_Fenster
   NR         21
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
Attributes:
   IODev      MQTT_T
   bridgeRegexp zuhause/zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"


Bevor ich das jetzt lange herumspiele, lege ich halt die Devices von Hand an:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEVICETOPIC DACH_FLUR_Fenster2
   FUUID      5d77c174-f33f-2e1c-5f98-cb1eae4f136a0950
   IODev      MQTT_T
   LASTInputDev MQTT_T
   MQTT_T_MSGCNT 17
   MQTT_T_TIME 2019-09-10 17:34:41
   MSGCNT     17
   NAME       DACH_FLUR_Fenster2
   NR         1213
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-09-10 17:34:41   battery         100
     2019-09-10 17:34:41   contact         true
     2019-09-10 17:34:41   linkquality     10
     2019-09-10 17:34:41   voltage         3025
Attributes:
   IODev      MQTT_T
   readingList zuhause/zigbee2mqtt/DachfensterFlur:.* { json2nameValue($EVENT) }


Das reicht mir völlig aus.

Du hast Recht, MQTT2 ist schon komfortabel, aber so ein kleines Minibeispiel könnte evtl. für Nicht-Experten hilfreich sein.

Danke sehr für die Unterstützung.
Michael

[Beta-User]

Alle Beispiele in dem Wiki-Artikel gehen davon aus, dass man "defaults" verwendet und MQTT2_SERVER . Steht da ganz am Anfang des Artikels, wenn ich mich recht entsinne...

Aber das template sollte auch mit anderen Einstellungen funktionieren (du hattest danach was in der bridgeRegexp geändert, oder...?), es ist nur an einer anderen Stelle noch ein Fehlerchen drin.

Was die bridgeRegexp angeht und das Verständnis von bridgeRegexp iVm. "autocreate" auf den verschiedenen Ebenen (TYPE=autocreate, TYPE=MQTT2_(CLIENT|SERVER) und TYPE=MQTT2_DEVICE) angeht, hattest du m.E. meine Anregung etwas mißverstanden, die Angaben in den lists sind m.E. jedenfalls noch nicht optimal . (Ich bin mir aber andererseits auch nicht 100% sicher, ob das, was das "A_00..."-template macht, der Weisheit letzter Schluß ist . Gerne können wir das weiter optimieren, ich bräuchte aber zum weiteren Austüfteln jemanden, der ernsthaft und dauerhaft MQTT2_CLIENT nutzt; es gibt dazu auch irgendwo im MQTT-Bereich einen separaten Thread).

[mifh]

Danke für die Hilfe. Ich denke, das automatische Anlegen der Devices ist für mich eher unwichtig. Ich mache das lieber manuell, da habe ich mehr Kontrolle. Mein PRoblem ist jetzt gelöst, nachdem ich dann irgendwann verstanden hatte, was diese Zeile eigentlich veranstaltet:

Code Auswählen Erweitern

readingList zuhause/zigbee2mqtt/DachfensterFlur:.* { json2nameValue($EVENT) }
Das ist ja mit dem alten MQTT umständlicher.

Ich hatte auch den Hinweis gelesen, dass die Beispiele für den Betrieb über den eingebauten MQTT Server optimiert sind. Ich fände es spannend, herauszubekommen, wie viele Anwender das tatsächlich so machen und wie viele Anwender auf einen separaten MQTT-Server setzen. Selbst wenn es diese Lösung gegeben hätte, als ich mit MQTT angefangen habe, würde ich es trotzdem bevorzugen, den Message-Broker als separaten Service zu fahren. Das in FHEM zu integrieren,geht so in Richtung großer zentraler Service, der alles regelt. Kann man machen, aber es es gibt schon gute Gründe, warum man heutzutage eher auf (Micro-) Service Architekturen setzt. Und dann wäre die die Anbindung von FHEM als MQTT2-Client der Standard und nicht die Ausnahme.

Viele Grüße
Michael

[Beta-User]

Mein PRoblem ist jetzt gelöst,

Dann vielleicht ein [anders gelöst] vor den Thread-Titel packen?

Danke auch für das nette feedback und die Bestätigung, dass MQTT2_DEVICE die Sache zeimlich vereinfachen kann .

Ich hatte auch den Hinweis gelesen, dass die Beispiele für den Betrieb über den eingebauten MQTT Server optimiert sind. Ich fände es spannend, herauszubekommen, wie viele Anwender das tatsächlich so machen und wie viele Anwender auf einen separaten MQTT-Server setzen. Selbst wenn es diese Lösung gegeben hätte, als ich mit MQTT angefangen habe, würde ich es trotzdem bevorzugen, den Message-Broker als separaten Service zu fahren. Das in FHEM zu integrieren,geht so in Richtung großer zentraler Service, der alles regelt. Kann man machen, aber es es gibt schon gute Gründe, warum man heutzutage eher auf (Micro-) Service Architekturen setzt. Und dann wäre die die Anbindung von FHEM als MQTT2-Client der Standard und nicht die Ausnahme.

Die templates sollten (in der Regel) auch bei "geänderten" Topic-Strukturen und mit MQTT2_CLIENT funktionieren, da ist es aber halt nicht immer vollst. ausgetestet. In der Regel ist es aber ausreichend, wenn ein passender readingList-Eintrag vorhanden ist, man muß also auch dann nicht viel manuell machen...

Was die Frage angeht, wie das Verhältnis der MQTT2-IO's zueinander hinsichtlich des tatsächlichen Einsatzes ist, gibt es als Indiz https://fhem.de/stats/statistics.html: 3:1 für SERVER.

M.E. wird sich das auch nicht wesentlich ändern, denn: zum einen verursacht ein separater Server die doppelte Last, da alle Daten ja in FHEM und auf dem externen Server vorgehalten werden (müssen), was (an sich funktionierenden Server-Code vorausgesetzt) nur dann sinnvoll ist, wenn nicht nur "ein paar Devices" verwaltet werden sollen, die sowieso eigentlich nur in FHEM verarbeitet/gesteuert/... werden sollen, sondern noch andere Schnittstellen bedient werden müssen/sollen. Das ist vermutlich eher die Ausnahme, und z.B. für MQTT-basierte Visualisierungen dürfte auch MQTT2_SERVER immer noch als Server ausreichen.
Zum anderen braucht man so "0" externe Software, was die Zahl der potentiellen Fehlerquellen minimiert. Das ist m.E. (für viele "normale User") auch kein Fehler.

Aber wir können ja alle 12 Monate mal nachsehen, was "statistics" dazu meint .

[mifh]

 
Interessante Statistik. Ich vermute mal, dass sich das Verhältnis nur ändern würde, wenn die MQTT User auf MQTT2 umschwenken. Aber: "never change a running system". Ich denke, Du hast Recht. Wenn ich neu anfangen würde, liegt es nahe, erst mal den integrierten Server zu nutzen. Und das dann hinterher umzustellen, bedeutet eine Umkonfiguration jedes Clients.
Ich halte es zwar immer noch für die bessere Konstellation, einen separaten Broker zu haben.  Aber ich gebe zu, ich würde das selbst nicht so machen, würde ich neu starten.
Viele Grüße
Michael

[dev0]

Zu expandJSON kann ich wenig sagen, habe aber gewisse Zweifel, dass der string "false" als string behandelt wird. Eventuell wird das wie ein Wahrheitswert behandelt und da wird aus false auch schon mal ""...

In der expandJSON Doku steht im 3. Satz:

Additionally JSON::XS may be required if Boolean values (true/false) are missing. Package name for this lib is libjson-xs-perl or perl-JSON-XS

[mifh]

Wer lesen kann, ist klar im Vorteil. Die anderen brauchen Unterstützung 
Danke für den Hinweis. Ich probier's bei Gelegenheit mal aus.