setreading: kein Event und Protokollierung aus einem notify heraus

[roedert]

Ich habe ein selbstdefiniertes Reading in einem FS20-Device. Wenn ich dieses aus der Befehlszeile im Webfrontend oder per telnet:7072 heraus mit "setreading...." setze ist alles ok - das reading wird geändert, protokolliert (File- und DbLog) und in einer definierten Readingshistory angezeigt.

Wenn ich jedoch aus einem notify mit perl-Code heraus das setreading ausführe wird es nicht protokolliert - weder in DB- noch in FileLog, der Rest ist aber in Ordnung, d.h. das reading wurde gesetzt und auch in der Readingshistory angezeigt.

Code Auswählen Erweitern

def xxx notify xxx:xxxx {if (xxxx) {fhem("setreading ........")}}

PS: Ich habe den Titel mal geändert ..... es hat sich herausgestellt, dass nicht der Perl-Code "schuld", sondern der Aufruf aus einem Notify heraus

[Icinger]

Hi....So sollts klappen:

Code Auswählen Erweitern

def xxx notify xxx:xxxx {if (xxxx) {ReadingSingleUpdate($hash,$reading,$value,1)}}

[roedert]

Danke, werde ich mal testen......

Aber was ist das ... ReadingSingleUpdate?
Ok, was es ist kann ich mir denken ... aber bisschen mehr Hintergrund wäre schon schön 

Dazu konnte ich nirgends was finden ... nicht in der Commandref, Forum oder Wiki?

Edit: Ausprobiert und klappt nicht 
Undefined subroutine &main::ReadingSingleUpdate called at (eval 384275) line 9.

[Icinger]

Sorry, mein Fehler: RedingsSingleUpdate

Nähere Infos findest du zB hier: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Readings

Damit triggerst du das FHEM-Interne Event-System

lg, Ici

[roedert]

Ok, bestens Dank ... durch die Suche bin ich grade auf einen Beitrag gestossen mit dem gleichen Problem.
Aus einem Notify heraus wird kein Event und somit auch kein Logeintrag ausgelöst 

http://forum.fhem.de/index.php?topic=14515.0

[justme1968]

setreading macht nichts anderes als RedingsSingleUpdate aufzurufen.

hast du dir userreadings angeschaut?

vielleicht schreibst du mal was du genau machen möchtest.

gruß
  andre

[roedert]

ok, die Erklärung ... die Überwachung der Katze 

An der Katzenklappe sind 2 Magnetkontakte angebracht ... innen und aussen, diese sind mit einem FS20-Sender FS20S4M verbunden uns senden also on/dimup oder off/dimmdown.

Allerdings pendelt die Katzenklappe, ist aber kein Problem, der zuerst ausgelöste Magnetkontakt ist der richtige - in FHEM kann ich das mit event-min-interval abbilden:

Code Auswählen Erweitern

def Katzenklappe.Sensor FS20 xxxx xx
attr Katzenklappe.Sensor event-min-interval state:4

In einem entsprechenden Notify wollte ich dann das eigene Reading "drin" setzen ... was ja auch soweit alles klappt.

Code Auswählen Erweitern

def Katzenklappe.Sensor_nfy Katzenklappe.Sensor:(on|off|dimup|dimdown) {fhem("setreading $NAME drin " . ($EVENT eq "on" || $EVENT eq "dimup") ? 1 : 0) }

Problem ist nun, dass dieses setreading im notify eben kein event und kein Logging auslöst wie es ja in dem genannten Forumsbeitrag auch bestätigt wird.

Vorher hatte ich statt dem zusätzlichen Reading von Katzenklappe.Sensor einen DUMMY genutzt - da hat auch das Logging funktioniert.
Aber ein eigenes Reading wäre die übersichtlichere Lösung gewesen.

[justme1968]

aber genau dafür ist doch userReadings da.

was du auch probieren kannst ist zusätzlich zum setreading ein trigger... aufruf machen. dann sollte es auch gehen.

gruss
  andre

[roedert]

hast du dir userreadings angeschaut?

Ja ... hilft aber in meinem Fall nicht, da die userreadings immer 1:1 gesetzt werden und sich nicht von dem event-min-intervall beeinflussen lassen.

[rudolfkoenig]

Wenn man ein Reading R fuer Geraet G aus einem Notify fuer dieses Geraet G setzt, dann wird fuer R kein Event generiert.
Gilt fuer Events generell, ist nicht notify-spezifisch.

[justme1968]

es sollte auch in deinem fall helfen wenn du die zeit selber mit berücksichtigst. du hast den readingsTimestamp des letzen update und die aktuelle zeit.

gruss
  andre

[justme1968]

man könnte den trigger mit einem at verzögern. dann wird das event generiert. das sollte auch bei setreading gehen fällt mir gerade auf.

@rudi: gibt es ausser einem eventuellen rekursions problem noch einen anderen grund die events explizit nicht zu generieren? das ist glaube ich schon öfter als problem aufgefallen.

[roedert]

Code Auswählen Erweitern

def Katzenklappe.Sensor_nfy notify Katzenklappe.Sensor:(on|off|dimup|dimdown) {fhem("define kk_tmp at +00:00:01 setreading $NAME drin ".(($EVENT eq "on" || $EVENT eq "dimup")?1:0))}

funktioniert 

Aber ist eigentlich nur ein unschöner Workaround mit dem zusätzlichen at.
Ist die Frage ob die Einschränkung dass aus einem notify heraus nicht noch einmal ein Event generiert werden kann, wirklich einen tieferen Sinn/Grund hat.
Außer natürlich der eventuellen Rekursion wenn man da "Mist" baut.

[rudolfkoenig]

@andre: ja:
- Aktuelle Implementierung: Events werden an $hash->CHANGED drangehaengt, und zum Schluss alle NotifyFns aufgerufen. Wenn ein notify hier was  dranhaengt, dann bekommen die bereits aufgerufenen NotifyFns diesen Wert nicht. Bestimmte Module (average, dewpoint) setzen die Notify-Prioritaet und bearbeiten CHANGED direkt, aber der generischen reading*Update ist das untersagt.
- Alternativ koennte man waehrend der NotifyFn Schleife neue Events in $hash->CHANGED2 sammeln, und man wiederholt die Schleife zum Schluss nochmal, falls hier was drin ist. Was alles fuer diese Aenderung angefasst werden muesste, weiss ich nicht.
- der Code in fhem.pl (bzw. in den diversen Modulen, die Dispatch/DoTrigger/etc aufrufen) ist so verworren bezueglich Reihenfolge/Verschachtelung, dass ich mich nicht traue es anzufassen. Oder anders: die mehrere Tage Zeit zum reparieren sind es mir nicht Wert.

[justme1968]

@roedert: das ganze sollte noch einfacher werden wenn man statt dem at ein fhem sleep verwendet. also etwa so:

Code Auswählen Erweitern

{my $state = (($EVENT eq "on" || $EVENT eq "dimup")?1:0); fhem("sleep1;; setreading $NAME $state")}

@rudi: wie wäre es in der doku zu setreading zu erwähnen das es nicht innerhalb eines notify funktioniert und auf den workaround mit fhem sleep hinweisen? oder gleich in setreading ein temporäres at/sleep zu verwenden wenn es innerhalb eines notify aufgerufen wird.

das würde die von dir befürchteten nebenwirkungen einer 'richtigen' lösung umgehen und sollte von aufwand überschaubar sein.