Hi, ein Busch-Jaeger Zigbee-Aktor hat seit dem letzten Update von zigbee2mqtt das Problem, dass er sowohl "state" als auch "state_relay" Daten liefert, "state" dabei allerdings immer "off" ist und nur state_relay Brauchbares liefert.
Hat jemand ein Idee, wie ich das per mqtt gelieferte Reading "state" ignorieren und (über stateFormat vermutlich - oder über ) ein eigenes state erzeugen kann?
Aktueller, leider nicht ganz funktionierender Versuch:
Internals:
CID zigbee_Lt_Vorratskeller
DEF zigbee_Lt_Vorratskeller
FUUID 63dd23d5-f33f-e1ef-b930-fd8392da912c1664
IODev myBroker
LASTInputDev myBroker
MSGCNT 1199
NAME Lt_Vorratskeller
NR 977
STATE off
TYPE MQTT2_DEVICE
eventCount 47
myBroker_MSGCNT 1199
myBroker_TIME 2025-05-05 22:30:36
OLDREADINGS:
READINGS:
2025-05-05 03:03:29 IODev myBroker
2023-02-04 12:19:23 associatedWith MQTT2_zigbee2mqtt
2023-02-03 16:10:27 attrTemplateVersion 20221201
2025-04-27 23:21:20 availability {"state":"online"}
2025-05-05 22:30:36 brightness_relay 254
2025-05-05 22:30:36 linkquality 61
2025-05-05 22:30:36 state off
2025-05-05 22:30:36 state_relay OFF
Attributes:
devStateIcon on:light_ceiling@orange:off off:light_ceiling_off:on
devicetopic zigbee2mqtt/Lt_Vorratskeller
event-on-change-reading state,state_relay,availability_state
fp_fp_Grundriss_UG 189,227,0,Lt_Vorratskeller,
genericDeviceType light
homebridgeMapping Brightness=brightness::brightness,maxValue=100,max=100,factor=0.39371,delay=true
model zigbee2mqtt_light_dimmer
readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}) if defined $ret->{state}; return $ret }
zigbee2mqtt/Lt_Vorratskeller/availability:.* availability
room Cfg_Licht,Cfg_Zigbee,Vorratskeller
setList on:noArg $DEVICETOPIC/set {"state_relay":"ON"}
off:noArg $DEVICETOPIC/set {"state_relay":"OFF"}
setStateList on off
stateFormat {lc(ReadingsVal($name,'state_relay','err'))}
webCmd on:off
Danke für einen Schubser in die richtigere Richtung.
Na dann probiere doch mal das Attribut "jsonMap".
Damit solltest du auf einfachem Weg an dein Ziel kommen.
userReading wäre auch noch eine Lösung, aber bei MQTT geht das m.E. so am einfachsten.
Gruß
Dan
Danke, Dan. Wenn ich Dich richtig verstanden habe, meintest Du sowas:
attr Lt_Vorratskeller jsonMap state:state_defunct state_relay:state
Das ändert leider nichts. Statusänderungen kommen nach wie vor im Reading state_relay an, das Reading state_defunct wird nicht erzeugt und das Reading state enthält nach wie vor das von z2m erzeugte und übermittelte permanente "off".
Kannst Du uns bitt die Eingangsdaten (JSON) zeigen?
Ich habe hier mal die MQTT Messages für ein Ein- und wieder Ausschalten des Schalters mitgeschnitten:
Client null received PUBLISH (d0, q0, r0, m0, 'zigbee2mqtt/Lt_Vorratskeller', ... (74 bytes))
{"brightness_relay":254,"linkquality":14,"state":"OFF","state_relay":"ON"}
Client null received PUBLISH (d0, q0, r0, m0, 'zigbee2mqtt/Lt_Vorratskeller', ... (75 bytes))
{"brightness_relay":254,"linkquality":58,"state":"OFF","state_relay":"OFF"}
Hilft das?
Hallo,
kannst das state-Reading evtl. einfach ausfiltern, wie hier (https://www.zigbee2mqtt.io/devices/6735_6736_6737.html#relay-exposed-as-dimmable-light) beschrieben?
Gruß Thomas
Ich habe mit folgender Definition kein Problem die beiden Werte umzutauschen.
define Lt_Vorratskeller MQTT2_DEVICE
attr Lt_Vorratskeller devicetopic zigbee2mqtt/Lt_Vorratskeller
attr Lt_Vorratskeller jsonMap state:state_relay state_relay:state
attr Lt_Vorratskeller readingList $DEVICETOPIC:.* { json2nameValue(lc($EVENT),'',$JSONMAP) }
Cooler Gedanke, aber was will man mit einem Reading das sich nie ändert?
Evtl. Konfigurationsfehler (hab die Doku gerade bloss überflogen) oder es wird sicherlich (wenn wer darauf hinweist) mit einem der nächsten Updates behoben.
Man kann state auch einfach filtern:
attr Lt_Vorratskeller jsonMap state:0 state_relay:state
Ja, kam mir nach dem schreiben auch...
Das man mit 0 bei jsonMap das Reading ausknipsen kann, spukt doch nur in wenigen Köpfen rum (?) und ist nicht dokumentiert, geht mir im nachhinein auch durch den Kopf, oder irre ich mich?
Zitat von: TomLee am 06 Mai 2025, 21:19:04Das man mit 0 bei jsonMap das Reading ausknipsen kann, spukt doch nur in wenigen Köpfen rum (?) und ist nicht dokumentiert, geht mir im nachhinein auch durch den Kopf, oder irre ich mich?
Comref, bzw. Hilfe:
ZitatjsonMap oldReading1:newReading1 oldReading2:newReading2...
space or newline separated list of oldReading:newReading pairs.
Used in the automatically generated readingList json2nameValue function to map the generated reading name to a better one. E.g.
attr m2d jsonMap SENSOR_AM2301_Humidity:Humidity
attr m2d readingList tele/sonoff/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }
The special newReading value of 0 will prevent creating a reading for oldReading.
Jo, ich hab nicht bis zum Ende gelesen ¯\_(ツ)_/¯, konnts ja selbst nicht wirklich glauben.
Die Variante mit jsonMap state:0 state_relay:state funktioniert - danke!
Wäre nicht die einfachste Variante, das Attribut readingList anzupassen, wenn dort state ohnehin schon separat behandelt wird?
readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state_relay}); return $ret }
Vielleicht habe ich aber auch was falsch verstanden.
Zitat von: TomLee am 06 Mai 2025, 18:12:55Hallo,
kannst das state-Reading evtl. einfach ausfiltern, wie hier (https://www.zigbee2mqtt.io/devices/6735_6736_6737.html#relay-exposed-as-dimmable-light) beschrieben?
Gruß Thomas
Habs jetzt erst mal nachvollzogen.
Lässt sich bequem auch in den Einstellungen eines Geräts im Frontend unter
ZitatGefilterte 'publish' Attribute
Attribute mittels regulärem Ausdruck aus publiziertem Payload filtern.
einstellen/filtern. Hatte ich bisher nicht auf dem Schirm.
Das erscheint mir weiterhin die eleganteste Variante zu sein.