notify auf Dummy-Device bei Schaltung über HM-Fernbedienungen

[martinp876]

Hallo Andre,

sehr seltsam. Ich nehme an, dass du das aktuelle fhem.pl hast und keine sonstigen "addons"?
Im Code den ich sehe KANN es nicht getriggert werden. Und es macht genau, was ich sehe. Weitergereicht wird übrigens der trigger des DUMMY nicht - der vom HM device funktioniert.
Und es liegt nicht an dummy - auch "subtending" hm-trigger bleiben hängen (innerhalb von CUL_HM repariert - wenn der User ein eigenes Reading setzt würde es stehen bleiben).

Gibt es details zu deinem Setup, die man wissen sollte. Kannst du dein fhem.pl schon einmal posten? Offensichtlich haben wir Unterschiede im Setup.

Gruss Martin

[justme1968]

hallo martin,

der test heute früh war mit dem stand von gestern oder vorgestern auf dem produktiv system. keine addons. nichts besonderes.

ich hab eben remote ein update gemacht und teste es nachher wenn ich nach hause komme nochmal. die HM-OU-LED16 kann ich nicht remote bedienen

gruss
  andre

[ThaBear]

Hmmmm:
http://forum.fhem.de/index.php/topic,14728.msg107625.html#msg107625

[justme1968]

noch mal getestet mir der aktellen version und geht immer noch mit der HM-OU-LED16.

möchste du noch mehr informationen von mir oder hat sich das mit rudis bemerkung erst mal erübrigt?

gruss
  andre

[martinp876]

Hallo Andre,

muss ich wohl mit Rudi auskarteln. Ich stimme ihm so nicht zu. Sollte es ein HM-problem sein müsste es bei dir auftreten.
Seine Begründung kann ich nicht nachvollziehen - werde ich aber mit ihm ausdiskutieren.
was ich nicht verstehe ist, warum die Trigger bei dir kommen. Werde ich noch einmal ansehen
Gruss Martin

[ThaBear]

Moin,

gibt's schon ein Update?

Der Workaround funktioniert nur, wenn man das DoTrigger wirklich in jedes Notify der Kaskade (inkl. z.B. dem LightScene-Code) einbaut. Das ist nicht wirklich praktikabel und der Schalter somit fuer mich unbrauchbar, der WAF entsprechend niedrig...

Cheers,
M.

[martinp876]

Hallo,

sollte jetzt auch ohne DoTigger funktionieren.

Gruss Martin

[justme1968]

hallo martin,

rein aus neugier: hast du auch rausgefunden warum es bei mir mit meinen devices immer ging und bei den tastern und fernbedienungen nicht?

gruss
  andre

[martinp876]

Andre,

die lange Beschreibung:
fhem.pl hat 2 Funktionen, die hier mitspielen: den dispatcher zum messages-weiterleiten und das Reading schreiben.

ReadingEnd kann man sagen: setze das Reading und sorge dafür, das ein trigger ausgelöst werden soll

dispatch sorgt dafür, dass das trigger-auslösen unterdrückt wird und erwartet von seinen "Usern" sich selbst zu kümmern. Es erwartet, dass User eine Liste aller geänderten und zu triggernden Readings selbst mitführt. Am Ende muss der User diese Liste an disptch zurückgeben - dann werden die Trigger ausgelöst. dispatch schreibt aber zusätzlich noch parameter wie message-count, usw. geschrieben. Das passt nicht, da HM auch readings in abgeleiteten Entities ändert (TC UND VD, Channels UND devices UND trigger-ziele...). Daher habe ich in HM diese abgeleiteten Trigger "manuell" ausgelöst. Übersehen habe ich, dass der User weitere trigger ableiten und auslösen kann.
Es klappte also nicht, wenn du einen trigger aus einem "abgeleiteten trigger" weiter kaskadieren wolltest.

Jetzt habe wir eine Lösung, in der zwar immer noch der Nutzer von dispatch protokolieren und melden muss, was er in readingsUpdateEnd schon an fhem.pl mitgeteilt hat, aber man kann das Schreiben von (im HM Fall unangebrachten) Parametern verhindern.

Was nicht implementiert wurde:
- das fhem.pl sicherstellt alle trigger auszulösen, die mit readingsUpdateEnd beantragt wurden
-- in dispatch gibt es diverse (sicher seltene) Abbrüche, die das Auslösen der Trigger dann verhindern.
- das fhem.pl sicherstellt trigger und on notifies strict sequenziell auszuführen. Das geht jetzt verschachtelt, als trigger-in-trigger

Gruss Martin