FHEM Forum

Die MQTT2_CLIENT_Bridge sieht aktuell so aus:

17 ###############
18 #MQTT2_CLIENT_Bridge
19 #
20 name:MQTT2_CLIENT_general_bridge
21 filter:TYPE=MQTT2_DEVICE
22 desc:recommended to use this as general bridgeing device when using MQTT2_CLIENT as IO to get around missing CID info for distinguishing different popular devices<br>NOTE:<br>This might create a new MQTT2-device or change existing ones, especially destroy readingList attributes!
23 order:000001
24 #par:IODEVNAME;Name of the IO-Device; { AttrVal("DEVICE","IODev",undef) }
25 #par:DEVTYPE;TYPE of the device; { InternalVal("DEVICE","TYPE",undef)}
26 #par:DEVCID;CID of the device as written in the DEF; { InternalVal(AttrVal("DEVICE","IODev",""),"clientId","mosquitto") eq InternalVal("DEVICE","DEF","mosquitto") ? "MQTT2_GeneralBridge" : InternalVal("DEVICE","DEF","mosquitto")}
27 #par:NEWDEVROOM;Room of the calling device; {AttrVal("DEVCID","room","MQTT2_\DEVICE" )}
28 par:ICON;ICON as set, defaults to mqtt_bridge_2;{ AttrVal("DEVICE","icon","mqtt_bridge_2") }
29 attr DEVICE icon ICON
30 #defmod DEVCID MQTT2_\DEVICE DEVCID
31 attr DEVICE bridgeRegexp \
32   (tele|stat)[/]([^/]+)[/].*:.* "$2"\
33   shellies[/]([^/]+)[/].*:.* "$1"\
34   (zigbee2mqtt)[/].*:.* "$1"\
35   (ESPClient_[^/]+)[/].*:.* "$1"\
36   valetudo[/]([^/]+)[/].*:.* "$1"\
37   [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
38   wallpanel[/]([^/]+)[/].*:.* "$1"\
39   (wled)[/]([^/]+)[/].*:.* "$1_$2"\
40   (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
41   (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"\
42   Advantech[/]([^/]+)[/].*:.* "$1"\
43   sonos[/](RINCON_[A-Z0-9]+):.* "$1"\
44   (sonos)[/][^/]+/.* "$1"\
45   (tvheadend)[/][^/:]+.* "$1"\
46   homeassistant/.*/config:.* ""
47 #attr DEVCID autocreate 1
48 attr DEVICE comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
49 #attr DEVCID room NEWDEVROOM
50 #attr DEVICE icon mqtt_bridge_2
51 attr DEVICE setStateList on off
52 #deleteattr DEVICE readingList
53 #deletereading -q DEVICE (?!associatedWith).*
54 #deleteattr DEVCID readingList
55 #deletereading -q DEVCID (?!associatedWith).*
56 #setreading DEVCID associatedWith DEVICE
57 #{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
58 farewell:template has been applied successfully. Be carefull when extending the brigeRegexp!
59 attr DEVCID model MQTT2_CLIENT_general_bridge
60 setreading DEVCID attrTemplateVersion 20200619

Auf einer 2.Instanz hab ich einen MQTT2_CLIENT definiert:

defmod M2CLIENT MQTT2_CLIENT 192.168.188.26:1883
attr M2CLIENT autocreate simple
attr M2CLIENT room zMQTT
attr M2CLIENT username Thomas

setstate M2CLIENT opened
setstate M2CLIENT 2020-06-24 11:24:07 state opened

Daraufhin wird automatisch ein Sammeldevice erstellt:

defmod MQTT2_M2CLIENT MQTT2_DEVICE M2CLIENT
attr MQTT2_M2CLIENT IODev M2CLIENT
attr MQTT2_M2CLIENT readingList M2CLIENT:ebusd/global/uptime:.* uptime\
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }\
M2CLIENT:shellies/shelly1-59E540/relay/0:.* relay_0\
M2CLIENT:shellies/shelly1-59E540/input/0:.* input_0\
...

Wende ich auf dieses das MQTT2_CLIENT_general_bridge_Template anwende erscheint das Dialogfeld mit

Please define DEVCID first
Please define DEVCID first


das Device sieht dann so aus:

defmod MQTT2_M2CLIENT MQTT2_DEVICE M2CLIENT
attr MQTT2_M2CLIENT IODev M2CLIENT
attr MQTT2_M2CLIENT bridgeRegexp (tele|stat)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (zigbee2mqtt)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*:.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"\
  Advantech[/]([^/]+)[/].*:.* "$1"\
  sonos[/](RINCON_[A-Z0-9]+):.* "$1"\
  (sonos)[/][^/]+/.* "$1"\
  (tvheadend)[/][^/:]+.* "$1"\
  homeassistant/.*/config:.* ""
attr MQTT2_M2CLIENT comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_M2CLIENT icon mqtt_bridge_2
attr MQTT2_M2CLIENT readingList M2CLIENT:ebusd/global/uptime:.* uptime\
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }\
M2CLIENT:mygateway1-out/3/2/1/0/23:.* 0_23
attr MQTT2_M2CLIENT room MQTT2_DEVICE
attr MQTT2_M2CLIENT setStateList on off

setstate MQTT2_M2CLIENT 2020-06-24 12:12:52 0_23 1556
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 0_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 0_value 64.0
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 1_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 2_name temp2
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 2_value 31.312
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 3_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 3_value 0.0
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 4_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 4_value 46.0
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 5_name pumpstate
setstate MQTT2_M2CLIENT 2020-06-24 12:14:22 5_value off
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 bdate_value 24.06.2020
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 btime_value 12:13:42
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 date_value 24.06.2020
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 dcfstate_value valid
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 temp2_value 31.312
setstate MQTT2_M2CLIENT 2020-06-24 12:13:40 time_value 12:13:41
setstate MQTT2_M2CLIENT 2020-06-24 12:14:10 uptime 4732377

Die Bridge macht ihren Dienst und vereinzelt alle Geräte, aber irgendwas stimmt doch nicht ?

Will mich damit nicht beschäftigen, hab bloss was von Testsystem und der Frage -> hier muss ich doch dann auch wieder anlernen usw. gelesen und mir gedacht das probierste mal aus die Geräte auf dem 2 Pi zu spiegeln, so das kein weiterer CUL bzw.  CC2531 Stick benötigt wird, das geht ja dann mit allen Geräten nicht nur denen die MQTT sprechen.

Gruß

Thomas

Ist ein bug, fix habe ich eben eingecheckt.

(Nach einer Diskussion jüngst mit Rudi dazu habe ich die Funktion "Sammeldevice" und Bridge wieder auf einem Device vereint...)

funzt  :)

Zitattemplate has been applied successfully. Be carefull when extending the brigeRegexp!

Jetzt gehts doch weiter  >:( will ich gar nicht. Warum füllt sich die RL der Bridge mit den ebus-topics, statt Devices angelegt werden ?

Beim Client müsst ich jetzt doch auch auf complex umstellen ?

defmod MQTT2_M2CLIENT MQTT2_DEVICE M2CLIENT
attr MQTT2_M2CLIENT IODev M2CLIENT
attr MQTT2_M2CLIENT bridgeRegexp (tele|stat)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (zigbee2mqtt)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*:.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"\
  Advantech[/]([^/]+)[/].*:.* "$1"\
  sonos[/](RINCON_[A-Z0-9]+):.* "$1"\
  (sonos)[/][^/]+/.* "$1"\
  (tvheadend)[/][^/:]+.* "$1"\
  homeassistant/.*/config:.* ""
attr MQTT2_M2CLIENT comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_M2CLIENT icon mqtt_bridge_2
attr MQTT2_M2CLIENT model MQTT2_CLIENT_general_bridge
attr MQTT2_M2CLIENT readingList M2CLIENT:ebusd/global/uptime:.* uptime\
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HwcPostrunTime/get:.* get\
M2CLIENT:ebusd/bai/StorageTempDesired/get:.* get\
M2CLIENT:ebusd/bai/FanHours/get:.* get\
M2CLIENT:ebusd/bai/HcHours/get:.* get\
M2CLIENT:ebusd/bai/HwcHours/get:.* get\
M2CLIENT:ebusd/bai/HwcStarts/get:.* get\
M2CLIENT:ebusd/bai/RemainingBoilerblocktime/get:.* get\
M2CLIENT:ebusd/bai/SDFlame/get:.* get\
M2CLIENT:ebusd/bai/WaterPressure/get:.* get\
M2CLIENT:ebusd/bai/HcStarts/get:.* get\
M2CLIENT:ebusd/bai/CounterStartattempts1/get:.* get\
M2CLIENT:ebusd/bai/CounterStartattempts2/get:.* get\
M2CLIENT:ebusd/bai/CounterStartAttempts3/get:.* get\
M2CLIENT:ebusd/bai/CounterStartAttempts4/get:.* get\
M2CLIENT:ebusd/bai/FlowHysteresisON/get:.* get\
M2CLIENT:ebusd/bai/FlowHysteresisOff/get:.* get\
M2CLIENT:ebusd/700/PrEnergySumHc/get:.* get\
M2CLIENT:ebusd/700/PrEnergySumHwc/get:.* get\
M2CLIENT:ebusd/700/PrFuelSumHc/get:.* get\
M2CLIENT:ebusd/700/HwcOpMode/get:.* get\
M2CLIENT:ebusd/700/HwcSFMode/get:.* get\
M2CLIENT:ebusd/700/CylinderChargeHyst/get:.* get\
M2CLIENT:ebusd/700/Hc1FlowTemp/get:.* get\
M2CLIENT:ebusd/700/Hc1Status/get:.* get\
M2CLIENT:ebusd/700/Hc1PumpStatus/get:.* get\
M2CLIENT:ebusd/700/z1DayTemp/get:.* get\
M2CLIENT:ebusd/700/z1NightTemp/get:.* get\
M2CLIENT:ebusd/700/HwcLockTime/get:.* get\
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday/get:.* get\
M2CLIENT:ebusd/700/DisplayedOutsideTemp/get:.* get\
M2CLIENT:ebusd/700/Hc1ExcessTemp/get:.* get\
M2CLIENT:ebusd/700/PrFuelSumHcThisMonth/get:.* get\
M2CLIENT:ebusd/700/PartloadHcKW/get:.* get\
M2CLIENT:ebusd/700/Hc1HeatCurve/get:.* get\
M2CLIENT:ebusd/700/HwcTempDesired/get:.* get\
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired/get:.* get\
M2CLIENT:ebusd/700/PumpAdditionalTime/get:.* get\
M2CLIENT:ebusd/700/MaxCylinderChargeTime/get:.* get\
M2CLIENT:ebusd/bai/StorageTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/RemainingBoilerblocktime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartattempts2:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartAttempts3:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartAttempts4:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FlowHysteresisON:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FlowHysteresisOff:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PrEnergySumHc:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PrEnergySumHwc:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcOpMode:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcSFMode:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/CylinderChargeHyst:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1FlowTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1Status:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1PumpStatus:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/z1NightTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcLockTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/DisplayedOutsideTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1ExcessTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PumpAdditionalTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/MaxCylinderChargeTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }
attr MQTT2_M2CLIENT room MQTT2_DEVICE
attr MQTT2_M2CLIENT setStateList on off

setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 0_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 0_value 62.0
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 1_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 2_name temp2
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 2_value 32.562
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 3_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 3_value 0.0
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 4_name temp1
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 4_value 46.0
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 5_name pumpstate
setstate MQTT2_M2CLIENT 2020-06-24 12:50:43 5_value off
setstate MQTT2_M2CLIENT 2020-06-24 12:46:26 attrTemplateVersion 20200624
setstate MQTT2_M2CLIENT 2020-06-24 12:50:52 bdate_value 24.06.2020
setstate MQTT2_M2CLIENT 2020-06-24 12:50:52 btime_value 12:50:53
setstate MQTT2_M2CLIENT 2020-06-24 12:48:32 calibrationv_value 5
setstate MQTT2_M2CLIENT 2020-06-24 12:49:52 date_value 24.06.2020
setstate MQTT2_M2CLIENT 2020-06-24 12:50:52 dcfstate_value valid
setstate MQTT2_M2CLIENT 2020-06-24 12:48:27 energy4_value 0
setstate MQTT2_M2CLIENT 2020-06-24 12:48:24 get
setstate MQTT2_M2CLIENT 2020-06-24 12:48:25 hoursum2_value 1226
setstate MQTT2_M2CLIENT 2020-06-24 12:48:25 minutes0_value 0
setstate MQTT2_M2CLIENT 2020-06-24 12:48:32 minutes2_value 60
setstate MQTT2_M2CLIENT 2020-06-24 12:48:27 opmode_value auto
setstate MQTT2_M2CLIENT 2020-06-24 12:48:25 press_value 2.133
setstate MQTT2_M2CLIENT 2020-06-24 12:48:25 sensor_value ok
setstate MQTT2_M2CLIENT 2020-06-24 12:48:27 sfmode_value auto
setstate MQTT2_M2CLIENT 2020-06-24 12:48:26 temp0_value 37
setstate MQTT2_M2CLIENT 2020-06-24 12:50:52 temp2_value 32.562
setstate MQTT2_M2CLIENT 2020-06-24 12:48:27 temp_value 8.00
setstate MQTT2_M2CLIENT 2020-06-24 12:48:32 tempv_value 31.062
setstate MQTT2_M2CLIENT 2020-06-24 12:49:52 time_value 12:49:52
setstate MQTT2_M2CLIENT 2020-06-24 12:50:57 uptime 4734585

ebus ist nicht in der bridgeRegexp (ergänze ich bei Gelegenheit), von daher ist das Verhalten "normal".

MAn. brauchst du auch nicht auf complex umstellen, wenn du die ebus-Devices später via attrTemplate konfigurierst, sollten die erweiterten json2nameValue()-Funktionen darüber passend eingestellt werden, wo es erforderlich ist.
(Hatte ich nicht an anderer Stelle geschrieben, dass das "General-Bridge"-templaate irgendwie mangels Rückmeldung vermutlich weiter verbesserungsfähig ist).

MAn. brauchst du auch nicht auf complex umstellen, wenn du die ebus-Devices später via attrTemplate konfigurierst,

hier wird nix mehr umgestellt oder konfiguriert, nur noch ein delete <devicename> auf alle Geräte die benötigt waren um das nachzustellen, fertig.

Wollts bloss vorher ausprobieren bevor ich das vlt. wirklich  ;D als weiteren Ansatz ins Spiel bringe Geräte von beiden Pis aus zu bedienen.

Von mir aus kann ruhig jemand den Vorreiter machen für eine "multipoint"-Bedienung/Readingsverteilung via MQTT, das wäre jetzt "für alle" vom Lernen her vermutlich der nächste Schritt; macht also Sinn, wenn das jemand vorexerziert, der die vorhandenen "Mittel und Wege" kennt.

Was man allerdings beachten sollte: Die "set"-Anweisungen muss man mAn. in "autocreate"-Umgebungen "rechtzeitig" rausfiltern - am besten via ignoreRegexp am IO. Wenn es da mal "gesammelte Erkenntnisse" gibt, die über den allgemeinen Ratschlag rausgehen, doch die homeassistant-autodiscovery-Meldungen und Tasmota-Set-Anweisungen da reinzunehmen (was via attrTemplate schon geht), wäre das vermutlich auch gut im Wiki aufgehoben (@Praxisbeispiele?).

Wenn wir das von unserer Seite her steuern, kommt es auch nicht zu solchen nicht ganz optiomalen Effekten, das jemand "irgendwo" was reinbastelt, wie jüngst im Artikel "MQTT" passiert. Da hat jemand OpenMQTTGateway eingepflegt, was zwar an sich nicht verkehrt ist, aber eben auch nicht optimal, da dieses Interface (zumindest im Moment noch) etwas exotisch ist...

Hat du eine Idee weshalb auf dem Haupt.- und versuchsweise auch auf dem Test-System das Modul nicht geladen werden kann ?

defmod M2GB MQTT_GENERIC_BRIDGE
attr M2GB IODev mqtt
attr M2GB room Test1
attr M2GB stateFormat dev: device-count in: incoming-count out: outgoing-count

ZitatCannot load module MQTT_GENERIC_BRIDGE

Die Datei ist vorhanden und die Rechte stimmen auch !

Mobil: fehlendes Perl-Modul

Ja, meine da kommen Erinnerungen wieder, hab das schonmal getestet, aber lese jetzt beim überfliegen der entsprechenden Threads, commandref und Wiki nicht welche bzw. das welche zusätzlich benötigt werden, wird nirgendwo erwähnt.

Die Definition auf dem Hauptsystem kann man ja wieder löschen, aber das noch zusätzliche libs installiert werden müssen um mal kurz zu schauen wie MQTT_GENERIC_BRIDGE tickt,  ist/wäre schon bescheiden.

MQTT_GENERIC_BRIDGE laedt leider das alte MQTT Modul, und bei dessen commandref Eintrag (https://fhem.de/commandref_modular.html#MQTT) steht, dass man Net::MQTT von CPAN Installieren muss. Vmtl. steht eine (mehr oder weniger) verstaendliche Meldung auch in FHEM.log

Ich sag doch es kommen Erinnerungen (https://forum.fhem.de/index.php/topic,91984.msg957557.html#msg957557) hoch  ;D

@Rudi: Bezogen auf unsere Diskussion neulich: Es ist irritierend, dass (anscheinend nur) libmodule-pluggable-perl tatsächlich nachinstalliert werden muß, nicht Net::MQTT (das wird mit FHEM unter lib ausgeliefert). (Ich hatte das damals nur recht kurz angetestet, kann also sein, dass im längeren Betrieb doch noch was von den anderen beiden Modulen benötigt wird, die noch im Wiki zu MQTT-alt gelistet sind).

@TomLee: Wir können das gerne im Wiki noch deutlicher rausarbeiten, wie gesagt, das was da heute steht ist nur das Ergebnis einer kurzen Testphase eines einzelnen Beta-Testers...

Nach einem apt-get install libmodule-pluggable-perl klappt alles wie gewünscht.

Testweise nur ein Device, eine IT-Steckdose (it_Steckdose1), die Definition der MQTT_GENERIC_BRIDGE sieht dann so aus.

defmod MGB MQTT_GENERIC_BRIDGE mqtt it_Steckdose1
attr MGB IODev MQTT2_Server

setstate MGB 2020-06-24 20:00:05 device-count 1
setstate MGB 2020-06-24 20:04:03 incoming-count 1697
setstate MGB 2020-06-24 20:02:59 outgoing-count 19
setstate MGB 2020-06-24 20:02:59 transmission-state outgoing publish sent
setstate MGB 2020-06-24 20:02:59 updated-reading-count 6
setstate MGB 2020-06-24 19:23:07 updated-set-count 0

Ich möchte das der Status des Geräts it_Steckdose1 aus der Hauptinstanz auch an das Device auf der 2. Pi übertragen wird (mqttPublish) und auch auf der 2. Pi schalten können (mqttSubscribe).

Das Device in der  Hauptinstanz hab ich dementsprechend wie folgt ergänzt, das userattr wird von der MQTT_GENERIC_BRIDGE gesetzt :

defmod it_Steckdose1 IT 0F0F00000F FF F0
attr it_Steckdose1 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr it_Steckdose1 IODev sduino
attr it_Steckdose1 alexaName heizung
attr it_Steckdose1 mqttPublish state:topic=haus/wohnzimmer/steckdosen/state
attr it_Steckdose1 mqttSubscribe state:topic=haus/wohnzimmer/steckdosen/set
attr it_Steckdose1 room IT

setstate it_Steckdose1 on
setstate it_Steckdose1 2019-03-28 21:53:20 protocol V1
setstate it_Steckdose1 2020-06-24 20:02:59 state on

Auf der 2. Pi sehe ich jetzt das in der ReadingList der MQTT2_CLIENT_general_bridge folgender Eintrag automatisch ergänzt wird, nachdem ich die Steckdose einmal geschalten habe.

M2CLIENT:haus/wohnzimmer/steckdosen/state:.* state

Diesen Topic-Pfad lösche ich aus der ReadingList der MQTT2_CLIENT_general_bridge und trage ihn in die ReadingList des zuvor von Hand erstellten leeren MQTT2_DEVICE ein:

define MQTT2_it_Steckdose MQTT2_DEVICE

und ergänze noch die setList wie folgt:

defmod MQTT2_it_Steckdose MQTT2_DEVICE
attr MQTT2_it_Steckdose IODev M2CLIENT
attr MQTT2_it_Steckdose readingList haus/wohnzimmer/steckdosen/state:.* state
attr MQTT2_it_Steckdose room MQTT2_DEVICE
attr MQTT2_it_Steckdose setList off:noArg haus/wohnzimmer/steckdosen/set off\
on:noArg haus/wohnzimmer/steckdosen/set on\
toggle:noArg haus/wohnzimmer/steckdosen/set toggle

setstate MQTT2_it_Steckdose off
setstate MQTT2_it_Steckdose 2020-06-24 20:30:14 state off

---

Was die zigbee2mqtt-Devices angeht wird bei mir folgendes Gerät automatisch von der MQTT2_CLIENT_general_bridge angelegt:

defmod MQTT2_zigbee2mqtt MQTT2_DEVICE zigbee2mqtt
attr MQTT2_zigbee2mqtt IODev M2CLIENT
attr MQTT2_zigbee2mqtt readingList zigbee2mqtt/0x00158d00031c22fa:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000302cc1e:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00032c6d54:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d0003274a6c/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00028aedf7:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/config:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* state\
zigbee2mqtt/0x00158d0002fdc5d7:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee2mqtt room MQTT2_DEVICE

setstate MQTT2_zigbee2mqtt OFF
setstate MQTT2_zigbee2mqtt 2020-06-24 19:42:00 action wakeup
setstate MQTT2_zigbee2mqtt 2020-06-24 19:06:49 associatedWith MQTT2_M2CLIENT
setstate MQTT2_zigbee2mqtt 2020-06-24 20:55:42 battery 100
setstate MQTT2_zigbee2mqtt 2020-06-24 20:51:32 brightness 254
setstate MQTT2_zigbee2mqtt 2020-06-24 20:52:57 illuminance 412
setstate MQTT2_zigbee2mqtt 2020-06-24 20:55:42 linkquality 0
setstate MQTT2_zigbee2mqtt 2020-06-24 19:07:37 log_level info
setstate MQTT2_zigbee2mqtt 2020-06-24 20:53:18 occupancy false
setstate MQTT2_zigbee2mqtt 2020-06-24 19:07:37 permit_join true
setstate MQTT2_zigbee2mqtt 2020-06-24 20:51:32 state OFF
setstate MQTT2_zigbee2mqtt 2020-06-24 20:55:42 voltage 3005

wende ich darauf das zigbee2mqtt_bridge-Template an, sieht das Device so aus, nachdem ich ein paar Bulbs geschalten habe:

defmod MQTT2_zigbee2mqtt MQTT2_DEVICE zigbee2mqtt
attr MQTT2_zigbee2mqtt IODev M2CLIENT
attr MQTT2_zigbee2mqtt bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee2mqtt comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_zigbee2mqtt devicetopic zigbee2mqtt
attr MQTT2_zigbee2mqtt getList devicelist:noArg log $DEVICETOPIC/bridge/config/devices\
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/networkmap graphviz
attr MQTT2_zigbee2mqtt model zigbee2mqtt_bridge
attr MQTT2_zigbee2mqtt readingList zigbee2mqtt/0x00158d0003274a6c/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00032c6d54:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00031c22fa:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000302cc1e:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00028aedf7:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee2mqtt room MQTT2_DEVICE
attr MQTT2_zigbee2mqtt setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1\
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1\
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1\
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
attr MQTT2_zigbee2mqtt setStateList on off

setstate MQTT2_zigbee2mqtt OFF
setstate MQTT2_zigbee2mqtt 2020-06-24 21:21:44 action wakeup
setstate MQTT2_zigbee2mqtt 2020-06-24 21:21:44 associatedWith MQTT2_M2CLIENT
setstate MQTT2_zigbee2mqtt 2020-06-24 21:12:32 attrTemplateVersion 20200522 or prior
setstate MQTT2_zigbee2mqtt 2020-06-24 21:25:37 battery 100
setstate MQTT2_zigbee2mqtt 2020-06-24 21:27:11 brightness 254
setstate MQTT2_zigbee2mqtt 2020-06-24 21:25:19 illuminance 167
setstate MQTT2_zigbee2mqtt 2020-06-24 21:27:11 linkquality 0
setstate MQTT2_zigbee2mqtt 2020-06-24 21:25:37 occupancy false
setstate MQTT2_zigbee2mqtt 2020-06-24 21:27:11 state OFF
setstate MQTT2_zigbee2mqtt 2020-06-24 21:25:37 voltage 3025

es werden keine neuen Geräte angelegt, hab mich noch nicht weiter mit beschäftigt, für heut ist mit dem Thema Schluß.

Doch alles nicht so einfach wie gedacht  :D

passe ich getList, readingList und setList händisch an, schalte ein paar Bulbs landen die ganzen Topic-Pfade wieder in der RL der zigbee2mqtt_bridge:

defmod MQTT2_zigbee2mqtt MQTT2_DEVICE zigbee2mqtt
attr MQTT2_zigbee2mqtt IODev M2CLIENT
attr MQTT2_zigbee2mqtt bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee2mqtt comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_zigbee2mqtt devicetopic zigbee2mqtt
attr MQTT2_zigbee2mqtt getList devicelist:noArg log zigbee2mqtt/bridge/config/devices\
  networkmap_raw:noArg raw zigbee2mqtt/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz zigbee2mqtt/bridge/networkmap graphviz
attr MQTT2_zigbee2mqtt model zigbee2mqtt_bridge
attr MQTT2_zigbee2mqtt readingList zigbee2mqtt/bridge/state:.* state\
  zigbee2mqtt/bridge/config/devices:.* {}\
  zigbee2mqtt/bridge/config/log_level:.* log_level\
  zigbee2mqtt/bridge/config/permit_join:.* permit_join\
  zigbee2mqtt/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  zigbee2mqtt/bridge/log:.* log\
  zigbee2mqtt/bridge/networkmap:.* {}\
  zigbee2mqtt/bridge/networkmap/graphviz:.* graphviz\
  zigbee2mqtt/bridge/networkmap/raw:.* raw\
  zigbee2mqtt/bridge/config:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d0003274a6c/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000360ba24:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d000340eac3:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x00158d00032c6d54:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee2mqtt room MQTT2_DEVICE
attr MQTT2_zigbee2mqtt setList log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
  permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
  remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
  y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField zigbee2mqtt/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField zigbee2mqtt/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField zigbee2mqtt/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField zigbee2mqtt/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField zigbee2mqtt/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField zigbee2mqtt/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField zigbee2mqtt/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField zigbee2mqtt/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField zigbee2mqtt/bridge/config/elapsed $EVTPART1\
  z_last_seen:textField zigbee2mqtt/bridge/config/last_seen $EVTPART1\
  z_ban:textField zigbee2mqtt/bridge/config/ban $EVTPART1\
  z_rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg zigbee2mqtt/bridge/config/reset
attr MQTT2_zigbee2mqtt setStateList on off

setstate MQTT2_zigbee2mqtt ON
setstate MQTT2_zigbee2mqtt 2020-06-25 07:12:08 associatedWith MQTT2_M2CLIENT
setstate MQTT2_zigbee2mqtt 2020-06-25 07:01:32 attrTemplateVersion 20200522 or prior
setstate MQTT2_zigbee2mqtt 2020-06-25 07:13:50 battery 91
setstate MQTT2_zigbee2mqtt 2020-06-25 07:10:55 brightness 254
setstate MQTT2_zigbee2mqtt 2020-06-25 07:09:37 devices {"type":"devices","message":[{"ieeeAddr":"0x00158d0002fdc5d7","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d0002fdc5d7"},{"ieeeAddr":"0x00158d00028aedf7","type":"EndDevice","model":"MFKZQ01LM","friendly_name":"0x00158d00028aedf7"},{"ieeeAddr":"0x00158d0003274a6c","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d0003274a6c"},{"ieeeAddr":"0x00158d000340eac3","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d000340eac3"},{"ieeeAddr":"0x00158d000360ba24","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d000360ba24"},{"ieeeAddr":"0x00158d00032c6d54","type":"EndDevice","model":"RTCGQ01LM","friendly_name":"0x00158d00032c6d54"},{"ieeeAddr":"0x00158d00031c22fa","type":"EndDevice","model":"RTCGQ01LM","friendly_name":"0x00158d00031c22fa"},{"ieeeAddr":"0x00158d000302cc1e","type":"EndDevice","model":"RTCGQ11LM","friendly_name":"0x00158d000302cc1e"}]}
setstate MQTT2_zigbee2mqtt 2020-06-25 07:06:03 illuminance 502
setstate MQTT2_zigbee2mqtt 2020-06-25 07:13:50 linkquality 0
setstate MQTT2_zigbee2mqtt 2020-06-25 07:09:37 log {"type":"devices","message":[{"ieeeAddr":"0x00158d0002fdc5d7","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d0002fdc5d7"},{"ieeeAddr":"0x00158d00028aedf7","type":"EndDevice","model":"MFKZQ01LM","friendly_name":"0x00158d00028aedf7"},{"ieeeAddr":"0x00158d0003274a6c","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d0003274a6c"},{"ieeeAddr":"0x00158d000340eac3","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d000340eac3"},{"ieeeAddr":"0x00158d000360ba24","type":"Router","model":"404006/404008/404004","friendly_name":"0x00158d000360ba24"},{"ieeeAddr":"0x00158d00032c6d54","type":"EndDevice","model":"RTCGQ01LM","friendly_name":"0x00158d00032c6d54"},{"ieeeAddr":"0x00158d00031c22fa","type":"EndDevice","model":"RTCGQ01LM","friendly_name":"0x00158d00031c22fa"},{"ieeeAddr":"0x00158d000302cc1e","type":"EndDevice","model":"RTCGQ11LM","friendly_name":"0x00158d000302cc1e"}]}
setstate MQTT2_zigbee2mqtt 2020-06-25 07:13:50 occupancy false
setstate MQTT2_zigbee2mqtt 2020-06-25 07:10:06 raw [{"ieeeAddr":"0x00158d0002fdc5d7","nwkAddr":55335,"lqi":0,"parent":"0x00124b0018ed284e","status":"offline"},{"ieeeAddr":"0x00158d0003274a6c","nwkAddr":33849,"lqi":1,"parent":"0x00124b0018ed284e","status":"offline"},{"ieeeAddr":"0x00158d000340eac3","nwkAddr":55164,"lqi":1,"parent":"0x00124b0018ed284e","status":"offline"},{"ieeeAddr":"0x00158d000360ba24","nwkAddr":53893,"lqi":1,"parent":"0x00124b0018ed284e","status":"offline"},{"ieeeAddr":"0x00158d00031c22fa","nwkAddr":15146,"lqi":65,"parent":"0x00124b0018ed284e","status":"online"}]
setstate MQTT2_zigbee2mqtt 2020-06-25 07:10:55 state ON
setstate MQTT2_zigbee2mqtt 2020-06-25 07:13:50 voltage 2985

edit:

Denkfehler mit dem händischen anpassen, ist ja gar nicht nötig gewesen mit dem händischen anpassen, denke nie an das Attribut devicetopic das ging irgendwie zwischendurch an mir vorbei.
Trotzdem landen die Topic-Pfade in dem zigbee2mqtt_bridge-Device, keine Geräte werden vereinzelt.

...jetzt kommen bei mir Erinnerungen hoch...

Vorab kurz zu den set-Zweigen: Wie geschrieben, muß man sich darum gesondert kümmern und am besten diese Teile über eine ignoreRegexp am IO "entsorgen". In der Hinsicht könnten wir allenfalls eine Art "typisierter Vorschlag" machen, was die von einem Template eventuell erkennbare Struktur angeht (z.B.  fhemnn/.*/set), aber das erschlägt leider die ganzen set-Zweige von "irgendwelchen" Diensten wie (sonos|zigbee|.*)2mqtt vermutlich nicht so einfach (wobei man ggf. mal den Versuch unternehmen könnte, das 2mqtt als "General-Präfix" iVm. dem set-Ende zu verwenden?)...

Zum Rest:
Da war mal ein Thread (v.a. mit Rudi und mir), bei dem es um die interne Verwaltung der bridgeRegexp-Ausdrücke ging. Fazit: alle werden in einem internen Hash gesammelt, die Auswertung auf matches bei unbekannten Topics ist zufällig und nicht vorhersehbar.

Ergo: Wir brauchen im General-Bridge-template "schärfere" bridgeRegexp-Ausdrücke, die optimalerweise nur bei den  Messages greift, die auch später an das jeweilige zentrale Gerät gehen sollen.

Bezogen auf zigbee2mqtt bedeutet das, dass wir sinnvollerweise nur auf den "bridge"-Topicbranch matchen, einen entsprechenden Vorschlag habe ich eben ins svn geschoben, den ebus habe ich vorläufig mal rausgenommen...

Beim Rest (ebus, ems-esp, sonos2mqtt usw.) müssen wir uns das nochmal ansehen. Da kann man sicher manches noch ergänzen bzw. verbessern, das braucht aber vermutlich noch etwas Gehirnschmalz und erst sollte das Prinzip der begrenzteren bridgeRegexp an sich bestätigt sein (?).

Zitateinen entsprechenden Vorschlag habe ich eben ins svn geschoben

Danke, funzt.

Weshalb gibts eigentlich keine bridgeRegexp zu milight, einfach bisher nicht dran gedacht ?

OK, Danke!

Das ist schon mal was.

Magst du die restlichen Bridge-Type-Devices mal ansehen und v.a. mal testen, ob du eine sinnvolle ignoreRegexp für das IO hinbekommst?

Evtl. würde es auch Sinn machen, den ganzen Thread umzubenennen, es geht zwar auch um das genannte attrTemplate, aber jetzt eher im Sinne von wie verbessern wir FHEM2MQTT2FHEM...?

Zitat von: TomLee am 25 Juni 2020, 08:30:18
Weshalb gibts eigentlich keine bridgeRegexp zu milight, einfach bisher nicht dran gedacht ?

Vermutlich weil ich zum einen keine Werbung für die Technik machen wollte (ist aber zwischenzeitlich etwas moderater wg. der FB-Option...), und eventuell bin ich auch über das Thema gestolpert und hatte damals keine Idee, wie man es lösen kann (deswegen war vermutlich auch der ebus draußen und im Wiki findet sich der etwas kryptische Hinweis, dass man für andere Bridge-Type-Geräte einfach das "Sammeldevice" kopieren sollte und die CID anpassen... ::) ). Aber im Kern ist es wirklich so: ich hatte das irgendwann mal "nebenbei" angefangen, erst mal gesammelt und dann eben auf Rückmeldung gewartet. Die kommt (leider) erst jetzt. Aber immerhin: Das wird! Jetzt haben wir ja auch die Tools und ein bißchen mehr Erfahrung, um das sinnvoll zu gestalten :) .

ZitatMagst du die restlichen Bridge-Type-Devices mal ansehen ...

Wie meinst du das ? es gibt 3 Bridge-Devices bei mir : ebus, milight,zigbee2mqtt

Alle 3 haben wir hier jetzt angesprochen gehabt, wie soll ich mir jetzt die anderen ansehen/testen ?

Zitat... ob du eine sinnvolle ignoreRegexp für das IO hinbekommst?

wie so oft, immer überlesen, ich meine da war letzte Woche ein kleiner Aha-Moment, hat sich aber offnsichtlich nicht eingeprägt sonst wüsst ich jetzt auf Anhieb wie das anzugehen ist/was genau die ignoreRegexp macht ohne nochmal nachzuschauen, sry.

Welchen Titel hättest den gerne, einfach FHEM2MQTT2FHEM ?

Das ist so gemeint: Wir haben einen getesteten Prototypen (zigbee2mqtt). Den sollte man jetzt portieren

1. auf die anderen drei bridge-Typen, die du hast und auch testen kannst (ebus, sonos2mqtt und milight) und
2. (möglichst) auf den Rest (ems-esp, OpenMQTTGateway, ... (?)).

Mein Wunsch wäre jetzt, dass du das für Teil 1 übernimmst und schlicht eine überarbeitete Fassung des templates lieferst - ich kenne nämlich derzeit (ohne Recherche) z.B. den LWT-Topic für den ebus nicht.
Für Teil 2 müßte "jemand" die betreffenden Templates mal durchsehen, zumindest bei dem ems-esp steht der LWT-Topic in der mqtt2.template-file. Wäre super, wenn du das auch übernehmen könntest, aber testen können wir (ich) da allenfalls OpemMQTTGateway (müßte dazu aber meinen Test-Pi aus dem Keller holen o.ä.). Sollte aber inhaltlich eigenlich kein Thema sein, wenn sich das Prinzip, via General-Bridge nur den LWT-Pfad zu erfassen bewähren sollte.
Als "Vision" sehe ich immer noch, dass wir bei "default"-Topictrees am Ende eine Vorsortierung haben, wie sie MQTT2_SERVER auch machen würde (=> sonos ist im Moment "to much", das RINCON sollte mMn. raus). Dann kann der "Normaluser" einfach auch mit FHEM2MQTT2FHEM da in die "Praxisbeispiele" einsteigen, wo er es bei einer normalen Installation mit MQTT2_SERVER auch tun würde...

Vermutlich würde es Sinn machen, das General-Bridge-template noch mit einem Setter/"Knopf" zu ergänzen, der die readingList löscht und die Readings bis auf asociatedWith löscht (?).

---

Zum anderen wäre es gut, wenn du dich (auch testweise) mit dem ignoreRegexp-Thema beschäftigen könntest. Hier sollte ebenfalls Ziel sein, im Ergebnis typische Probleme von Anfang an zu umschiffen. Eine erste Basis sollte mit den beiden MQTT2_IO_ignoreRegexp_.*-templates vorhanden sein...

peu à peu bitte.

Die bridgeRegexp der MQTT2_CLIENT_general_bridge hab ich mal um

(milight)[/]([^/:]+)[/]([^/:]+)[/]([^/:]+).*:.* "$1"
(milight)[/]([^/:]+).*:.* "$1"
erweitert.

Damit landen landen alle Pfade in einem neuen MQTT2DEVICE  :)

defmod MQTT2_milight MQTT2_DEVICE milight
attr MQTT2_milight IODev M2CLIENT
attr MQTT2_milight readingList milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }\
milight/updates/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }\
milight/states/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }\
milight/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_milight room MQTT2_DEVICE

setstate MQTT2_milight ON
setstate MQTT2_milight 2020-06-25 11:18:28 associatedWith MQTT2_M2CLIENT
setstate MQTT2_milight 2020-06-25 11:17:54 brightness 102
setstate MQTT2_milight 2020-06-25 11:17:54 bulb_mode color
setstate MQTT2_milight 2020-06-25 11:17:54 color_b 0
setstate MQTT2_milight 2020-06-25 11:17:54 color_g 106
setstate MQTT2_milight 2020-06-25 11:17:54 color_r 255
setstate MQTT2_milight 2020-06-25 11:17:54 device_id 36182
setstate MQTT2_milight 2020-06-25 11:17:54 device_type rgbw
setstate MQTT2_milight 2020-06-25 11:18:28 firmware milight-hub
setstate MQTT2_milight 2020-06-25 11:17:54 hue 25
setstate MQTT2_milight 2020-06-25 11:18:28 ip_address 192.168.188.55
setstate MQTT2_milight 2020-06-25 11:17:54 level 40
setstate MQTT2_milight 2020-06-25 11:18:28 reset_reason Software/System restart
setstate MQTT2_milight 2020-06-25 11:17:54 state ON
setstate MQTT2_milight 2020-06-25 11:18:28 status connected
setstate MQTT2_milight 2020-06-25 11:18:28 version 1.10.5

Macht man das so mit dem LWT-Pfad das man einen weiteren Eintrag in der bridgeRegexp vornimmt ?
Und schreibt man das LWT eventuell besser aus statt regexp zu verwenden ?

Auf dieses Device das esp_milight_hub_bridge-Template angewendet kommt folgende Meldung im Diaologfeld Unknown command milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.*, try help.

Das Device sieht danach so aus:

defmod MQTT2_milight MQTT2_DEVICE milight
attr MQTT2_milight IODev M2CLIENT
attr MQTT2_milight autocreate 1
attr MQTT2_milight bridgeRegexp 1:.* { json2nameValue($EVENT) }
attr MQTT2_milight devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight model esp_milight_hub_bridge
attr MQTT2_milight room MQTT2_DEVICE
attr MQTT2_milight setStateList on off
attr MQTT2_milight stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

setstate MQTT2_milight <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
setstate MQTT2_milight 2020-06-25 11:27:15 attrTemplateVersion 20200522 or prior

(milight)[/]([^/:]+)[/]([^/:]+)[/]([^/:]+).*:.* "$1"
(milight)[/]([^/:]+).*:.* "$1"
Ich meine, das kann man auch so schreiben, um mein Hirn nicht so lange mit Regexp-Parsen zu beschaeftigen:
milight/.+ "milight"

Ich verstehe auch nicht, warum ich so oft [/] sehe, statt /
Vermutlich uebersehe ich etwas.

Hmm, also: in die General-Bridge sollte mAn. _nur_ der LWT-Pfad, nichts anderes. Wie geschrieben: Es sollte nur die zu MQTT2_SERVER vergleichbare Funktionalität erreicht werden, nicht mehr, v.a. dürfen keine Doppelungen (im Sinne von: beide regexe würden passen) mit der "anschließenden" bridgeRegexp aus der "weiteren Bridge" vorkommen.

Müßte bei milight dann (nur) so sein:
(milight)/LWT:.* "$1"

Das erste Problem ist dann nur, dass die readingList nicht so ist, wie die par-Auswertung des esp_milight_hub_bridge darauf nicht matcht. Müßte man evtl. so erweitern (hoffe, das ist noch kompatibel zu SERVER...):
par:BASE_ID;BASE_ID typically is milight;{ my $rL = AttrVal("DEVICE","readingList",""); $rL =~ m{([^/:]+)/LWT:} ? $1 : $rL =~ m,([^/]+)/[^/]*at[^/]+/.*:, ? $1 : undef }
Wegen des unknown command rätsle ich grade noch.

Das andere Thema ist das, dass dann alle anderen, Bulb-spezifischen Topic-Pfade erst mal in der General-Bridge aufschlagen und dort gelöscht werden müssen. Daher der Vorschlag mit dem setter...

Nachtrag:
Der setter könnte z.B. so aussehen (Zeile in setList der GeneralBridge):clear_all:noArg {fhem("deleteattr $NAME readingList; deletereading -q $NAME (?!associatedWith).*");return undef}

Dann müßte/könnte man bei allen weiteren bridge-Templates diesen setter aufrufen, oder vermultich (kompatibler mit bestehenden Installationen) diese zwei Befehle in ein separates attrTemplate auslagern, das dann nur diese beiden Befehle ausführt:
deletereading -q TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList

mit der par-Anweisung von oben landen aber weiterhin die Pfade mit dem Hex-Namen in der GB

M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }


Zitat
(hoffe, das ist noch kompatibel zu SERVER...)

An meinem Hauptsystem teste ich nix.

wenn ich im Template das deleteattr und setreading wie folgt ergänze wird beim anwenden die RL der GB nicht gelöscht, es steht nichts im Log, der setter ist vorhanden und funktioniert.

name:esp_milight_hub_bridge
filter:TYPE=MQTT2_DEVICE
desc:use this with Chris Mullins ESP-Milight-Hub. for further details visit https://github.com/sidoh/esp8266_milight_hub <br>Recommended stru$
order:X_01
par:BASE_ID;BASE_ID typically is milight;{ my $rL = AttrVal("DEVICE","readingList",""); $rL =~ m{([^/:]+)/LWT:} ? $1 : $rL =~ m,([^/]+)/[^/]*$
attr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr DEVICE model esp_milight_hub_bridge
deletereading -q TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
setreading DEVICE attrTemplateVersion 20200522 or prior
{ AttrTemplate_Initialize() }

Zitat von: TomLee am 25 Juni 2020, 12:43:36
mit der par-Anweisung von oben landen aber weiterhin die Pfade mit dem Hex-Namen in der GB

Code Auswählen Erweitern

M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }


Das ist genau die Absicht!
Nochmal: hat man zwei konkurrierende bridgeRegexp, kann man nicht im Voraus sagen, welche denn greift, und das Ergebnis ist purer Zufall! In der GB sollte daher wirklich NUR umgeleitet werden, was dann am Ende auch in dem in der GB enthaltenen "Umleitungsziel" "enden" soll. Alles andere bleibt temporär in der "Sammeldevice"-GB - daher der Aufwand mit dem "Lösch-attrTemplate" und dem setter eben unzugeordnet an einem zentralen Ort...

ZitatAn meinem Hauptsystem teste ich nix.

Akzeptiert. Dann muß ich den Teil eben selbst testen bzw. auf Verdacht einchecken; da der erste Teil zu funktionieren scheint, bin ich sehr optimistisch...
(Diese Diskussion hilft mir so oder so schon sehr viel weiter! Und am Ende hoffentlich auch allen Usern, die das nutzen wollen...).

---

Was deine GB angeht: Da ist model nicht gesetzt, wenn es noch so ist wie im ersten Beitrag?

defmod MQTT2_M2CLIENT MQTT2_DEVICE M2CLIENT
attr MQTT2_M2CLIENT IODev M2CLIENT
attr MQTT2_M2CLIENT autocreate 1
attr MQTT2_M2CLIENT bridgeRegexp (tele|stat)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (zigbee2mqtt)/bridge/.*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*:.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"\
  Advantech[/]([^/]+)[/].*:.* "$1"\
  sonos[/](RINCON_[A-Z0-9]+):.* "$1"\
  (sonos)/connected.* "$1"\
  (tvheadend)[/][^/:]+.* "$1"\
  homeassistant/.*/config:.* ""\
(milight)/LWT:.* "$1"
attr MQTT2_M2CLIENT comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_M2CLIENT icon mqtt_bridge_2
attr MQTT2_M2CLIENT model MQTT2_CLIENT_general_bridge
attr MQTT2_M2CLIENT readingList M2CLIENT:ebusd/global/uptime:.* uptime\
M2CLIENT:ebusd/bai/HwcPostrunTime/get:.* get\
M2CLIENT:ebusd/bai/StorageTempDesired/get:.* get\
M2CLIENT:ebusd/bai/FanHours/get:.* get\
M2CLIENT:ebusd/bai/HcHours/get:.* get\
M2CLIENT:ebusd/bai/HwcHours/get:.* get\
M2CLIENT:ebusd/bai/HwcStarts/get:.* get\
M2CLIENT:ebusd/bai/RemainingBoilerblocktime/get:.* get\
M2CLIENT:ebusd/bai/SDFlame/get:.* get\
M2CLIENT:ebusd/bai/WaterPressure/get:.* get\
M2CLIENT:ebusd/bai/HcStarts/get:.* get\
M2CLIENT:ebusd/bai/CounterStartattempts1/get:.* get\
M2CLIENT:ebusd/bai/CounterStartattempts2/get:.* get\
M2CLIENT:ebusd/bai/CounterStartAttempts3/get:.* get\
M2CLIENT:ebusd/bai/CounterStartAttempts4/get:.* get\
M2CLIENT:ebusd/bai/FlowHysteresisON/get:.* get\
M2CLIENT:ebusd/bai/FlowHysteresisOff/get:.* get\
M2CLIENT:ebusd/700/PrEnergySumHc/get:.* get\
M2CLIENT:ebusd/700/PrEnergySumHwc/get:.* get\
M2CLIENT:ebusd/700/PrFuelSumHc/get:.* get\
M2CLIENT:ebusd/700/HwcOpMode/get:.* get\
M2CLIENT:ebusd/700/HwcSFMode/get:.* get\
M2CLIENT:ebusd/700/CylinderChargeHyst/get:.* get\
M2CLIENT:ebusd/700/Hc1FlowTemp/get:.* get\
M2CLIENT:ebusd/700/Hc1Status/get:.* get\
M2CLIENT:ebusd/700/Hc1PumpStatus/get:.* get\
M2CLIENT:ebusd/700/z1DayTemp/get:.* get\
M2CLIENT:ebusd/700/z1NightTemp/get:.* get\
M2CLIENT:ebusd/700/HwcLockTime/get:.* get\
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday/get:.* get\
M2CLIENT:ebusd/700/DisplayedOutsideTemp/get:.* get\
M2CLIENT:ebusd/700/Hc1ExcessTemp/get:.* get\
M2CLIENT:ebusd/700/PrFuelSumHcThisMonth/get:.* get\
M2CLIENT:ebusd/700/PartloadHcKW/get:.* get\
M2CLIENT:ebusd/700/Hc1HeatCurve/get:.* get\
M2CLIENT:ebusd/700/HwcTempDesired/get:.* get\
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired/get:.* get\
M2CLIENT:ebusd/700/PumpAdditionalTime/get:.* get\
M2CLIENT:ebusd/700/MaxCylinderChargeTime/get:.* get\
M2CLIENT:ebusd/bai/StorageTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/RemainingBoilerblocktime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartattempts2:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartAttempts3:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/CounterStartAttempts4:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FlowHysteresisON:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/FlowHysteresisOff:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PrEnergySumHc:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PrEnergySumHwc:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcOpMode:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcSFMode:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/CylinderChargeHyst:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1FlowTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1Status:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1PumpStatus:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/z1NightTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcLockTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/DisplayedOutsideTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1ExcessTemp:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/PumpAdditionalTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/700/MaxCylinderChargeTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }\
M2CLIENT:mygateway1-out/3/2/1/0/23:.* 0_23\
M2CLIENT:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT) }\
M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }
attr MQTT2_M2CLIENT room MQTT2_DEVICE
attr MQTT2_M2CLIENT setList clear_all:noArg {fhem("deleteattr $NAME readingList;; deletereading -q $NAME (?!associatedWith).*");;return undef}
attr MQTT2_M2CLIENT setStateList on off

setstate MQTT2_M2CLIENT ON
setstate MQTT2_M2CLIENT 2020-06-25 13:28:57 0_23 15022
setstate MQTT2_M2CLIENT 2020-06-25 13:35:54 0_name
setstate MQTT2_M2CLIENT 2020-06-25 13:35:54 0_value 0.85
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 1_name temp1
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 2_name temp2
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 2_value 35.938
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 3_name temp1
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 3_value 0.0
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 4_name temp1
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 4_value 46.0
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 5_name pumpstate
setstate MQTT2_M2CLIENT 2020-06-25 13:35:05 5_value off
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 bdate_value 25.06.2020
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 btime_value 13:37:25
setstate MQTT2_M2CLIENT 2020-06-25 13:35:54 calibrationv_value 5
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 date_value 25.06.2020
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 dcfstate_value valid
setstate MQTT2_M2CLIENT 2020-06-25 13:35:52 energy4_value 0
setstate MQTT2_M2CLIENT 2020-06-25 13:35:51 get
setstate MQTT2_M2CLIENT 2020-06-25 13:35:51 hoursum2_value 1227
setstate MQTT2_M2CLIENT 2020-06-25 13:16:44 level 40
setstate MQTT2_M2CLIENT 2020-06-25 13:35:51 minutes0_value 0
setstate MQTT2_M2CLIENT 2020-06-25 13:35:54 minutes2_value 60
setstate MQTT2_M2CLIENT 2020-06-25 13:35:52 opmode_value auto
setstate MQTT2_M2CLIENT 2020-06-25 13:35:51 press_value 2.142
setstate MQTT2_M2CLIENT 2020-06-25 13:35:51 sensor_value ok
setstate MQTT2_M2CLIENT 2020-06-25 13:35:52 sfmode_value auto
setstate MQTT2_M2CLIENT 2020-06-25 13:16:44 status ON
setstate MQTT2_M2CLIENT 2020-06-25 13:35:52 temp0_value 37
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 temp2_value 35.938
setstate MQTT2_M2CLIENT 2020-06-25 13:35:52 temp_value 8.00
setstate MQTT2_M2CLIENT 2020-06-25 13:35:56 tempv_value 34.438
setstate MQTT2_M2CLIENT 2020-06-25 13:37:26 time_value 13:37:24
setstate MQTT2_M2CLIENT 2020-06-25 13:37:32 uptime 4823780

Und ehrlich gesagt kann ich jetzt nicht mehr folgen.

Auch wenn ich die RL selbst lösche landet M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) } doch immer wieder in der GB.

...strange...
Was sagt
list TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingListbzw.
list TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge
(Es gibt ja afaik keine "verbotenen" Befehle bei attrTemplate; dann müßte das eigentlich hinhauen).

---

Was ebus angeht: "broadcast" statt (@milight) "LWT"?

Und dann hast du da ja noch ein hübsches MySensors-MQTT-Gateway...?
(mygateway[\d]+)-(in|out)/.* "$1"

---

Zitat von: TomLee am 25 Juni 2020, 13:45:33
Auch wenn ich die RL selbst lösche landet

Code Auswählen Erweitern

M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) } doch immer wieder in der GB.

Da paßt die bridgeRegexp auch aus dem "normalen template" nicht drauf, was auch nicht weiter verwunderlich ist, denn das sind die Kommando-Zweige, wenn ich das richtig interpretiere. Das gehört also eigentlich in die ignoreRegexp am IO...
Das spricht umso mehr dafür, diese ursprünglich zwei Zeilen in ein eigenes attrTemplate aufzunehmen und dann gleich ein entsprechendes "add to IO ignoreRegexp" dazuzubasteln und mit auszuführen?

ich sehe gerade: in keinem Device (2 Bulbs ) meines FHEM-Server ist dieser Topic in einer RL vorhanden ? ? ?

aber in den Einstellungen angegeben:

milight/:device_id/:device_type/:group_id

k. A. was das jetzt ist

Zitatlist TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList

Was es soll:

MQTT2_M2CLIENT           M2CLIENT:ebusd/global/uptime:.* uptime
M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }
M2CLIENT:mygateway1-out/3/2/1/0/23:.* 0_23
M2CLIENT:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcPostrunTime/get:.* get
M2CLIENT:ebusd/bai/StorageTempDesired/get:.* get
M2CLIENT:ebusd/bai/FanHours/get:.* get
M2CLIENT:ebusd/bai/HcHours/get:.* get
M2CLIENT:ebusd/bai/HwcHours/get:.* get
M2CLIENT:ebusd/bai/HwcStarts/get:.* get
M2CLIENT:ebusd/bai/RemainingBoilerblocktime/get:.* get
M2CLIENT:ebusd/bai/SDFlame/get:.* get
M2CLIENT:ebusd/bai/WaterPressure/get:.* get
M2CLIENT:ebusd/bai/HcStarts/get:.* get
M2CLIENT:ebusd/bai/CounterStartattempts1/get:.* get
M2CLIENT:ebusd/bai/CounterStartattempts2/get:.* get
M2CLIENT:ebusd/bai/CounterStartAttempts3/get:.* get
M2CLIENT:ebusd/bai/CounterStartAttempts4/get:.* get
M2CLIENT:ebusd/bai/FlowHysteresisON/get:.* get
M2CLIENT:ebusd/bai/FlowHysteresisOff/get:.* get
M2CLIENT:ebusd/700/PrEnergySumHc/get:.* get
M2CLIENT:ebusd/700/PrEnergySumHwc/get:.* get
M2CLIENT:ebusd/700/PrFuelSumHc/get:.* get
M2CLIENT:ebusd/700/HwcOpMode/get:.* get
M2CLIENT:ebusd/700/HwcSFMode/get:.* get
M2CLIENT:ebusd/700/CylinderChargeHyst/get:.* get
M2CLIENT:ebusd/700/Hc1FlowTemp/get:.* get
M2CLIENT:ebusd/700/Hc1Status/get:.* get
M2CLIENT:ebusd/700/Hc1PumpStatus/get:.* get
M2CLIENT:ebusd/700/z1DayTemp/get:.* get
M2CLIENT:ebusd/700/z1NightTemp/get:.* get
M2CLIENT:ebusd/700/HwcLockTime/get:.* get
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday/get:.* get
M2CLIENT:ebusd/700/DisplayedOutsideTemp/get:.* get
M2CLIENT:ebusd/700/Hc1ExcessTemp/get:.* get
M2CLIENT:ebusd/700/PrFuelSumHcThisMonth/get:.* get
M2CLIENT:ebusd/700/PartloadHcKW/get:.* get
M2CLIENT:ebusd/700/Hc1HeatCurve/get:.* get
M2CLIENT:ebusd/700/HwcTempDesired/get:.* get
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired/get:.* get
M2CLIENT:ebusd/700/PumpAdditionalTime/get:.* get
M2CLIENT:ebusd/700/MaxCylinderChargeTime/get:.* get
M2CLIENT:ebusd/bai/StorageTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/RemainingBoilerblocktime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartattempts2:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartAttempts3:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartAttempts4:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FlowHysteresisON:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FlowHysteresisOff:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PrEnergySumHc:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PrEnergySumHwc:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcOpMode:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcSFMode:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/CylinderChargeHyst:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1FlowTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1Status:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1PumpStatus:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/z1NightTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcLockTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/DisplayedOutsideTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1ExcessTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PumpAdditionalTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/MaxCylinderChargeTime:.* { json2nameValue($EVENT) }

Zitat

list TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge

auch:

Internals:
   CID        M2CLIENT
   DEF        M2CLIENT
   DEVICETOPIC MQTT2_M2CLIENT
   FUUID      5ef323c1-f33f-0353-032d-90c837fc1d2c3080
   IODev      M2CLIENT
   LASTInputDev M2CLIENT
   M2CLIENT_MSGCNT 1028
   M2CLIENT_TIME 2020-06-25 14:05:00
   MSGCNT     1028
   NAME       MQTT2_M2CLIENT
   NR         43
   STATE      ON
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2020-06-25 14:00:15   0_23            17418
     2020-06-25 14:00:32   0_name          temp1
     2020-06-25 14:00:32   0_value         63.0
     2020-06-25 14:00:32   1_name          temp1
     2020-06-25 14:00:32   2_name          temp2
     2020-06-25 14:00:32   2_value         36.375
     2020-06-25 14:00:32   3_name          temp1
     2020-06-25 14:00:32   3_value         0.0
     2020-06-25 14:00:32   4_name          temp1
     2020-06-25 14:00:32   4_value         46.0
     2020-06-25 14:00:32   5_name          pumpstate
     2020-06-25 14:00:32   5_value         off
     2020-06-25 14:04:32   bdate_value     -.-.-
     2020-06-25 14:04:32   btime_value     14:04:40
     2020-06-25 13:51:08   calibrationv_value 5
     2020-06-25 14:03:32   date_value      25.06.2020
     2020-06-25 14:04:32   dcfstate_value  sync
     2020-06-25 13:51:00   energy4_value   0
     2020-06-25 13:50:57   get             
     2020-06-25 13:50:57   hoursum2_value  1227
     2020-06-25 13:42:02   level           40
     2020-06-25 13:50:58   minutes0_value  0
     2020-06-25 13:51:08   minutes2_value  60
     2020-06-25 13:51:00   opmode_value    auto
     2020-06-25 13:50:58   press_value     2.142
     2020-06-25 13:50:58   sensor_value    ok
     2020-06-25 13:51:01   sfmode_value    auto
     2020-06-25 13:42:02   status          ON
     2020-06-25 13:50:59   temp0_value     37
     2020-06-25 14:04:32   temp2_value     36.375
     2020-06-25 13:51:00   temp_value      8.00
     2020-06-25 13:51:07   tempv_value     32
     2020-06-25 14:03:32   time_value      14:03:31
     2020-06-25 14:05:00   uptime          4825428
Attributes:
   IODev      M2CLIENT
   autocreate 1
   bridgeRegexp (tele|stat)[/]([^/]+)[/].*:.* "$2"
  shellies[/]([^/]+)[/].*:.* "$1"
  (zigbee2mqtt)/bridge/.*:.* "$1"
  (ESPClient_[^/]+)[/].*:.* "$1"
  valetudo[/]([^/]+)[/].*:.* "$1"
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"
  wallpanel[/]([^/]+)[/].*:.* "$1"
  (wled)[/]([^/]+)[/].*:.* "$1_$2"
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"
  Advantech[/]([^/]+)[/].*:.* "$1"
  sonos[/](RINCON_[A-Z0-9]+):.* "$1"
  (sonos)/connected.* "$1"
  (tvheadend)[/][^/:]+.* "$1"
  homeassistant/.*/config:.* ""
(milight)/LWT:.* "$1"
   comment    Do not use very open bridgeRegexp expressions! This might lead to irritating results...
   icon       mqtt_bridge_2
   model      MQTT2_CLIENT_general_bridge
   readingList M2CLIENT:ebusd/global/uptime:.* uptime
M2CLIENT:milight/0x8D56/rgbw/1:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/Status01:.* { json2nameValue($EVENT) }
M2CLIENT:mygateway1-out/3/2/1/0/23:.* 0_23
M2CLIENT:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcPostrunTime/get:.* get
M2CLIENT:ebusd/bai/StorageTempDesired/get:.* get
M2CLIENT:ebusd/bai/FanHours/get:.* get
M2CLIENT:ebusd/bai/HcHours/get:.* get
M2CLIENT:ebusd/bai/HwcHours/get:.* get
M2CLIENT:ebusd/bai/HwcStarts/get:.* get
M2CLIENT:ebusd/bai/RemainingBoilerblocktime/get:.* get
M2CLIENT:ebusd/bai/SDFlame/get:.* get
M2CLIENT:ebusd/bai/WaterPressure/get:.* get
M2CLIENT:ebusd/bai/HcStarts/get:.* get
M2CLIENT:ebusd/bai/CounterStartattempts1/get:.* get
M2CLIENT:ebusd/bai/CounterStartattempts2/get:.* get
M2CLIENT:ebusd/bai/CounterStartAttempts3/get:.* get
M2CLIENT:ebusd/bai/CounterStartAttempts4/get:.* get
M2CLIENT:ebusd/bai/FlowHysteresisON/get:.* get
M2CLIENT:ebusd/bai/FlowHysteresisOff/get:.* get
M2CLIENT:ebusd/700/PrEnergySumHc/get:.* get
M2CLIENT:ebusd/700/PrEnergySumHwc/get:.* get
M2CLIENT:ebusd/700/PrFuelSumHc/get:.* get
M2CLIENT:ebusd/700/HwcOpMode/get:.* get
M2CLIENT:ebusd/700/HwcSFMode/get:.* get
M2CLIENT:ebusd/700/CylinderChargeHyst/get:.* get
M2CLIENT:ebusd/700/Hc1FlowTemp/get:.* get
M2CLIENT:ebusd/700/Hc1Status/get:.* get
M2CLIENT:ebusd/700/Hc1PumpStatus/get:.* get
M2CLIENT:ebusd/700/z1DayTemp/get:.* get
M2CLIENT:ebusd/700/z1NightTemp/get:.* get
M2CLIENT:ebusd/700/HwcLockTime/get:.* get
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday/get:.* get
M2CLIENT:ebusd/700/DisplayedOutsideTemp/get:.* get
M2CLIENT:ebusd/700/Hc1ExcessTemp/get:.* get
M2CLIENT:ebusd/700/PrFuelSumHcThisMonth/get:.* get
M2CLIENT:ebusd/700/PartloadHcKW/get:.* get
M2CLIENT:ebusd/700/Hc1HeatCurve/get:.* get
M2CLIENT:ebusd/700/HwcTempDesired/get:.* get
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired/get:.* get
M2CLIENT:ebusd/700/PumpAdditionalTime/get:.* get
M2CLIENT:ebusd/700/MaxCylinderChargeTime/get:.* get
M2CLIENT:ebusd/bai/StorageTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/RemainingBoilerblocktime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartattempts2:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartAttempts3:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/CounterStartAttempts4:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FlowHysteresisON:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/bai/FlowHysteresisOff:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PrEnergySumHc:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PrEnergySumHwc:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcOpMode:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcSFMode:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/CylinderChargeHyst:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1FlowTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1Status:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1PumpStatus:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/z1NightTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcLockTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/ccTimer\x5c\x2eSaturday:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/DisplayedOutsideTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1ExcessTemp:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/Hc1MinFlowTempDesired:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/PumpAdditionalTime:.* { json2nameValue($EVENT) }
M2CLIENT:ebusd/700/MaxCylinderChargeTime:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    clear_all:noArg {fhem("deleteattr $NAME readingList; deletereading -q $NAME (?!associatedWith).*");return undef}
   setStateList on off

ZitatWas ebus angeht: "broadcast" statt (@milight) "LWT"?

Hab das mit dem Bridge Device jetzt so verstanden, das es global sein müsste, oder nicht ?

RL der MQTT2_ebusd_Bridge:

ebusd/global/uptime:.* uptime
ebusd/global/running:.* running
ebusd/global/version:.* version
ebusd/global/signal:.* signal
ebusd/global/updatecheck:.* updatecheck
ebusd/scan\.08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
ebusd/scan\.ec/:.* { json2nameValue($EVENT, 'scan.ec_', $JSONMAP) }
ebusd/scan\.ec/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }

Zitat von: TomLee am 25 Juni 2020, 14:07:01
Was es soll:

...dann habe ich keine Erklärung, warum das nicht via attrTemplate klappen sollte. (Nur zur Sicherheit, nicht verhauen: "Initialize" hattest du nach der Änderung ausgeführt?)

Zitat von: TomLee am 25 Juni 2020, 14:01:42
ich sehe gerade: in keinem Device (2 Bulbs ) meines FHEM-Server ist dieser Topic in einer RL vorhanden ? ? ?

Korrekt, so sollte es mMn. auch sein: die Einstellungen sind doch die Einstellungen für "auf diesem Pfad erwarte ich Anweisungen", oder? So wie bei Tasmota die "cmnd"-Zweige nichts in der readingList verloren haben (jedenfalls nach meiner Meinung...).

Zitat von: TomLee am 25 Juni 2020, 14:18:54
Hab das mit dem Bridge Device jetzt so verstanden, das es global sein müsste, oder nicht ?

global ist besser, agreed!
(Ähm, diese scan-Geschichten: Sind das auch Anweisungen? (=>ignoreRegexp)).

---

Generell: Vermutlich sollten wir das mit der Erweiterung der ignoreRegexp intensivieren bzw. aktiv anschieben. An der Diskussion hier ist bereits abzulesen, dass "Otto Normaluser" das noch viel weniger verstehen wird wie das "himmeln" des "homeassistant"-Topics...
Das wird dann aber praktisch alle templates betreffen (zum Glück laufen die "Massendevices" ohne zentrale bridge wie Tasmota fast alle über ein oder zwei zentrale templates...

(Falls ich gedanklich auf einem Holzweg zu sein scheine: Bitte Säge holen... Wenn es "nur unverständich" ist: Nachfragen...)

Hat es irgendwas mit der Reihenfolge der Befehle zu tun ?

Weil alles was rot ist wird nicht ausgeführt, also auch setreading DEVICE attrTemplateVersion 20200522 or prior.
Merkwürdigerweise aber das Initialize(), das seh ich im Log an AttrTemplates: got 175 entries

Zitatattr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat \
status\
Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr DEVICE model esp_milight_hub_bridge
deletereading -q TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
setreading DEVICE attrTemplateVersion 20200522 or prior
{ AttrTemplate_Initialize() }

defmod MQTT2_milight MQTT2_DEVICE milight
attr MQTT2_milight IODev M2CLIENT
attr MQTT2_milight autocreate 1
attr MQTT2_milight bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight model esp_milight_hub_bridge
attr MQTT2_milight readingList milight/LWT:.* { json2nameValue($EVENT) }
attr MQTT2_milight room MQTT2_DEVICE
attr MQTT2_milight setStateList on off
attr MQTT2_milight stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version

setstate MQTT2_milight <a href="http://192.168.188.55" target="_blank">\
connected\
</a>Version: \
1.10.5
setstate MQTT2_milight 2020-06-25 15:48:09 associatedWith MQTT2_M2CLIENT
setstate MQTT2_milight 2020-06-25 15:42:01 attrTemplateVersion 20200522 or prior
setstate MQTT2_milight 2020-06-25 15:48:10 firmware milight-hub
setstate MQTT2_milight 2020-06-25 15:48:10 ip_address 192.168.188.55
setstate MQTT2_milight 2020-06-25 15:48:10 reset_reason Software/System restart
setstate MQTT2_milight 2020-06-25 15:48:10 status connected
setstate MQTT2_milight 2020-06-25 15:48:10 version 1.10.5


das setreading wird auch nicht ausgeführt wenn ich deleteattr und deletereading rausunehme:

attr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat \
status\
Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr DEVICE model esp_milight_hub_bridge
setreading DEVICE attrTemplateVersion 20200522 or prior
{ AttrTemplate_Initialize() }

Argh, DEVICE in MQTT2_DEVICE ist ein Problem (das erklärt aber nicht, warum die dritte Zeile nicht ausgeführt wird).

So sollten zumindest die ersten beiden Anweisungen gehen:
deletereading -q TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList


Ja klappt, aber das setreading immer noch nicht.

Das der Code, der angezeigt wird, wenn man ein Template aus dem setter auswählt:

attr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat \
status\
Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr DEVICE model esp_milight_hub_bridge
deletereading -q TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
setreading DEVICE attrTemplateVersion 20200522 or prior
{ AttrTemplate_Initialize() }

schau mal oben das Reading Sidoh-Bridge  :o

setstate MQTT2_milight 2020-06-25 15:42:01 attrTemplateVersion 20200522 or prior

Alles gut, Denkfehler.

---

An welchem IO genau muss jetzt diese ignoreregexp gesetzt werden, hab ich bisher nicht verstanden, am MQTT2_SERVER, geht doch nur dort ?

Brauch ich diese ignoreregexp also nur iVm. mit dem MQTT2_CLIENT ?

Hmm, dann scheint das doch zu klappen, oder habe ich das jetzt irgendwie vertauscht oder mißverstanden?

Was den Aufruf dieser beiden Zeilen angeht: Das sollte mMn. am einfachsten über ein eigenes template (innerhalb mqtt2.template) laufen, dann können wir das für alle entsprechenden Fälle zentral ansprechen. Dabei sollten wir dann noch einen par:ADD_TO_IO_IGNOREREGEXP vorsehen für die entsprechende ignoreRegexp-Erweiterung. (Vorschläge für die Benennungen: gerne, ist mal wieder auf die Schnelle aus dem Ärmel...)

Im Ergebnis also sowas:
set DEVICE attrTemplate do_general_mqtt_cleanup ADD_TO_IO_IGNOREREGEXP=BASE_ID/0x[0-9a-fA-F]{1,4}/.*/[0-8]
Dieses template sähe dann in etwa so aus:
name:do_general_mqtt_cleanup
filter:NAME=speechrecognTesting
order:Z00004
desc:template to do some cleanup and set ignoreRegexp that may help in case MQTT commands may be issued from not within this FHEM server; call e.g. with RADIO_ADD_TO_IO_IGNOREREGEXP=milight/0x[0-9a-fA-F]{1,4}/.*/[0-8].
par:IODEVNAME;Name of the IO-Device; { AttrVal("DEVICE","IODev",undef) }
par:ADD_TO_IO_IGNOREREGEXP;add ignoreRegexp to be attached to the current one, defaults to "";{ "" }
par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if expression is already included, otherwise it will be added;{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",undef);; !defined $old ? ADD_TO_IO_IGNOREREGEXP : $old =~ m,ADD_TO_IO_IGNOREREGEXP, ? $old : $old."|ADD_TO_IO_IGNOREREGEXP" }
deletereading -q TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
option:{return 1 if ADD_TO_IO_IGNOREREGEXP ne "";;return 0}
attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP

(in den beiden vorhandenen sind Schreibfehler drin, korrigiere ich auch bei nächster Gelegenheit...)

Aha, am MQTT2_CLIENT

defmod M2CLIENT MQTT2_CLIENT 192.168.188.26:1883
attr M2CLIENT autocreate simple
attr M2CLIENT ignoreRegexp milight/.*/.*/1:.*
attr M2CLIENT room zMQTT
attr M2CLIENT username Thomas

setstate M2CLIENT opened
setstate M2CLIENT 2020-06-25 15:34:50 state opened

Zitat von: TomLee am 25 Juni 2020, 16:24:35
Brauch ich diese ignoreregexp also nur iVm. mit dem MQTT2_CLIENT ?

Sorry, hatte ich vorher nicht wahrgenommen...

MAn. sollte man das präventiv eigentlich an jeder Art IO setzen. Solange man nur MQTT2_SERVER hat und nichts von außen steuert, ist es schnuppe, aber sobald das nicht mehr so ist, wird es "lustig"*. Neige daher dazu, das wirklich in praktisch jedes template mit setList (ggf. indirekt über die zentralen Basistemplates) einzubauen.

Wie gesagt: Falls ich gedanklich auf dem Holzweg zu sein scheine, bitte ich um ein passendes Signal bzw. um Verständnisfragen...

(Da das ein Thema ist, das alle möglichen User betrifft, nochmal die Bitte den Threadtitel anzupassen... Dann nehmen das ggf. noch ein paar mehr wahr, die das bisher für ein völlig exotisches Thema gehalten hatten ;D .).

---

*Vor langem hatte ich mal geschrieben, dass ich teils sehr irritierende Effekte im Zusammenspiel von MQTT2_SERVER und MQTT2_CLIENT hatte. So einen richtigen Anpack hatte ich dazu nie, aber irgendwas schien unter manchen Umständen dazu zu führen, dass die readingList mancher Devices immer neue und immer längere/krudere Einträge hatte. Das ganze erinnerte an ein Ping-Pong-Spiel, bei dem immer wieder was dazukam.
Vermutlich waren auch da irgendwie unscharfe regexe am Werk, wobei es damals noch nicht ging, irgendwas direkt am IO rauszufischen... Bin also mal verhalten optimistisch, dass wir da auf dem richigen Weg sind, und ich bin willens, die Chance zu nutzen, das "richtig" (im Sinne von in sich konsistent) aufzugleisen, damit wir möglichst keine "seltsamen" Effekte rückgemeldet bekommen :) . Deswegen ist es so wichtig, dass alles "seinen" Platz findet bzw. an der passenden Stelle abgearbeitet (oder verworfen) wird.

Vorab mal Danke für's Ändern des Thread-Titels :) .

Und dann noch ein  Nachtrag zu dem hier:

Zitat von: Beta-User am 25 Juni 2020, 16:55:56

Code Auswählen Erweitern


par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if expression is already included, otherwise it will be added;{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",undef);; !defined $old ? ADD_TO_IO_IGNOREREGEXP : $old =~ m,ADD_TO_IO_IGNOREREGEXP, ? $old : $old."|ADD_TO_IO_IGNOREREGEXP" }


Es würde wohl Sinn machen, die Abfrage rumzudrehen, also zu fragen, ob der neue/zusätzliche Ausdruck bereits auf die alte matcht...

par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if expression is already included, otherwise it will be added;{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",undef);; !defined $old ? ADD_TO_IO_IGNOREREGEXP : ADD_TO_IO_IGNOREREGEXP =~ m,$old, ? $old : $old."|ADD_TO_IO_IGNOREREGEXP" }

Bei Gelegenheit sammle ich mal die Bruchstückchen hier mal zusammen und schubse das ins svn, muß eh' zeitnah diese beiden Fehlerchen korrigieren. Oder? (Darfst gerne einen aus deiner Sicht sinnvollen Zwischenstand hier posten, da werden wir vermutlich ein paar Interationen brauchen...)

So, nächste Iteration ist im svn. Da habe ich das mit dem ignoreRegexp-Ding jetzt mal in die Bridges zu zigbee2mqtt und MiLight reingebastelt und die GB-regexp angepaßt...
(Zum großen Testen vorab hat es leider nicht gereicht, aber eigentlich erwarte ich nicht die großen Überraschungen. Im Zweifel funktioniert es halt mal wieder eine Zeitlang nicht vollständig ::) ).

Kam bisher zu nix. Heute morgen wurde nichts mehr an den Client übertragen, hab leider kein List mehr, erst jetzt nach einem restart vom FHEM-Server läuft wieder alles, es steht nichts im Log, beider Pis.
In incoming-count der MQTT_GENERIC_BRIDGE waren rd. 72000 Messages aufgelaufen, kann es was mit der hohen Anzahl zu tun gehabt haben ?

Weiß nicht ob OT oder nicht, sonos2mqtt läuft ja zum Test auf der 2. Pi aber unter einem eigenen MQTT2_SERVER.
Der ist aber seit ich den Client definiert habe disabled (die Nachrichten werden aber ja trotzdem noch empfangen), jetzt wollt ich das Beispiel von 87insane ausprobieren, hab den Server wieder aktiviert und empfange weiterhin bloss, kann keine setter mehr absetzen, es kommt nix bei sonos2mqtt an, die Befehle stehen im Log, ein restart hat bisher auch nix gebracht, alles etwas merkwürdig heute ???

Zitat von: TomLee am 26 Juni 2020, 12:41:50
Kam bisher zu nix. Heute morgen wurde nichts mehr an den Client übertragen, hab leider kein List mehr, erst jetzt nach einem restart vom FHEM-Server läuft wieder alles, es steht nichts im Log, beider Pis.
In incoming-count der MQTT_GENERIC_BRIDGE waren rd. 72000 Messages aufgelaufen, kann es was mit der hohen Anzahl zu tun gehabt haben ?

Die Zahl ist hoch, aber vermutlich ist die Datenlast insgesamt nicht das Thema und das dürfte sich ja auch auf mehrere Stunden verteilen und nicht alles auf einmal kommen, oder?

Vermutlich sollte man das Thema disconnects MQTT2_SERVER <=> MQTT2_CLIENT gesondert untersuchen. Ob das Problem (vorausgesetzt es besteht eines, was aber der Fall zu sein schein) "nur" CLIENT betrifft oder die Kombi, wäre noch zu klären, es gibt hier ja immer wieder welche, die das im Forum berichten, auch iVm. mit mosquitto (ohne allerdings dessen Version bzw. version des CLIENT-Moduls zu nennen oder zu erläutern, warum das über die externe Netzwerkschnittstelle abgewickelt wird und nicht über localhost...)

Generell an dich die Frage: Wo ist die MQTT_GENERIC_BRIDGE? Auf dem Hauptsystem oder (auch) auf dem mit dem CLIENT?

ZitatWeiß nicht ob OT oder nicht, sonos2mqtt läuft ja zum Test auf der 2. Pi aber unter einem eigenen MQTT2_SERVER.
Der ist aber seit ich den Client definiert habe disabled (die Nachrichten werden aber ja trotzdem noch empfangen), jetzt wollt ich das Beispiel von 87insane ausprobieren, hab den Server wieder aktiviert und empfange weiterhin bloss, kann keine setter mehr absetzen, es kommt nix bei sonos2mqtt an, die Befehle stehen im Log, ein restart hat bisher auch nix gebracht, alles etwas merkwürdig heute ???

Generell sollte der 2. Server kein Ding sein; der läuft ja auf einem anderen Port, von daher erschließt sich mir jetzt grade das Problem bzw. der Zusammenhang nicht.

ZitatWo ist die MQTT_GENERIC_BRIDGE?

Ja auf dem Hauptsystem, wo sonst ?
Der ebusd verursacht die vielen Messages.

defmod MGB MQTT_GENERIC_BRIDGE mqtt it_Steckdose1
attr MGB IODev MQTT2_Server

setstate MGB 2020-06-26 10:36:55 device-count 1
setstate MGB 2020-06-26 13:05:00 incoming-count 4585
setstate MGB 2020-06-26 12:19:20 outgoing-count 18
setstate MGB 2020-06-26 12:19:19 transmission-state outgoing publish sent
setstate MGB 2020-06-26 10:42:52 updated-reading-count 3
setstate MGB 2020-06-26 10:36:54 updated-set-count 0

Generell sollte der 2. Server kein Ding sein; der läuft ja auf einem anderen Port, von daher erschließt sich mir jetzt grade das Problem bzw. der Zusammenhang nicht.

Ja, so stell ich mir das auch vor, frag bloss vorsichtig ob es einen Zusammenhang geben könnte, warum jetzt auf einmal, seit ich den Test-Pi installiert habe läuft sonos2mqtt ohne Probleme, war bisher immer sehr einfach alles zu handeln.

Na ja, es könnte auch auf dem Testsystem echte Hardware geben, und dann wäre die MQTT_GENERIC_BRIDGE ggf. nur dort bzw. auf beiden Systemen zu finden... (sinnvollerweise ggf. mit anderen Topic-Pfaden bzw. mind. einem 2. Basis-Pfad; so ein setup ist dann aber wirklich was für "Fortgeschrittene", da sollte man in der Lage sein, zu wissen, was woher und warum kommt und auf alle Fälle sicherstellen, dass "Clone" von Devices des jeweils anderen Systems nur als MQTT2_DEVICE existieren (Zur Klarstellung: es gibt (einige) User, die machen das "schon immer" mit dummy und "nur" MGB, aber das wäre dann für Experten und bietet mMn. eigentlich keinen Vorteil (mehr) gg. der Verwendung von MQTT2_DEVICE. Wollte nur darauf hinweisen, dass man das auch anders sehen kann, bitte durch diesen Annex nicht irrigieren lassen)).

Dass ebus die Quelle ist, überrascht nicht wirklich, aber ähnlich wie bei MQTT2_DEVICE selbst dürfte das - für sich genommen - unproblematisch sein. Allerdings wäre die Frage, wie und ob man die incoming-messages irgendwie begrenzen kann; da habe ich aber auf die Schnelle nichts gefunden (was nicht heißt, dass es nicht möglich sein kann). Ich meine dazu irgendwie im Ohr zu haben, dass der MAINTAINER mal geschrieben hätte, dass er die Last für die Auswertung gemessen hat und festgestellt, dass es sich nicht lohnt, eingehende Messages irgendwie vorzusortieren (das dürfte der Hintergrund zu der etwas kryptischen Info bei globalSubscribe sein).

ZitatDa habe ich das mit dem ignoreRegexp-Ding jetzt mal in die Bridges zu zigbee2mqtt und MiLight reingebastelt und die GB-regexp angepaßt...

funzt super bei zigbee, aber wende ich nochmal das Bridge-Template an kommt das Dialogfeld mit Specify the unknown parameters for zigbee2mqtt_bridge:
base topic set in configuration.yaml of the zigbee2mqtt bridge obwohl in devicetopic der Name drin steht.

   
auch das milight-Bridge-Template funzt, aber auch hier kommt das Dialogfeld Specify the unknown parameters for esp_milight_hub_bridge:
BASE_ID typically is milight, in der RL steht aber der Topic drin milight/LWT:.* { json2nameValue($EVENT) }

und zusätzlich steht noch nach dem anwenden im Log:

2020.06.26 14:28:59 1: PERL WARNING: Bareword found where operator expected at (eval 5101) line 1, near "9a"
2020.06.26 14:28:59 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 14:28:59 1: ERROR evaluating {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}: Bareword "milight" not allowed while "strict subs" in use at (eval 5101) line 1.
syntax error at (eval 5101) line 1, near "0x["
syntax error at (eval 5101) line 1, near "0}"

Was ich nicht verstehe : sollte nicht mit

set DEVICE attrTemplate do_general_mqtt_cleanup ADD_TO_IO_IGNOREREGEXP=BASE_TOPIC/[A-Za-z0-9._]+/set

die ignoreregexp beim MQTT2_CLIENT nach dem anwenden der Templates eingetragen werden, das passiert nämlich nicht, sehe nix im Log, aber auch noch nicht geforscht.

Muß ich mir mal genauer und im Zusammenhang ansehen, evtl. fehlen da ein paar Klammern und Quotes... Wird dauern...

Habs denk ich, aber wie es jetzt genau richtig ist weiß ich nicht, schalten Statusupdates, alles klappt ja.

In jedem angelegten Gerät steht in IODev der MQTT2_SERVER vom 2. Pi (der damit gar nichts zu tun hat) und dann gibts zusätzlich noch das Internal LASTInputDev in dem der MQTT2_CLIENT steht.

zwei Beispiele:

die steckdose

Internals:
   DEVICETOPIC MQTT2_it_Steckdose1
   FUUID      5ef390bc-f33f-0353-4450-3705584a18a0d292
   IODev      MQTT2_Server
   LASTInputDev M2CLIENT
   M2CLIENT_MSGCNT 2
   M2CLIENT_TIME 2020-06-26 17:20:55
   MSGCNT     2
   NAME       MQTT2_it_Steckdose1
   NR         55
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-06-26 17:20:55   state           off
Attributes:
   IODev      MQTT2_Server
   readingList haus/wohnzimmer/steckdosen/state:.* state
   room       MQTT2_DEVICE
   setList    off:noArg haus/wohnzimmer/steckdosen/set off
on:noArg haus/wohnzimmer/steckdosen/set on
toggle:noArg haus/wohnzimmer/steckdosen/set toggle


die Milight-Bridge:

Internals:
   CID        milight
   DEF        milight
   DEVICETOPIC speechrecognTesting
   FUUID      5ef486a7-f33f-0353-0834-fb173fdd8de0a448
   IODev      MQTT2_Server
   LASTInputDev M2CLIENT
   M2CLIENT_MSGCNT 2
   M2CLIENT_TIME 2020-06-26 17:12:10
   MSGCNT     2
   NAME       speechrecognTesting
   NR         59
   STATE      <a href="http://192.168.188.55" target="_blank">
connected
</a>Version:
1.10.5
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-06-26 15:25:32   associatedWith  MQTT2_M2CLIENT
     2020-06-26 14:41:25   attrTemplateVersion 20200626
     2020-06-26 17:12:10   firmware        milight-hub
     2020-06-26 17:12:10   ip_address      192.168.188.55
     2020-06-26 17:12:10   reset_reason    Software/System restart
     2020-06-26 17:12:10   status          connected
     2020-06-26 17:12:10   version         1.10.5
Attributes:
   IODev      MQTT2_Server
   autocreate 1
   bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
   devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
   model      esp_milight_hub_bridge
   readingList milight/LWT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setStateList on off
   stateFormat <a href="http://ip_address" target="_blank">
status
</a>Version:
version

Hmm, das mit dem "falschen" IO ist mMn. eine "unerwünschte Nebenwirkung" von DevIO, wenn man das "einfach so" machen läßt: Das greift sich immer das letzte prinzipiell passende IO aus der cfg (also das, das am weitesten hinten steht). Muß man manuell korrigieren und dürfte bei vielen Modulen auftreten (bei MySensors habe ich das im Modul verhindert/korrigiert, aber da ist der matching-Mechanismus auch anders als üblich (nicht unbedingt besser, eher ineffizienter)).

Spricht was gegen { InternalVal("DEVICE","LASTInputDev",undef) } habs im do_general_mqtt_cleanup-Template ausprobiert, klappt. Es landet aber immer noch keine ignoreregexp in MQTT2_CLIENT.

Wenn sich sonst noch jemand auskennt mit regex das steht weiterhin im Log :

2020.06.26 18:23:55 1: PERL WARNING: Bareword found where operator expected at (eval 2032) line 1, near "9a"
2020.06.26 18:23:55 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 18:23:55 1: PERL WARNING: (Missing operator before a?)
2020.06.26 18:23:55 3: eval: {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}
2020.06.26 18:23:55 1: ERROR evaluating {return 1 if milight/0x[0-9a-fA-F]{1,4}/.*/[0-8] ne "";;return 0}: Bareword "milight" not allowed while "strict subs" in use at (eval 2032) line 1.
syntax error at (eval 2032) line 1, near "0x["
syntax error at (eval 2032) line 1, near "0}"

So sieht das Template aus:

name:esp_milight_hub_bridge
filter:TYPE=MQTT2_DEVICE
desc:use this with Chris Mullins ESP-Milight-Hub. for further details visit https://github.com/sidoh/esp8266_milight_hub <br>Recommended stru$
order:X_01
par:BASE_ID;BASE_ID typically is milight;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/][^/]*at[^/]+[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp BASE_ID/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE stateFormat <a href="http://ip_address" target="_blank">\
status\
</a>Version: \
version
attr DEVICE devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
set DEVICE attrTemplate do_general_mqtt_cleanup ADD_TO_IO_IGNOREREGEXP=BASE_ID/0x[0-9a-fA-F]{1,4}/.*/[0-8]
attr DEVICE model esp_milight_hub_bridge
setreading DEVICE attrTemplateVersion 20200626
{ AttrTemplate_Initialize() }


Zitat von: TomLee am 26 Juni 2020, 18:36:01
Spricht was gegen

Code Auswählen Erweitern

{ InternalVal("DEVICE","LASTInputDev",undef) } habs im do_general_mqtt_cleanup-Template ausprobiert, klappt. Es landet aber immer noch keine ignoreregexp in MQTT2_CLIENT.

Guter Vorschlag!

Was das andere angeht: Versuch's evtl. mal in Zeile 85 mit
option:{return 1 if 'ADD_TO_IO_IGNOREREGEXP' ne "";;return 0}

 :)

defmod M2CLIENT MQTT2_CLIENT 192.168.188.26:1883
attr M2CLIENT autocreate simple
attr M2CLIENT ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
attr M2CLIENT room zMQTT
attr M2CLIENT username Thomas

setstate M2CLIENT opened
setstate M2CLIENT 2020-06-26 17:12:07 state opened

Und der regex greift auch der Pfad taucht nicht mehr in der GB auf.

 :)

Danke für's unermüdliche Testen und die Rückmeldung!

Bliebt die Frage, ob das setup insgesamt sinnig ist?
Ich könnte mir vorstellen, dass irgendwann irgendeiner mit dieser Art der Zwangsbeglückung nicht glücklich ist. Bin aber unschlüssig; letztlich wird es immer irgendein Kompromiss sein...

@all: Bitte um rechtzeitige Meldung, wenn ihr eher skeptisch seid, was diesen Teil angeht. Vermutlich ist es einfacher/schmerzfreier, das gleich reinzubauen, wie nachher wieder irgendwas drumrumzubasteln. Aber wenn, wäre die Frage, wie? Zuerst hatte ich an irgendeinen Marker bei global gedacht, zwischenzeitlich fände ich es eher zielführend, das wenn, dann entweder am IO unterzubringen, oder bei dem General-Bridge-Gerät (hier jeweils als userattr?). Da ließe es sich ggf. auch später noch einigermaßen schmerzfrei reinbasteln...?

@Rudi: Was mir auch leichtes Kopfzerbrechen bereitet: Derzeit sind einige (immer mehr) von diesen zentralen Funktionstemplates nur sichtbar, wenn man versucht, die grade auf ein Gerät mit einem speziellen Namen anzuwenden. Für die Entwicklung und das Testen war das ok, aber irgendwie sollte da (bei Bedarf bzw. auf Wunsch) mehr Transparenz her. Da die templates innerhalb des Systems immer verfügbar sein "müssen", ist prereq: nicht zielführend, und filter: ist reine devspec, so dass man nicht so einfach auf externe Infos zugreifen kann. Wenn letzteres möglich wäre, könnte man es z.B. mit dem global-Attribut "showInternalValues" verknüpfen? Das hat sowieso die Funktion einer Art "Expertenansicht". Die entsprechenden Template-Namen mit einem Punkt zu beginnen wäre vermutlich vom Aufwand her nicht das große Problem, einfacher wäre, jeweils ein filter2: dazuzuschreiben (oder irgendwas in der Art halt).
Bin da aber nicht festgelegt und das ganze ist auch nicht dringlich; vielleicht fällt dir ja was cleveres ein :) ?

Zur Info: eben habe ich noch ein update ins svn geschust (https://svn.fhem.de/trac/changeset/22278/). Da ist das mit den Quotes drin und auch die beiden allgemeinen ignoreRegexp-Templates habe ich etwas umgebaut, Hinweise erweitert...

Wie immer: feedback ist willkommen!

Zitat{ { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }

Müsste noch korrigiert werden

---

Es bleibt bei

Specify the unknown parameters for esp_milight_hub_bridge:
BASE_ID typically is milight

trotz das der Pfad in der RL vorhanden ist.

---

ZitatVorab kurz zu den set-Zweigen: Wie geschrieben, muß man sich darum gesondert kümmern und am besten diese Teile über eine ignoreRegexp am IO "entsorgen". In der Hinsicht könnten wir allenfalls eine Art "typisierter Vorschlag" machen, was die von einem Template eventuell erkennbare Struktur angeht (z.B.  fhemnn/.*/set), aber das erschlägt leider die ganzen set-Zweige von "irgendwelchen" Diensten wie (sonos|zigbee|.*)2mqtt vermutlich nicht so einfach (wobei man ggf. mal den Versuch unternehmen könnte, das 2mqtt als "General-Präfix" iVm. dem set-Ende zu verwenden?)...

Mach mal bitte einen Vorschlag zu den Tasmota set-Zweigen, egal wie ich es machen würde du löst es am Ende eh dann wieder mit einer anderen regex.

M2CLIENT:cmnd/sonoffDual_schaltschrank/POWER1:.* POWER1
M2CLIENT:cmnd/tasmota/POWER1:.* POWER1
M2CLIENT:cmnd/tasmotairwz/IRSend:.* { json2nameValue($EVENT) }

 ::)

Neues update ist drin, ich hoffe, auch den Milight-Teil irgendwie erwischt zu haben...

Es gab schon Vorschläge betr. die Shelly- und Tasmota-Zweige. Die habe ich jetzt "entzerrt" und das Basistemplate modularisiert, so dass man jetzt auch die einzelnen Teile gesondert aufrufen kann.

ZitatHmm, das mit dem "falschen" IO ist mMn. eine "unerwünschte Nebenwirkung" von DevIO, wenn man das "einfach so" machen läßt: Das greift sich immer das letzte prinzipiell passende IO aus der cfg

Stimmt im Prinzip, nur im Detail nicht :)
Die Zuordnung macht fhem.pl in AssignIoPort, was ueblicherweise aus dem Modul-eigenen DefineFn aufgerufen wird. Falls $proposed nicht gesetzt ist, wird die zuletzt definierte "passende" IO-Geraet zugewiesen, auch wenn sie noch nicht in fhem.cfg steht.

@Beta-User: wg. dem "Kopfzerbrechen": kannst Du mir bitte das Problem nochmal schildern, gerne mit einem konkreten Beispiel?

Zitat(Ähm, diese scan-Geschichten: Sind das auch Anweisungen? (=>ignoreRegexp)).

Nein.

defmod MQTT2_ebusd_Bridge MQTT2_DEVICE ebusd
attr MQTT2_ebusd_Bridge IODev MQTT2_Server
attr MQTT2_ebusd_Bridge autocreate 1
attr MQTT2_ebusd_Bridge bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr MQTT2_ebusd_Bridge devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd_Bridge devStateStyle style="text-align:right"
attr MQTT2_ebusd_Bridge group MQTT2_Bridges
attr MQTT2_ebusd_Bridge icon mqtt_bridge_2
attr MQTT2_ebusd_Bridge model eBus_daemon_splitter
attr MQTT2_ebusd_Bridge readingList ebusd/global/uptime:.* uptime\
ebusd/global/running:.* running\
ebusd/global/version:.* version\
ebusd/global/signal:.* signal\
ebusd/global/updatecheck:.* updatecheck\
ebusd/scan\.08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.ec/:.* { json2nameValue($EVENT, 'scan.ec_', $JSONMAP) }\
ebusd/scan\.ec/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }
attr MQTT2_ebusd_Bridge room MQTT2_DEVICE
attr MQTT2_ebusd_Bridge setList getKnown:noArg ebusd/list onlyknown\
  getAll:noArg ebusd/list
attr MQTT2_ebusd_Bridge stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd_Bridge userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}

setstate MQTT2_ebusd_Bridge Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 001 05:36
setstate MQTT2_ebusd_Bridge 2020-01-05 14:59:35 associatedWith MQTT2_ebusd_Bridge
setstate MQTT2_ebusd_Bridge 2020-06-28 07:13:52 formatedUptime 0 001 05:36
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_counter_value 005260
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_prefix_value 21
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_product_value 0010010678
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_suffix_value N2
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_supplier_value 3100
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_week_value 34
setstate MQTT2_ebusd_Bridge 2020-01-04 18:13:05 id_year_value 17
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:26 running true
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_HW_value 6403
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_ID_value 70000
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_MF_value Vaillant
setstate MQTT2_ebusd_Bridge 2019-12-24 16:30:04 scan.ec_SW_value 0510
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:42 signal true
setstate MQTT2_ebusd_Bridge 2019-12-22 16:47:52 state getKnown
setstate MQTT2_ebusd_Bridge 2020-06-27 01:39:44 updatecheck "version 3.4 available"
setstate MQTT2_ebusd_Bridge 2020-06-28 07:13:52 uptime 106586
setstate MQTT2_ebusd_Bridge 2020-06-27 01:37:26 version "ebusd 3.3.v3.3"

zum letzten update:


Wende ich das MQTT2_IO_ignoreRegexp_tasmota-Template an wird immer der regex cmnd/[^/]+/ in ignoreRegexp geschrieben egal ob vorher was drin stand.
Wenn ich{ InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) } über die Befehlszeile prüfe ist alles korrekt.
Wenn ich{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old } prüfe, dann seh ich das immer der Ersatzwert genommen wird, komm nicht drauf hab mit ' und " schon gespielt.


Am besten schaust dir den Rest selbst nochmal an irgendwas musst ja grundlegend geändert haben, das nichts so richtig klappt:

Wende ich das MQTT2_IO_ignoreRegexp_shelly-Template an wird immer der regex zweimal shellies/[^/]+/command|shellies/[^/]+/command in ignoreRegexp geschrieben egal ob vorher was drin stand, also praktisch immer dem Ersatzwert nochmal der regex angehängt.

Wende ich das MQTT2_IO_ignoreRegexp_homeassistant an kommt das Dialogfeld
ERROR executing perl-code { my $old =  AttrVal("IODEVNAME","ignoreRegexp",undef);; !defined $old ? 'homeassistant/.*/config:.*' : homeassistant/.*/config =~ m,$old, ? $old : $old.'|homeassistant/.*/config'  } for param NEWIGNOREREGEXP: syntax error at (eval 6282) line 1, near "/."
Im Log steht 2020.06.28 08:49:00 1: PERL WARNING: Bareword found where operator expected at (eval 6282) line 1, near "*/config"
2020.06.28 08:49:00 1: PERL WARNING: (Missing operator before config?)

weder bei der zigbee2mqtt noch der milight-Bridge wird jetzt die BASE_ID/BASE_TOPIC ausgelesen, kommt das Dialogfeld.

Wende ich das milight-Bridge Template an wird der korrekte regex milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]  in ignoreRegexp eingetragen, aber nicht angehängt wenn ein alter Wert vorhanden war.

Wende ich das z2m-Bridge Template an wird  ADD_TO_IO_IGNOREREGEXP in ignoreRegexp eingetragen. ;D

Zitat von: rudolfkoenig am 27 Juni 2020, 12:18:58
Stimmt im Prinzip, nur im Detail nicht :)
Die Zuordnung macht fhem.pl in AssignIoPort, was ueblicherweise aus dem Modul-eigenen DefineFn aufgerufen wird. Falls $proposed nicht gesetzt ist, wird die zuletzt definierte "passende" IO-Geraet zugewiesen, auch wenn sie noch nicht in fhem.cfg steht.

Danke für die Klarstellung.

Da wir es zunehmend mit Installationen zu tun haben, die nicht nur (einen) MQTT2_SERVER nutzen, sondern ggf. mehrere (z.B. aktuelles Stichwort "bumper") und Mischungen auch mit MQTT2_CLIENT für externe Server/Broker: Wäre es ein großer Aufwand, bei autocreate das $proposed sinnvoll zu setzen?

Zitat@Beta-User: wg. dem "Kopfzerbrechen": kannst Du mir bitte das Problem nochmal schildern, gerne mit einem konkreten Beispiel?

Als hartes "Problem" kann man das mAn. nicht bezeichnen, das ist mehr ein "atmosphärisches" Thema. Du hast einige features gebastelt, damit der User möglichst vorher sieht, was ein bestimmtes Template macht, ohne in den Quelltext sehen zu müssen. Die teils indirekten Aufrufe, die ich (vor allem zur Vermeidung allzugroßer Redundanzen und zur Verringerung möglicher Fehlerquellen) reingebaut habe, hast du (zurecht) als (im Sinne der Transparenz) zweischneidig angesehen.

Im Ergebnis war das ok, denn der Anwender hat spätestens nach Anwendung der Templates gesehen, was eigentlich passiert ist, er hatte das fertige Device ja gesehen. Die Auswirkungen waren (fast) immer auf das eigentliche Device begrenzt.

Eine kleine Aunahme waren schon lange die Tasmota-templates, die auch Änderungen in der Konfiguration auf dem Microcontroller bewirken. Aber auch das ist  über die desc: vorab kommuniziert und scheint allg. akzeptiert zu sein. Und auch das beschränkt sich auf das eigentliche Device und die zugehörige Hardware.

Bei den zwischendurch aufgerufenen ("indirekten") templates war es meistens auch so, dass man die gesondert über FHEMWEB ansehen konnte, wenn man wollte. Auch noch transparent, wenn auch nicht mehr komfortabel oder "übersichtlich".

Mit verarbeitet werden aber seit einiger Zeit auch die templates aus  speechcontrol.template und general_use.template - und die sieht man normalerweise nicht, weil der filter: sehr speziell ist. Ist zwar nicht dramatisch, was da passiert, und aus dem Aufruf kann man schon in etwa erraten, was da passiert.
Wenn du ein Beispiel für diese Kaskade suchst, kannst du ja mal dem Pfad von shelly25_split folgen.

Jetzt kommt aber mit diesen automatischen ignoreRegepx-Erweiterungen was hinzu, was sich auf ein ganz anderes Device auswirkt, nämlich das IO. Auch das dürfte sinnvoll sein (die Frage ist mMn. noch nicht abschließend beantwortet, aber das ist was, was sich eher an die User richtet), aber transparent ist es nicht (da via filter: ebenso versteckt wie die aus den anderen files). Diese Art template auch per default anzuzeigen dürfte aber die Mehrzahl der user verwirren; die interessieren sich eigentlich nicht für die Feinheiten, und ohne Parameter kann man die (überwiegend) auch nicht sinnvoll verwenden.

Hinterher für Transparenz zu sorgen, indem man z.B. mit show auch das IO mit anzeigt, ginge zwar prinzipiell, aber eben nicht in allen Fällen (bei mehrkanaligen müßte man sonst immer das IO mit ermitteln, kann aber nicht wissen, ob ignoreRegexp geändert wurde), und der geneigte "Normaluser" wird auch nicht verstehen, wieso er auch das IO angezeigt bekommt.

Ergo überlege ich eben grade, wie man die betreffenden, heute mit dem "filter:NAME=speechrecognTesting" ausgeblendeten Templates irgendwie transparenter machen könnte, ohne den User auf den Quelltext (in welcher Datei...?) zu verweisen. Eine Lösung könnte eben in einer Art Expertenmodus bestehen, in dem diese auch ganz normal über FHEMWEB bzw. das attrTemplate-Auswahl-dropDown angezeigt würden?

Zitat von: TomLee am 28 Juni 2020, 07:16:01
Nein.

Danke für die Rückmeldung, dann ist insoweit keine "action required" :) .

---

Das mit den ignoreRegexpes muß ich mir gesondert nochmal ansehen, vermute, ich habe da irgendwas durcheinandergewürfelt ::) ; Danke erst mal für die Rückmeldung!

Zitat
Wenn ich{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old } prüfe, dann seh ich das immer der Ersatzwert genommen wird, komm nicht drauf hab mit ' und " schon gespielt.

Falsch.

{ my $old =  AttrVal("IODEVNAME","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old }
gibt in der Befehlszeile genau das zurück was es soll.
Wenn zuvor bspw. shellies/[^/]+/command (händisch eingetragen) in ignoreregexp drin stand dann shellies/[^/]+/command|cmnd/[^/]+/ sonst nur cmnd/[^/]+/

Nur wenn man das Template anwendet dann landet immer nur cmnd/[^/]+/ ohne dem alten Wert in ignoreregexp, also habe ich den Verdacht das der Ersatzwert genommen wird.
Trotz das { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) } über die Befehlzeile korrekt den Namen des MQTT2_CLIENT ausgibt.


oder noch anders dargestellt :

{ my $ioc =  InternalVal("MQTT2_mygateway1","LASTInputDev",AttrVal("MQTT2_mygateway1","IODev",undef));; my $old =  AttrVal("$ioc","ignoreRegexp",'cmnd/[^/]+/');; $old = $old.'|cmnd/[^/]+/' if $old !~ m,cmnd/[^/]+/, ;; return $old }

aus der Befehlszeile ergibt shellies/[^/]+/command|cmnd/[^/]+/

das gleiche aus dem Template cmnd/[^/]+/

ZitatWenn du ein Beispiel für diese Kaskade suchst, kannst du ja mal dem Pfad von shelly25_split folgen.

Ab sofort werden beim gesetzten "attr global showInternalValues 1" in FHEMWEB die attrTemplate Inhalte rekursiv angezeigt. Nach dem Anblick des Inhalts bei shelly25_split wollte ich mich in Pandora umbennen :)

Die basic/tasmota/shelly/homeassistant-ignoreregexp-Template tun jetzt ihren Dienst.

Bei den beiden Bridge-Templates bleibts beim Dialogfeld und bei beiden bleibt ignoreregexp unangetastet, es passiert nichts.

Zitat von: rudolfkoenig am 28 Juni 2020, 14:19:19
Ab sofort werden beim gesetzten "attr global showInternalValues 1" in FHEMWEB die attrTemplate Inhalte rekursiv angezeigt. Nach dem Anblick des Inhalts bei shelly25_split wollte ich mich in Pandora umbennen :)

Na ja, ich hatte ein etwas extremes Beispiel gewählt, aber es gibt den Energy-messenden Shelly auch noch in 4-fach ;D ...

Die Idee mit der rekursiven Anzeige gefällt mir jedenfalls gut!

---

Ansonsten habe ich jetzt nochmal die mqtt2.template aktualisiert, damit sollten die meisten der seltsamen Effekte weg sein, leider nicht alle (irgendwie wollte kommt es immer noch zu Doppeleinträgen beim Versuch, die MiLight-ignoreRegexp zu prüfen, aber immerhin scheint der Rest zu funktionieren...).
(Da gab es bei mir @MiLight einen Fehler, der auch im Log steht; hatte mit den übergebenen Quotes zu tun; jetzt ist "Saft alle", mache ggf. irgendwann später weiter; evtl. hat ja bis dahin noch jemand eine zündende Idee, an was es liegt? Die "/" in den Pfaden sind es eher nicht? Evtl. bei MiLight die {} bei den Wiederholungen? (Könnte man in [] packen...)).

So klappts bei mir beim do_general_mqtt_cleanup Template bei dem ADD_TO_IO_IGNOREREGEXP vor dem match mussten die ' weg.

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'ADD_TO_IO_IGNOREREGEXP');;ADD_TO_IO_IGNOREREGEXP =~ m{($old)} ? $ old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Bei Milight wird plötzlich kein Dialogfeld mehr angezeigt, ignoreregexp passt auch.
Bei z2m kommt noch das Dialogfeld.

Man kann das basic/tasmota/homeassistant-ignoreregexp-Template noch mal anwenden das kein Problem wenn der regex schon vorhanden war wird das erkannt.
shelly und die zwei Bridge-Templates fügen dann nochmal den regex an (ohne alten Wert)

Hmm, irgendwie irritierend mit dem zigbee2mqtt-Ding. Evtl. müssen wir da noch Leerzeichen abfangen?
(Zeile 113):par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/: ]+)[/].*:, ? $1 : undef }

---

Bie MiLight konnte ich das testen, da habe ich die regex angepaßt, daher sollte das "eigentlich" jetzt passen (es fügte allerdings immer die regex nochmal zu ignoreregex dazu, aber evtl. ist das dasselbe Problem mit den Quotes, s.u.)

---

Ansonsten bin ich etwas unsicher: Bezieht sich deine Rückmeldung auf 22296 oder die Version davor? Bei der vorherigen Version hatte ich auch die Anführungszeichen mit übergeben, was in Kombination mit diesen weiteren Quotes in der von dir geposteten Zeile zu Problemen geführt hatte. Aber wenn das mit dem Weglassen des Rätsels Lösung wäre, wären wir einen großen Schritt weiter!

Ja das war auf 22296 bezogen, aber auch wieder hinfällig.

Es stimmt doch irgendwas grundsätzlich nicht.

Zum Test lösche mal immer nachdem du das Milight-Bridge Template mit dem u. a.  Code in Zeile 100 aufrufst (ans Ende des Template hab ich zum testen ein save angehängt) die ignoreregexp im MQTT2_CLIENT, das Template also immer nur anwenden wenn nichts in ignoreregexp steht.
Du bekommst willkürlich immer was anderes zurück, mal ist es ADD_TO_IO_IGNOREREGEXP mal der regex selbst milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

Zitat{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'ADD_TO_IO_IGNOREREGEXP');; 'ADD_TO_IO_IGNOREREGEXP' =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Sry so
{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp","ADD_TO_IO_IGNOREREGEXP");; "ADD_TO_IO_IGNOREREGEXP" =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Zitat von: TomLee am 29 Juni 2020, 13:32:11
Du bekommst willkürlich immer was anderes zurück, mal [...]

@Rudi: wenn ich was von einem zufälligen Verhalten lese, klingt bei mir immer die Frage nach, ob irgendwo ein Hash durchgegangen wird. Das ist zwar der Fall, aber alle substitutions, die ich auf die Schnelle in AttrTemplate.pm gefunden habe, waren mit dem /g modifier. Hmm, aber:
Es kann dann vorkommen, dass der eine par: noch nicht aufgelöst wurde, wenn er innerhalb der nächsten par:- Anweisung benötigt würde...?!? Dann bleibt einfach der Text "as is" intern gespeichert?

Wenn das so ist, müssen wir uns was anderes überlegen und diese Art der Ergänzung ggf. über eine option:-Kaskade abfangen...?

Und die regex mit den geschweiften Klammern: Ist die ok, oder sollte man zur Sicherheit was einfacheres nehmen? Z.B.milight/0x[0-9a-fA-F]+/.*/[0-8]

Die Parameter sind in einem Array gespeichert, da ist die Reihenfolge konstant.
Kannst Du bitte ein "Howto zum Nachstellen" liefern?

Zitat von: TomLee am 29 Juni 2020, 13:32:11
Zum Test lösche mal immer nachdem du das Milight-Bridge Template mit dem u. a.  Code in Zeile 100 aufrufst (ans Ende des Template hab ich zum testen ein save angehängt) die ignoreregexp im MQTT2_CLIENT, das Template also immer nur anwenden wenn nichts in ignoreregexp steht.
Du bekommst willkürlich immer was anderes zurück, mal ist es ADD_TO_IO_IGNOREREGEXP mal der regex selbst milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

Sry so

Code Auswählen Erweitern

{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp","ADD_TO_IO_IGNOREREGEXP");; "ADD_TO_IO_IGNOREREGEXP" =~ m{($old)} ? $old : $old.'|ADD_TO_IO_IGNOREREGEXP' }

Kann ich auf folgender Basis bestätigen:

FHEM@Win nach update neu gestartet (=alle Module+templates aktuell)

Start mit:
defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
(kein ignoreRegexp) und
define Milight_Bridge MQTT2_DEVICE milight_hub_1370325
attr Milight_Bridge IODev MQTT2_FHEM_Server
attr Milight_Bridge autocreate 1
attr Milight_Bridge bridgeRegexp milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.* "milight_$1_$2"
attr Milight_Bridge devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr Milight_Bridge group Interfaces
attr Milight_Bridge icon mqtt
attr Milight_Bridge model esp_milight_hub_bridge
attr Milight_Bridge readingList milight/LWT:.* { json2nameValue($EVENT) }
attr Milight_Bridge room Steuerung->Interfaces
attr Milight_Bridge setStateList on off
attr Milight_Bridge stateFormat <a href="http://ip_address" target="_blank">\\nstatus\\n</a>Version: \\nversion

setstate Milight_Bridge <a href="http://192.168.2.96" target="_blank">\\nconnected\\n</a>Version: \\n1.10.6
setstate Milight_Bridge 2020-06-28 15:56:02 attrTemplateVersion 20200628
setstate Milight_Bridge 2020-06-28 17:20:18 firmware milight-hub
setstate Milight_Bridge 2020-06-28 17:20:18 ip_address 192.168.2.96
setstate Milight_Bridge 2020-06-28 17:20:18 reset_reason Software/System restart
setstate Milight_Bridge 2020-06-28 17:20:18 status connected
setstate Milight_Bridge 2020-06-28 17:20:18 version 1.10.6

darauf dann
set Milight_Bridge attrTemplate esp_milight_hub_bridge

ergibt:
attr MQTT2_FHEM_Server ignoreRegexp ADD_TO_IO_IGNOREREGEXP

template nochmal angewendet ergibt:
attr MQTT2_FHEM_Server ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]

attr@MQTT2_FHEM_Server gelöscht, nochmal angewendet ergibt wieder
attr MQTT2_FHEM_Server ignoreRegexp milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
Ergo: sehe auch keine wirkliche Regel...

EDIT: Hab's noch ein paar Mal durchgespielt und es dabei wirklich auf völlig willkürlich scheinende Ergebnisse gebracht: U.A. bis auf 4x die gewollte regexp am Stück, Wechsel zwischen ADD_TO_IO_IGNOREREGEXP und dem eigentlichen Ziel, Kobinationen davon, nach löschen mal das eine, mal das andere... Wirklich keinerlei Regel zu erkennen.

- Parameter werden in Parameter nicht ersetzt.
- die Ersetzung der Parameter in Befehlen passiert in einer nicht deterministischer Reihenfolge (keys %repl)

In Eurem Beispiel definiert ihr (u.a.) die Parameter

ZitatADD_TO_IO_IGNOREREGEXP = milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]
NEWIGNOREREGEXP = ADD_TO_IO_IGNOREREGEXP

und das fragliche Befehl ist "attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP"
Wenn als erstes im Befehl NEWIGNOREREGEXP ersetzt wird (durch ADD_TO_IO_IGNOREREGEXP), dann wird daraus im naechsten Schritt milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]. Falls die Reihenfolge andersrum ist, dann bleibt es bei ADD_TO_IO_IGNOREREGEXP.

Ich habe jetzt die Ersetzung deterministisch gemacht (per sort), damit koennte man bei geeigneten Namenswahl sowas aehnliches wie Parameterersetzung betreiben.
Ich frage mich aber, wieso ihr das Problem nicht mit einem (mehrzeiligen?) Perl-Code-Abschnitt loest, anstelle von 3 par: und eine option: Zeile.

Nun ja, bisher war mir nicht so ganz bewußt gewesen, dass das ein Problem darstellt, weil eben das meiste linear von oben nach unten abläuft, und sowas verschachteltes auf der anderen Seite bisher eher selten "gebraucht" wurde.

Vermutlich ist es tatsächlich das einfachste, das meiste bzw. den eigentlichen CommandAttr() direkt in Perl mit echten Variablen abzubilden. Ist dann zwar noch weniger attrTemplate-like, aber das ist sowieso eine sehr spezielle Ecke, oder...? Dass da die Parameter-Namen auch eine Rolle spielen könnten, habe ich nämlich vermutlich in einer Woche vergessen :( .

(Vielleicht kommt am Ende doch noch die Hoffnung aus der Büchse?)

(Wird ein bißchen dauern, bis ich das betreffende update dann im Kasten haben werde).

@TomLee: irgendwelche Rückmeldungen zu dem Leerzeichen bei zigbee2mqtt?

Ich komm nicht mit wo welche Leerzeichen abgefangen werden sollten, es gibt mMn keine.

---

Mir kommts so vor als sollte das eine Prüfung sein ob ich mitdenke  :P

Dir muss doch klar sein das die / escaped gehören  :)

22296 Zeile 113

par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }

hab keine Zeit, eine ignorregexp wird noch nicht eingetragen.

Das Problem scheinen weniger die escapes gewesen zu sein (es werden andere Trennzeichen verwendet), sondern die Umstellung auf "devicetopic": Damit ist der Schrägstrich entfallen (nur hier, in den anderen paßt es...) , sobald devicetopic vorhanden ist.

So müßte es an dieser Stelle passen:
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)(/.+)?, ? $1 : undef }

---

Was den Rest angeht, habe ich etwas weiter dran rumgebastelt, komme aber nicht so richtig auf einen grünen Zweig. Gedanklicher Ausgangspunkt ist die Prüfung, die MQTT2_SERVER hier in Zeile 461 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MQTT2_SERVER.pm#L461) macht:my $ir = AttrVal($serverName, "ignoreRegexp", undef);
461      next if(defined($ir) && "$tp:$val" =~ m/$ir/);
Also ein eigentlich simples matching. Ein paar regexe hatte wir ja, von daher hatte ich versucht, die einfach 1:1 da reinzubasteln und auch einfach die obige Prüfung so nachzubauen. (Dass gängige regex-online-Tester wie regex101.com da rummaulen, war auch vorher schon so, sollte aber hier eigentlich nicht stören. Komisch sind aber diese irgendwie - jedenfalls mit meinen noch nicht so geschärften Augen - wenig in sich konsistenten Ergebnisse:

Aktuelle Versuchsfile (Auszug):
name:MQTT2_IO_ignoreRegexp_basic
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "cmnd" tasmota and "command" for shelly. <br>Additionally homeassistat discovery branch will be deactivated. <br>NOTE: early experimental version...
order:000002
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_shelly \IODEVNAME=IODEVNAME
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_tasmota \IODEVNAME=IODEVNAME
set DEVICE attrTemplate MQTT2_IO_ignoreRegexp_homeassistant \IODEVNAME=IODEVNAME
setreading IODEVNAME attrTemplateVersion 20200628

name:MQTT2_IO_ignoreRegexp_tasmota
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "cmnd" tasmota. <br>NOTE: early experimental version...
order:0000021
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if expression is already included, otherwise it will be added;{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'cmnd/[^/]+/');; 'cmnd/[^/]+/' =~ m/$old/ ? $old : $old.'|cmnd/[^/]+/' }
attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP

name:MQTT2_IO_ignoreRegexp_shelly
filter:TYPE=MQTT2_DEVICE
desc:Adds a new ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages typically meant to go towards the hardware including branches with "command" for shelly. <br>NOTE: early experimental version...
order:0000022
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
{my $ign = AttrVal('IODEVNAME','ignoreRegexp','not_set');  if ( $ign eq 'not_set' ) { CommandAttr(undef, "IODEVNAME ignoreRegexp shellies/[^/]+/command"); return; }; if ( 'shellies/[^/]+/command' =~ m/$ign/ ) {return;} else { $ign .= '|shellies/[^/]+/command' ; CommandAttr(undef, "IODEVNAME ignoreRegexp $ign"); } }


name:MQTT2_IO_ignoreRegexp_homeassistant
filter:TYPE=MQTT2_DEVICE
desc:Expands existing or adds a ignoreRegexp to the courrent IO device of device it is applied to. This will prevent evaluation of incoming messages meant for homeassistant for auto-discovery of devices. You are strongly encouraged to not use homeassistant autodiscovery at all, but in case you need it for some reason, adding this ignoreRegexp-expression might help to avoid confusion!<br>NOTE: early experimental version...
order:000002a
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:NEWIGNOREREGEXP;NEWIGNOREREGEXP as set if homeassistant is included, otherwise it will be added;{ my $old = AttrVal(InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)),"ignoreRegexp",'homeassistant/.*/config');; 'homeassistant/.*/config' =~ m/$old/ ? $old : $old.'|homeassistant/.*/config' }
attr IODEVNAME ignoreRegexp NEWIGNOREREGEXP
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=IODEVNAME'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
farewell:template has been applied successfully. Check further extending the ignoreRegexp by yourself!

name:do_general_mqtt_cleanup
filter:NAME=speechrecognTesting
order:000002b
desc:template to do some cleanup and set ignoreRegexp that may help in case MQTT commands may be issued from not within this FHEM server; call e.g. with ADD_TO_IO_IGNOREREGEXP=milight/0x[0-9a-fA-F]{1,4}[/].*/[0-8].
par:IODEVNAME;Name of the IO-Device; { InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
par:ADD_TO_IO_IGNOREREGEXP;add ignoreRegexp to be attached to the current one, defaults to "";{ "" }
deletereading -q TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_\DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList
{return if 'ADD_TO_IO_IGNOREREGEXP' eq ""; my $ign = AttrVal('IODEVNAME','ignoreRegexp','');  if ( $ign eq '' ) { CommandAttr(undef, "IODEVNAME ignoreRegexp ADD_TO_IO_IGNOREREGEXP"); return; }; if ( 'ADD_TO_IO_IGNOREREGEXP' !~ m/$ign/ ) { $ign .= '|ADD_TO_IO_IGNOREREGEXP' ; CommandAttr(undef, "IODEVNAME ignoreRegexp $ign");} }

Spielt man nur mit dem MQTT2_IO_ignoreRegexp_basic und den darin enthaltenen dreien rum, wird die ignoreRegexp immer weiter um den shelly-Anteil erweitert.
Meine Vermutung: irgendwo wird da in der shelly-Variante ein eval dazwischengeschaltet, das den reinen Perl-Weg verhindert?

@Rudi: Wenn das so ist, brauche ich dafür zwei par-Anweisungen (bzw. eine plus eine option:), und muß auf dem  denn eigentlich sollte man neuen und alten Wert vergleichen und das Attribut nur sezten, wenn was geändert wird, oder?
Aber ich brauche eigentlich den "echten Perl-Weg", weil sonst das Ersetzen der Parameter innerhalb der par:-Auswertung gar nicht klappen kann (also so, wie es jetzt in do_general_mqtt_cleanup gelöst ist)... Grübel... Muß also doch vermutlich irgendwie über die Reihenfolge gehen? Im Moment noch ratlos...

ZitatMeine Vermutung: irgendwo wird da in der shelly-Variante ein eval dazwischengeschaltet, das den reinen Perl-Weg verhindert?

Seufz, Denkaufgabe am Abend. Dein Denkfehler ist, dass 'shellies/[^/]+/command' =~ m/$ign/ matcht. Wenn man $ign per "Log 1, $ign" ausgibt, dann merkt man, dass wg den anderen Templates $ign zu shellies/[^/]+/command|cmnd/[^/]+/|homeassistant/.*/config gewachsen ist => man muss die Reihenfolge tauschen: $ign =~ m/shellies.*command/.

Optionales Erweitern eines fremden Attributes, samt Umleitung des Frontends, als _TEIL_ eines weiteren Templates.
Ihr wollt es zu perfekt machen, und verkompliziert es soweit, dass keiner mehr durchblickt. Der Benutzer lernt auch nichts dazu, weil er die -zig Zeilen Text+Anweisung nicht durchliest bzw. versteht, und staunt nur (wie ich), dass die Anzeige nach Setzen von Attributen nicht wiederzuerkennen ist.

Ich (als Fan von rudimentaeren Loesungen) wuerde per farewell sagen, dass man ignoreRegexp im MQTT2_SERVER/CLIENT setzen kann (festkodiert, nur Text, kein Perl-Code, IO-Namen nicht aufgeloest).
Der Benutzer hat die Moeglichkeit beim IO-Device per attrTemplate einzelne Ignores hinzuzufuegen. Wenn er es zweimal macht, steht es Doppelt drin (selbst schuld), er hat ja die Moeglichkeit es zu entfernen.

Wenn Ihr doch auf die "perfekte Loesung" besteht, dann wuerde ich ein Hilfsmodul vorschlagen, da drin kann man passende Funktionen definieren, die Einzelheiten vom Benutzer verstecken, und man muss auch nicht um die (AttrTemplate-)Ecke denken.

Puh, also:

- Betr. der Frage, was denn jetzt bei dem Matching links und was rechts zu stehen hat, war ich auch unsicher und hatte das auch schon anders herum ausprobiert. Das Ergebnis war auch dann nicht befriedigend, soweit ich mich entsinne, und die jetzige Fassung bildet genau das nach, was das Modul auch macht. Kopfkratz...
(Ich hatte auch schon spekuliert, ob es an den Wildcards liegt, aber das erklärt nicht, warum der Tasmota-Teil sich anders verhält als der Shelly; zwischen diesen beiden besteht von den Regex-Inhalten her eigentlich kein wirklicher Unterschied...

- Über den Rest muß ich mal nachdenken. Vielleicht sollten wir hier tatsächlich nur auf das Netz zeigen, statt Fische zu liefern. Ich sehe nur zwei Probleme:
-- es gibt durchaus erfahrene Leute hier, die erst mal geneigt waren, insbesondere den Hinweis darauf, dass man den homeassistant-Zweig unbedingt verwerfen sollte, einfach nicht glauben wollten (=>sonos-Thread). Ergo vermute ich, dass das ein Dauerthema werden wird, den Leuten zu vermitteln, dass das wirklich Sinn macht. Und weiter ist es (mMn.) noch etwas schwieriger zu verstehen, dass man die set-Anweisungen aus anderen Quellen ebenfalls direkt rausfiltern sollte...
Von daher wäre die "rundum-sorglos-das-machen-wir-halt-einfach"-Variante für den Großteil der User passend, die sind halt verwöhnt 8) , und ich hätte das "Mach's ggf. dazu"-template z.B. auch bei jeder Anwendung irgendeines Tasmota- oder Shelly-Templates intern mit aufgerufen (man kann ja nicht wissen, ob es schon gesetzt ist, bevor man es geprüft hat...), von daher ist das Argument " der user muß es ja nicht aufrufen" leider nur bedingt schlagend.
-- farewell ist eventuell teils ebenfalls schwierig umzusetzen (sorry, ja: wegen Pandora). Muß das mal intensiver beleuchten, aber wenn man bestimmte Templates (auch) intern verwenden will, kommt es da zu Konflikten, wenn ich das richtig im Kopf habe (ist mit ein Grund, warum ich davon eher spärlich Gebrauch mache).

Muß mal sehen, wie ich die Bausteinchen jetzt wieder für mich selbst sortiere. Vermutlich baue ich das erst mal aus dem MiLight- und zigbee-Ding wieder aus, bis klar ist, ob und wie es funktioniert.

Zitates gibt durchaus erfahrene Leute hier, die erst mal geneigt waren, insbesondere den Hinweis darauf, dass man den homeassistant-Zweig unbedingt verwerfen sollte, einfach nicht glauben wollten (=>sonos-Thread).

Das ist ok: wenn sie gegen die Wand laufen, dann hoeren sie das naechste Mal aufmerksamer zu.

ZitatVon daher wäre die "rundum-sorglos-das-machen-wir-halt-einfach"-Variante für den Großteil der User passend

Ich stimme dir zu, _es sei denn_ es ist nicht mehr einfach. Wenn ich damit mehr Aufwand habe, als 2-3 Antworten auf Beschwerden zu schreiben, dann ueberlege ich, ob es Wert ist. Ok, es gibt auch noch en Spieltrieb :)
Ich sehe AttrTemplate auch als HOWTO fuer Benutzer.
Wenn es zu kompliziert wird, dann ist dieser Effekt weg.

Zitat von: rudolfkoenig am 01 Juli 2020, 09:46:38
Das ist ok: wenn sie gegen die Wand laufen, dann hoeren sie das naechste Mal aufmerksamer zu.

;D (Die Hoffnung ist ja noch in der Büchse, vielleicht sollten wir die jetzt endlich mal rauslassen?)

ZitatIch stimme dir zu, _es sei denn_ es ist nicht mehr einfach. Wenn ich damit mehr Aufwand habe, als 2-3 Antworten auf Beschwerden zu schreiben, dann ueberlege ich, ob es Wert ist. Ok, es gibt auch noch en Spieltrieb :)
Ich sehe AttrTemplate auch als HOWTO fuer Benutzer.
Wenn es zu kompliziert wird, dann ist dieser Effekt weg.

Bin geneigt, das auch so zu sehen, der jetzige Lösungsansatz ist auch etwas dem Spieltrieb geschuldet... Generell wäre dann eher die Frage, wie man die betreffenden Erkenntnisse konsolidiert und allg. (auch als anzupassende Beispiele) verfügbar macht. (Irgendwie: ab nach Praxisbeispiele... Ist halt nicht optimal für den englischsprachigen Teil der User... Na ja, Code ist international ::) )
(Was die Funktion als "Howto" angeht, glaube ich, dass das relativ gut klappt. Zumindest habe ich diesen Eindruck, hoffe, der täuscht nicht ::) .)

Hi,

Beta-User hat in diesem Thread https://forum.fhem.de/index.php/topic,112242.0.html (https://forum.fhem.de/index.php/topic,112242.0.html) vorgeschlagen, hier weiterzumachen.
Ich möchte den Thread hier natürlich nicht karpern ;-)
Nach Durchlesen des gesamten Threads (das ist schon eine ganze Menge und für mich teilweise ziemlich undurchschaubar, weil ich in dieser Materie noch immer nicht drin bin) stellt sich mir die Frage, ob/wie es in der Zwischenzeit vielleicht schon möglich ist, eine MQTT_GENERIC_BRIDGE mit MQTT2 und aktiviertem autocreate zu betreiben?
Ich vermute, daß das eh irgendwo hier in dem Thread steht, aber ich konnte es nicht rauslesen.

Wenn ich irgendwie beim Testen helfen kann, mach ich natürlich gerne. Aber ich befürchte, daß ich dafür zuerst eine Anleitung brauche. Das Thema MQTT2 ist mittlerweile wirklich SEHR komplex geworden.
Danke im voraus und cheers,
Pula

Zitat von: pula am 01 Juli 2020, 13:06:50
stellt sich mir die Frage, ob/wie es in der Zwischenzeit vielleicht schon möglich ist, eine MQTT_GENERIC_BRIDGE mit MQTT2 und aktiviertem autocreate zu betreiben?

Ja, aber ich glaube, es stand eher in "deinem Thread" (vermutlich dort ziemlich am Anfang), wie es geht:
Einfach die bzw. eine bridgeRegexp so fassen, dass "" als "Pseudo-CID" rauskommt. Bitte melden, falls das zu kryptisch ist. Dann aber bitte möglichst mit Info über die konkreten Pfaden, die deine MGB nutzt.

Zitat von: Beta-User am 01 Juli 2020, 14:36:39
Ja, aber ich glaube, es stand eher in "deinem Thread" (vermutlich dort ziemlich am Anfang), wie es geht:
Einfach die bzw. eine bridgeRegexp so fassen, dass "" als "Pseudo-CID" rauskommt. Bitte melden, falls das zu kryptisch ist. Dann aber bitte möglichst mit Info über die konkreten Pfaden, die deine MGB nutzt.

Was ist eine Pseudo-CID? Wieder mal Bahnhof :-(
Eigentlich ist mein "System" recht einfach. Das "Haupt"-fhem sendet mit der base fhem/ und das "Zweit"-fhem sendet mit der base fhem2/
Also die MGB auf dem Zweit-fhem sieht so aus:
Internals:
   DEF        mqttBridge
   IODev      mqtt2
   NAME       myGenericMQTTBridge
   NTFY_ORDER 50-myGenericMQTTBridge
   STATE      dev: 3 in: 24773 out: 19361
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     mqttBridge
   READINGS:
     2020-06-30 15:58:16   device-count    3
     2020-07-01 17:35:41   incoming-count  24773
     2020-07-01 17:35:17   outgoing-count  19361
     2020-07-01 17:35:17   transmission-state outgoing publish sent
     2020-07-01 17:33:58   updated-reading-count 892
     2020-07-01 15:39:16   updated-set-count 3
   devices:
     :global:
       :defaults:
         pub:base   fhem2
         sub:base   fhem2
     SN658X06TE:
       :defaults:
         pub:base   {"$base/$device"}
         sub:base   {"$base/$device"}
       :publish:
         *:
           mode       R
           topic      {"$base/$reading"}
       :subscribe:
         HASH(0x562ebc399fd8)
     verowz:
       :defaults:
         pub:base   {"$base/$device"}
         sub:base   {"$base/$device"}
       :publish:
         *:
           mode       R
           topic      {"$base/$reading"}
       :subscribe:
         HASH(0x562ebda38480)
   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:
   IODev      mqtt2
   globalDefaults base=fhem2
   icon       mqtt_bridge_2
   room       MQTT
   stateFormat dev: device-count in: incoming-count out: outgoing-count

Auf dieser Instanz müsste die regexp also irgendwas mit ^fhem/ sein, nehme ich an. Aber was das mit der Pseudo-CID heisst, ist mir nicht wirklich klar, sorry....
Cheers,
Pula

Du brauchst irgendein MQTT2_DEVICE, an das du die bridgeRegexp "hängen" kannst.
sowas sollte reichen:
attr <das_Device> bridgeRegexp  [\b]fhem/.*:.* ""
(Das \b ist nur dazu da, dass entweder der Beginn oder eine vorhergehende "echte CID" erfaßt werden)

Super, vielen Dank! Scheint jetzt mit autocreate simple zu funktionieren die MGB...
Cheers,
Pula

Hab's mal ins Wiki gepackt mit der bridgeRegexp und das Umfeld etwas umgestellt: https://wiki.fhem.de/wiki/MQTT#MQTT_GENERIC_BRIDGE_und_autocreate_bei_MQTT2-IO-Modulen

Wäre nett, wenn ihr (bzw. v.a. pula) mal drübersehen würdet und Rückmeldung geben, ob das so halbwegs verständlich ist bzw. einfach so nachgebaut werden kann. Weiter ist da die Rede davon, dass man auch für die MGB zwei weitere Perl-Module benötigen würde. Ich meine, das sei sachlich falsch und wir hätten das jüngst auch nochmal geklärt gehabt. Für eine entsprechende nochmalige Bestätigung wäre ich dankbar, dann verbanne ich den (berichtigten) Hinweis in eine Fußnote, damit sich nicht nochmal jemand bemüßigt fühlt, das zu "verbessern". Und ob der Text zu 00_MQTT wirklich so paßt, wäre eine weitere Frage. Denn dann könnte man auf die Auslieferung der Perl-libs unter https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Net eigentlich verzichten, oder?