FHEM2MQTT2FHEM ... und seine Hürden

[TomLee]

einen entsprechenden Vorschlag habe ich eben ins svn geschoben

Danke, funzt.

[TomLee]

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

[Beta-User]

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

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 .

[TomLee]

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

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

[Beta-User]

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

[TomLee]

peu à peu bitte.

Die bridgeRegexp der MQTT2_CLIENT_general_bridge hab ich mal um

Code Auswählen Erweitern


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

Damit landen landen alle Pfade in einem neuen MQTT2DEVICE 

Code Auswählen Erweitern

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

Code Auswählen Erweitern

Unknown command milight/[^/]*at[^/]+/(0x[0-9a-fA-F]{1,4})/.*/([0-8])?.*:.*, try help.

Das Device sieht danach so aus:

Code Auswählen Erweitern

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

[rudolfkoenig]

Code Auswählen Erweitern

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

Code Auswählen Erweitern

milight/.+ "milight"

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

[Beta-User]

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:

Code Auswählen Erweitern

(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...):

Code Auswählen Erweitern

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

[Beta-User]

Nachtrag:
Der setter könnte z.B. so aussehen (Zeile in setList der GeneralBridge):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

deletereading -q TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge (?!associatedWith).*
deleteattr TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingList

[TomLee]

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


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

An meinem Hauptsystem teste ich nix.

[TomLee]

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.

Code Auswählen Erweitern

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

[Beta-User]

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

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

[TomLee]

Code Auswählen Erweitern

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

[TomLee]

Und ehrlich gesagt kann ich jetzt nicht mehr folgen.

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.

[Beta-User]

...strange...
Was sagt

Code Auswählen Erweitern

list TYPE=MQTT2_DEVICE:FILTER=model=MQTT2_CLIENT_general_bridge readingListbzw.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

(mygateway[\d]+)-(in|out)/.* "$1"

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?