Bitte um Hilfe bei Fehlersuche

[Nielsiwilsi]

Hallo Leute,

ich habe folgendes Shelly1 per MQTT angebunden. Funktioniert auch soweit, nur die Anzeige wenn man am Lichtschalter schaltet wird nicht auf das state übertragen. Es relay0 zeigt es aber an. Da auf dem reading relay0 ein on ankommt muss ja das Topic funktionieren.

Code Auswählen Erweitern

defmod EG_Ankleide_Licht MQTT2_DEVICE mqtt2client
attr EG_Ankleide_Licht IODev mqtt2_client
attr EG_Ankleide_Licht autocreate 0
attr EG_Ankleide_Licht model A_10_shelly1
attr EG_Ankleide_Licht readingList shellies/shelly1-123abc/relay/0:.* state\
  shellies/shelly1-123abc/relay/0:.* relay0\
  shellies/shelly1-123abc/input/0:.* input0\
  shellies/shelly1-123abc/online:.* online\
  shellies/shelly1-123abc/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr EG_Ankleide_Licht room EG_Ankleide
attr EG_Ankleide_Licht setList off:noArg shellies/shelly1-123abc/relay/0/command off\
  on:noArg shellies/shelly1-123abc/relay/0/command on

setstate EG_Ankleide_Licht off
setstate EG_Ankleide_Licht 2019-02-14 08:30:21 input0 0
setstate EG_Ankleide_Licht 2019-02-14 08:30:21 relay0 on
setstate EG_Ankleide_Licht 2019-02-14 08:20:59 state off


hat jemand eine Idee?

VG
Niesl

[rudolfkoenig]

Ich empfehle in solchen Faellen

Code Auswählen Erweitern

attr EG_Ankleide_Licht stateFormat relay0

[Beta-User]

@Rudi:
Gestern hatte schon jemand berichtet, dass nur eines von zwei Readings aktualisiert wird, obwohl die readingList einen "doppelten" Eintrag enthält. Verwirrenderweise funktioniert es wohl, wenn man einen der Einträge mit der passenden CID versieht...!?!

Ich bin bisher davon ausgegangen, dass das früher funktioniert hat. War das schon immer so?
Wenn das Verhalten jetzt dauerhaft so ist, müßte ich die templates entsprechend ergänzen, oder? (dann kann aber state auch raus, das bringt dann nichts).

[rudolfkoenig]

Gestern hatte schon jemand berichtet, dass nur eines von zwei Readings aktualisiert wird, obwohl die readingList einen "doppelten" Eintrag enthält.

Sorry, ich brauche das genauer fuer eine qualifizierte Antwort.

[Nielsiwilsi]

Das Verhalten ist beim Shelly2 genau das gleiche. Der Workarround greift auch hier. Danke.

Wann sich dies Verhalten geändert hat, kann ich nicht sagen. Müsste aber schon funktioniert haben.
Hab am 1.2. und 11.2. ein Update gemacht. Also irgendwann dazwischen.

Code Auswählen Erweitern

2019.02.01 00:07:38.826 1: UPD FHEM/00_MQTT2_CLIENT.pm
2019.02.01 00:07:38.853 1: UPD FHEM/00_MQTT2_SERVER.pm
2019.02.01 00:07:38.877 1: UPD FHEM/10_MQTT2_DEVICE.pm
...
2019.02.11 13:37:30.539 1: UPD FHEM/00_MQTT2_SERVER.pm
2019.02.11 13:37:30.753 1: UPD FHEM/10_MQTT2_DEVICE.pm
2019.02.11 13:37:30.779 1: UPD FHEM/10_MQTT_GENERIC_BRIDGE.pm

[rudolfkoenig]

Die Aenderung (sofern eins gab) war sicher nicht in den Perl Modulen: MQTT2_DEVICE kennt nur beim Setzen state, aber nicht beim Interpretieren der Eingangsdaten. Das Modul ist generisch, und weiss ohne externe Hilfe nicht, welcher der Readings als state zu setzen ist. Das kann man mit userReading machen, oder mit stateFormat state ueberspringen, und gleich STATE setzen. Evtl. wurde einer diesen Methoden in einem frueheren attrTemplate gesetzt, und spaeter entfernt. Das ist aber pure Spekulation.

[Beta-User]

Sorry, ich brauche das genauer fuer eine qualifizierte Antwort.

War schon vorgestern: https://forum.fhem.de/index.php/topic,97218.msg905075.html#msg905075

Evtl. wurde einer diesen Methoden in einem frueheren attrTemplate gesetzt, und spaeter entfernt. Das ist aber pure Spekulation.

Das mit userreading usw. war mal ein Thema bei den Tasmota-Templates. Bei den Shellys gibt es "nur" eine erweiterte readingList seit etwas mehr als einem Monat (rev=18220). Da ich diese Art Hardware aber (auch) nicht habe, konnte ich das nie testen. Seltsam ist halt, dass sich erst jetzt Leute melden, bei denen das scheinbar nicht (mehr) funktioniert...

[rudolfkoenig]

War schon vorgestern: https://forum.fhem.de/index.php/topic,97218.msg905075.html#msg905075

Die regexp/device Kombination war bisher einmalig, die letzte Zeile aus readingList gewinnt.

D.h. man konnte beim Empfang einer Nachricht mit einem bestimmten Regexp in einem FHEM-Geraet "nur" ein Reading setzen, mit unterschiedlichen Regexps konnte man das "Problem" aber umgehen.
Ich frage mich, wieso man einen Eingangswert unbedingt unter mehreren Readings in einem FHEM-Geraet abspeichern will.

Um komische Diskussionen zu vermeiden habe ich das jetzt geaendert: man kann ab sofort (update morgen ab acht) in MQTT2_DEVICE ueber das readingList mit einem topic mehr als ein Reading setzen. Damit Doppelspeicherer eine Alternative zu userReading haben.

Man könnte noch mit userreadings rumexperimentieren [...] (wird ständig getriggert und man kann den eigentlichen Zeitstempel nicht mehr erkennen...).

Wenn man die userReadings mit dem richtigen "trigger" versieht (siehe Doku), dann stimmt diese Aussage nicht.

[Beta-User]

Danke für die Rückmeldung.
Das mit der doppelten Datenhaltung ist ein an sich berechtigter Einwand, ich habe leider auch nicht mehr parat, warum das Sinn macht (tauchte nach meiner Erinnerung) als erstes in den tasmotas auf.

Ansonsten ist immer wieder überraschend, was so alles in der commandref steht . Das mit userreadings war mir bisher nicht so bewußt, löst aber uU. das Problem mit diesen dusseligen color-JSON-Blobs (=>RGB-Wert) ohne externes notify .