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.
Wer die jeweils aktuellste Version testen möchte, der muss die github Url vom dev branch nehmen:
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
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ß
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.
Funktioniert jetzt.
Wollte den Weg ohne Github gehen.
Werde testen und berichten.
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
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.
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ß
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.
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ß
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.
CID wird komplett überbewertet.
Vielleicht die bridgeRegepx-Idee aus m2d übernehmen?
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
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ß
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ß
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
Das längste gemeinsame Präfix hört sich doch genau richtig an.
Meld Dich, wenn eine neue Version verfügbar ist, ich teste gerne weiter.
ich hab jetzt alles eingebaut, was ich anhand deiner Posts als Problem erkennen konnte. ist noch nicht im main, aber du kannst die aktuelle version so testen:
update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.0-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart
unittests liefen jedenfalls alle sauber durch und bei mir lokal funktionierts jetzt so wie es soll
Geräte gelöscht, Update gemacht und mqttDiscovery neu angelegt.
Devicetopic passt soweit für mich, aber es werden wieder die readingslist bei jedem Restart erneut befüllt (alle Geräte).
neu angelegtes Device nach 2 restarts:
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) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
attr WZ_LIGHTSTRIP_LICHT room N_E_U
attr WZ_LIGHTSTRIP_LICHT setList brightness:slider,0,1,254 $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/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\
state:ON,OFF $DEVICETOPIC/set {"state":"$EVTPART1"}
Fehlermeldung im Log zu dem Device:
2026.08.22 18:44:24 2: MQTT2_DISCOVERY mqttDiscovery: manual configuration wins for target=WZ_LIGHTSTRIP_LICHT; conflicts=state,brightness,effect_speed,effect,power_on_behavior,effect_color
Gruß
schon gefunden. alleine auf INITIALIZED abzustellen reicht nicht. ich muss die retained messages wohl erstmal cachen bis INITIALIZED erreicht ist. das geht aber schnell zu fixen
hab die Änderungen drin:
update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.2-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart
0.9.2
Leider keine Verbesserung: (1 Restart)
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
der bridge Eintrag verwundert mich ebenfalls, war bei den anderen Versionen auch schon.
Beim Erstellen von mqttDiscovery hab ich noch folgendes im Log:
2026.08.22 20:53:18 1: PERL WARNING: Prototype mismatch: sub main::decode_json ($) vs none at /usr/lib/aarch64-linux-gnu/perl-base/Exporter.pm line 63.
2026.08.22 20:53:18 2: MQTT2_DISCOVERY mqttDiscovery: defined for MQTT2_CLIENT MQTT2_TEST_CLIENT; version=0.9.2
Gruß
da komm ich jetzt leider nicht weiter ohne deine hilfe. führe bitte einmal diesen befehl in der fhem kommandozeile aus. bei $d="mqttDiscovery" bitte dein devicename eintragen, wenn es jetzt anders heissen sollte:
{my $d="mqttDiscovery";; my $v=ReadingsVal($d,".registry","");; local $@="";; my $r=length($v) ? eval { JSON::PP->new->decode($v) } : undef;; my $e=$@;; my $h=defined($defs{$d}) ? $defs{$d}{helper}{registry} : undef;; my $sd=length($v)==0 ? 0 : (!$e && ref($r) eq "HASH" && ref($r->{devices}) eq "HASH" ? scalar(keys %{$r->{devices}}) : "-");; my $hd=(ref($h) eq "HASH" && ref($h->{devices}) eq "HASH") ? scalar(keys %{$h->{devices}}) : "undef";; "time=".TimeNow()." device=".$d." init_done=".$main::init_done." configDB=".(configDBUsed()?1:0)." discoveredDevices=".ReadingsVal($d,"discoveredDevices","?")." discoveredEntities=".ReadingsVal($d,"discoveredEntities","?")." registryLength=".length($v)." decode=".(length($v)==0 ? "empty" : ($e ? "ERROR ".$e : "ok"))." storedDevices=".$sd." helperDevices=".$hd}
output kopieren. danach fhem über "shutdown restart" neu starten. nach dem neustart kurz warten und schauen ob neue duplikate da sind. dann den befehl nochmal ausführen. ich brauche beide outputs einmal zum abgleichen. danke ;)
time=2026-08-22 21:48:10 device=mqttDiscovery init_done=1 configDB=0 discoveredDevices=58 discoveredEntities=480 registryLength=855523 decode=ok storedDevices=58 helperDevices=58
time=2026-08-22 21:51:25 device=mqttDiscovery init_done=1 configDB=0 discoveredDevices=58 discoveredEntities=480 registryLength=855523 decode=ok storedDevices=58 helperDevices=58
und das bitte nochmal:
{my $d="mqttDiscovery";;my $t="WZ_LIGHTSTRIP_LICHT";;my $r=$defs{$d}{helper}{registry};;my @rec=grep {ref($_) eq "HASH" && defined($_->{name}) && $_->{name} eq $t} values %{$r->{devices}};;my $o=@rec && ref($rec[0]{owned_reading}) eq "ARRAY" ? $rec[0]{owned_reading}:[];;my @c=grep {length($_)} split(/\r?\n/,AttrVal($t,"readingList",""));;my %u=map {$_=>1}@c;;my $m=grep {$u{$_}}@$o;;my %seen;;my $dups=grep {$seen{$_}++}@c;;"device=$d target=$t records=".scalar(@rec)." current=".scalar(@c)." unique=".scalar(keys%u)." owned=".scalar(@$o)." matched=$m duplicates=$dups"}
device=mqttDiscovery target=WZ_LIGHTSTRIP_LICHT records=1 current=24 unique=3 owned=3 matched=3 duplicates=21
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) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
attr WZ_LIGHTSTRIP_LICHT room N_E_U
attr WZ_LIGHTSTRIP_LICHT setList brightness:slider,0,1,254 $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/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\
state:ON,OFF $DEVICETOPIC/set {"state":"$EVTPART1"}
Die Ursache lag bei der Zeichenkodierung der internen Geräteliste. Enthielt sie Sonderzeichen wie °, konnte sie nach einem FHEM-Neustart nicht korrekt gelesen werden. MQTT2_DISCOVERY erkannte dadurch seine vorhandenen Einträge nicht mehr und fügte sie erneut hinzu. Das ist mit Version 0.9.3 behoben und wurde mit mehreren Neustarts erfolgreich getestet:
update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.3-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart
0.9.3
Auch nach mehreren Restarts keine Verdoppelung der Einträge mehr.
Was jetzt immernoch auffällt ist, dass bei jedem Zigbeegerät der Eintrag der bridge enthalten ist:
attr readingList:
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
Gruß
$DEVICETOPIC ist auch in dem Beispiel weiter "zigbee2mqtt/WZ_LIGHTSTRIP_LICHT" ? kannst du mal ein list von dem device posten? danke
Ist bei allen Zigbeegeräten vorhanden,
hier das List:
Internals:
CID mqtt2_discovery_7b82ac6886500890
DEF mqtt2_discovery_7b82ac6886500890
FUUID 6a8aa3ee-f33f-0f6f-86df-a2e363e4650d3e8b
IODev MQTT2_TEST_CLIENT
LASTInputDev MOSQUITTO_WPI
MOSQUITTO_WPI_MSGCNT 7
MOSQUITTO_WPI_TIME 2026-08-23 10:35:14
MQTT2_TEST_CLIENT_MSGCNT 7
MQTT2_TEST_CLIENT_TIME 2026-08-23 10:35:14
MSGCNT 14
NAME WZ_LIGHTSTRIP_LICHT
NR 1065
STATE OFF
TYPE MQTT2_DEVICE
eventCount 14
.DT:
DEVICETOPIC zigbee2mqtt/WZ_LIGHTSTRIP_LICHT
.attraggr:
.attrminint:
READINGS:
2026-08-23 09:58:05 IODev MQTT2_TEST_CLIENT
2026-08-23 10:35:14 availability online
2026-08-23 10:35:14 brightness 72
2026-08-23 10:35:14 color_mode xy
2026-08-23 10:35:14 color_temp 168
2026-08-23 10:35:14 color_x 0.323
2026-08-23 10:35:14 color_y 0.329
2026-08-23 10:35:14 effect none
2026-08-23 10:35:14 philips_raw 07000001ea01
2026-08-23 10:35:14 state OFF
SEMANTIC_METADATA:
confidence 0.95
entities:
HASH(0x559357e9c8)
HASH(0x5593590e00)
HASH(0x55935932b0)
HASH(0x55935abc80)
HASH(0x5593590f50)
Attributes:
DbLogExclude .*
devicetopic zigbee2mqtt/WZ_LIGHTSTRIP_LICHT
group N_E_U
readingList $DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }
$DEVICETOPIC:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
room N_E_U
setList brightness:slider,0,1,254 $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/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
state:ON,OFF $DEVICETOPIC/set {"state":"$EVTPART1"}
Die devicetopics passen noch nicht bei allen Gerätearten.
Bei "light" passt das
Bei Sensoren (Kontakt/ Temperatur) sieht es noch so aus:
defmod TEMP_SENSOR_SZ MQTT2_DEVICE mqtt2_discovery_d1ba2cf229e73501
attr TEMP_SENSOR_SZ DbLogExclude .*
attr TEMP_SENSOR_SZ devicetopic zigbee2mqtt
attr TEMP_SENSOR_SZ group N_E_U
attr TEMP_SENSOR_SZ readingList $DEVICETOPIC/TEMP_SENSOR_SZ/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC/TEMP_SENSOR_SZ:.* { json2nameValue($EVENT) }\
$DEVICETOPIC/bridge/state:.* { json2nameValue($EVENT) }
attr TEMP_SENSOR_SZ room N_E_U
Bei Schaltern sieht es momentan noch so aus.
automatisch angelegtes Gerät:
defmod SCHALTER_WAND_SZ MQTT2_DEVICE mqtt2_discovery_c4cf107fac74f7e2
attr SCHALTER_WAND_SZ DbLogExclude .*
attr SCHALTER_WAND_SZ devicetopic zigbee2mqtt/SCHALTER_WAND_SZ
attr SCHALTER_WAND_SZ group N_E_U
attr SCHALTER_WAND_SZ readingList $DEVICETOPIC/action:off$ action_off\
$DEVICETOPIC/action:on$ action_on\
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
attr SCHALTER_WAND_SZ room N_E_U
attr SCHALTER_WAND_SZ setList schalter_wand_sz_identify:noArg $DEVICETOPIC/set/identify identify
schön fände ich:
defmod SCHALTER_WAND_SZ MQTT2_DEVICE mqtt2_discovery_c4cf107fac74f7e2
attr SCHALTER_WAND_SZ DbLogExclude .*
attr SCHALTER_WAND_SZ devicetopic zigbee2mqtt/SCHALTER_WAND_SZ
attr SCHALTER_WAND_SZ group N_E_U
attr SCHALTER_WAND_SZ readingList $DEVICETOPIC/availability:.* { json2nameValue($EVENT, '', {'state' => 'availability'}) }\
$DEVICETOPIC:.* { json2nameValue($EVENT) }
attr SCHALTER_WAND_SZ room N_E_U
attr SCHALTER_WAND_SZ setList identify:noArg $DEVICETOPIC/set/identify identify
Gruß
Das ist alles richtig so, da zigbee2mqtt den bridgestatus auch bei jedem einzelnen device im discovery mitschickt. HA nutzt das für die Verfügbarkeitsprüfung. Dort werden bei zigbee2mqtt default 2 Werte im discovery topic eines devices übertragen - die des devices und die der bridge. wenn beide positiv sind, dann ist availability = 1 bei HA.
Wenn du in Zigbee2mqtt unter settings>home assistant integration "enabled" aktivierst, wird auch automatisch ein Zigbee Bridge Device angelegt. HA funktioniert ja etwas anders als fhem. Das ist eigentlich unnötig in jedem device den bridge status zu haben. Aber es ist auch komfortabel, weil man so nichts händisch machen muss, wie bei fhem. MQTT2_Discovery soll das HA / Tasmota Protokoll insoweit 1:1 umsetzen und verzichtet auf hardcodierte Umbiegungen. Das funktioniert also alles so wie gewollt und würde in HA auch nicht anders laufen.
ich bau das aber gerade schon ein, dass entsprechend der HA Vorgaben ein availabilty topic gesetzt wird. die readings von device+bridge würden dann ausgeblendet, oder optional über attribut trotzdem angelegt werden. so in etwa solls werden.
Zitat von: SH_Heini am 23 August 2026, 11:28:40Bei Schaltern sieht es momentan noch so aus.
automatisch angelegtes Gerät:
kannst du davon die discovery message einmal posten?
Zitatkannst du davon die discovery message einmal posten?
da stehe ich gerade auf dem Schlauch, was meinst Du mit discovery message?
das sind die mqtt nachrichten mit discovery prefixen. default:
homeassistant/...
tasmota/discovery/...
nur diese nachrichten verarbeitet MQTT2_Discovery. alle anderen sind states/cmd und werden unverändert von MQTT2_Device verarbeitet. Ich brauch also die zu dem Gerät gehörende Nachricht die mit einem der beiden präfixe beginnt. also z.b. tasmota/discovery/<gerät>/...
{
"availability": [
{
"topic": "zigbee2mqtt/bridge/state",
"value_template": "{{ value_json.state }}"
},
{
"topic": "zigbee2mqtt/SCHALTER_WAND_SZ/availability",
"value_template": "{{ value_json.state }}"
}
],
"availability_mode": "all",
"command_topic": "zigbee2mqtt/SCHALTER_WAND_SZ/set/identify",
"default_entity_id": "button.schalter_wand_sz_identify",
"device": {
"hw_version": 1,
"identifiers": [
"zigbee2mqtt_0xf4b3b1fffea4daf8"
],
"manufacturer": "IKEA",
"model": "TRADFRI on/off switch",
"model_id": "E1743",
"name": "SCHALTER_WAND_SZ",
"sw_version": "24.4.6",
"via_device": "zigbee2mqtt_bridge_0x983268fffe1c1485"
},
"device_class": "identify",
"entity_category": "config",
"object_id": "schalter_wand_sz_identify",
"origin": {
"name": "Zigbee2MQTT",
"sw": "2.13.0",
"url": "https://www.zigbee2mqtt.io"
},
"payload_press": "identify",
"unique_id": "0xf4b3b1fffea4daf8_identify_zigbee2mqtt"
}
das hier?
ich hab das jetzt so umgesetzt, dass ein availability reading entsprechend automatisch berechnet wird anhand der discovery settings. falls ein device zufällig diesen reserved key selbst setzen sollte, wird das reading state_availability benannt. Das entspricht jetzt so der HA Vorgaben.
update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.5-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart
die angelegte readinglist/setlist sollte dann sauber sein bei dir. teste das mal.
Hab mit oben genannten Befehl alles neu geladen, scheint aber noch die alte Version zu sein.
2026.08.24 18:51:11 2: MQTT2_DISCOVERY mqttDiscovery: defined for MQTT2_CLIENT MQTT2_TEST_CLIENT; version=0.9.3
commit ohne push funktioniert nicht ;-) jetzt aber
update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.5-1-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart
Hier wird für jedes action - payload ein eigenes Reading erstellt.
Schöner fände ich 1 Reading für action
$DEVICETOPIC/action:arrow_left_click$ action_arrow_left_click
$DEVICETOPIC/action:arrow_right_click$ action_arrow_right_click
$DEVICETOPIC/action:brightness_move_down$ action_brightness_move_down
$DEVICETOPIC/action:brightness_move_up$ action_brightness_move_up
$DEVICETOPIC/action:brightness_stop$ action_brightness_stop
$DEVICETOPIC/action:off$ action_off
$DEVICETOPIC/action:on$ action_on
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:battery|linkquality)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"latest\",\"reading\":\".availability_policy_5b2bc7f1\",\"sources\":[\".availability_ad7452a7\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_ad7452a7\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
das List eines Gerätes welches offline ist:
Internals:
CFGFN
CID mqtt2_discovery_216684b4ecee73c1
DEF mqtt2_discovery_216684b4ecee73c1
FUUID 6a8c8dfc-f33f-0f6f-011e-7f86aa44e50e9c92
IODev MQTT2_TEST_CLIENT
LASTInputDev MQTT2_TEST_CLIENT
MQTT2_TEST_CLIENT_MSGCNT 2
MQTT2_TEST_CLIENT_TIME 2026-08-24 20:33:00
MSGCNT 2
NAME FLUR_LIGHTSTRIP_LICHT
NR 1100
STATE ???
TYPE MQTT2_DEVICE
eventCount 3
.DT:
DEVICETOPIC zigbee2mqtt/FLUR_LIGHTSTRIP_LICHT
.attraggr:
.attrminint:
READINGS:
2026-08-24 20:33:00 .availability_4e04eb0c offline
2026-08-24 20:32:44 .availability_5c66e817 online
2026-08-24 20:32:00 .availability_io online
2026-08-24 20:33:00 .availability_policy_5a662e8d offline
2026-08-24 20:31:24 IODev MQTT2_TEST_CLIENT
2026-08-24 20:33:00 availability offline
SEMANTIC_METADATA:
confidence 0.95
entities:
HASH(0x55ab5f1f40)
HASH(0x55ab5ec268)
HASH(0x55ab60c048)
HASH(0x55ab3f37a0)
Attributes:
DbLogExclude .*
devicetopic zigbee2mqtt/FLUR_LIGHTSTRIP_LICHT
group N_E_U
readingList $DEVICETOPIC/availability:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_5a662e8d\",\"sources\":[\".availability_4e04eb0c\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_4e04eb0c\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:brightness|linkquality|power_on_behavior|state)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_5a662e8d\",\"sources\":[\".availability_4e04eb0c\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_5c66e817\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
room N_E_U
setList brightness:slider,0,1,254 $DEVICETOPIC/set {"brightness":$EVTPART1}
flur_lightstrip_licht_effect:blink,breathe,okay,channel_change,finish_effect,stop_effect,colorloop,stop_colorloop $DEVICETOPIC/set/effect
identify:noArg $DEVICETOPIC/set/identify identify
power_on_behavior:off,on,toggle,previous $DEVICETOPIC/set/power_on_behavior
state:ON,OFF $DEVICETOPIC/set {"state":"$EVTPART1"}
Allgemin empfinde ich die jetzige Art der readingList Definitionen als unübersichtlich.
Gruß
die readinglist wird definitiv bei Geräten, die zb Jinja Templates nutzen komplexer. Bei einfachen Geräten wie Steckdosen Tasmotas usw gibts eigentlich keinen Unterschied. Dafür entstehen keine unsinnigen Reading mehr und man muss sich nicht mit der Suche nach einem passenden Template rumschlagen. das sieht da jetzt auch nur wegen dem neuen availabilty so komplex aus. dafür haben jetzt all deine Zigbee Devices ein availabilty Flag, was sofort zeigt, ob es funktioniert.
dass da mehrere readings angelegt wurden für arrow_left_click/arrow_right_click ist eigentlich richtig. Jedenfalls ist das kein Bug. Genau dieses Schema kann man der HA Doku entnehmen und Zigbee2mqtt setzt das genauso um. Das ist für Fhem etwas doof. man könnte aber sowas ggf. in etwa so zusammenfassen:
$DEVICETOPIC/action:(?:arrow_left_click|arrow_right_click|...)$ action
Da muss ich aber erst schauen, ob das nicht irgendwelche anderen Sachen beeinflusst. Derzeit bin ich schon am Sonos2Mqtt Parser dran. Das wird dann neben Tasmota und HA der dritte Aggregator. Das muss ich erst fertig machen bevor ich danach schauen kann, aber werd mich dem dann annehmen.
Wegen der Readinglist muss man schauen. Es gibt eine versteckte Registry im Modul. Da stehen die Sachen etwas detaillierter drin. Man könnte da nur stabile Policy und Source IDs in die readinglist schreiben und den Rest aus der registry holen. Das ist aber komplexer und es betrifft nur die Lesbarkeit der readingList bei komplexen Geräten. Eigentlich soll man durch MQTT2_Discovery nie wieder die readinglist/setlist bearbeiten müssen.
Schön ist aber, dass die neue Version availability richtig berechnet und damit auch bei dir funktioniert 8) Sonst sehen deine Readings jetzt aber sauber aus?
Folgende Meldung hab ich nach einem Neustart im Log, betrifft alle Zigbeegeräte, die man über Zigbee2MQTT updaten kann.
2026.08.26 12:58:00 1: MQTT2_DISCOVERY mqttDiscovery: parser error for topic=homeassistant/update/0x001788010c570283/update/config: Nicht unterstuetzte Komponente: update
topic:
homeassistant/update/0x001788010c570283/update/config
payload:
{
"availability": [
{
"topic": "zigbee2mqtt/bridge/state",
"value_template": "{{ value_json.state }}"
},
{
"topic": "zigbee2mqtt/WZ_LIGHTSTRIP_LICHT/availability",
"value_template": "{{ value_json.state }}"
}
],
"availability_mode": "all",
"command_topic": "zigbee2mqtt/bridge/request/device/ota_update/update",
"default_entity_id": "update.wz_lightstrip_licht",
"device": {
"hw_version": 0,
"identifiers": [
"zigbee2mqtt_0x001788010c570283"
],
"manufacturer": "Philips",
"model": "Hue white and color ambiance LightStrip plus",
"model_id": "8718699703424",
"name": "WZ_LIGHTSTRIP_LICHT",
"sw_version": "1.163.1",
"via_device": "zigbee2mqtt_bridge_0x983268fffe1c1485"
},
"device_class": "firmware",
"entity_category": "config",
"entity_picture": "https://github.com/Koenkk/zigbee2mqtt/raw/master/images/logo.png",
"name": null,
"object_id": "wz_lightstrip_licht",
"origin": {
"name": "Zigbee2MQTT",
"sw": "2.13.0",
"url": "https://www.zigbee2mqtt.io"
},
"payload_install": "{\"id\": \"0x001788010c570283\"}",
"state_topic": "zigbee2mqtt/WZ_LIGHTSTRIP_LICHT",
"unique_id": "0x001788010c570283_update_zigbee2mqtt",
"value_template": "{\"latest_version\":\"{{ value_json['update']['latest_version'] }}\",\"installed_version\":\"{{ value_json['update']['installed_version'] }}\",\"update_percentage\":{{ value_json['update'].get('progress', 'null') }},\"in_progress\":{{ (value_json['update']['state'] == 'updating')|lower }}}"
}
Gruß
das ist mehr ein Warning als Error. Update wird noch nicht unterstützt. Das ist zwar nicht allzuviel Arbeit, aber das kann ich erst machen wenn das andere durch ist. Sonos2mqtt Support ist fast durch, aber Unittests halten da ewig auf und beim Erstellen findet man ja oft genug noch Bugs. Bau ich dann aber ein. Betrifft aber auch nur OTA Updates.
Bei Sonos2MQTT kann ich leider nicht helfen, habe keine Sonos Geräte, vielleicht findet sich ja ein weiterer Tester.
Was mir aufgefallen ist, bei den Tür- und Temperatursensoren ist noch das Problem mit Devicetopic:
defmod TK_TUER_BAD MQTT2_DEVICE mqtt2_discovery_6aab4e3c0e228bff
attr TK_TUER_BAD DbLogExclude .*
attr TK_TUER_BAD devicetopic zigbee2mqtt
attr TK_TUER_BAD group N_E_U
attr TK_TUER_BAD readingList $DEVICETOPIC/TK_TUER_BAD/availability:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_c7655aa3\",\"sources\":[\".availability_40f55c20\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_40f55c20\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }\
$DEVICETOPIC/TK_TUER_BAD:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:battery|contact|device_temperature|linkquality|power_outage_count|trigger_count|voltage)$') }\
$DEVICETOPIC/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_c7655aa3\",\"sources\":[\".availability_40f55c20\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_5c66e817\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
attr TK_TUER_BAD room N_E_U
Gruß
devicetopic Erkennung ist da wegen zigbee2mqtt/bridge/status richtig, dass es nur zigbee2mqtt ist. Hast du dafür die passende discovery message, wo auch TK_TUER_BAD drin ist?
OT-Frage: spricht etwas dagegen, sowas ins SVN zu packen?
Wenn nicht (schon) als offizielles Modul, dann eventuell contrib?
Du hast ja noch ein paar mehr Sachen am Kochen...
Da spricht grundsätzlich nichts dagegen. Ich nutz nur selbst kein Subversion mehr und hab alles auf git umgestellt. Deswegen pack ich auf github auch grad meine Sachen step by step. Hast du das Modul mal selbst getestet? Ich hab zwar schon super viele tests geschrieben, aber tests ersetzen nicht alles :))
Bei einer Lampe wird "zigbee2mqtt/bridge/status" genommen, bei Sensoren jedoch "$DEVICETOPIC/bridge/state".
Würde Ersteres bevorzugen, da dann das Devicetopic für das jeweilige Gerät besser genutzt wird.
readingList von WZ_LIGHTSTRIP_LICHT:
$DEVICETOPIC/availability:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_cde3617c\",\"sources\":[\".availability_1fd9595d\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_1fd9595d\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:brightness|effect|effect_speed|linkquality|power_on_behavior|state)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_cde3617c\",\"sources\":[\".availability_1fd9595d\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_5c66e817\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
discovery message von TK_TUER_BAD:
{
"availability": [
{
"topic": "zigbee2mqtt/bridge/state",
"value_template": "{{ value_json.state }}"
},
{
"topic": "zigbee2mqtt/TK_TUER_BAD/availability",
"value_template": "{{ value_json.state }}"
}
],
"availability_mode": "all",
"default_entity_id": "binary_sensor.tk_tuer_bad_contact",
"device": {
"hw_version": 2,
"identifiers": [
"zigbee2mqtt_0x00158d0007e78871"
],
"manufacturer": "Aqara",
"model": "Door and window sensor",
"model_id": "MCCGQ11LM",
"name": "TK_TUER_BAD",
"sw_version": "3000-0001",
"via_device": "zigbee2mqtt_bridge_0x983268fffe1c1485"
},
"device_class": "door",
"object_id": "tk_tuer_bad_contact",
"origin": {
"name": "Zigbee2MQTT",
"sw": "2.13.0",
"url": "https://www.zigbee2mqtt.io"
},
"payload_off": true,
"payload_on": false,
"state_topic": "zigbee2mqtt/TK_TUER_BAD",
"unique_id": "0x00158d0007e78871_contact_zigbee2mqtt",
"value_template": "{{ value_json[\"contact\"] }}"
}
Gruß
das müsste mit der neuen Version schon funktionieren. Lief jedenfalls gerade bei mir sauber durch. Wenn die letzten Sachen fertig und unittests komplett sind, gibts die neue Version ;)
Zitat von: Guybrush am 26 August 2026, 20:17:01Hast du das Modul mal selbst getestet?
Nein, und das war auch weder mein Plan, noch war mein Anliegen hinter beiden Posts persönliches (Nutzungs-) Interesse. Kurz zu den Punkten:
svn:
Unabhängig davon, ob man svn nun gut findet oder nicht, oder die Art und Weise, wie patches den Eingang ins (fhem-) svn-Repo finden, ist svn aktuell die Methode, mit der die allgemeine Code-Basis gepflegt wird. Damit ist auch implizit verbunden, dass grundsätzlich klar ist, dass ggf. auch anderen diese Code-Basis dauerhaft zur Nutzung bereit steht und (praktisch eher im Notfall, aber) auch andere Entwickler mit svn-Zugang die Möglichkeit haben, Fehler zu beseitigen.
Weiter schaue ich am ehesten in der commandref nach, wenn ich eine (Modul-)Lösung für ein Problem suche, danach im Wiki bzw. Forum. Vielleicht dann zuletzt im allgemeinen Internet. Wenn dann die Lösung in contrib zu finden ist, bin ich persönlich eher geneigt, das auszuprobieren, wie wenn ich (gut gepflegte!) github-repos einbinden muss. (Die imo schlechteste Variante ist es, wenn man sich in Bandwurm-Threads die jeweils letzte Fassung selbst suchen muss).
Da du in der letzten Zeit mind. 3 update-Quellen angelegt hast, wollte ich dich einfach dazu anpingen :) .
Die mich mich einfachste Variante dabei war, schlicht den Thread zu nutzen, in dem ich sowieso schon mal gepostet hatte ;) .
bridgeRegexp:Dabei ging es mir weniger um die Übernahme der konkret zu MQTT2_DEVICE gefundenen Lösung, sondern eher um die Überlegung, ob es nicht zielführend ist, eine Eingabestelle für den einzelnen User zu haben, mit der dem Modul ggf. mitgeteilt werden kann, was der User selbst als relevant für solche "autocreate"-Vorgänge ansieht.
Wenn man sowas nicht braucht oder es kontraproduktiv ist, darfst du das gerne anders lösen.
Es dürfte kein Problem sein über github actions bei einem commit nach main einen commit ins fhem svn anzulegen. Hab ich noch nicht gemacht, aber wenn das gewünscht ist und ich Zugang zu habe, kann ich mir das gerne anschauen.
BridgeRegexp ist aus meiner Sicht eher ein Behelf, der ohne das Discovery Modul schon fast essentiell ist, wenn man da nicht vollgemüllte readings haben möchte. Ich hab das in der neuen Version schon drin, dass optional per Attribut alle über Discovery erkannten sicheren Readings auch schon ohne Wert angelegt werden können. Man könnte aber auch drüber nachdenken noch eine Regexp Filterung zu hinterlegen, wenns denn Sinn macht. Ich selbst will eigentlich alle sinnigen Readings haben. Über autocreate erstellte Readings werden alle Discovery Config Elemente als reading erkannt, auch wenns nur beschreibend ist usw. Das wird schnell unübersichtlich. Das passiert mit MQTT2_Discovery aber nicht mehr.
Ich hab das Modul geupdatet. Die aktuelle Version liegt noch im Dev Branch, den ich dann aber später in Main überführen möchte:
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
Zigbeebridge usw sollten jetzt auch richtig gehen. So sieht meine Zigbee2Mqtt Bridge nach discovery und rebuild aus:
attr zigbee2mqtt readingList $DEVICETOPIC/info:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_ddd6824033ac357c', $EVENT) }\
$DEVICETOPIC/state:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f37c2d6e26b25423', $EVENT) }
attr zigbee2mqtt setList Restart:noArg $DEVICETOPIC/request/restart \
log_level:error,warning,info,debug $DEVICETOPIC/request/options\
permit_join:on,off { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_48b97e793d1525c8', $EVENT) }
Man kann jetzt auch zuvor per autocreate/manuell angelegte MQTT2_DEVICES durch MQTT2_DISCOVERY übernehmen. dafür gibts den neuen Befehl "rebuildDevice <device> clearReadings". clearReadings ist optional und löscht alle readings. Das macht Sinn, wenn durch autocreate blödsinnige Readings entstanden sind. Ich hab das jetzt bei mir ins Produktivsystem übernommen und funktioniert soweit fehlerfrei. Daher gerne andere bitte auch mal testen.
Changelog:
Sonos2mqtt integriert und Discovery-Verarbeitung erweitert
- Sonos2mqtt als dritten Discovery-Adapter eingebunden
- Media-Player-Readings, Availability und Steuerbefehle abgebildet
- Home-Assistant-Update-Entitäten samt Installationsbefehl unterstützt
- Root-Entities unabhängig von Groß- und Kleinschreibung korrekt benannt
- Geräteaktionen mit gemeinsamem Topic zu einem Reading zusammengeführt
- Jinja-Auswertung um defined, undefined und bedingte Ausdrücke erweitert
- Komplexe Templates, Mappings und JSON-Auswertungen über stabile Runtime-Referenzen gekapselt
- Unicode-Werte an der FHEM- und MQTT-Grenze korrekt als UTF-8 codiert
- Doppelte Codierung bereits vorliegender MQTT-Bytes verhindert
- extraJsonReadings, availabilityReading und createReadings ergänzt
- Reading-Kollisionen anhand des Topic-Pfads eindeutig aufgelöst
- Attributänderungen ohne erneute Discovery-Nachrichten neu gerendert
- Vorhandene JSON-Sammelhandler im konservativen Modus berücksichtigt
- Devicetopic-Ableitung anhand geräteeigener Availability-Topics verbessert
- rebuildDevice um atomare Devicetopic- und Listenerzeugung erweitert
- Optionales Löschen sichtbarer Readings beim Neuaufbau ergänzt
- Rollback und Erfolgserkennung beim Löschen von Readings korrigiert
- FHEMWEB-Übersicht für verwaltete und nicht verwaltete Devices ergänzt
- Interne Tasmota-Neuaufbauten von echten Discovery-Löschungen getrennt
Zitat von: Guybrush am 29 August 2026, 11:06:42Ich hab das Modul geupdatet. Die aktuelle Version liegt noch im Dev Branch, den ich dann aber später in Main überführen möchte:
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
Beim Versuch, den aktuellen dev-Stand frisch zu aktualisieren, bricht FHEM bei mir mit einer Größenabweichung ab:
Downloading https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
MQTT2_DISCOVERY
UPD FHEM/10_MQTT2_DISCOVERY.pm
Got 99666 bytes for FHEM/10_MQTT2_DISCOVERY.pm, expected 144096
aborting.
In der controls_MQTT2_DISCOVERY.txt steht aktuell für die Datei:
UPD 2026-08-29_10:50:01 144096 (tel:01%20144096) FHEM/10_MQTT2_DISCOVERY.pm
Die aktuell geladene Datei im dev-Branch scheint aber 99666 Bytes groß zu sein.
Könntest du bitte die controls-Datei aktualisieren?
Ich würde danach meine Tasmota-/ESPresense-/sonos2mqtt-Tests mit einem sauberen aktuellen dev-Stand wiederholen, bevor ich die gefundenen Punkte poste.
Den Fehler hab ich lokal schon behoben. Das fiel mir auch auf, dass der Pre-Commit Hook unsauber arbeitete. Ich hab die aktuelle Fassung jetzt in den DEV Branch gepushed. Sollte jetzt gehen!
Vielen Dank für das neue Modul und die viele Arbeit, die da offensichtlich schon hineingeflossen ist.
Ich habe den aktuellen dev-Stand bei mir mit einem MQTT2_SERVER getestet. Insgesamt macht das schon einen sehr guten Eindruck.
Positiv getestet habe ich bisher:
* Tasmota Discovery mit zwei Gosund EP2
* ESPresense über Home-Assistant-Discovery
* Restart von FHEM mit anschließendem Wiederherstellen der Registry
* erneuter rescan
* Availability der erzeugten Devices
* get mqttDiscovery devices
Besonders positiv: Nach Restart und erneutem rescan bleiben die erzeugten readingList-Einträge bei mir stabil. Die zuvor beobachteten mehrfachen Einträge konnte ich mit dem aktuellen Stand nicht mehr reproduzieren.
Aktuell sind mir noch zwei Punkte aufgefallen.
1. Sonos2mqtt
Mein sonos2mqtt publiziert die Discovery-Informationen in der von sonos2mqtt dokumentierten Form:
homeassistant/music_player/<RINCON>/sonos/config
Genau diese retained Topics sehe ich auch auf meinem Broker.
Ein Beispiel-Payload enthält u.a.:
{
"device_class": "speaker",
"state_topic": "sonos/RINCON_xxx",
"command_topic": "sonos/RINCON_xxx/control",
"availability_topic": "sonos/connected",
"payload_available": "2"
}
MQTT2_DISCOVERY verarbeitet diese Topics bei mir aktuell mit dem HomeAssistant-Adapter und meldet:
Nicht unterstuetzte Komponente: music_player
Im aktuellen README ist für den Sonos2mqtt-Adapter dagegen das Format
sonos2mqtt/discovery/<mqttPrefix>/<RINCON>
beschrieben.
Die sonos2mqtt-Dokumentation beschreibt jedoch:
homeassistant/music_player/<RINCON>/sonos/config
Siehe:
https://sonos2mqtt.svrooij.io/topics.html
Daher meine Frage: Ist sonos2mqtt/discovery/... für eine andere bzw. neuere sonos2mqtt-Version gedacht, oder sollte der Sonos2mqtt-Adapter auch das offiziell dokumentierte homeassistant/music_player/.../sonos/config erkennen?
2. ESPresense / number
ESPresense funktioniert bei mir grundsätzlich gut:
* Device wird korrekt angelegt
* Telemetrie wie uptime und freeHeap funktioniert
* Availability funktioniert
* absorption und max_distance werden als Readings korrekt aktualisiert
Bei den beiden number-Entities erhalte ich allerdings:
number: ungueltige min/max/step-Kombination
Betroffen sind:
homeassistant/number/espresense_xxx/absorption/config
homeassistant/number/espresense_xxx/max_distance/config
Die relevanten Discovery-Payloads sehen so aus:
{
"~": "espresense/rooms/sz",
"name": "Absorption",
"stat_t": "~/absorption",
"cmd_t": "~/absorption/set",
"step": "0.1",
"entity_category": "config"
}
und:
{
"~": "espresense/rooms/sz",
"name": "Max Distance",
"stat_t": "~/max_distance",
"cmd_t": "~/max_distance/set",
"step": "0.1",
"entity_category": "config"
}
Die Readings funktionieren:
absorption 2.70
max_distance 16.00
Es wird jedoch für beide kein Setter erzeugt.
Soweit ich die Home-Assistant-MQTT-number-Dokumentation verstehe, sind min und max optional und haben Defaultwerte. Daher könnte hier eventuell das Default-Handling für fehlendes min/max fehlen.
Insgesamt funktioniert aber bereits erstaunlich viel sehr sauber. Vielen Dank auch dafür, dass die Restart-/Rescan-Themen im aktuellen Stand offenbar schon deutlich robuster geworden sind.
Danke ;D auch für die Tests!
Wegen Sonos:
Du hast wohl noch eine ältere Sonos2Mqtt Version laufen. Seit der aktuellen 4.0.0-beta-6 haben die das von /homeassistant/music_player/<RINCON>/sonos/config auf sonos2mqtt/discovery/<mqttPrefix>/<RINCON> geändert:
https://github.com/svrooij/sonos2mqtt/pull/184/changes/8c1cbb7b0af75dbcc18cf821ebb34dd2284cc171
Daher habe ich mich entschlossen direkt (nur) das neue Format zu unterstützen. HomeAssistant selbst kennt jedenfalls nativ auch kein music_player. Es ist/war schon immer eine spezifische Sonos2Mqtt Erweiterung. Deswegen kennt der HA Parser das auch nicht, da das nur im S2M Parser drin ist. Die neuen 4.0.0 Beta Releases von S2M laufen aber gut. Daher hab ich die bei mir nun auch schon produktiv laufen. Wenn S2M das aber auf Dauer doch beides parallel unterstützen sollte kann ich das noch integrieren. Ansonsten will ich das so erstmal lassen. S2M wird ja aktiv entwickelt.
Wegen ESPpresence:
Du hast scheinbar ein Bug im Default-Handling gefunden. Aktuell werden min=0, max=100 und step=1 nur gemeinsam gesetzt, wenn alle drei Angaben fehlen. Ist lediglich step=0.1 vorhanden, bleiben min und max undefiniert und die nachfolgende Validierung verwirft den Setter. Home Assistant behandelt diese Felder hingegen unabhängig voneinander als optional. Das ist aber nicht schwer anzupassen. Mach ich im Laufe des Tages ;)
Hakelig war vor allem, dass manuelle Ergänzungen/Änderungen an der reading/setList erhalten bleiben, aber neue Sachen auch ergänzt werden. Theoretisch muss man mit Discovery garnichts mehr an den Attributen ändern. Aber es gibt leider immer wieder Devices, die Topics senden, die nicht per Discovery vorher bekannt gegeben wurden. Insofern ist es schon gut, wenn wir diese Freizügigkeit bei FHEM erhalten und das nicht zu stark vorgeben wie HA es macht. Aber schön, dass das bei dir auch gut läuft ;D
In der neuen DEV Version ist der Fehler mit den Settern bzgl. ESPresence behoben. Nicht gesetzte Setter Werte werden nun mit Defaults gesetzt (min=0,max=100,step=1)
update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update
Spannendes Modul, wenn man -wie ich- MQTT selten nutzt und das auch meist nur zum Experiementieren in FHEM-Testinstanzen. Inbesondere setList quält mich dann immer wieder.
Sonos, mit dem ich zuletzt mit MQTT2_Discovery gespielt habe, habe ich so einfach integriert bekommen. Aufgefallen ist mir nur, dass ich immer wieder ein zusätzliches MQTT-Device bekam, wenn der MQTT-Device-Name nicht dem Sonos-Gerätenamen entsprach. In dem zusätzlichen MQTT-Device waren readingList-Einträge avtransport für alle Sonos-Geräte mit den Namen. Ob ich etwas falsch gemacht habe:? Wenn Du dazu Infos brauchst versuche ich das noch einmal nachzustellen.
Zuvor hatte ich homeassistant-discovery gearbeitet. Die Sensoren funktionerten problemlos. Sind aber leztlich für mich auch problemlos ohne MQTT2_discovery einbindbar. Mein Saugroboterpark (valetudo) funktioniert leider nicht, da nur einzelne setList-Befehle angelegt werden. Nur die Hauptfunktionen start,stop, usw. nicht. Nachdem ich in die Doku geschaut habe, ist das auch so dokumentiert: homeassistant-discovery vaccum ist noch(?) nicht unterstützt.
Experimente mit der MQTT-Anbindung von zwavejs-ui, was eigentlich meine große Hoffnung war, habe ich nicht gemacht, da zwischenzeitlich homeassitant-discovery von zwavejs-ui wohl auf nicht mehr gewartet wird. Die Verbindung zwavejs-ui-Homeassitant soll nun über websocket erfolgen.
Danke für dein Modul, das ich auch gerne im SVN hätte. :)
Ohne Discovery-Support im Gerät hilft MQTT2_DISCOVERY leider nicht viel. Aber wenn Sonos direkt funktionierte ist das top ;-) Poste aber gerne mal lists von den beiden devices. Dass ein zusätzliches device erscheint dürfte nicht sein. Ist vielleicht noch autocreate im mqtt2_server/client an? das sollte besser deaktiviert werden, wenn man das Modul nutzt.
Zitat von: Guybrush am 12 September 2026, 10:38:42Ist vielleicht noch autocreate im mqtt2_server/client an?
Ja, das war mein Fehler. Ohne autocreate am mqtt2_server hat es jetzt bei 2 Tests ohne Probleme funktioniert. Danke.