Möglicherweise Bug in MQTT2_Client/MQTT_GENERIC_BRIDGE oder Verständnisproblem

Begonnen von gurkc006, 16 Februar 2024, 20:23:31

Vorheriges Thema - Nächstes Thema

gurkc006

Hallo zusammen,
ich habe ein Problem mit meinem MQTT-Setup. Ich befürchte, der Beitrag wird etwas länger, sorry dafür schon mal!  ;D
Ich habe einen externen MQTT-Broker. Mit diesem verbinde ich mich mit einem MQTT2_CLIENT:
define venusMQTT MQTT2_CLIENT 192.168.100.108:1883
attr venusMQTT autocreate no
attr venusMQTT clientId fhemVenusMqtt
attr venusMQTT clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr venusMQTT connectTimeout 60
attr venusMQTT disable 0
attr venusMQTT icon mqtt
attr venusMQTT keepaliveTimeout 30
attr venusMQTT mqttVersion 3.1.1
attr venusMQTT room Devices->MQTT
attr venusMQTT subscriptions setByTheProgram
attr venusMQTT verbose 3
#   BUF       
#   Clients    :MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:
#   ClientsKeepOrder 1
#   DEF        192.168.100.108:1883
#   DeviceName 192.168.100.108:1883
#   FD         67
#   FUUID      633fcb08-f33f-f3d4-c6a9-0f32db9a193cc2df
#   NAME       venusMQTT
#   NR         821
#   PARTIAL   
#   STATE      opened
#   TIMEOUT    60
#   TYPE       MQTT2_CLIENT
#   WBCallback
#   clientId   fhemVenusMqtt
#   eventCount 344
#   lastMsgTime 1708109343.11063
#   nextOpenDelay 10
#   nrConnects 4
#   MatchList:
#     1:MQTT_GENERIC_BRIDGE ^.
#     2:MQTT2_DEVICE ^.
#   READINGS:
#     2024-02-16 19:48:53   lastPublish     R/dca632079210/keepalive:{ "keepalive-options" : ["suppress-republish"] }
#     2024-02-16 18:12:37   state           opened
#
setstate venusMQTT opened
setstate venusMQTT 2024-02-16 19:48:53 lastPublish R/dca632079210/keepalive:{ "keepalive-options" : ["suppress-republish"] }
setstate venusMQTT 2024-02-16 18:12:37 state opened


Das scheint auch soweit gut zu klappen. Ursprünglich hatte ich mich an diesen MQTT2_CLIENT mit mehreren MQTT2_DEVICEs verbunden und dann über über das Attribut "readingList" die gewünschten readings rausgezogen. Das hat auch geklappt.
Problematisch war, dass der externe Broker ziemlich viele Nachrichten generiert (wen es interessiert: Victron VenusOS für Heimspeicher und ESS), so dass der Raspberry 3B+ mit einem Prozessor (fhem.pl) eigentlich durchgehend auf 100% lief.
Eine erste Diagnose zeigte, dass der externe Broker alle Nachrichten von allen Topics, die er empfängt, an FHEM sendet. Das liegt wohl an einem subscribe #.
Ich habe mir dann das ganze Thema MQTT2 und Attr Subscriptions angeschaut. Dort habe ich gefunden, dass, wenn keine Subscription gesetzt ist, der MQTT2_CLIENT einfach "#" subscribed, also alle Nachrichten. Das ist natürlich u.U. eher suboptimal, aber natürlich erstmal der einfachste Ansatz, da dann wenigstens irgendwas ankommt.
Um das mit dem # zu verhindern habe ich mir dann die Module mal im Source-Code angeschaut und dort gefunden, dass im MQTT2-CLIENT das Attribut "subscriptions" auf "setByTheProgram" gesetzt werden soll. Dann ist wohl die Idee, dass das interne Attribut "subscriptions" durch z.B. ein oder mehrere MQTT_GENERIC_BRIDGE gesetzt werden kann/soll.
Daher habe ich mir dann ein MQTT_GENERIC_BRIDGE angelegt:
define mqttBridgeVenus MQTT_GENERIC_BRIDGE mqttV
attr mqttBridgeVenus IODev venusMQTT
attr mqttBridgeVenus room Devices->MQTT
attr mqttBridgeVenus verbose 3
#   DEF        mqttV
#   FUUID      633fca48-f33f-f3d4-5d69-9229543f1766e37d
#   IODev      venusMQTT
#   NAME       mqttBridgeVenus
#   NR         820
#   NTFY_ORDER 70-mqttBridgeVenus
#   STATE      ???
#   TYPE       MQTT_GENERIC_BRIDGE
#   devspec    .*
#   eventCount 3
#   prefix     mqttV
#   READINGS:
#     2024-02-16 17:58:34   IODev           venusMQTT
#     2024-02-16 18:12:37   device-count    6
#     2024-02-16 17:58:32   incoming-count  0
#     2024-02-16 17:58:32   outgoing-count  0
#     2024-02-16 17:58:34   transmission-state IO device initialized (mqtt2)
#     2024-02-16 17:58:32   updated-reading-count 0
#     2024-02-16 17:58:32   updated-set-count 0
#   devices:
#     battery:
#       :publish:
#       :subscribe:
#         HASH(0x7e8f328)
#     ecu:
#       :publish:
#         maxTemp:
#           expression {'W/dca632079210/temperature/1/Temperature'=>'{"value":'.$value.'}'}
#     ess:
#       :publish:
#       :subscribe:
#         HASH(0x7e8f490)
#     gridmeter:
#       :publish:
#       :subscribe:
#         HASH(0x7e8f5f8)
#     pv_anbau:
#       :subscribe:
#         HASH(0x7e8f730)
#     pv_garden:
#       :subscribe:
#         HASH(0x7e8f868)
#   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:
#
setstate mqttBridgeVenus 2024-02-16 17:58:34 IODev venusMQTT
setstate mqttBridgeVenus 2024-02-16 18:12:37 device-count 6
setstate mqttBridgeVenus 2024-02-16 17:58:32 incoming-count 0
setstate mqttBridgeVenus 2024-02-16 17:58:32 outgoing-count 0
setstate mqttBridgeVenus 2024-02-16 17:58:34 transmission-state IO device initialized (mqtt2)
setstate mqttBridgeVenus 2024-02-16 17:58:32 updated-reading-count 0
setstate mqttBridgeVenus 2024-02-16 17:58:32 updated-set-count 0


Um dieses zu nutzen, habe ich dann in einigen MQTT2_DEVICEs das passende Attribut "mqttVSubscribe" gesetzt. Z.B. hier in diesem Device:
define ess MQTT2_DEVICE
attr ess IODev mqttBridgeVenus
attr ess autocreate 0
attr ess event-min-interval .*:5
attr ess icon mqtt
attr ess mqttVSubscribe dummy:topic=N/dca632079210/system/0/Ac/Consumption/#
attr ess readingList N/dca632079210/system/0/Ac/Consumption/L1/Power:.* {{power_L1=>sprintf('%.1f', decode_json($EVENT)->{value}) }}\
N/dca632079210/system/0/Ac/Consumption/L2/Power:.* {{power_L2=>sprintf('%.1f', decode_json($EVENT)->{value}) }}\
N/dca632079210/system/0/Ac/Consumption/L3/Power:.* {{power_L3=>sprintf('%.1f', decode_json($EVENT)->{value}) }}
attr ess room Devices->MQTT,Rooms->Strom
attr ess stateFormat {sprintf("%.0f W", ReadingsVal($name,"power",0))}
attr ess userReadings power { ReadingsVal("ess","power_L1",0)+ReadingsVal("ess","power_L2",0)+ReadingsVal("ess","power_L3",0) }
#   FUUID      641b4682-f33f-f3d4-e07e-0769549c52a13f9a
#   IODev      mqttBridgeVenus
#   LASTInputDev venusMQTT
#   MSGCNT     19470
#   NAME       ess
#   NR         833
#   STATE      532 W
#   TYPE       MQTT2_DEVICE
#   eventCount 4805
#   venusMQTT_MSGCNT 19470
#   venusMQTT_TIME 2024-02-16 20:00:35
#   READINGS:
#     2024-02-16 17:58:33   IODev           mqttBridgeVenus
#     2024-02-16 20:00:35   power           532.1
#     2024-02-16 20:00:35   power_L1        441.8
#     2024-02-16 20:00:35   power_L2        52.9
#     2024-02-16 20:00:34   power_L3        37.4
#
setstate ess 532 W
setstate ess 2024-02-16 17:58:33 IODev mqttBridgeVenus
setstate ess 2024-02-16 20:00:35 power 532.1
setstate ess 2024-02-16 20:00:35 power_L1 441.8
setstate ess 2024-02-16 20:00:35 power_L2 52.9
setstate ess 2024-02-16 20:00:34 power_L3 37.4


Das Problem was ich nun habe ist folgendes: Wenn ich FHEM neu starte, dann wird entweder...

a) der MQTT2_CLIENT wird zuerst initialisiert. Dann ist das interne Attribut "subscriptions" (noch) nicht gesetzt und daher wird eine Subscription auf "#" gemacht, was dann zu sehr vielen Nachrichten führt. Die MQTT_GENERIC_BRIDGE wird danach initialisiert, die checkt alle Devices ab und bildet eine Liste mit allen Topics, die subscribed werden sollen. Danach wird dann das interne Attribut "subscriptions" vom MQTT2_CLIENT beschrieben (IOWrite($hash, "subscriptions", join(" ", @new));). Das Problem scheint zu sein, dass das der MQTT2_CLIENT nicht mitbekommt und daher die Subscription auf "#" nicht wieder aufhebt. Oder ich habe das nicht gefunden...

b) Die MQTT_GENERIC_BRIDGE wird zuerst initialisiert. Die Liste der Subscriptions wird aufgebaut und am Ende wird versucht, das interne Attribut "subscriptions" des MQTT2_CLIENT zu setzen. Das geht aber natürlich noch nicht, da das der ja noch gar nicht initialisiert ist. Den gibt's noch gar nicht. Dann wird später der MQTT2_CLIENT initialisiert und dann kommt natürlich wieder das "#".

Was funktioniert ist, wenn ich nach einem FHEM-Restart einen der Attribute mqttVSubscribe in einem meiner MQTT2_DEVICEs setze (gerne auch auf den schon vorhandenen Wert). Das triggert intern dann, dass die "dranhängende" MQTT_GENERIC_BRIDGE intern die Liste aller notwendigen Subscriptions neu aufbaut und in das interne Attrribut "subscriptions" vom MQTT2_CLIENT überträgt (aber leider keinen disconnect und connect auslöst).
Wenn ich dann von Hand den MQTT2_CLIENT Disconnecte und wieder connecte, dann geht es wie gewünscht und es werden nur noch die notwendigen Topics subscribed.
Im Prinzip bin ich im Source Code in 10_MQTT_GENERIC_BRIDGE.pm im sub UpdateSubscriptions fündig geworden. Ich habe da mal noch etwas debug code eingebaut (markiert mit #cg):
  if(isIODevMQTT2_CLIENT($hash)) {
    # MQTT2 Subscriptions
    Log3($hash->{NAME},1,"MQTT_GENERIC_BRIDGE:DEBUG:> [$hash->{NAME}] UpdateSubscriptions: IODevice is MQTT2_CLIENT "); #cg
    IOWrite($hash, "subscriptions", join(" ", @new));
    my $iodt = retrieveIODevType($hash); #cg
    #MQTT2_CLIENT_Disco($iodt); #cg
  }


Leider weiß ich nicht, ob das ganze überhaupt so Sinn macht. Kann ich in dem Modul MQTT_GENERIC_BRIDGE irgendwie einen reconnect in dem $iodt auslösen?
Sorry für den langen Post, aber ich wollte versuchen,das Problem so gut ich kann zu beschreiben.
Freue mich über Hilfe oder Ideen!  :)
lg
Christian

DasQ

Kurze Antwort

Ne das macht kein Sinn. Wirf den externen Broker über Board und lass alles vom fhem mqtt2 Server erledigen. Erspart dir echt an haufen wirr Ware.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

betateilchen

Zitat von: gurkc006 am 16 Februar 2024, 20:23:31Ich habe einen externen MQTT-Broker. Mit diesem verbinde ich mich mit einem MQTT2_CLIENT:
...
Problematisch war, dass der externe Broker ziemlich viele Nachrichten generiert

Du hast zusätzlich auch ein Verständnisproblem:

  • Ein MQTT Broker generiert keine Nachrichten.
  • Er empfängt Nachrichten von MQTT clients und verteilt sie an andere MQTT clients weiter, die sich dafür interessieren.

Aber eine Notwendigkeit für eine MQTT_BRIDGE kann ich in Deinem Szenario noch nicht erkennen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

gurkc006

Hallo!
@DasQ: danke für die schnelle Rückmeldung. Leider kann ich den externen Broker nicht aufgeben, der ist zentraler Teil meines Victron Hausspeichersystems (mit mehreren PV-Invertern, Gridmetern, Batteriemonitor). Das steht leider außer Frage, dass ich den externen Broker brauche. Grundsätzlich sollte das ja auch kein Problem sein.
Wenn ich bei diesem Broker auf alles subscribe (was MQTT2-CLIENT macht), dann laufen ca. 7000 Messages pro Minute ein. Das ist leider für den Raspi/FHEM scheinbar etwas zu viel.
Daher möchte ich gerne nur die Topics subscriben, die ich wirklich brauche. Das funktioniert ja, wenn ich es mit meiner manueller Methode mache.
Nur leider verstehe ich selbst nach Studium des Source-Codes nicht so richtig, wann der MQTT2_CLIENT von einer dranhängenden MQTT_GENERIC_BRIDGE mit mehreren MQTT2_DEVICEs die gesetzen mqttSubscribe-Attribute übergeben bekommt. Ich vermute, dass das beim Initialisieren aneinander vorbeiläuft. Es gab da auch schon mal eine Thread zu: https://forum.fhem.de/index.php?topic=124353.0
Dort wurde genau das vermutet, dass die Reihenfolge irgendwie eine Rolle spielen könnte.

@betateilchen: Danke auch für Deine Rückmeldung. Klar, der Broker generiert von sich aus keine Nachrichten. Aber von FHEM aus gesehen, bekommt FHEM von dem Broker die Nachrichten (bei Subscribe auf "#" ca. 100/s), die das Victron-System hintendran generiert.
Die Notwendigkeit von der Bridge kommt daher, dass ich irgendwie versuche, dem MQTT_CLIENT beizubringen, dass er nicht auf "#" subscriben soll (weil dann zu viele Nachrichten kommen), sondern nur auf bestimmte Topics bzw. Topic-Bereiche. Ich könnte dann wohl alle Topcis in das "subscriptions"-Attrribut vom MQTT2_CLIENT schreiben. Dummerweise wird mir in der Weboberfläche bei DIESEM Attribut nicht der Editor geöffnet, so dass das sehr unübersichtlich würde (ich benötige im Moment ca. 5 Topics).
Ich habe dann in der Referenz und im Source-Code gesehen, dass eine MQTT_GENERIC_BRIDGE (MGB) sich die "subscriptions"-Attribute von allen assoziierten MQTT2_DEVICES einsammelt und diese dann an das IO-Device (in meinem Fall der MQTT2_CLIENT) weitergibt. Das macht total Sinn, dann stehen die für die einzelnen Devices notwendigen Subscriptions auch bei den Devices (Objektorientierter Ansatz).
Mein Problem ist, dass das Sammeln der Subscriptions von der MGB nur ganz am Anfang oder bei Änderung eines Subscriptions-Attributes eines assoziierten Device.
Jetzt bin ich wieder bei meinen zwei Fällen:
a) Wenn die MGB zuerst initialisiert wird, gibts den MQTT2_CLIENT scheinbar noch gar nicht und er kann seine gesammelten Subscriptions nirgendwo eintragen. Egal, passiert ja nix. Allerdings startet dann danach irgendwann der MQTT2_CLIENT, sieht, ich habe keine Subscription von "außerhalb" und subscribed daher auf "#"
b) Wenn der MQTT2_CLIENT zuerst initialisiert wird, dann hat er natürlich auch noch kein subscriptions-Attribut und subscribed auch auf "#". Später startet dann irgendwann die MGB, sammelt ihre Subscriptions ein und überträgt sie an den MQTT2_CLIENT, aber der macht dann nix. Er müsst in dem Fall, dass sich sein internes subscription-Attribut ändert im Idealfall die alten Subscriptions unsubscriben und dann die neuen subscriben. Oder einfacher die Verbindung zum Broker trennen und eine neue aufbauen und dann die neuen Subscriptions zum Broker schicken.
Es tut mir leid, wenn das immer etwas länglicher wird, aber ich verstehs einfach nicht richtig.
Ich hab mir schon alle möglichen Debug-Outputs in den Source-Code gebastelt, um zu verstehen, wie die MGB den MQTT2_CLIENT benachrichtigt, bin aber nicht fündig geworden. Ich habe leider bisher nicht in PERL programmiert, kann aber grundsätzlich in verschiedenen anderen Sprachen programmieren.
Ich habe den Verdacht, dass dieser Subscriptions-Mechanismus nicht von vielen benutzt wird und daher vielleicht noch nicht ganz zu Ende programmiert ist? Ich würde da je gerne helfen, damit das richtig funktioniert.
Viele liebe Grüße, Christian


Beta-User

Kurz zum Hintergrund:
Nach meinem Codeverständnis wird der Verbindungsaufbau erst nach FHEM-Start per timer ausgelöst, und erst danach werden dann auch die subscriptions übermittelt. . Sieht zumindest auf den ersten Blick "sauber" aus, "eigentlich" sollte ein Client mit "setByTheProgram" keine Probleme machen.

@Rudi: Allerdings verwendet auch MGB "1" als Timer-Vorgabe für den "Start-Internaltimer". Demnach kommt es uU. doch auf die Frage an, welches Modul zuerst initialisiert wird, oder? Sollten wir da "2" (für CLIENT) draus machen...?

(@gurkc006: vielleicht könntest du mal ausprobieren, ob das das Reihenfolgeproblem löst, wenn du https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MQTT2_CLIENT.pm#L103 entsprechend anpaßt?)

Das Konzept, das hier per MQTT_GENERIC_BRIDGE sammeln zu lassen, aber MQTT2_DEVICE zu verwenden, halte ich für fragwürdig, weil dann gar nicht mehr klar ist, wo was herkommt.

Prinzipiell sollte es doch möglich sein, das subscriptions-Attribut passend zu füllen? Da gehen ja auch (MQTT-) Wildcards etc..

@Rudi: Ich sehe eventuell (für die Phase der erstmaligen Definition?) den Bedarf für einen connect ohne "totale Subscription", wenn man sich - wie hier - mit einem Server verbinden muss, der sehr viele Topics liefert (z.B. indem man im define gleich noch "setByTheProgram" mit angibt, damit das Attribut direkt (initial) definiert wird und bereits da ist, wenn der Timer zuschlägt. Danach sollte man dann ja in Ruhe "seine" subscriptions passend zusammensuchen können, und sowas "ganz normal" via MQTT2_DEVICE zu lösen...
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

gurkc006

Hab das mit der Verzögerung von 2 und 10 probiert, macht keinen Unterschied. Aber das ist schonmal ein guter Hinweis, dass das Verbinden generell verzögert passiert.
Problem ist irgendwie, dass in 00_MQTT2_CLIENT.pm L202ff die Abfrage passiert, ob dieses Stichwort "setByTheProgram" gesetzt ist:
202     if($s eq "setByTheProgram") {
203       $s = ($hash->{".subscriptions"} ? $hash->{".subscriptions"} : "#");
204     }

Das klappt auch wie gewünscht. ABER in der folgenden Zeile kommt die Abfrage, ob $hash->{".subscriptions"} gesetzt ist und das ist scheinbar nicht der Fall. Dieser Wert ist initial irgendwie NULL, also leer. Daher die Subscription auf "#".
Ich schau mir mal an, in welcher Reihenfolge die Initialisierungen erfolgen, also ob es beim Starten von der MGB schon das MQTT2_DEVICE gibt... Melde mich gleich...

Beta-User

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

gurkc006

Ich habe mal ein paar Logs eingebaut. Hier der Start meines FHEMs (alle unwichtigen Logs entfernt):

2024.02.17 18:05:52 1:  Logfile gelöscht
2024.02.17 18:05:57 0:  Server shutdown
2024.02.17 18:06:03 1:  Including fhem.cfg
2024.02.17 18:06:03 2:  eventTypes: loaded 6559 lines from ./log/eventTypes.txt
2024.02.17 18:06:16 2:  MQTT_GENERIC_BRIDGE () initalize
2024.02.17 18:06:17 2:  MQTT_GENERIC_BRIDGE (mqttBridgeVenus) define
2024.02.17 18:06:17 2:  MQTT2_CLIENT_Define
2024.02.17 18:06:18 1:  Including ./log/fhem.save
2024.02.17 18:06:20 2:  MQTT_GENERIC_BRIDGE (mqttBridgeVenus) firstInit
2024.02.17 18:06:20 2:  MQTT_GENERIC_BRIDGE (mqttBridgeVenus) updateSubscriptions
2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(pv_garden) = $VAR1 = {
          ':subscribe' => [
                            {
                              'topicExp' => '^.*N\\/dca632079210\\/pvinverter\\/1\\/Ac\\/#$',
                              'wildcardTarget' => '',
                              'dev' => 'pv_garden',
                              'topic' => 'N/dca632079210/pvinverter/1/Ac/#',
                              'mode' => 'R',
                              'reading' => 'dummy',
                              'topicOrig' => 'N/dca632079210/pvinverter/1/Ac/#'
                            }
                          ]
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(pv_anbau) = $VAR1 = {
          ':subscribe' => [
                            {
                              'mode' => 'R',
                              'reading' => 'dummy',
                              'topicOrig' => 'N/dca632079210/system/0/Dc/Pv/#',
                              'topicExp' => '^.*N\\/dca632079210\\/system\\/0\\/Dc\\/Pv\\/#$',
                              'wildcardTarget' => '',
                              'dev' => 'pv_anbau',
                              'topic' => 'N/dca632079210/system/0/Dc/Pv/#'
                            }
                          ]
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(ess) = $VAR1 = {
          ':subscribe' => [
                            {
                              'topicOrig' => 'N/dca632079210/system/0/Ac/Consumption/#',
                              'reading' => 'dummy',
                              'mode' => 'R',
                              'topic' => 'N/dca632079210/system/0/Ac/Consumption/#',
                              'dev' => 'ess',
                              'wildcardTarget' => '',
                              'topicExp' => '^.*N\\/dca632079210\\/system\\/0\\/Ac\\/Consumption\\/#$'
                            }
                          ]
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(gridmeter) = $VAR1 = {
          ':subscribe' => [
                            {
                              'topicOrig' => 'N/dca632079210/grid/30/Ac/#',
                              'reading' => 'dummy',
                              'mode' => 'R',
                              'topic' => 'N/dca632079210/grid/30/Ac/#',
                              'dev' => 'gridmeter',
                              'wildcardTarget' => '',
                              'topicExp' => '^.*N\\/dca632079210\\/grid\\/30\\/Ac\\/#$'
                            }
                          ]
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(battery) = $VAR1 = {
          ':subscribe' => [
                            {
                              'reading' => 'dummy',
                              'topicOrig' => 'N/dca632079210/battery/1/#',
                              'mode' => 'R',
                              'dev' => 'battery',
                              'topic' => 'N/dca632079210/battery/1/#',
                              'topicExp' => '^.*N\\/dca632079210\\/battery\\/1\\/#$',
                              'wildcardTarget' => ''
                            }
                          ]
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: smap(ecu) = $VAR1 = {
          ':publish' => {
                          'maxTemp' => {
                                         'expression' => '{\'W/dca632079210/temperature/1/Temperature\'=>\'{"value":\'.$value.\'}\'}'
                                       }
                        }
        };

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: topics = $VAR1 = 'N/dca632079210/system/0/Ac/Consumption/#';
$VAR2 = 'N/dca632079210/pvinverter/1/Ac/#';
$VAR3 = 'N/dca632079210/system/0/Dc/Pv/#';
$VAR4 = 'N/dca632079210/battery/1/#';
$VAR5 = 'N/dca632079210/grid/30/Ac/#';

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: remove =
2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: new = $VAR1 = 'N/dca632079210/system/0/Ac/Consumption/#';
$VAR2 = 'N/dca632079210/pvinverter/1/Ac/#';
$VAR3 = 'N/dca632079210/system/0/Dc/Pv/#';
$VAR4 = 'N/dca632079210/battery/1/#';
$VAR5 = 'N/dca632079210/grid/30/Ac/#';

2024.02.17 18:06:20 1:  MQTT_GENERIC_BRIDGE:DEBUG:> [mqttBridgeVenus] UpdateSubscriptions: IODevice is MQTT2_CLIENT
2024.02.17 18:06:20 0:  Featurelevel: 6.3
2024.02.17 18:06:20 0:  Server started with 317 defined entities (fhem.pl:28484/2024-02-06 perl:5.028001 os:linux user:fhem pid:26531)
2024.02.17 18:06:20 2:  MQTT2_CLIENT_Connect
2024.02.17 18:06:21 2:  MQTT2_CLIENT_doinit (hash.connecting=1)
2024.02.17 18:06:21 1:  192.168.100.108:1883 reappeared (venusMQTT)
2024.02.17 18:06:21 2:  MQTT2_CLIENT_doinit (hash.connecting=2)
2024.02.17 18:06:21 2:  venusMQTT: attr subscriptons = setByTheProgram
2024.02.17 18:06:21 2:  venusMQTT: .subscriptions = null
2024.02.17 18:06:22 2:  MQTT2_CLIENT_doinit (hash.connecting=3)

Wie schon bisher, bei der vorletzten Zeile, diese .subscriptions = null. Der Code, den ich zum loggen habe lautet:

    if($s eq "setByTheProgram") {
      Log3 $name, 2, "$hash->{NAME}: attr subscriptons = setByTheProgram"; #cg
      if($hash->{".subscriptions"}) { #cg
my $subs = $hash->{".subscriptions"}; #cg
        Log3 $name, 2, "$hash->{NAME}: .subscriptions = ${subs}"; #cg
      } else {#cg
        Log3 $name, 2, "$hash->{NAME}: .subscriptions = null"; #cg
  } #cg
      $s = ($hash->{".subscriptions"} ? $hash->{".subscriptions"} : "#");
    }

Keine Ahnung, warum die zu diesem Zeitpunkt NULL sind?!?!

betateilchen

ZitatDummerweise wird mir in der Weboberfläche bei DIESEM Attribut nicht der Editor geöffnet, so dass das sehr unübersichtlich würde (ich benötige im Moment ca. 5 Topics).

Das kannst Du doch per Attribut widgetOverride selbst steuern?

Den Ansatz mit der MQTT_GENERIC_BRIDGE verstehe ich immer noch nicht. Für mich ist das irgendwie ein Holzweg.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

gurkc006

Guten Morgen!
Danke betateilchen für den Hinweis mit dem widgetOverride. Das kannte ich noch gar nicht :-)
Ich habe mein Setup dann tatsächlich mal vereinfacht, also nur noch den MQTT2_CLIENT mit meinen notwendigen Subscriptions im Attribut "subscriptions" statt dem "setByTheProgram". Dann die MQB rausgeworfen und dann die verschiedenen MQTT2_DEVICEs direkt an den MQTT2_CLIENT "gehängt" mit dem Attribut "IODev".
Das läuft jetzt dann auch nach einem Restart problemlost.
Für mich wäre mein Problem damit erstmal gelöst, vielen Dank für das Mitdenken!
lg
Christian

betateilchen

Zitat von: gurkc006 am 18 Februar 2024, 10:26:35Das kannte ich noch gar nicht

Du scheinst einiges noch nicht zu kennen.

Noch eine Anmerkung hierzu:

Zitat von: gurkc006 am 18 Februar 2024, 10:26:35und dann die verschiedenen MQTT2_DEVICEs direkt an den MQTT2_CLIENT "gehängt" mit dem Attribut "IODev".

Das muss man normalerweise nicht selbst machen, es sei denn, Du hast mehrere MQTT2_CLIENT definiert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Schön, dass es erst mal funktioniert wie gedacht.

Trotzdem wäre es interessant gewesen zu erfahren, warum der Automatismus von MGB nicht funktioniert. Bei RHASSPY klappt das nämlich...

@Rudi (falls du hier mit liest): irgend eine Idee?
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

gurkc006

Zitat von: betateilchen am 18 Februar 2024, 11:44:24
Zitat von: gurkc006 am 18 Februar 2024, 10:26:35Das kannte ich noch gar nicht

Du scheinst einiges noch nicht zu kennen.


DAS stimmt sicherlich :-)
Der Hinweis mit dem IODev ist auch interessant, allerdings würde ich gerne den jetzt für andere Devices genutzten FHEM-eigenen MQTT-Broker durch flashMQ ersetzen. Damit erhoffe ich mir, dass der FHEM-Prozess noch etwas entlastet wird. Daher werde ich zukünftig das Attr IODev wohl wieder brauchen. Aber trotzdem gut zu wissen :-)
lg