Werte Stromzähler per MQTT publishen

Begonnen von karpate, 24 September 2021, 07:40:01

Vorheriges Thema - Nächstes Thema

karpate

Hallo zusammen,
dies ist sicher eine Anfängerfrage und kann auch gerne ins Anfängerforum verschoben werden.
Am Laufen habe ich den FHEM MQTT Server und bisher ein Device (Wasseruhr) damit verbunden. Empfang der Topcis funktioniert seit einwandfrei.
Jetzt möchte ich das Reading power meines Stromzählers per MQTT (an evcc) übergeben. Dafür habe ich das device MQTT_GENERIC_BRIDGE angelegt und im Stromzähler das Attribut mqttPublish power:topic=keller/strom/zaehler. Da die Counts der Bridge bisher 0 zählen, vermute ich das noch etwas an meiner Konfiguration fehlt.
Kann mir jemand eine Starthilfe geben?
Auf der Empfänger-Seite (evcc), wäre die Subscription einfach keller/strom/zaehler?
Danke Ingo

list ITR_Stromzaehler
Internals:
   FUUID      xxx
   NAME       ITR_Stromzaehler
   NR         1291
   STATE      Aktuell: 263.0 W, Zählerstand 1.8.0: 10433 kWh seit 24.9., 07:27.
   TYPE       dummy
   READINGS:
     2021-09-24 07:27:29   1.8.0_Verbrauch 10433282.9
     2021-09-24 07:27:29   2.8.0_Einspeisung 0
     2021-09-24 07:27:29   ManufID2        ITR
     2021-09-24 07:27:30   power           263
Attributes:
   group      UG_Technik
   icon       icoBlitz
   mqttPublish power:topic=keller/strom/zaehler
   room       0_Keller


list mqttGenericBridge
Internals:
   CFGFN     
   FUUID      xxx
   IODev      MQTT2_FHEM_Server
   NAME       mqttGenericBridge
   NR         27575
   NTFY_ORDER 50-mqttGenericBridge
   STATE      dev: 1 in: 0 out: 0
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     mqtt
   READINGS:
     2021-09-23 20:23:53   IODev           MQTT2_FHEM_Server
     2021-09-23 21:31:35   device-count    1
     2021-09-23 20:23:52   incoming-count  0
     2021-09-23 20:23:52   outgoing-count  0
     2021-09-23 20:23:52   updated-reading-count 0
     2021-09-23 20:23:52   updated-set-count 0
   devices:
     ITR_Stromzaehler:
       :alias:
       :publish:
         power:
           mode       R
           topic      keller/strom/zaehler
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
Attributes:
   room       999_Kommunikation
   stateFormat dev: device-count in: incoming-count out: outgoing-count


list MQTT2_FHEM_Server
Internals:
   CONNECTS   9
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         73
   FUUID      xxx
   NAME       MQTT2_FHEM_Server
   NR         1233
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-09-24 07:14:28   RETAIN          {"wasserzaehler/connection":"connection lost","wasserzaehler/main/error":"Neg. Rate - Read: 362.1181 - Raw: 362.11812 - Pre: 362.1182 "}
     2021-09-23 21:33:05   nrclients       1
     2021-09-20 16:10:51   state           Initialized
   clients:
     MQTT2_FHEM_Server_192.168.xxx.xxx_54274 1
   retain:
     wasserzaehler/connection:
       ts         1632147100.17658
       val        connection lost
     wasserzaehler/main/error:
       ts         1632460468.13069
       val        Neg. Rate - Read: 362.1181 - Raw: 362.11812 - Pre: 362.1182
Attributes:
   room       999_Kommunikation
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

Bei TYPE=dummy stellt sich die Frage, wie das Reading da hinein gelangt? MQTT_GENERIC_BRIDGE ist in Senderichtung als Event-Handler ausgelegt.

Evtl. gibt es einen weiteren Punkt, der mir schon länger im Hinterkopf rumschwirrt, aber dazu ggf. später mehr. Bitte dazu vorab dann ein list von dem anderen Event-Handler einstellen.
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

antonwinden

Mir stellt sich da eher die Frage: Wohin schickt du die Messages?
Wenn der MQTT Server auf dem gleichen Gerät ist warum dann den Umweg?
Wenn nicht wo ist auf dem Sendegerät die Def des Servers?
gruß anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Beta-User

M.E. verwirrt diese Antwort eher, er sendet an einen externen Client:
Auf der Empfänger-Seite (evcc), wäre die Subscription einfach keller/strom/zaehler?

Und das wäre schon passend, wenn was auf den Topic rausginge; tut es aber aus "irgendwelchen" Gründen nicht...
Vermutung: Reihenfolgeproblem beim Aufrufen der beteiligten Eventhandler (der Name bestimmt die Reihenfolge, MGB ist vor dem anderen), man sollte eventuell im Modulcode was setzen:
Zitat
$hash->{NotifyOrderPrefix} = "55-"  # Alle Definitionen des Moduls X werden bei der Eventverarbeitung als letztes geprüft
@karpate: Evtl. kannst du das direkt mal austesten, dann lasse ich @hexenmeister einen passenden Patch zukommen.
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

karpate

Danke für die schnellen Antworten
Ich habe vergessen zu erwähnen, das der Stromzähler physisch an einer zweiten fhem-Instanz hängt, welche per FHEM2FHEM an den Dummy der Hauptinstanz übergeben wird.

@Beta-User:
ZitatBitte dazu vorab dann ein list von dem anderen Event-Handler einstellen
Meinst du damit den eigentlichen Sensor an der Zweitinstanz?
list ITR_Stromzaehler
Internals:
   DEF        /dev/ttyUSB0@9600,8,N,1 SML
   DeviceName /dev/ttyUSB0@9600,8,N,1
   FD         9
   FUUID      xxx
   MeterType  SML
   NAME       ITR_Stromzaehler
   NR         20
   PARTIAL   
   STATE      Aktuell: 285.0 W, Verbrauch: 10434 kWh seit 24.9., 11:27.
   TYPE       OBIS
   READINGS:
     2021-09-24 11:27:17   1.8.0_Verbrauch 10434633.2
     2021-09-24 11:27:17   2.8.0_Einspeisung 0
     2021-09-24 11:27:17   ManufID2        ITR
     2021-09-24 11:27:17   power           285
     2021-09-12 07:26:22   state           opened
   helper:
     BUFFER     
     EoM        1
     LastPacketTime 1632475637.67684
     SPEED      5
     SPEED2     5
     TRIGGERTIME 1631424382.46779
     Channels:
       1-0:1.8.0*255 1.8.0_Verbrauch
       1-0:2.8.0*255 2.8.0_Einspeisung
     DEVICES:
       
       10
       
     RULECACHE:
       1-0:16.7.0*255 Channels
       1-0:96.50.1*1 ManufID2
Attributes:
   channels   {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
   interval   10
   pollingMode on
   room       Stromzähler
   stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }


ZitatEvtl. kannst du das direkt mal austesten, dann lasse ich @hexenmeister einen passenden Patch zukommen.
Die "hash"-Zeile würde ich im Modul 10_MQTT_GENERIC_BRIDGE.pm im Bereich ab Zeile 525 einfügen. Oder spielt das keine Rolle?

@anton
die Meldung soll an einen weiteren Server mit evcc gehen. Auf dieser Seite kommt die Meldung das er sich am Broker des MQTT2_FHEM_Server erfolgreich anmeldet, aber erhält keine Readings.
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

Hmm, F2F ist außerhalb meines Erfahrungssschatzes, aber mit "ab Zeile 525" liegst du richtig (bitte ein ";" ans Ende hängen, das fehlte im Wiki, und evtl. gleich "deutlich" verschieben, schlage mal "70" vor).
Dann werden wir ja sehen. Falls der neue Eintrag nach einem reinen "reload" noch nicht in den Internals sichtbar ist => Neustart von FHEM.
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

karpate

In Zeile 533 habe ich den Eintrag eingefügt

$hash->{NotifyOrderPrefix} = "70";  # Alle Definitionen des Moduls X werden bei der Eventverarbeitung als letztes geprüft

anschließend ein Modul Reload ...nichts,
dann ein "Shutdown Restart"...leider immer noch keine outgoing counts der Bridge
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

Wirft denn der dummy Events, wenn er aktualisiert wird (sollte eigentlich schon).

Mit folgendem Test habe ich keine Probleme feststellen können:
defmod ITR_Stromzaehler dummy
attr ITR_Stromzaehler mqttPublish power:topic=keller/strom/zaehler
attr ITR_Stromzaehler readingList power

(Ob readingList erforderlich ist? Glaube nicht, dein Reading wird ja gefüllt).

Ein via Kommandozeile eingegebenes
set ITR_Stromzaehler power 33
publisht dann die "33" sauber auf den angegebenen Topic.

Würde jetzt also mal testweise den Wert auch via "set" (oder "setreading") manuell setzen, dann müßte zumindest der counter hochgehen. Wenn nicht, ist was grundsätzlich verbogen. Wenn ja, solltest du mal den Event-Monitor mitlaufen lassen und schauen, was da im Lauf der Zeit so aufläuft wegen dieses dummy.
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

karpate

die Readings des Dummy werden alle 10s aktualisiert. Habe trotzdem einmal manuell abgesetzt

setreading ITR_Stromzaehler power 33

hat leider keinen Counter hochgezählt  :(
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

Sehr seltsam...

Habe eben bei meinem Testdummy auch readingList gelöscht und dann (nach restart) den "setreading-Test" gemacht; funktioniert...

Ein paar Kleinigkeiten sind bei mir im Testsystem anders, aber das dürfte keinen Einfluss haben: Die hat als IO ein M2C, clientOrder ist RHASSPY + MGB first, und ich habe eine leicht veränderte Modulfassung, weil ich gleich neben der "NotifyPrefixOrder" auch noch ein paar Code-Referenzen (statt "Klartext") angepaßt habe.

FHEM ist aktuell, und das OS+Perl auch halbwegs?
(Im Log ist auch Ruhe, oder?)
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

Noch ein Unterschied: Bei mir war IODev als Attribut gesetzt. Lösche ich das, speichere und starte neu, paßt es nicht mehr...

Bitte daher vorläufig das IODev-Attribut setzen!
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

karpate

#11
cool!  8)

IO Device Attribut an der Bridge gesetzt und schon ist der Counter losgerannt und das Topic wird gepublished (und kommt in evcc an)
Vielen Dank

Im Log habe ich mit der geänderte Version diese Meldung gefunden
2021.09.24 13:59:27 1: PERL WARNING: Use of uninitialized value $iiodn in string ne at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2885.
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

#12
Falls du testen magst und kannst: Anbei eine Version, die das IODev auch finden sollte, wenn es "modern" gesetzt wird (und die "uninitialized" erschlagen sollte).
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

karpate

Na klar mach ich. Wird heute aber nichts mehr 🙈
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

karpate

#14
habe die angehängte Version getestet:
- Attribut IODevice entfernt
- Reload Modul
wurden die Topics wieder gepublished. Würde also sagen es funktioniert ;)

...aber im Log sehe ich folgende Warnungen (nach dem Reload)
2021.09.26 07:26:30 1: PERL WARNING: Subroutine ::MQTT_GENERIC_BRIDGE_Initialize redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 488.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isDebug redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 574.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine trim redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 580.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine startsWith redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 583.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Define redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 591.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Undefine redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 660.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine refreshUserAttr redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 668.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine retrieveIODevName redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 678.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine retrieveIODevType redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 685.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isIODevMQTT redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 700.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine checkIODevMQTT2 redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 708.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine checkIODevMQTT2_CLIENT redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 716.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isIODevMQTT2 redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 724.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isIODevMQTT2_CLIENT redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 731.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine initUserAttr redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 738.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine firstInit redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 766.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine timerProc redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 820.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isConnected redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 836.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine updateDevCount redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 856.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine removeOldUserAttr redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 875.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine IsObservedAttribute redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 936.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine _takeDefaults redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 969.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateSingleDeviceTableAttrDefaults redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 993.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateSingleDeviceTableAttrAlias redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1023.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateSingleDeviceTableAttrPublish redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1061.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine updatePubTime redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1117.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine getDevicePublishRec redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1143.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine getDevicePublishRecIntern redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1196.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine retrieveQosRetainExpression redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1288.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine computeDefaults redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1327.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine _evalValue2 redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1371.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine searchDeviceForTopic redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1439.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine createRegexpForTopic redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1500.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateSingleDeviceTableAttrSubscribe redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1519.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine deleteEmptyDevices redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1640.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateSingleDeviceTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1659.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine _RefreshDeviceTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1675.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine RefreshDeviceTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1701.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine RefreshGlobalTableAll redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1710.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine RefreshGlobalTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1720.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine RenameDeviceInTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1730.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine DeleteDeviceInTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1747.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CreateDevicesTable redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1758.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine UpdateSubscriptionsSingleDevice redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1785.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine UpdateSubscriptions redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1794.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine RemoveAllSubscripton redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1861.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine InitializeDevices redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1885.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine CheckInitialization redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1895.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Get redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1910.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine getDevInfo redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1996.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Set redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2062.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Notify redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2068.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine checkPublishDeviceReadingsUpdates redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2144.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine defineGlobalTypeExclude redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2253.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine defineGlobalDevExclude redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2317.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine defineDefaultGlobalExclude redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2362.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isTypeDevReadingExcluded redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2375.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine isDoForward redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2426.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine doPublish redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2445.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine publishDeviceUpdate redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2549.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Attr redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2673.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine ioDevConnect redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2749.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine ioDevDisconnect redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2782.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine doSetUpdate redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2794.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine Parse redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2859.
2021.09.26 07:26:30 1: PERL WARNING: Subroutine onmessage redefined at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 2914.
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr

Beta-User

Danke für die Rückmeldung.

Anmerkungen:
- "reload" ist für's Testen hier nicht ausreichend, weil  die Internals schon (gesetzt mit dem  alten Code) vorhanden sind und sich der Code daher potentiell etwas anders verhält als bei einem Neustart.
- Jedenfalls mit gesetztem Attribut hatte ich es gestern mit der letzten Fassung getestet, das war soweit ok (davor am Testsystem eine leicht ändere Fassung, die aber mit Attribut nicht funktionierte...(daher der Edit gestern noch))
- MAn. ist es bei MQTT sinnvoll, das Attribut zu setzen, von daher empfehle ich auch, das wieder zu ergänzen, wenn du mit Testen durch bist ;) .
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

karpate

ok, also ein "shutdown restart" ohne gesetztes Attribut -->
- es werden die topics gepublished
- bisher keine Meldungen im Log sichtbar

Habe nach deinem Vorschlag das IODevice Attribut wieder gesetzt.
# Pi3 (BBB;FB7390)
# TCM310, CUL V4, HM-CFG-LAN,JeeLink,Tradfri,ESP32-Cam@MQTT: Wasseruhr