MQTT2_Discovery - nativer HA/Tasmota discovery Support

Begonnen von Guybrush, 19 August 2026, 23:50:58

Vorheriges Thema - Nächstes Thema

Guybrush

Ich hab mal meinen lokalen Stand meines MQTT2_Discovery jetzt auf github veröffentlicht. Vielleicht mag das einer mal auf einer parallel laufenden Fhem Umgebung testen  ;)

https://github.com/next81/fhem.MQTT2_Discovery

Bislang gibt es keine native Discovery in fhem. Das was dem am nächsten kommt ist die Umsetzung über fhempy. Die autocreates vom MQTT2_Server/Client funktionieren zwar halbwegs, aber die ganzen setLists etc musste man trotzdem alle händisch erstellen, was ja offensichtlich bei einigen zu Problemen führte. Mit dem MQTT2_Discovery muss man nichts mehr händisch machen. Es "verschluckt" auch die sonst nervigen homeassistant/config und tasmota discoveries. Dafür wird das Modul im Attribut clientOrder des MQTT2_Server oder MQTT2_Client voran gestellt. es reagiert nur auf die discovery topics, so dass MQTT2_Devices dann die übrigen Messages unverändert erhalten. Es ist da natürlich wichtig dass im MQTT2_Server/Client kein ignore auf die discoverytopics gesetzt ist. Hintergrund für die Entwicklung war meine Umsetzung eines Webclients auf FTUI Basis. Da brauch ich aber noch ein paar Tage, bis ich das Releasefertig hab. Funktioniert aber inzwischen wie HA.

Jinja Templates werden auch (noch beschränkt) unterstützt. Im Ergebnis funktioniert das aber schon sauber, ich hab jedenfalls kein device gefunden, wo es Probleme gab. (Meine) Shellys, Tasmota und ESPHome Devices funktionieren damit jedenfalls einwandfrei. Ich hab mich auch bemüht die Readme auf Github so vollständig wie möglich zu erstellen. Dort ist nochmal alles etwas detaillierter als hier beschrieben.

update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/main/controls_MQTT2_DISCOVERY.txt
update
shutdown restart
define mqttDiscovery MQTT2_DISCOVERY <mqttServer>
set mqttDiscovery activate
mqttServer ist dabei das jeweilige MQTT2_Server oder MQTT2_Client device. Wenn man eine parallele FHEM Installation laufen hat, kann man ja bequem über MQTT2_Client parallel mitlesen.

SH_Heini

Hallo Guybrush,
ich bin interessiert und wollte gerade testen, jedoch kam diese Fehlermeldung:
2026.08.20 10:07:54 1: Downloading https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/main/controls_MQTT2_DISCOVERY.txt
2026.08.20 10:07:54 1: MQTT2_DISCOVERY
2026.08.20 10:07:54 1: UPD FHEM/10_MQTT2_DISCOVERY.pm
2026.08.20 10:07:54 1: Got 72144 bytes for FHEM/10_MQTT2_DISCOVERY.pm, expected 73810
2026.08.20 10:07:54 1: aborting.

Gruß

Guybrush

sollte behoben sein. Der Generator zählte Windows-CRLF-Bytes. GitHub liefert das Modul mit LF aus: 72144 statt 73810 Bytes. Hatte für die generierung der controls noch keinen unittest hinterlegt. dadurch viel das nicht auf  ::)

alternativ kann man sich aber auch die dateien aus dem git runterladen. es werden die Verzeichnisse FHEM/ und lib/ benötigt, die so in den FHEM Root müssen.

SH_Heini

Funktioniert jetzt.
Wollte den Weg ohne Github gehen.
Werde testen und berichten.

satprofi

Hallo. Erstmal danke für das neue Modul.
Habe es definiert, aber ereignise sehe ich keine. Klappt das nur bei neuen Devices?
hier das list
Internals:
   CFGFN     
   DEF        myBroker
   FUUID      6a86cca2-f33f-3579-cdf7-3ee86c9fd11fa296
   IODev      myBroker
   IODevName  myBroker
   NAME       mqttDiscovery
   NR         964
   STATE      active
   TYPE       MQTT2_DISCOVERY
   eventCount 22
   READINGS:
     2026-08-20 11:50:32   discoveredDevices 0
     2026-08-20 11:50:32   discoveredEntities 0
     2026-08-20 11:50:32   lastRescan      processed=0 failed=0
     2026-08-20 11:50:26   state           active
   helper:
     registry:
       version    1
       devices:
Attributes:
   autoCreate 1
   room       CUL_MQTT
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,Zigbee,Shelly,
Tasmota,LD382A,Telegram

Guybrush

#5
bestehende devices werden default konservativ behandelt. sofern da was manuell gesetztes mit den automatisch erkannten kollidiert, werden diese verworfen. das kann man mit dem Attribut existingDevices steuern. default ist konservativ. replace z.b. ersetzt es hingegen vollständig. konservativ sollte im Regelfall aber gut passen. Du müsstest dann im mqtt2discovery device ein reading conflicts sehen.

es wertet auch nur die discovery topics aus. also normale mqtt messages fliessen ungefiltert durchs modul an mqtt2_device. also schau mal ob da auch discovery topics kamen.

SH_Heini

Hallo Guybrush,
grundsätzlich funktioniert das Modul schon gut. Geräte werden erkannt und angelegt.

Die angelegten Geräte haben bei mir jedoch alle dieselbe Client-ID, was dazu führt, dass bei allen Geräten die readingslist mit allen gerätefremden Topics befüllt wird.
Aus meiner Sicht wäre es gut, wenn das Modul die ClientID des neu angelegten Devices einzigartig erstellt. (ClientID_Gerätename)


Fehlermeldung
lastError   Mehrere MQTT2_DEVICE-Devices verwenden Client-ID testcID: SONOFF_01, SONOFF_02, TASMOTA_RELAIS_01
defmod mqttDiscovery MQTT2_DISCOVERY MQTT2_TEST_CLIENT
attr mqttDiscovery DbLogExclude .*
attr mqttDiscovery room N_E_U

MQTT2_CLIENT (ignoreRegexp ist mit Absicht noch drin)
defmod MQTT2_TEST_CLIENT MQTT2_CLIENT 192.168.5.10:1880
attr MQTT2_TEST_CLIENT DbLogExclude .*
attr MQTT2_TEST_CLIENT autocreate complex
attr MQTT2_TEST_CLIENT clientId testcID
attr MQTT2_TEST_CLIENT clientOrder MQTT2_DISCOVERY MQTT2_DEVICE MQTT_GENERIC_BRIDGE
attr MQTT2_TEST_CLIENT ignoreRegexp homeassistant/[^:"]+/config
attr MQTT2_TEST_CLIENT room N_E_U
attr MQTT2_TEST_CLIENT sortby 1
Beispielgerät automatisch erstellt
defmod SONOFF_02 MQTT2_DEVICE testcID
attr SONOFF_02 DbLogExclude .*
attr SONOFF_02 group N_E_U
attr SONOFF_02 readingList stat/SONOFF_02/POWER1:.* POWER1\
stat/SONOFF_02/POWER2:.* POWER2\
stat/SONOFF_02/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/LWT:.* LWT\
tele/SONOFF_02/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
testcID:homeassistant/status:.* status\
testcID:cmnd/TASMOTA_IR_01/STATUS:.* STATUS\
testcID:cmnd/TASMOTA_RELAIS_01/STATUS:.* STATUS\
testcID:cmnd/TASMOTA_RELAIS_01/STATE:.* STATE\
testcID:cmnd/SONOFF_02/STATUS:.* STATUS\
testcID:cmnd/SONOFF_02/STATE:.* STATE\
testcID:stat/TASMOTA_IR_01/STATUS10:.* { json2nameValue($EVENT, 'STATUS10_', $JSONMAP) }\
testcID:stat/TASMOTA_IR_01/STATUS1:.* { json2nameValue($EVENT, 'STATUS1_', $JSONMAP) }\
testcID:stat/SONOFF_02/STATUS1:.* { json2nameValue($EVENT, 'STATUS1_', $JSONMAP) }\
testcID:stat/TASMOTA_IR_01/STATUS11:.* { json2nameValue($EVENT, 'STATUS11_', $JSONMAP) }\
testcID:stat/TASMOTA_RELAIS_01/STATUS1:.* { json2nameValue($EVENT, 'STATUS1_', $JSONMAP) }\
testcID:stat/TASMOTA_RELAIS_01/STATUS10:.* { json2nameValue($EVENT, 'STATUS10_', $JSONMAP) }\
testcID:stat/SONOFF_02/STATUS11:.* { json2nameValue($EVENT, 'STATUS11_', $JSONMAP) }\
testcID:stat/TASMOTA_RELAIS_01/STATUS11:.* { json2nameValue($EVENT, 'STATUS11_', $JSONMAP) }\
testcID:tele/TASMOTA_IR_01/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
testcID:tele/TASMOTA_IR_01/STATE:.* { json2nameValue($EVENT, 'STATE_', $JSONMAP) }\
testcID:cmnd/TASMOTA_IR_01/POWER:.* POWER\
stat/SONOFF_02/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_02/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr SONOFF_02 room N_E_U
attr SONOFF_02 setList POWER1:ON,OFF cmnd/SONOFF_02/POWER1\
POWER2:ON,OFF cmnd/SONOFF_02/POWER2
Beispiel mit angepasster ClientID
defmod SONOFF_01 MQTT2_DEVICE testcID_SONOFF_01
attr SONOFF_01 DbLogExclude .*
attr SONOFF_01 group N_E_U
attr SONOFF_01 readingList stat/SONOFF_01/POWER:.* POWER\
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/LWT:.* LWT\
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr SONOFF_01 room N_E_U
attr SONOFF_01 setList POWER:ON,OFF cmnd/SONOFF_01/POWER


Gruß

Guybrush

Dein Einwand ist zutreffend. Das Problem ist, dass der MQTT2_Client im Gegensatz zum MQTT2_Server die cid des devices nicht kennt. Wenn du das MQTT2_Discovery aber mit dem MQTT2_Server nutzt, ist auch die cid entsprechend gleich und autocreate=1 kein Problem. Das verhält sich beim MQTT2_Client anders. Da ist autocreate=1 zur Zeit ein Problem, weil die "echte" cid nicht bekannt ist. Derzeit ist nur kein fallback drin eine eigene cid zu erzeugen, wenn diese nicht (mehr) im stream ist. Deswegen ist autocreate=1 beim MQTT2_Client noch problematisch. Das Modul funktioniert mit beiden ohne Unterscheidung, nur dass beim client eben die cid nicht mehr da ist. Ich bau das aber nacher mal ein. Eigentlich ist im Modul schon alles dafür nötige drin.

SH_Heini

Das neu angelegte Gerät bekommt ja momentan die CID vom MQTT2_CLIENT als Standard. Da würde ich einfach den Namen des Gerätes anhängen.

<CIDvomMQTT2_CLIENT>_<Gerätename>

Letztlich ist ja m.E. nur wichtig, dass die CID am Gerät einzigartig ist.

funktioniert ebenfalls:
defmod SONOFF_01 MQTT2_DEVICE abc
Und natürlich Danke fürs Erstellen des Moduls.

Gruß

Guybrush

gerätename ist leider nicht eindeutig. wenn man die umbenennt gibts konfikte. ich hab das jetzt als fallback eingebaut, dass aus der entität des  topic ein 16stelliger hash erzeugt wird. der ändert sich nicht mehr bei einer umbenennung. sollte nach einem update gehen.   

Beta-User

CID wird komplett überbewertet.

Vielleicht die bridgeRegepx-Idee aus m2d übernehmen?
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Guybrush

das aus m2d brauchen wir hier nicht. Ich hab das schon vereinheitlicht.

Beispiel

Discovery-Topic:
homeassistant/sensor/node42/temperature/config

{
   "name": "Temperatur",
   "unique_id": "node42_temperature",
   "state_topic": "node42/temperature",
   "device": {
      "identifiers": ["node42"],
      "name": "Kellersensor"
   }
}

Weil device.identifiers vorhanden ist, lautet die interne Identität "mqtt|id|node42". sha1 davon auf 16 zeichen gekürzt "9442e7ea955bc09d" -> mqtt2_discovery_9442e7ea955bc09d

wenn identifiers nicht vorhanden ist, wird es zu "mqtt|connection|["mac","AA:BB:CC:DD:EE:FF"]". sha1 -> mqtt2_discovery_8809c1129335e71c

Ohne device.identifiers und device.connections wäre der Fallback dann auf topic basis
mqtt|entity|node42_temperature|node42|homeassistant/sensor/node42/temperature/config = "76212a9440030ab7" => mqtt2_discovery_76212a9440030ab7

identifiers ist stabiler als connection und das ist stabiler als topic. daher die reihenfolge

SH_Heini

Nach Update und Restart werden die Geräte sauber angelegt und readingslist wird nicht mehr mit gerätefremden Einträgen gefüllt.

neu automatisch angelegtes Gerät:
defmod SONOFF_01 MQTT2_DEVICE mqtt2_discovery_4b0a66f8fee617dc
attr SONOFF_01 DbLogExclude .*
attr SONOFF_01 group N_E_U
attr SONOFF_01 readingList stat/SONOFF_01/POWER:.* POWER\
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/LWT:.* LWT\
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr SONOFF_01 room N_E_U
attr SONOFF_01 setList POWER:ON,OFF cmnd/SONOFF_01/POWER


danach hab ich das noch vorhandene ignoreRegexp entfernt und sämtliche Zigbee Geräte wurden nun angelegt.

neu automatisch angelegtes Zigbee Gerät:
defmod WZ_LIGHTSTRIP_LICHT MQTT2_DEVICE mqtt2_discovery_7b82ac6886500890
attr WZ_LIGHTSTRIP_LICHT DbLogExclude .*
attr WZ_LIGHTSTRIP_LICHT devicetopic zigbee2mqtt
attr WZ_LIGHTSTRIP_LICHT group N_E_U
attr WZ_LIGHTSTRIP_LICHT readingList $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC/WZ_LIGHTSTRIP_LICHT:.* wz_lightstrip_licht\
$DEVICETOPIC/WZ_LIGHTSTRIP_LICHT:.* { json2nameValue($EVENT, '', {'brightness' => 'wz_lightstrip_licht_brightness', 'effect' => 'wz_lightstrip_licht_effect', 'effect_speed' => 'wz_lightstrip_licht_effect_speed', 'linkquality' => 'wz_lightstrip_licht_linkquality', 'power_on_behavior' => 'wz_lightstrip_licht_power_on_behavior'}) }\
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }
attr WZ_LIGHTSTRIP_LICHT room N_E_U
attr WZ_LIGHTSTRIP_LICHT setList wz_lightstrip_licht:ON,OFF $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set\
wz_lightstrip_licht_brightness:slider,0,1,255 $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set {"brightness":$EVTPART1}\
wz_lightstrip_licht_effect:blink,breathe,okay,channel_change,candle,fireplace,colorloop,sunset,sunrise,sparkle,opal,glisten,underwater,cosmos,sunbeam,enchant,none,finish_effect,stop_effect,stop_hue_effect $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set/effect\
wz_lightstrip_licht_effect_color $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set/effect_color\
wz_lightstrip_licht_effect_speed:slider,0,0.01,1 $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set/effect_speed\
wz_lightstrip_licht_power_on_behavior:off,on,toggle,previous $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set/power_on_behavior

was mir hier aufgefallen ist, vielleicht auch nur eine persönliche Präferenz, ist die Benutzung vom Attribut devicetopic und setList.

mein Wunschergebnis beim automatischen Anlegen:

defmod WZ_LIGHTSTRIP_LICHT MQTT2_DEVICE mqtt2_discovery_7b82ac6886500890
attr WZ_LIGHTSTRIP_LICHT DbLogExclude .*
attr WZ_LIGHTSTRIP_LICHT devicetopic zigbee2mqtt/WZ_LIGHTSTRIP_LICHT
attr WZ_LIGHTSTRIP_LICHT group N_E_U
attr WZ_LIGHTSTRIP_LICHT readingList $DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }
attr WZ_LIGHTSTRIP_LICHT room N_E_U
attr WZ_LIGHTSTRIP_LICHT setList state:ON,OFF $DEVICETOPIC/set $EVTPART1\
brightness:slider,0,1,255 $DEVICETOPIC/set {"brightness":$EVTPART1}\
effect:blink,breathe,okay,channel_change,candle,fireplace,colorloop,sunset,sunrise,sparkle,opal,glisten,underwater,cosmos,sunbeam,enchant,none,finish_effect,stop_effect,stop_hue_effect $DEVICETOPIC/WZ_LIGHTSTRIP_LICHT/set/effect\
effect_color $DEVICETOPIC/set/effect_color\
effect_speed:slider,0,0.01,1 $DEVICETOPIC/set/effect_speed\
power_on_behavior:off,on,toggle,previous $DEVICETOPIC/set/power_on_behavior\
deletereading:noArg {fhem("deletereading -q $NAME .*");;return undef}

Gruß

SH_Heini

Nach erneutem restart von fhem füllt sich readingslist bei allen Geräten wie folgt: (hier 3 Restarts)

stat/SONOFF_01/POWER:.* POWER
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/LWT:.* LWT
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
stat/SONOFF_01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/INFO(?:1|2|3):.* { $EVENT =~ m,^..Info(?:1|2|3)..(.+).$, ?  json2nameValue($1,'',$JSONMAP) : json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/SONOFF_01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }

2 Restarts:

$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT:.* kue_lightstrip_licht
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT:.* { json2nameValue($EVENT, '', {'brightness' => 'kue_lightstrip_licht_brightness', 'effect' => 'kue_lightstrip_licht_effect', 'effect_speed' => 'kue_lightstrip_licht_effect_speed', 'linkquality' => 'kue_lightstrip_licht_linkquality', 'power_on_behavior' => 'kue_lightstrip_licht_power_on_behavior'}) }
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT:.* { json2nameValue($EVENT, '', {'brightness' => 'kue_lightstrip_licht_brightness', 'effect' => 'kue_lightstrip_licht_effect', 'effect_speed' => 'kue_lightstrip_licht_effect_speed', 'linkquality' => 'kue_lightstrip_licht_linkquality', 'power_on_behavior' => 'kue_lightstrip_licht_power_on_behavior'}) }
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC/KUE_LIGHTSTRIP_LICHT:.* { json2nameValue($EVENT, '', {'brightness' => 'kue_lightstrip_licht_brightness', 'effect' => 'kue_lightstrip_licht_effect', 'effect_speed' => 'kue_lightstrip_licht_effect_speed', 'linkquality' => 'kue_lightstrip_licht_linkquality', 'power_on_behavior' => 'kue_lightstrip_licht_power_on_behavior'}) }
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }

Gruß

Guybrush

ich setz dafür den fix gerade schon um. die duplicates kommen, weil ich bislang nicht berücksichtigt hab, ob fhem schon INITIALIZED ist. weil die Werte aber schon beim define eingelesen werden und da das statfile noch nicht eingelesen ist, werden sie als manuell angelegte readings erkannt und in der folge ignoriert, was auch das richtige verhalten ist. devicetopic passe ich auch an, aber da geht dann nur das längste gemeinsame präfix. den mapper passe ich auch an wegen der json Probleme