Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

Begonnen von edy_80, 25 Oktober 2020, 19:06:36

Vorheriges Thema - Nächstes Thema

jazzor

Zitat von: Beta-User am 30 Mai 2022, 10:57:43
mqttPublish an den Geräten _konkret_ und _so_ zu setzen, dass _nur_ das raus geht, was auch interessiert. Bei 22k publishes (dein list) stellt sich die Frage, über welchen Zeitraum das zusammengekommen ist...
Ha Fehlannnahme dann meinerseits, ich dachte, nur die Readingsänderungen würden gepusht. Wie würde ich denn bspw den Status und das Reading "homekit_pos" publishen? Mit mqttPublish einfach status,homekit_pos eingeben bei dem Gerät?
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
Das ist ein (etwas) anderes Problem: Du hast  (@MQTT2_CLIENT)
a) keine Einschränkung der subscriptions, und
Verstehe ich, kümmere ich mich drum.
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
b) keine geänderte clientOrder
Hier kann ich dir nicht folgen. Finde bei keinem meiner Geräte das Attribut clientOrder. Kannst du mir sagen, wo ich suchen muss?
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
(Thermostatdummy klingt auch gruselig, und das log wäre in einem Anhang besser aufgehoben gewesen).
Das Log hat sich erfolgreich mehrmals den code-Tags widersetzt. Thermostatdummy ist leider eine Notwendigkeit, und der Name leider historisch gewachsen :P

Beta-User

Zitat von: jazzor am 30 Mai 2022, 20:34:25
Ha Fehlannnahme dann meinerseits, ich dachte, nur die Readingsänderungen würden gepusht. Wie würde ich denn bspw den Status und das Reading "homekit_pos" publishen? Mit mqttPublish einfach status,homekit_pos eingeben bei dem Gerät?
MQTT_GENERIC_BRIDGE reagiert auf "Events". Jedes "erfasste" Event wird auch gepublisht...

...jetzt habe ich die commandref schon so umgestellt, dass man die Beispiele direkt sieht, wenn man das Attribut auswählt, da steht nichts von einem Komma als Trenner...
"Status" bzw. "status" ist vermutlich "state"? Dann würde ich das auch direkt auf den "Haupttopic" publishen => unterschiedliche Topic-Angaben...

Zitat
Hier kann ich dir nicht folgen. Finde bei keinem meiner Geräte das Attribut clientOrder.
Bei meinem MQTT2_CLIENT-Device ist es da... Dein FHEM ist aktuell?

ZitatDas Log hat sich erfolgreich mehrmals den code-Tags widersetzt.
Ärgerliches, aber bekanntes Problem mit der Foren-Software. Daher der Hinweis, dass es in solchen "länglichen" Fällen besser als Anhang gepostet werden sollte.

Zitat
Thermostatdummy ist leider eine Notwendigkeit, und der Name leider historisch gewachsen :P
Wir können gerne wetten, aber nicht in diesem Thread...
Meine Erfahrung ist die: 95% aller irgendwo zu findenden TYPE=dummy sind überflüssig wie ein Kropf und machen das Gesamtsystem nicht einfacher zu durchschauen. (just my2ct).
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

Beta-User

Weitere Anmerkungen:

- Um das Einrichten zu vereinfachen, unterstützt MQTT_GENERIC_BRIDGE attrTemplate. Damit muss man sich als User eigentlich gar nicht mit den ganzen Details rumschlagen, sondern hat die Option, direkt einen "Satz" zusammenpassender Attribute zu erhalten (base_settings_to_MQTT_GENERIC_BRIDGE)...

Das macht aber z.B. aus guten Gründen keine retain-publishes, die dann dazu führen, dass man sowas im Log hat ;D :
2022.05.29 12:31:28 5: Starting notify loop for mqttGeneric, 23556 event(s),

- Es gibt auch für den einen oder anderen konkreten Anwendungsfall attrTemplate, um die "Klienten" der Bridge zu konfigurieren, allerdings bisher nicht für ROLLO (bei dem sich eh' die Frage stellt, warum es nicht invertiert wird, statt irgendeine Logik für das "homekit_pos"-Handling drumrum zu basteln... Mit gesetztem rl_type/HomeKit verhält sich ROLLO halt wie andere Kauf-Rollladenaktoren auch (soweit mir bekannt) bzw. wie Tasmota oder Shelly im Shutter-Modus... )

(Das mit den attrTemplate für MGB ist sicher nicht perfekt, das kann man  vermutlich durchaus noch verbessern, keine Frage).
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

jazzor

So, als aller-allererstes ein dickes DANKESCHÖN! :-)

Deine Hinweise waren genau die richtigen: Angefangen mit einer alten Version, über die Subscriptions bis zur clientOrder.

Nach ersten Tests scheint es jetzt vernünftig zu funktionieren, trotzdem würde ich mich freuen, wenn du mir sagen könntest, ob ich in dieser Konfiguration jetzt 'sauber' bin:
   
MQTT2_CLIENT:

defmod ha_MQTT2 MQTT2_CLIENT 192.168.0.20:1883
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr ha_MQTT2 icon mqtt
attr ha_MQTT2 ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 subscriptions fhem/set/#
attr ha_MQTT2 username mqtt_fhem


   
MQTT_GENERIC_BRIDGE :

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=MQTT_HA
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric icon mqtt_bridge_1
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0


Und bei den Rollos habe ich exemplarisch:

attr Rollo_Nr_01 mqttPublish state|homekit_pos:topic={"fhem/$device/$name"}
attr Rollo_Nr_01 mqttSubscribe state:stopic={"fhem/set/Rollo_Nr_01/state"} position_homekit:stopic={"fhem/set/Rollo_Nr_01/homekit_pos"}
attr Rollo_Nr_01


Mir ist allerdings noch aufgefallen, dass beim Horchen auf "fhem/#"  mit Mosquito/Homeassistant als erstes die Ganze Litanei eines Rollos kommt. Und zwar nicht nur state und homekit_pos sondern alle folgenden:
fhem/Rollo_Nr_01/homekit_pos
fhem/Rollo_Nr_01/position
fhem/Rollo_Nr_01/drive-type
fhem/Rollo_Nr_01/last_drive
fhem/Rollo_Nr_01/desired_position
fhem/Rollo_Nr_01/command
fhem/Rollo_Nr_01/state

Kann das sein, dass die aus Homeassistant selbst republished werden? Danke für die Hilfe! :)

Beta-User

Zitat von: jazzor am 02 Juni 2022, 19:37:10
So, als aller-allererstes ein dickes DANKESCHÖN! :-)
:) Danke für die Rückmeldung!

Zitat
Nach ersten Tests scheint es jetzt vernünftig zu funktionieren, trotzdem würde ich mich freuen, wenn du mir sagen könntest, ob ich in dieser Konfiguration jetzt 'sauber' bin:
Mir gefällt manches noch nicht, Kernpunkte: zu viel "Handarbeit", und "von außen" ist das Device nicht "standardkonform". Einen Rollladen will ich im Topic mit "pct" sehen, nicht mit "irgendwas, was grade da ist"...
Schnelle Stichworte: globalDefaults, $alias

Zitat
Mir ist allerdings noch aufgefallen, dass beim Horchen auf "fhem/#"  mit Mosquito/Homeassistant als erstes die Ganze Litanei eines Rollos kommt. [...]
Kann das sein, dass die aus Homeassistant selbst republished werden? Danke für die Hilfe! :)
Das ist eine Folge der ehemaligen pauschalen Publisherei mit "retain"-Flag, würde ich behaupten. Habe leider keine Ahnung, wie die aus dem von dir verwendeten MQTT-Server zu löschen wären, vielleicht, indem eine leere Info ohne Flag auf den Topic gesendet wird (ist aber mühsam, schon klar). Bei Mosquitto gäbe es da einen Schalter in der config; ist der nicht gesetzt, sind die retain-Messages nach einem Neustart des Mosquitto (afaik) weg...
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

jazzor

Nochmal ein dickes Dankeschön und kurz, falls zukünftig mal jemand ähnliche Problemchen haben sollte meine Lösung:
Zitat von: Beta-User am 03 Juni 2022, 09:10:50
zu viel "Handarbeit", und "von außen" ist das Device nicht "standardkonform". [...]
Schnelle Stichworte: globalDefaults, $alias
Habe deine Anmerkungen bzgl. Standardisierung umgesetzt.
Zitat von: Beta-User am 03 Juni 2022, 09:10:50
Das ist eine Folge der ehemaligen pauschalen Publisherei mit "retain"-Flag,
Absolut richtige Annahme. Ich habe die Software "MQTT-Explorer" genutzt, um alle alten retained-topics zu löschen. Das war jedenfalls die Lösung mit der schnellsten usability ;)
Vielen Dank nochmal!

Smarti

Zitat von: gadget am 21 Januar 2021, 17:16:41
ich hab meinen Post #2 mal angepasst auf die zwischenzeitlichen Ändernungen an der MQTT_GENERIC_BRIDGE. Zum Erstellungszeitpunkt hatte das noch alles so wie ursprünglich beschrieben funktioniert gehabt.

Kleiner Fehler: "password" anstatt "passwort"

Und inzwischen ist der Switch in HA als:
mqtt:
  switch:
  [..]

einzubinden...

C0mmanda

Moin moin,

der Thread hier hat mich schon recht weit gebracht, aber ich habe gerade ein Problem was mit etwas Kopfschmerzen bereitet... :(

Ich habe 2 Schalter angelegt,
Die Kommunikation FHEM -> HA funktioniert einwandfrei, aber bei der Kommunikation HA --> FHEM scheint es ein Problem zu geben.

In FHEM kann ich beide Schalter einzeln schalten und die werden auch korrekt in HA angezeigt.
Wenn ich aber in HA einen Schalter schalte, wird das (von HA?) an alle (beide) Topics gesendet, also es werden beide Schalter
gleich geschaltet.

Hier habe ich z.B. in HA nur den demoswitch "on" geschaltet:

SENT fhem/OG.gz.LI.TVLampe/state on
SENT fhem/demoswitch/state on
RCVD fhem/demoswitch/set on
RCVD fhem/OG.gz.LI.TVLampe/state on
RCVD fhem/demoswitch/state on


Wo liegt mein Fehler?

Mein MQTT-Client Device:

Internals:
   BUF       
   CFGFN     
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.1.221:1883
   DeviceName 192.168.1.221:1883
   FD         27
   FUUID      6384e931-f33f-dd8f-3500-360ec9207d56c8e8
   NAME       ha_MQTT2
   NR         264469
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhem
   eventCount 26
   lastMsgTime 1669663915.40313
   nextOpenDelay 5
   qosCnt     117
   qosMaxQueueLength 100
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2022-11-28 18:26:43   state           opened
   qosQueue:
Attributes:
   DbLogExclude .*
   clientId   fhem
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       Server
   username   hamqtt


Mein Bridge-Device:

Internals:
   BUF       
   CFGFN     
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.1.221:1883
   DeviceName 192.168.1.221:1883
   FD         27
   FUUID      6384e931-f33f-dd8f-3500-360ec9207d56c8e8
   NAME       ha_MQTT2
   NR         264469
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhem
   eventCount 26
   lastMsgTime 1669664156.19664
   nextOpenDelay 5
   qosCnt     117
   qosMaxQueueLength 100
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2022-11-28 18:26:43   state           opened
   qosQueue:
Attributes:
   DbLogExclude .*
   clientId   fhem
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       Server
   username   hamqtt


Schalter 1:

Internals:
   CFGFN     
   FUUID      63844f3b-f33f-dd8f-a83f-828d26612b3735ed
   LASTInputDev ha_MQTT2
   MSGCNT     40
   NAME       demoswitch
   NR         230561
   STATE      off
   TYPE       dummy
   eventCount 93
   ha_MQTT2_MSGCNT 40
   ha_MQTT2_TIME 2022-11-28 20:29:23
   READINGS:
     2022-11-28 20:29:23   state           off
Attributes:
   DbLogExclude .*
   mqttForward all
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS
   setList    on off
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     on:off


Mein zweiter Schalter:

Internals:
   DEF        0000F0FFFF FF F0
   FUUID      5c443666-f33f-02b0-cd30-019682e96cc09e0f
   IODev      CUL_Stick
   LASTInputDev ha_MQTT2
   MSGCNT     28
   NAME       OG.gz.LI.TVLampe
   NR         323
   STATE      off
   TYPE       IT
   XMIT       0000f0ffff
   XMITdimdown 00
   XMITdimup  00
   XMIToff    f0
   XMITon     ff
   eventCount 46
   ha_MQTT2_MSGCNT 28
   ha_MQTT2_TIME 2022-11-28 20:29:23
   CODE:
     1          0000f0ffff
   READINGS:
     2022-11-25 08:58:20   IODev           CUL_Stick
     2022-09-01 19:52:49   protocol        V1
     2022-11-28 20:29:23   state           off
Attributes:
   DbLogExclude .*
   IODev      CUL_Stick
   genericDeviceType light
   model      itswitch
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,Homekit,Licht
   userattr   OG.xx.LI.structType OG.xx.LI.structType_map mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude


Meine Config aus HA:


mqtt:
  switch:
    - unique_id: testswitch
      name: "Test Switch"
      state_topic: "fhem/demoswitch/state"
      command_topic: "fhem/demoswitch/set"
      payload_on: "on"
      payload_off: "off"
      state_on: "on"
      state_off: "off"
      qos: 0
      retain: true
      optimistic: false
     
    - unique_id: GaestezimmerLicht
      name: "GZ Lampe"
      state_topic: "fhem/OG.gz.LI.TVLampe/state"
      command_topic: "fhem/OG.gz.LI.TVLampe/set"
      payload_on: "on"
      payload_off: "off"
      state_on: "on"
      state_off: "off"
      qos: 0
      retain: true
      optimistic: false


Für meine Ahoy-DTU hatte ich mal ein MQTT_Server Device erstellt, kann das ein Problem sein?

Wäre echt dankbar wenn jemand eine Idee hat, ich komme einfach keinen Schritt weiter :(

Danke!

Beta-User

a) warum zeigst du 2 mal denselben MQTT2_CLIENT? Dort wäre aber bitte die clientOrder passend zu setzen, sonst kann es mittelfristig komische Effekte geben....
b) An der MQTT_GENERIC_BRIDGE kann man sich anzeigen lassen, was sie kennt (get-Befehl). Da sollten beide Switches an sich korrekt auftauchen.
c) Die Event-Abfolge dürfte umgedreht sein. Bitte checke mal, ob das auf der Homeassistant-Seite korrekt konfiguriert ist. Es kommen nämlich scheinbar zwei messages rein, was bedeutet, dass FHEM alles korrekt macht.
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

C0mmanda

Zitat von: Beta-User am 28 November 2022, 21:16:56
a) warum zeigst du 2 mal denselben MQTT2_CLIENT?

Fehler beim kopieren. Da sollte einmal ja list von der Matt-Bridge rein und nicht 2x der Client-Device...
Internals:
   CFGFN     
   DEF        mqtt room=HASS
   FUUID      6384ea99-f33f-dd8f-ab18-8a5983514813fa1e
   IODev      ha_MQTT2
   NAME       mqttGeneric
   NR         264699
   NTFY_ORDER 70-mqttGeneric
   STATE      in: 48 out: 113 devices: 2
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    room=HASS
   eventCount 118
   prefix     mqtt
   READINGS:
     2022-11-28 18:06:34   IODev           ha_MQTT2
     2022-11-28 18:26:43   device-count    2
     2022-11-28 21:31:28   incoming-count  48
     2022-11-28 21:31:28   outgoing-count  113
     2022-11-28 21:31:28   transmission-state outgoing publish sent
     2022-11-28 18:06:33   updated-reading-count 0
     2022-11-28 21:31:28   updated-set-count 84
   devices:
     :global:
       :alias:
       :defaults:
         pub:base   {"fhem/$device"}
         pub:qos    0
         pub:retain 1
         sub:base   {"fhem/$device"}
         sub:qos    2
         sub:retain 1
       :publish:
         *:
           mode       R
           topic      {"fhem/$device/$reading"}
     OG.gz.LI.TVLampe:
       :alias:
       :publish:
       :subscribe:
         HASH(0x55e08ad6f5d0)
     demoswitch:
       :alias:
       :publish:
       :subscribe:
         HASH(0x55e08aa134f8)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   subscribe:
Attributes:
   DbLogExclude .*
   globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
   globalPublish *:topic={"fhem/$device/$reading"}
   icon       mqtt_bridge_1
   room       Server
   stateFormat in: incoming-count out: outgoing-count devices: device-count
   verbose    0


ZitatDort wäre aber bitte die clientOrder passend zu setzen, sonst kann es mittelfristig komische Effekte geben....

Danke für den Hinweis.Was wäre aber dann der richtige Eintrag?
Syntax ist ja clientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]
Ich habe kein MQTT2_DEVICE angelegt. Gehört dann nur die Bridge da rein?

Zitatb) An der MQTT_GENERIC_BRIDGE kann man sich anzeigen lassen, was sie kennt (get-Befehl). Da sollten beide Switches an sich korrekt auftauchen.

Stimmt, das tun sie, alles korrekt. (get devlist)

Zitatc) Die Event-Abfolge dürfte umgedreht sein. Bitte checke mal, ob das auf der Homeassistant-Seite korrekt konfiguriert ist. Es kommen nämlich scheinbar zwei messages rein, was bedeutet, dass FHEM alles korrekt macht.

Ja das stimmt, die Event-Abfolge ist von unten nach oben zu lesen.
Wenn ich im HomeAssistant Broker auf alle Topics lausche (#) zeigt er mit diese Abfolge (ebenfalls von unten nach oben zu lesen)

Nachricht 7 empfangen auf fhem/OG.gz.LI.TVLampe/state um 21:47:
on
QoS: 0 - Retain: false
Nachricht 6 empfangen auf fhem/demoswitch/state um 21:47:
on
QoS: 0 - Retain: false
Nachricht 5 empfangen auf fhem/demoswitch/set um 21:47:
on


Alles was ich nach meinem Wissensstand auf HA-Seite konfigurieren kann ist dies:
mqtt:
  switch:
    - unique_id: testswitch
      name: "Test Switch"
      state_topic: "fhem/demoswitch/state"
      command_topic: "fhem/demoswitch/set"
      payload_on: "on"
      payload_off: "off"
      state_on: "on"
      state_off: "off"
      qos: 0
      retain: true
      optimistic: false
     
    - unique_id: GaestezimmerLicht
      name: "GZ Lampe"
      state_topic: "fhem/OG.gz.LI.TVLampe/state"
      command_topic: "fhem/OG.gz.LI.TVLampe/set"
      payload_on: "on"
      payload_off: "off"
      state_on: "on"
      state_off: "off"
      qos: 0
      retain: true
      optimistic: false


In den Broker-Einstellungen kann ich sonst nur Ports, User sowie Birth/Last Will einstellen....

Beta-User

Zitat von: C0mmanda am 28 November 2022, 21:58:33
   globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
   globalPublish *:topic={"fhem/$device/$reading"}
[/code]
[...]
Danke für den Hinweis.Was wäre aber dann der richtige Eintrag?
Syntax ist ja clientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]
Ich habe kein MQTT2_DEVICE angelegt. Gehört dann nur die Bridge da rein?
Brrr, ich habe da zum einen andere Vorstellungen zu fast allen Details und zum anderen als attrTemplate vercoded, was ich meine, was gut ist. Irgendwie sehe ich nicht so richtig ein, warum ich mir immer wieder die Finger wund schreibe (ist nicht persönlich gemeint). Im Wiki gibt es einen stub eines Artikels zu MQTT_GENERIC_BRIDGE, da ist erklärt, wie es (mAn.) funktioniert.

ZitatNachricht 7 empfangen auf fhem/OG.gz.LI.TVLampe/state um 21:47:

Ich habe keine Ahnung, wo #7 herkommt, und es paßt nicht zu dem, was du gezeigt hast (oder ich habe es übersehen)
Das müßte von dem anderen Switch in HASS kommen...
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

C0mmanda

Zitat von: Beta-User am 28 November 2022, 22:06:36
Brrr, ich habe da zum einen andere Vorstellungen zu fast allen Details und zum anderen als attrTemplate vercoded, was ich meine, was gut ist. Irgendwie sehe ich nicht so richtig ein, warum ich mir immer wieder die Finger wund schreibe (ist nicht persönlich gemeint). Im Wiki gibt es einen stub eines Artikels zu MQTT_GENERIC_BRIDGE, da ist erklärt, wie es (mAn.) funktioniert.

Hm, ok, kann ich sogar verstehen...Habe aus Unwissenheit auch nur als funktionierend "bestätigte" configs kopiert weil überhaupt keine Ahnung von MQTT.
Ich werde mir das wiki nochmal vornehmen.
Aber zu den attrTemplates muss ich leider sagen: funktioniert bei mir nicht.
Der "OK" Button im zweiten Schritt erscheint bei mir nicht und ich kann die Konfiguration nicht abschliessen. (Getestet in Safari + Firefox am Rechner sowie auf Safari am Handy)
Siehe dazu den Screenshot.

Zitat
Ich habe keine Ahnung, wo #7 herkommt, und es paßt nicht zu dem, was du gezeigt hast (oder ich habe es übersehen)
Das müßte von dem anderen Switch in HASS kommen...

Den Verdacht hatte ich auch schon, konnte aber auch nix finden. Werde weiter forschen und mich ggf. melden.
Danke für die Unterstützung bis hierher.

Gruß

Beta-User

Danke für den Versuch, ich schau's mir die Tage an, warum das nicht mehr funktioniert...

Es sollte trotzdem vor dem "set" angezeigt werden, was alles passieren kann (allerdings ist es wegen der Optionen etwas unübersichtich). Vielleicht hilft es auch so schon mal weiter.
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

Beta-User

Zitat von: Beta-User am 28 November 2022, 22:38:03
Danke für den Versuch, ich schau's mir die Tage an, warum das nicht mehr funktioniert...
Hmm, habe das mit aktuellem FHEM auf dem Testsystem grade nachzustellen versucht, es ist mir aber nicht gelungen... Zuerst hat sich meine neu erstellte MGB den bereits vorhandenen MQTT2_CLIENT geschnappt - da war aber u.a. clientOrder schon gesetzt => keine Rückfrage. Danach habe ich einen weiteren MQTT2_CLIENT erstellt, und die MGB nochmal angelegt => das Dialogfeld wird ordnungsgemäß angezeigt, (u.a.) OK ist vorhanden.

Ist dein FHEM halbwegs aktuell und ggf. der Browsercache mal gelöscht (es gab einige updates zum FHEMWEB-js-script)?
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

C0mmanda

Danke für's nachschauen.
Mein FHEM war -relativ- aktuell, hatte ich zuletzt vor ein oder zwei Wochen ge-updated.
Wie dem auch sei, heute nochmal ein Update gemacht, der attrTemplate setter hat funktioniert (lag aber vielleicht auch daran dass ich die Attribute mittlerweile manuell gesetzt hatte)

Dann bin ich noch einmal Schritt für Schritt das Wiki durchgegangen und habe alle Einstellungen gemacht und was soll ich sagen, aktuell funktioniert es scheinbar einwandfrei.
Werde jetzt mal in Ruhe Weitertesten und mich dann Schritt für Schritt an die eigentlichen devices machen.

Vielen Dank für den Schubs in die richtige Richtung!
Wenn ich wieder Probleme bekomme melde ich mich ;)

Danke & Gruß