MQTT: Retained state nicht korrekt

[tplus]

Hallo,

dieses Dummy ist immer auf "on" gesetzt:

Code Auswählen Erweitern

[code]define rasenalarm dummy
attr rasenalarm mqttDefaults retain=1
attr rasenalarm mqttPublish state:topic={"$base/$device/$name"} *:qos=1 *:retain=1
attr rasenalarm mqttSubscribe state:stopic={"$base/$device/$name"}
attr rasenalarm room rasen
attr rasenalarm setList on off
#   FUUID      63c679fa-f33f-a505-4b48-xxx
#   LASTInputDev home_broker
#   MSGCNT     19
#   NAME       rasenalarm
#   NR         120
#   STATE      on
#   TYPE       dummy
#   eventCount 27
#   home_broker_CONN home_broker_192.168.10.31_41508
#   home_broker_MSGCNT 19
#   home_broker_TIME 2023-01-21 19:02:26
#   READINGS:
#     2023-01-21 21:16:20   state           on
#
setstate rasenalarm on
setstate rasenalarm 2023-01-21 21:16:20 state on

[/code]

Der aktuelle Wert "state" der zur Zeit retained ist, ist aber "off", geprüft mit MQTT Explorer. Meist wechselt der Wert über Nacht, ohne irgendwelchen Eingriff. Broker ist FHEM intern, Raspi  auf 192.168.10.28.

Besten Dank für Tipps...

[betateilchen]

In der aktuellen Version von FHEM wird retain per default nicht mehr gespeichert.
Sollte das aus irgendwelchen Gründen tatsächlich gebraucht werden, muss es per Attribut explizit eingeschaltet werden.

Siehe auch die Ankündigung zu diesem Feature: https://forum.fhem.de/index.php/topic,131618.msg1257838.html#msg1257838

[tplus]

Besten Dank, attr ist gesetzt, probiere ich aus.

Könnte man das Dummy so einstellen, dass periodisch der State gepublished wird?

Ich brauche den aktuellen state da dieser auf einem Android Tablet im MQTT Dash angezeigt wird.

[betateilchen]

Könnte man das Dummy so einstellen, dass periodisch der State gepublished wird?

https://commandref.fhem.de/#at

[tplus]

Danke, at ist mir bekannt. Aber gibt es denn einen "publish"-Befehl?

[betateilchen]

Aber gibt es denn einen "publish"-Befehl?

Natürlich. Entweder direkt im FHEM-eigenen MQTT Server, falls verwendet, oder Du schreibst einfach per at den aktuellen Status erneut in den dummy. Dort hast Du doch das mqttPublish schon konfiguriert.

[tplus]

Könnte man statt regelmässigem Statusupdate auch per notify nur bei Änderung den dann aktuellen state publishen? Wie?

[betateilchen]

Könnte man. Wäre aber komplett sinnfrei. Wenn sich der Wert ändert, wird er doch über mqttPublish automatisch versendet.

[tplus]

Leider existiert das Problem immer noch: Trotz respectRetain=1 war der state heute morgen nicht korrekt. Warum?

[Beta-User]

WIE schaltest du denn?

Falls von extern: Wird dort auch mit retain gesendet?

($base ist in sub und pub unterschiedlich gesetzt?)
Ansonsten: mqttForward?

[tplus]

Meist schalte ich direkt in FHEM. Ich habe mich auch schon gefragt ob beim aufwecken des Tablets ein publish gesendet wird (was falsch sein kann). "Retain ist dort aber nicht gesetzt.

Ich kann in MQTTdash auswählen ob die Anzeige sofort wechseln oder ob erst auf Rückmeldung gewartet werden soll. Rückmeldung kommt aber nie obwohl die Schaltung in FHEM korrekt erfolgt. Vermutlich wegen der unterschiedlichen Topics:

Im Tablet, subscribe:
homebroker/rasenalarm/state (jetzt: on)

publish:
homebroker/set/rasenalarm/state (jetzt: off)

Aktuell ist "off", geschaltet durch das Tablet. Danach wurde homebroker/rasenalarm/state anscheinend nicht neu gepublished.

[Beta-User]

qed:

mqttForward

OT: dass hier mit dummy gearbeitet wird, sieht mir nicht optimal aus. Da hängt vermutlich irgendein eventhandler dran...

[tplus]

mqttforward ist nicht gesetzt.

Der Dummy wird nur von Hand geschaltet. Er wird als Bedingung in einem DOIF verwendet (wenn Bewegungsmelder = motion und dummy = on dann...). So schalte ich die Bewegungsmelderreaktion scharf/unscharf.

Ich hätte auf dem Tablet halt gerne den aktuellen Status und die Möglichkeit der Schaltung. Muss eben synchron sein. 

[Beta-User]

mqttforward ist nicht gesetzt.

...das war aus dem list zu entnehmen...

Hast du denn die commandref dazu gelesen?

[tplus]

Habe ich. Irritiert hatte mich:

If this attribute is missing, the default setting for all device types except 'dummy' is 'all' (so that actuators can receive commands and send their changes in the same time) and for dummies 'none' is used. This was chosen because dummies are often used as a kind of GUI switch element. In this case, 'all' might cause an endless loop of messages.

Das Dummy wird ja hier tatsächlich wie ein GUI Schalter genutzt.

Funktioniert aber jetzt, danke.