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:
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
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).
Zitat von: Beta-User am 23 Mai 2019, 11:00:56
gibt es Einträge im Log (beim FHEM-Start), die dazu irgendeine Aussage enthalten?
Hab natürlich geschaut .. leider nichts ...
Zitat von: Beta-User am 23 Mai 2019, 11:00:56
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.
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
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 :o
entweder passt da noch was nicht, dann müsste rudi mal gucken, oder du hast keine aktuelle version ;)
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
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?)
Zitat von: tomleitner am 23 Mai 2019, 11:22:04
Ich habe aber schon die aktuelle Version -- also ein update mache ich regelmäßig ...
das hatte ich befürchtet ;)
was auf jeden Fall noch weiterhilft:
ein list der betroffenen devices, keine screenshots (und das bitte in code-tags. das # über den smileys!)
Danke ... nun funktioniert es ja.
Das mit dem Code-Tag kenn ich ...
Danke Dir.
Hier noch ein List des Devices:
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
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.
Zitat von: rudolfkoenig am 24 Mai 2019, 09:39:26
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 ;D .