AnalyzeCommandChain Aufruf stoppt readingsBulkUpdate Verarbeitung

Begonnen von CoolTux, 31 Juli 2017, 07:59:10

Vorheriges Thema - Nächstes Thema

CoolTux

Guten Morgen,

Ich wurde heute Morgen von einem meiner "Schützlinge" auf ein interessantes Phänomen aufmerksam gemacht.

Zitat
Beschreibung der Situation:
Nachdem AnalyzeCommandChain ausgeführt worden ist werden READINGS mittels readingsBulkUpdate von FHEM nicht mehr übernommen/erstellt/aktualisiert - sie werden schlichtweg ignoriert! 

Zur Kontrolle habe ich die zu schreibenden Änderungen - die eigentlich in die READINGS sollen - in das LOG schreiben lassen und dies funktioniert tadellos.

Alle ReadingsBulkUpdate die vor der Ausführung von AnalyzeCommandChain gesetzt/aktualisiert werden, werden von FHEM übernommen.

Und seltsam ist dann:
Wenn AnalyzeCommandChain entfernt worden ist - so das AnalyzeCommandChain nicht ausgeführt wird - dann funktionieren alle ReadingsBulkUpdate  wie erwartet.
Zitat
Wird mit AnalyzeCommandChain ein FHEM Kommando ausgeführt, dass sich selbst auf die aufrufende eigene Geräteinstanz bezieht - in dem Fall das verändern eines eigenen Attributs - dann ist dieses Verhalten reproduzierbar. Da alle weiteren Funktionen in der Reihenfolge beanstandungslos ausgeführt werden scheinen nur die nachfolgenden readingsBulkUpdate-Funktionen davon betroffen zu sein.

Ich versuche das ganze in meiner Testumgebung mal nach zu stellen.
Wollte das ganze aber hier einfach mal zur Diskussion stellen.



Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

Die Beschreibung ist leider etwas nebuloes, aber ich kann mir durchaus vorstellen, dass man z.Bsp. in userReadings nicht problemlos FHEM-Befehle aufrufen kann. Und bevor ich daran was drehe, muesste noch wissen, wozu das noetig sein soll. Eine andere Einschraenkung ist mit Absicht eingebaut: falls ein Geraet ein Event generiert, dann kann das gleiche Geraet, ausgeloest durch dieses Event, keine weiteren generieren. Damit wird eine Endlosschleife beim "define n notify n trigger n" vermieden.

CoolTux

Guten Morgen Rudi,

Dran drehen sollst Du ja nichts, zu mindest nicht wenn es sich nicht um einen eindeutigen, im Sinne von sofort erklärbaren, Bug handelt.

Im Grunde genommen geht es unter anderem auch darum aus einem eigenen Modul heraus eine 99_myUtils Sub auf zu rufen. Der Michael hat es versucht über die AnalyzeCommandChain Routine zu machen.
Es sollen quasi FHEM Kommandos welche als Daten im Modul ankommen ausgeführt werden.

Ich schaue es mir noch genauer an. Sollte ich noch was finden melde ich mich, wenn nicht ist es nicht weiter von Interesse.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net