notify auf Dummy-Device läuft nicht

[thumu]

Hallo zusammen,

ich beobachte hier ein merkwürdiges Verhalten eines Dummy-Device in Verbindung mit einem Homematic-Funktaster (HM-PB-2-WM55).

Habe einen Dummy definiert, über den ich meine An-/Abwesenheit steuern möchte:

Code Auswählen Erweitern

define HomeStatus dummy
attr HomeStatus setList 0 1 2

Hierauf habe ich ein notify gesetzt, das reagiert, sobald sich der Anwesenheitsstatus ändert:

Code Auswählen Erweitern

define n_homestatus notify HomeStatus { Log 3, "HomeStatus changed";;fhem("set LichtDiele toggle") }

Setze ich nun den HomeStatus unmittelbar mittels set-Kommando oder Web-Frontend, funktioniert alles, wie erwartet. Die obige Log-Ausgabe erscheint und in der Diele wird das Licht umgeschaltet (das hier definierte Verhalten ist wenig sinnvoll, ist aber auch nur beispielhaft).

Nun möchte ich den HomeStatus durch einen Button steuern:

Code Auswählen Erweitern

define FS20_Button FS20 1234 10
define n_fs20home notify FS20_Button set HomeStatus 1

Immer noch alles prima. Beim Drücken des Buttons wird der Wert von HomeStatus gesetzt, der notify "n_homestatus" wird ausgeführt und das Licht umgeschaltet.

Nun soll es mit einem Homematic-Button gelöst werden:

Code Auswählen Erweitern

define BtnHomeStatus CUL_HM 123456
attr BtnHomeStatus .devInfo 020000
attr BtnHomeStatus .stc 40
attr BtnHomeStatus firmware 1.1
attr BtnHomeStatus model HM-PB-2-WM55
attr BtnHomeStatus serialNr JEQXXXXXXX
attr BtnHomeStatus subType pushButton
define BtnHomeStatus_Btn_01 CUL_HM 12345601
attr BtnHomeStatus_Btn_01 model HM-PB-2-WM55
define n_hmhome notify BtnHomeStatus_Btn_01.Short.* set HomeStatus 1

Nun wird's spannend. Der Homematic-Schalter ist gepaired und funktioniert auch. Nach dem Button-Druck steht der state von HomeStatus auf 1. Was jedoch in diesem Fall nicht erfolgt, ist das oben definierte notify auf das HomeStatus Dummy-Device, was mit dem FS20-Button noch funktioniert hat.

Mache ich was falsch oder ist dies möglicherweise ein Fehler im HM-Modul?

Bin für jeden Hinweis dankbar.
thumu

[rudolfkoenig]

>  Mache ich was falsch oder ist dies möglicherweise ein Fehler im HM-Modul?

Vermutlich weder noch, sondern ein Problem in fhem.pl

Kannst Du bitte ein Log-Mitschnitt der Schaltaktion hier posten, mit "attr global mseclog" und "attr global verbose 5" ?

[rudolfkoenig]

> define n_hmhome notify BtnHomeStatus_Btn_01.Short.* set HomeStatus 1

Vor dem Log waere noch ein "inform timer"/"Event-Log" Mitschnitt interessant, ich vermute dass dieser notify bei HM mehr als einmal zuschlaegt.

[thumu]

hier schonmal der "inform timer" Mitschnitt

Code Auswählen Erweitern

2013-09-12 15:57:53 CUL_HM BtnHomeStatus_Btn_01 Short (to broadcast)
2013-09-12 15:57:53 CUL_HM BtnHomeStatus_Btn_01 trigger: Short_32
2013-09-12 15:57:53 CUL_HM BtnHomeStatus battery: ok
2013-09-12 15:57:53 CUL_HM BtnHomeStatus BtnHomeStatus_Btn_01 Short (to broadcast)


[thumu]

hier der Log-Mitschnitt der Schaltaktion:

Code Auswählen Erweitern

2013.09.12 19:34:56.334 5: HMLAN_Parse: HMLAN1 R:E1D366E   stat:0000 t:0EC55F9A d:FF r:FFC6     m:50 8440 1D366E 000000 0126
2013.09.12 19:34:56.337 5: HMLAN1 dispatch A0B5084401D366E0000000126::-58:HMLAN1
2013.09.12 19:34:56.347 5: Triggering BtnHomeStatus_Btn_01 (2 changes)
2013.09.12 19:34:56.351 5: Notify loop for BtnHomeStatus_Btn_01 Short (to broadcast)
2013.09.12 19:34:56.396 5: Triggering n_btnabwesend
2013.09.12 19:34:56.400 5: Cmd: >set HomeStatus 2<
2013.09.12 19:34:56.402 4: dummy set HomeStatus 2
2013.09.12 19:34:56.416 5: Triggering BtnHomeStatus (2 changes)
2013.09.12 19:34:56.421 5: Notify loop for BtnHomeStatus battery: ok

[hobbyprovider]

Ich habe das gleiche Problem
Die Tasten am Sender "HS_Alarm_1_Btn_02" und "HS_Alarm_1_Btn_03" schalten "testdummy" ein und aus
wenn ich "testdummy" über Web ein und auschalte folgt "SW_Flur" ganz brav
Ein Tastendruck am Sender verursacht aber keine Wirkung bei "SW_Flur"
Die Funktion wird aber nachgeholt denn ich über Web auf "statusRequest" klicke
z.B.: ich drücke Button 2 - Flur bleibt dunkel - Klick auf "statusRequest" - Flur wird hell

Code Auswählen Erweitern


define not_HS_Alarm_1_Btn_02 notify HS_Alarm_1_Btn_02 set testdummy on
define not_HS_Alarm_1_Btn_03 notify HS_Alarm_1_Btn_03 set testdummy off

define testdummy dummy
attr testdummy webCmd statusRequest:on:off
attr testdummy room 9_Test

define not_testdummy notify testdummy set SW_Flur %


[ThaBear]

Moin,

hier ebenso.

Das Notify vom Sender aendert zwar den Status des Dummy (sichtbar im Web-Interface), aber darauf horchende Notifies werden nicht getriggert. Erst eine weitere Aktion im Web-Interface (z.B. statusRequest, on, off) loest die Notifies aus. Ein zusaetzliches statusRequest im Sender-Notify bringt auch nix.

[herman]

Moin,

hier ebenso.

Das Notify vom Sender aendert zwar den Status des Dummy (sichtbar im Web-Interface), aber darauf horchende Notifies werden nicht getriggert. Erst eine weitere Aktion im Web-Interface (z.B. statusRequest, on, off) loest die Notifies aus. Ein zusaetzliches statusRequest im Sender-Notify bringt auch nix.

kann ich genauso bestätigen. Beispiel:

define WZ_Remote_Btn_17Notify notify WZ_Remote_Btn_17 set HomeStatus Schlafen;;set Flur_Licht off

define HomeStatus_Change notify HomeStatus {fhem("{ChangeHomeStatus('%')}")}

--------------
Beim Betätigen des Senders führt das erste Notify dazu, dass im Webinterface der Dummy HomeStatus auf "Schlafen" gesetzt wird und das Licht im Flur ausgeht.
Notify HomeStatus_Change wird nicht ausgeführt.

Wird hingegen der Dummy Homestatus im Webinterface gesetzt, greift das zweite Notify.

Doppelte Nachrichten kann ich nicht bestätigten. Hier die entsprechenden Nachrichten über telnet / inform on:

CUL_HM WZ_Remote_Btn_17 Short (to KUE_Kaffeemaschine)
CUL_HM WZ_Remote_Btn_17 trigger: Short_194
CUL_HM WZ_Remote battery: ok
CUL_HM WZ_Remote WZ_Remote_Btn_17 Short (to KUE_Kaffeemaschine)

Ich hoffe auf eine baldige Lösung, da ich diverse solcher Dummies im Einsatz habe.

Grüße,
Merhan

[herman]

> define n_hmhome notify BtnHomeStatus_Btn_01.Short.* set HomeStatus 1

Vor dem Log waere noch ein "inform timer"/"Event-Log" Mitschnitt interessant, ich vermute dass dieser notify bei HM mehr als einmal zuschlaegt.

werden noch irgendwelche Logs benötigt?

[rudolfkoenig]

Sorry, dass ich diesen Thread "vergessen" habe, aber seit dem Forumswechsel kriege ich keine Antworten mehr (nur, wenn ich nach dem Forumswechsel selber eine Antwort geschrieben habe), und mein persoenlicher Merkzettel ist durch ein Plattencrash verloren gegangen.

Nach laengerem Debuggen ist das Problem klar: CUL_HM Ruft im CUL_HM_Parse DoTrigger direkt auf, und das ist ein "No-Go".
Das Mischen von readingsBulkUpdate und DoTrigger generiert genau diese Probleme.

[martinp876]

Hallo Rudi,

die DoTrigger sind nicht einfach so eingebaut - sondern zeitlich an der Stelle, an der der Dispatcher es eigentlich erledigen sollte, aber nicht tut.
Gemischt wird eigentlich nichts wenn du mal genauer hin siehst.
Mir fehlt immer noch die Aussage wann die durch readingsUpdateDelayTrigger blockierten DoTrigger abgearbeitet werden. Dispatch kümmert sich nicht darum. Kannst du mir einen Tip geben, welcher code die blockierten Entities sammelt oder sucht um sie dann auszuführen? Meine hingen ewig. Vielleicht fehlt mir ja ein Modul?

Wann wirst du den Dispatcher korrigieren?
Gruss Martin

[rudolfkoenig]

> ... aber nicht tut.
Dann ist es ein Bug, was ich fixen muss. Bitte mir den Fall genau beschreiben, und mir die Dispatch-Daten schicken, da ich kein Hardware habe.

> Mir fehlt immer noch die Aussage wann die durch readingsUpdateDelayTrigger blockierten DoTrigger abgearbeitet werden.
Im Dispatch, nachdem parseFn durch ist.

> Wann wirst du den Dispatcher korrigieren?
Das ist z.zt. noch relativ, ich meine Dispatcher ist ok, und der Aufruf in CUL_HM_ParseFn ist falsch

[rabi]

Seit zwei Wochen betreibe ich eine minimale HM-Konfiguration, die derzeit lediglich aus einem HMLAN und einem Temperatur-/Luftfeuchtesensor HM-WDS10-TH-O besteht. Die Inbetriebnahme (zu dem Zeitpunkt lief bei mir noch FHEM 5.4) lief reibungslos, auch die restlichen Devices die ich momentan noch nicht nutze funktionieren wunderbar, auch die BidCos-Kommunikation läuft. Jedoch habe ich recht früh bemerkt dass FHEM mehr oder weniger regelmäßig die Verbindung zum HMLAN-Adapter verliert, das sah in der Logfile dann so aus:

[rudolfkoenig]

@Merhan: ich meine wir haben mit Martin (p876) eine Loesung gefunden, und eingecheckt: kannst Du das bitte pruefen und berichten?

@rabi: Dein Problem hat nicht (jedenfalls nicht wirklich) was mit dem hier diskutierten zu tun. Diskussionsentfuehrungen sind bei uns verpoent: bitte im HomeMatic Bereich eine Neue oeffnen. Und Anhang nicht vergessen.

[herman]

@Merhan: ich meine wir haben mit Martin (p876) eine Loesung gefunden, und eingecheckt: kannst Du das bitte pruefen und berichten?

@rabi: Dein Problem hat nicht (jedenfalls nicht wirklich) was mit dem hier diskutierten zu tun. Diskussionsentfuehrungen sind bei uns verpoent: bitte im HomeMatic Bereich eine Neue oeffnen. Und Anhang nicht vergessen.

Hallo Rudi,
hallo Martin,

ich kam gestern nur kurz zum testen. Sieht aber gut aus - alle notifies wurden wieder angestoßen.

Getestet habe ich mit

HM-PB-4DIS-WM
HM-RC-12
HM-RC-4-B

vorher ein update und alle manuellen DoTrigger entfernt.

Viele Grüße,
Merhan

[MiiPuu]

Hallo,
ich habe auch das Problem mit dem notify auf Dummy... Ich habe dazu schon einen entsprechenden Post im Intertechno Bereich hinterlassen, da ich das Forum nicht mit Doppel-Posts zumüllen will, hier der Link dazu: http://forum.fhem.de/index.php/topic,16746.0.html

Hoffe ihr könnt mir helfen!

Danke!