FHEM2MQTT2FHEM ... und seine Hürden

Begonnen von TomLee, 24 Juni 2020, 12:32:08

Vorheriges Thema - Nächstes Thema

TomLee

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

TomLee

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


TomLee

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) }

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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() }

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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() }

TomLee

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 ?

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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 ::) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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 ???

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files