FHEM Forum

Moin,

ich steh auf dem Schlauch, vielleicht kann jemand helfen. Ich bastel mir mit dem ESP8266_12F ein Device, dass via MQTT mit dem MQTT2_Server kommuniziert. Im fhem habe ich dann noch ein MQTT2_DEVICE zur Steuerung und Anzeige angelegt. Zur Steuerung will ich den ESP auch individuell deaktivieren und aktieren konnen. Ging bis vor einigen Tagen alles sehr gut. Heute habe ich dann mit dem Befehl inactive zum ESP sowohl den ESP wunschgemäss schlafen gelegt - aber auch das MQTT2_DEVICE im fhem für immer ausgeschaltet.
Hier das List vom MQTT2_DEVICE
Internals:
   CFGFN     
   DEVICETOPIC bmw248716_2
   FUUID      5da651ed-f33f-5817-dd39-727d834fcb857383
   IODev      MQTT2_Broker
   LASTInputDev MQTT2_Broker
   MQTT2_Broker_MSGCNT 22
   MQTT2_Broker_TIME 2019-10-16 01:12:42
   MSGCNT     22
   NAME       bmw248716_2
   NR         487
   STATE      inactive
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
   READINGS:
     2019-10-16 01:12:42   AP              Fritz_xxx
     2019-10-16 01:12:42   D-serialNr      bmw248716
     2019-10-16 01:12:42   MAC             38:2B:78:03:CB:8C
     2019-10-16 01:12:42   SSID            Nord-IoT
     2019-10-16 01:12:42   battery         ok
     2019-10-16 01:12:42   interval            60
     2019-10-16 01:12:42   mqttDiscon      22
     2019-10-16 01:12:42   rssi            -64.0
     2019-10-16 01:12:53   state           inactive
     2019-10-16 01:12:41   watchdog        alive
Attributes:
   IODev      MQTT2_Broker
   autocreate 0
   group      Series_2
   readingList fhem/2CC82F/bmw_mqtt_0003/watchdog/set:.* watchdog
fhem/2CC82F/bmw_mqtt_0003/AP/set:.* AP
fhem/2CC82F/bmw_mqtt_0003/D-serialNr/set:.* D-serialNr
fhem/2CC82F/bmw_mqtt_0003/MAC/set:.* MAC
fhem/2CC82F/bmw_mqtt_0003/SSID/set:.* SSID
fhem/2CC82F/bmw_mqtt_0003/battery/set:.* battery
fhem/2CC82F/bmw_mqtt_0003/mqttDiscon/set:.* mqttDiscon
fhem/2CC82F/bmw_mqtt_0003/rssi/set:.* rssi
fhem/2CC82F/bmw_mqtt_0003/interval/set:.* interval
fhem/2CC82F/bmw_mqtt_0003/state/set:.* state
   room       Arduino
   setList    deviceRequest:noArg fhem/bmw_mqtt_0003/2CC82F/request deviceRequest
active:noArg fhem/bmw_mqtt_0003/2CC82F/request active
inactive:noArg fhem/bmw_mqtt_0003/2CC82F/request inactive
wifi_scan:noArg fhem/bmw_mqtt_0003/2CC82F/request wifi_scan
set_interval fhem/bmw_mqtt_0003/2CC82F/request set_interval

Der Befehl
inactive:noArg fhem/bmw_mqtt_0003/2CC82F/request inactive
wird mit dem richtigen Topic an den ESP geschickt aber leider wird offensichtlich auch dieses MQTT2_DEVICE deaktiviert.

Mit
active:noArg fhem/bmw_mqtt_0003/2CC82F/request active
wird leider das MQTT2_DEVICE nicht wieder aktiviert. Ich habe dann noch ein neues Device angelegt - das sofort funktioiert. Aber das konnte ich auch gleich wieder mit dem Befehl ausknipsen...

In der Doku habe ich nichts gefunden, was auf diese Steuerung hindeuted.

BUG, Geheimbefehl oder ein Dokuproblem ?

Moin und schon mal Danke für Eure Hilfe !
Bernd

Ohne das näher im Code gesucht zu haben: "inactive" ist (im STATE oder state?) tendenziell bei vielen Device-Typen das Signal, nichts mehr zu tun...
Ist an sich kein Geheimwissen, aber in der Regel ist ein Modul nicht so offen gestaltet wie MQTT2_DEVICE, als dass man da "einfach so" drüberstolpern könnte ;D .

Würde vorschlagen, das etwas anders zu gestalten und z.B. zum einen ein Reading "activation" mit den Optionen "activation:active,inactive" zu verwenden (und $EVTPART1 als Payload zu definieren), und zum anderen ggf. die setStateList irgendwie zu füllen (NICHT mit activation...).

danke für die Infos !
Scheint wirklich so zu sein, dass das Device "von sich aus" auch auf inactive geht. Das muss aber durch eine Änderung in der letzten Zeit passiert sein, weil meine Abläufe vor kurzer Zeit noch funktioniert haben.

Wäre aber interessant zu wissen, wie man so ein MQTT2_DEVICE wieder aktivieren kann. Löschen und neu anlegen ist ja nun nicht besonders professionell.

Wie auch immer, ich habe wie folgt meine Befehle an den ESP geändert:
set_active:noArg fhem/bmw_mqtt_0003/2CC82F/request set_active
set_sleeping:noArg fhem/bmw_mqtt_0003/2CC82F/request set_sleeping

Nach Ausführung des Befehls quittiert mein ESP dann mit "CMDs done" bzw. einer anderen Statusmeldung/Fehlermeldung auf das Reading state.

ZitatWürde vorschlagen, das etwas anders zu gestalten und z.B. zum einen ein Reading "activation" mit den Optionen "activation:active,inactive" zu verwenden (und $EVTPART1 als Payload zu definieren), und zum anderen ggf. die setStateList irgendwie zu füllen (NICHT mit activation...).

Geh leider nicht, weil ich strukturell die Topics für Befehle und Readings getrennt habe, um ein möglichst kompatibles Bild zum Beispiel zu meinen HM-Devices zu bekommen und um auch in den Readings wirklich nur die Infos vom ESP zu sehen.

Nur mit
<ommand>:<noArg|arguments> fhem/bmw_mqtt_0003/2CC82F/request <command>
wird der Command-Interpreter im ESP angesteuert. Als Antwort wird dann state gesendet.
readingList fhem/2CC82F/bmw_mqtt_0003/state/set:.* state\ ...usw

ok, das ist meine individuelle Programmierung des ESP, hat nix mit dem MQTT2_DEVICE zu tun und das kann niemand wissen.

Danke für Deine Hilfe !!!!
Bernd

Vermutlich reicht es, das Reading zu ändern (setreading oder deletereading).

Was den Rest angeht, kann ich das mit "kompatiblem Bild" nicht richtig nachvollziehen. Es ist klar, dass die zurückgelieferte Info und der Befehl irgendwie einen geschlossenen Kreis bilden sollten, aber das kann man auf mehrere Arten erreichen. Gerade "state" zu nutzen finde ich persönlich immer etwas kritisch, weil sich das auf essentielle Funktionen beschränken sollte (das scheint hier aber zu passen). mit "activation" hätte man z.B. auch das Reading in der Rücklieferung so benennen können und dann das Reading via stateFormat in STATE schreiben...
Da man eine Perl-Funktion für die Auswertung nutzen kann, ist prinzipiell "alles möglich" ;) . (Nur eben nicht "inactive" und evtl. noch ein oder zwei andere Schlüsselwörter in state).