Einige MQTT2 devices nehmen IODev nicht an -- IODevMissing = 1

[tomleitner]

Hallo,

Habe mit zwei meiner MQTT2 Devices ein komisches Problem nach meinem Update gestern und dem Löschen von fhem.save:
das IODev das im Attr gesetzt wird, wird nach einem fhem restart NICHT angenommen. Ich muss in der WEBUI manuell noch einmal "attr IODev MQTT_Client" eingeben damit es geht. 

Im Zustand indem das IODev nicht genommen wird, werden zwar MQTT Messages verarbeitet und tauchen in den readings auf -- die Befehle die in der setList definiert sind landen jedoch NICHT im Mosquitto.

Das Problem habe ich nur mit zwei meiner MQTT2 devices. Alle anderen ca. 15 devices gehen problemlos.

Screenshot1 zeigt die Situation nach einem fhem restart -- das IODev fehlt in den Internals.
Screenshot2 zeigt die Situation nachdem ich während der fhem Laufzeit ein "attr IODev MQTT_Client" eingegeben habe.

Nach manueller Eingabe von "attr IODev MQTT_Client" gehen auch die Set Befehle wieder ...

Hier noch die Definition des Devices:

Code Auswählen Erweitern

defmod Entfeuchter_Saunaraum MQTT2_DEVICE shellies/shellyplug-s-376D2D
attr Entfeuchter_Saunaraum IODev MQTT_Client
attr Entfeuchter_Saunaraum devStateIcon on:ios-on-green off:ios-off
attr Entfeuchter_Saunaraum group Schalter
attr Entfeuchter_Saunaraum icon humidity
attr Entfeuchter_Saunaraum model A_10_shelly1
attr Entfeuchter_Saunaraum readingList shellies/shellyplug-s-376D2D/relay/0:.* state\
  shellies/shellyplug-s-376D2D/relay/0:.* relay0\
  shellies/shellyplug-s-376D2D/relay/0/power:.* power\
  shellies/shellyplug-s-376D2D/relay/0/energy:.* energy\
  shellies/shellyplug-s-376D2D/temperature:.* temperature\
  shellies/shellyplug-s-376D2D/overtemperature:.* overtemperature\
  shellies/shellyplug-s-376D2D/online:.* online
attr Entfeuchter_Saunaraum room Device Status,Keller,MQTT
attr Entfeuchter_Saunaraum setList off:noArg shellies/shellyplug-s-376D2D/relay/0/command off\
  on:noArg shellies/shellyplug-s-376D2D/relay/0/command on
attr Entfeuchter_Saunaraum stateFormat State: state, Power: power

Irgendwelche Ideen jemand?

Danke // Tom

[Beta-User]

Hmmm,

gibt es Einträge im Log (beim FHEM-Start), die dazu irgendeine Aussage enthalten?

Wie ist die Reihenfolge der Devices in der cfg? (interessieren würden mich die beiden nicht funktionierenden, das IO (MQTT2_CLIENT) und ein funktionierendes).

[tomleitner]

gibt es Einträge im Log (beim FHEM-Start), die dazu irgendeine Aussage enthalten?

Hab natürlich geschaut .. leider nichts ...

Wie ist die Reihenfolge der Devices in der cfg? (interessieren würden mich die beiden nicht funktionierenden, das IO (MQTT2_CLIENT) und ein funktionierendes).

Das ist natürlich ein guter Punkt an den ich nicht gedacht habe. 

Code Auswählen Erweitern

pi@fhem /opt/fhem $ egrep 'MQTT_Client|MQTT2_DEVICE' fhem.cfg
define Entfeuchter_Saunaraum MQTT2_DEVICE shellies/shellyplug-s-376D2D
attr Entfeuchter_Saunaraum IODev MQTT_Client
define Entfeuchter_Waschkueche MQTT2_DEVICE shellies/shellyplug-s-376C9A
attr Entfeuchter_Waschkueche IODev MQTT_Client
define MQTT_Client MQTT2_CLIENT localhost:1883
setuuid MQTT_Client 5ce567ee-f33f-44cf-2421-d7f3a80d0c990851
attr MQTT_Client autocreate no
attr MQTT_Client disable 0
attr MQTT_Client room MQTT
define MQTT2_iobroker MQTT2_DEVICE iobroker
attr MQTT2_iobroker IODev MQTT_Client
#attr MQTT_BRIDGE IODev MQTT_Client
define TPSW4 MQTT2_DEVICE DVES_677061
attr TPSW4 IODev MQTT_Client
define TPSW5 MQTT2_DEVICE DVES_677004
attr TPSW5 IODev MQTT_Client


Es sieht tatsächlich so aus als ob die beiden problematischen Devices VOR dem IODev erzeugt werden ... das dürfte der Grund sein ...

Vielen Dank.
Tom

[nils_]

eigentlich wird das IODevMissing und IODevName doch im "Nachgang" nochmal bearbeitet und dann entsprechend das IODev gesetzt. konkret: https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L626
und dort eigentlich auch entfernt werden....

der teil ist aber - wenn ich es richtig gefunden habe -  seit 2017 vorhanden 

entweder passt da noch was nicht, dann müsste rudi mal gucken, oder du hast keine aktuelle version

[tomleitner]

Habe nun die Reihenfolge geändert und das MQTT2 IO Device VOR den anderen anglegt ... und nun paßt es.

Ich habe aber schon die aktuelle Version -- also ein update mache ich regelmäßig ...

Da paßt vermutlich was nicht ...

Danke für die Hilfe ...

Tom

[Beta-User]

Danke für's Nachsehen.

Ich kann leider nicht sagen, ob das mit der zusätzlichen Implikation zu tun hat, dass die statefile weg war, vermute aber eher nicht.

Mal schauen, ob Rudi hier mitliest und ggf. noch was in MQTT2_DEVICE (?) anpaßt, damit sowas abgefangen wird.

(Wie kam das eigentlich zustande? Hast du erst MQTT2_SERVER genutzt und bist dann umgestiegen oder hast zwischendurch mal das MQTT2_CLIENT-Gerät gelöscht?)

[nils_]

Ich habe aber schon die aktuelle Version -- also ein update mache ich regelmäßig ...

das hatte ich befürchtet

[nils_]

was auf jeden Fall noch weiterhilft:
ein list der betroffenen devices, keine screenshots (und das bitte in code-tags. das # über den smileys!)

[tomleitner]

Danke ... nun funktioniert es ja.

Das mit dem Code-Tag kenn ich ...

Danke Dir.

[tomleitner]

Hier noch ein List des Devices:

Code Auswählen Erweitern

Internals:
   CID        shellies/shellyplug-s-376C9A
   DEF        shellies/shellyplug-s-376C9A
   DEVICETOPIC Entfeuchter_Waschkueche
   FUUID      5ce653e2-f33f-44cf-65c5-ad4aea72561fbc93
   IODev      MQTT_Client
   LASTInputDev MQTT_Client
   MQTT_Client_MSGCNT 259
   MQTT_Client_TIME 2019-05-23 11:35:29
   MSGCNT     259
   NAME       Entfeuchter_Waschkueche
   NR         103
   STATE      State: on, Power: 0.00
   TYPE       MQTT2_DEVICE
   Helper:
     DBLOG:
       energy:
         logDb:
           TIME       1558604129.39181
           VALUE      0
       overtemperature:
         logDb:
           TIME       1558604129.56266
           VALUE      0
       power:
         logDb:
           TIME       1558604129.3178
           VALUE      0.00
       relay0:
         logDb:
           TIME       1558604129.44965
           VALUE      on
       state:
         logDb:
           TIME       1558604129.44965
           VALUE      on
       temperature:
         logDb:
           TIME       1558604129.50628
           VALUE      32.26
   READINGS:
     2019-05-23 11:35:29   energy          0
     2019-05-23 11:35:29   overtemperature 0
     2019-05-23 11:35:29   power           0.00
     2019-05-23 11:35:29   relay0          on
     2019-05-23 11:35:29   state           on
     2019-05-23 11:35:29   temperature     32.26
Attributes:
   IODev      MQTT_Client
   devStateIcon on:ios-on-green off:ios-off
   group      Schalter
   icon       humidity
   model      A_10_shelly1
   readingList shellies/shellyplug-s-376C9A/relay/0:.* state
  shellies/shellyplug-s-376C9A/relay/0:.* relay0
  shellies/shellyplug-s-376C9A/relay/0/power:.* power
  shellies/shellyplug-s-376C9A/relay/0/energy:.* energy
  shellies/shellyplug-s-376C9A/temperature:.* temperature
  shellies/shellyplug-s-376C9A/overtemperature:.* overtemperature
  shellies/shellyplug-s-376C9A/online:.* online
   room       Device Status,Keller,Waschkueche,MQTT
   setList    off:noArg shellies/shellyplug-s-376C9A/relay/0/command off
  on:noArg shellies/shellyplug-s-376C9A/relay/0/command on
   stateFormat State: relay0, Power: power

[rudolfkoenig]

Ich war auch der Meinung, dass solche Probleme automatisch abgefangen werden, es wird aber nur ein explizit gesetztes IODev Attribut nach init_done angewendet, falls die Reihenfolge vertauscht wurde. Ich habe jetzt die Fehlermeldung durch AssignIoPort() ausgetauscht, damit sollte das Problem auch ohne Attribut behoben sein. Nebeneffekt: bei mehreren moeglichen IODevs wird nach Editieren der fhem.cfg statt Fehlermeldung moeglicherweise das falsche IODev zugewiesen.

[Beta-User]

Nebeneffekt: bei mehreren moeglichen IODevs wird nach Editieren der fhem.cfg statt Fehlermeldung moeglicherweise das falsche IODev zugewiesen.

Thx; mal schauen, ob und ggf. wann und wie uns das auf die Füße fällt .