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

Begonnen von herman, 11 November 2013, 14:27:43

Vorheriges Thema - Nächstes Thema

herman

Hallo,

ich habe auch in der aktuellsten Version das Problem, dass bei Änderungen von Dummy-Werten über Homematic-Fernbedienungen die dazugehörigen notifies nicht ausgelöst werden.

Seit September existiert dieser Thread dazu: http://forum.fhem.de/index.php/topic,14728.msg94410.html#msg94410

Gibt es dafür einen Workaround? Ich würde gerne auf eine aktuellere Version gehen.

Danke & Grüße,
Merhan


martinp876

Hi,

das liegt nicht an HM.
Problem ist, dass während ein Event verarbeitet wird werden keine folge/abgeleiteten events getriggert. Diese werden gequeued, im device - aber die Queue wird nicht "verarbeitet".
Für HM-interne folgetrigger berücksichtige ich dies - in deinem Fall musst du es selbst.

Wahrscheinlich kannst du im dummy ein "changed" sehen, da stehen gequeuete, aber nicht "genotifiete" events drin. Du musst ein DoTrigger(<entity>,undef) anstossen.

Gruss Martin


herman

#2
Zitat von: martinp876 am 11 November 2013, 14:46:57

Wahrscheinlich kannst du im dummy ein "changed" sehen, da stehen gequeuete, aber nicht "genotifiete" events drin. Du musst ein DoTrigger(<entity>,undef) anstossen.


Hallo Martin,

vielen Dank für den Tipp. Damit funktioniert es wieder.

Es sind noch ein paar Fragen in meinem Kopf, da es ja in vorherigen Versionen ohne das DoTrigger funktioniert hat.
Ist das aktuell ein Bug und das DoTrigger ein Workaround?
Was passiert, wenn der Bug wieder behoben ist. Ist das "zusätzliche" DoTrigger ein Problem z.B. bzgl. Performance?

Vielen Dank!
Grüße,
Merhan

martinp876

hallo Merhan,

ich bin nicht sicher, wann es funktioniert hat. Auch in der CUL_HM SW muss ich es von Hand nachtriggern, wenn mehr als eine Entity zu ändern sind.
Das Verfahren ist, dass in der Bearbeitungsphase eines Events (beispielsweise einer message) alle Änderungen an DIESER entity gequeued werden und per DoTrigger "ausgelöst" werden. Gleichzeitig werden events aller anderen Entites gequeued (siehe CHANGED der Entity) - aber nicht ausgelöst. Das ist explizit geklemmt.
Als Grund sehe ich, dass man verhindern will in einer endlosschleife sich gegenseitig triggernder Events blockiert zu werden. Es könnte auch Performance-Gründe habe, dass ein Event nicht zu lange dauert (glaube ich aber nicht). Der Code sieht jedenfalls nicht nach einem Unfall aus.

Das ganze ist NICHT in CUL_HM - da hat sich auch nichts geändert (so weit ich sehen kann). Der Code ist in fhem.pl - ich denke Rudi ist hier der Master.

Gruss Martin

ThaBear

#4
Moin,

Edit: Hab das DoTrigger im LightScene Modul eingebaut, jetzt funktionierts. :)

ich haeng mich mal hier an, weil ich das selbe Problem hab und sich im anderen Thread gar nichts tut.

Ich hab eine Kaskade aus Dummies und LightScenes. Ein set auf einem Dummy (D1), aktiviert eine bestimmte Scene, die weiter Dummies (D2) setzt auf denen auch Notifies haengen. Funktioniert im Web-Interface.

Nun haenge ich vor das ganze den Schalter. Notifies auf den Buttons schalten die ersten Dummies.

Anfangs ging gar nichts (http://forum.fhem.de/index.php/topic,14728.msg106183.html#msg106183). Durch den Tip mit dem DoTrigger, wird jetzt zumindest die Scene und die weiteren, in der Scene definiert Dummies (D2) gesetzt.
Allerdings springen die Notifies auf diesen Dummies (D2) nicht an. DoTrigger kann ich hier nicht verwenden, da die Dummies ja durch die LightScene und nicht ueber ein Notify gesetzt werden.
Ich weiss nicht mehr weiter.

Ich verstehe auch nicht wirklich, wieso zwischen Schalter/Notify und set direkt im Web-Interface ueberhaupt ein Unterschied ist. Kann man die Web-Interface-Interaktion ev. in einem Notify emulieren oder anstossen?

Merci!

Cheers,
M.

justme1968

ich habe gerade versucht das problem nachzustellen. aber es gelingt mir auch mit zwei dummys, einer lightScene und einem homematic unterputz schalter nicht. siehe hier: http://forum.fhem.de/index.php/topic,11485.msg107221.html#msg107221

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

martinp876

andre,

Das Problem besteht im Zusammenhang mit Readings.
Wenn readings gesetzt werden gibt man an, ob diese einen trigger auslösen sollen. Das tun sie dann auch brav.
ABER - in bestimmten Situationen - wenn man gerade "in einem Trigger" ist und jetzt Readings ändert, wird es blockiert.
Ändert man readings der Entity, die gerade  "im trigger" ist sollte es kein Problem sein - die werden abgearbeitet. Ändert man aber ein Reading einer anderen entity wird die Änderung vermerkt - aber DoTrigger wird für diese Entity nicht aufgerufen.

Wenn du also ein notify auf ein Reading hast und hier den state eines Dummy änderst (dummy = 2. Entity) wird das Reading gesetzt (meist state bei dummies) - und es wird in CHANGED vermerkt. Aber der trigger für den Dummy kommt nicht.

Ändern kann man das. Das ist in fhem.pl, funktion readingsEndUpdate($$), ganz am Ende muss man sich die Entities merken und dann nach dispatch das DoTrigger anwerfen.
Gruss Martin


justme1968

hallo martin,

das weiss ich. ich verstehe aber nicht wie es dazu kommen kann wenn man nur notifys verwendet. egal wie sie kaskadiert werden.

ich habe versucht das ganze mit 3 dummys, einer light scene und einem panstamp rgb board nachzustellen. egal wie ich die devices über die notifys kaskadiere d.h. egal welche Reihenfolge, egal ob ich state oder ein anderes reading verwende, egal ob ich im web durch klick, mit set, mit setreading, mit trigger oder über eine zweite fhem installation per funk schalte, es funktioniert immer.

die frage ist also was genau ist die bestimmte situation. wie wird der state des dummy verändert ohne das die nachfolgenden trigger ausgelöst werden (ausser setstate zu verwenden das je eben ganz genau absichtlich nicht triggert). eine der möglichkeiten und faktoren oben kann es ja nicht sein.

wie kann man das ganze reproduzierbar nachstellen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

martinp876

Hallo Andre,

der Grund ist in fhem.pl.
Die Variable $readingsUpdateDelayTrigger in Dispatch blockiert das "DoTrigger" von Readings.

Dispatch wird wohl bei allen empfangenen Messages aufgerufen, nicht aber beim setzen von readings.
Es sollte also blockieren, wenn du ein notify an eine "receive-mesage" hängst und dann das Reading einer anderen Entity änderst (z.B. eines dummy device) Die Änderung des Dummy dürft nicht zu einem Trigger führen.

Die Lösung schient auch einfach.
in readingsEndUpdate() muss man die Namen der entites in einem Array sammeln (einfach neues Array zusammen mit $readingsUpdateDelayTrigger definieren, @readingsUpdateDelayQueue.
Am Ende von dispatch(), wenn
DoTrigger($found, undef);
aufgerufen wird sollte man - nach der @found schleife-  in @readingsUpdateDelayQueue duplicates entfernen und dann in eine
DoTrigger($_,undef) foreach(@readingsUpdateDelayQueue)
einbauen.

Bei der Gelegenheit sollte kann man prüfen, ob die @found schleife bei "UNDEFINED" mit return verlassen werden soll/muss oder mit "next" fortgefahren werden sollte.

Gruss Martin


justme1968

ich muss mir das noch mal in ruhe anschauen.

wie oben gesagt habe ich es aber auch probiert indem ich das notify an ein panstamp rgb board gehängt habe und das board dann von einer anderen fhem installation geschaltet habe. d.h. die nachrichten sind per rf und dispatch gekommen. und auch das hat funktioniert. hätte es aber laut deiner beschreibung nicht dürfen.

ich probiere es heute abend  auch noch mal mit einer fs20 fernbedienung und einem hm unterputz schalter.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

noch ein test mit einer HM-OU-LED16. mit einem notify das auf die tasten an der rückseite lauscht kann ich die kaskade der dummys auch schalten.

entweder tritt das problem wirklich nur mit den hm fernbedienungen oder tastern auf oder ich mache irgendetwas falsch. ich kann es einfach nicht reproduzieren.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

hallo martin,

was mir gerade auffällt: der unterschied von allen meinen devices mit denen ich es probiert habe (inklusive HM-OU-LED16 und   HM-LC-Sw1PBU-FM) und einem HM-PB-6-WM55 (und auch den anderen fernbedienungen) ist das es immer ein 'echtes' device ist und nicht der channel eines device. kann es sein das die ursache nicht in den notifys liegt sondern in der art wie die empfangene nachricht zwischen device und channel ausgetauscht wird?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

martinp876

Hallo Andre,

eigentlich nicht. In fhem.pl ist es eigentlich eindeutig - es wird beim ändern der readings in diesem Fall NICHT getriggert. Die geänderten Entites werden NICHT gesammelt. Somit müssten alle Änderungen irgendwo gesucht werden (es ist nur in den einzelnen Entites vermerkt, dass sich der Zustand geädert hat).
HM hat damit nichts zu tun.
da CUL_HM mit einer message ggf mehrere Entities  ändert (TC UND VD) und es zu Problemen kam sammle ich alle Änderungen und triggere diese.
Ich kann einmal ein test-scenario bauen - malsehen

Gruss Martin

martinp876

also - auf die schnelle:

define d dummy
define d1 dummy
define d2 dummy
define n11 notify d:on set d1 dISon
define n12 notify d:off set d1 dISoff
define n21 notify d1:dISon  set d2 d1ISon
define n22 notify d1:dISoff set d2 d1ISoff
define n31 notify FB2_B3:trig.*  set d on
define n32 notify FB2_B2:trig.*  set d off


wenn ich jetzt FB2_B3 drücke sollte d2 auf d1ISon gehen...
wenn ich jetzt FB2_B2 drücke sollte d2 auf d1ISoff gehen...
macht es aber nicht
in d bleibt CHANGED stehen und wartet!

wenn ich ein
set d on mache geht d2 auf d1ISoff

Gruss Martin

justme1968

gerade mit einer HM-OU-LED16 getestet da ich keine echte hm fernbedienung habe. und damit geht es ohne probleme.

wenn es nicht die aufteilung in ein device pro channel ist was ist dann der unterschied zwischen einer HM-OU-LED16 und einer echten fernbedienung ?

define d dummy
define d1 dummy
define d2 dummy
define n11 notify d:on set d1 dISon
define n12 notify d:off set d1 dISoff
define n21 notify d1:dISon  set d2 d1ISon
define n22 notify d1:dISoff set d2 d1ISoff
define n31 notify CUL_HM_outputUnit_1D4B0B:Btn15.* set d on
define n32 notify CUL_HM_outputUnit_1D4B0B:Btn16.* set d off


Zitat2013-11-15 09:17:41 dummy d2 d1ISon
2013-11-15 09:17:41 dummy d1 dISon
2013-11-15 09:17:41 dummy d on
2013-11-15 09:17:41 CUL_HM CUL_HM_outputUnit_1D4B0B Btn15 on (to cul2)
2013-11-15 09:18:21 dummy d2 d1ISoff
2013-11-15 09:18:21 dummy d1 dISoff
2013-11-15 09:18:21 dummy d off

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968