state Reading via MQTT unterdrücken und selbst generieren?

[Motivierte linke Hände]

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:

Code Auswählen Erweitern

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.

[DeeSPe]

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

[Motivierte linke Hände]

Danke, Dan. Wenn ich Dich richtig verstanden habe, meintest Du sowas:

Code Auswählen Erweitern

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

[rudolfkoenig]

Kannst Du uns bitt die Eingangsdaten (JSON) zeigen?

[Motivierte linke Hände]

Ich habe hier mal die MQTT Messages für ein Ein- und wieder Ausschalten des Schalters mitgeschnitten:

Code Auswählen Erweitern

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?

[TomLee]

Hallo,

kannst das state-Reading evtl. einfach ausfiltern, wie hier beschrieben?

Gruß Thomas

[rudolfkoenig]

Ich habe mit folgender Definition kein Problem die beiden Werte umzutauschen.

Code Auswählen Erweitern

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


[TomLee]

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.

[rudolfkoenig]

Man kann state auch einfach filtern:

Code Auswählen Erweitern

attr Lt_Vorratskeller jsonMap state:0 state_relay:state


[TomLee]

Ja, kam mir nach dem schreiben auch...

[TomLee]

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?

[frober]

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?

Comref, bzw. Hilfe:

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

[TomLee]

Jo, ich hab nicht bis zum Ende gelesen ¯\_(ツ)_/¯, konnts ja selbst nicht wirklich glauben.

[Motivierte linke Hände]

Die Variante mit jsonMap state:0 state_relay:state funktioniert - danke!

[betateilchen]

Wäre nicht die einfachste Variante, das Attribut readingList anzupassen, wenn dort state ohnehin schon separat behandelt wird?

Code Auswählen Erweitern

readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state_relay}); return $ret }
Vielleicht habe ich aber auch was falsch verstanden.