event on change für events one arribut

[Martin Thomas Schrott]

Hi zusammen,

ich bin gerade auf ein kleines Problem gestoßen, wo ich kurz Hilfe benötige.
Ich möchte alle events eines devices nur erhalten wenn sie sich ändern. Daher setze ich event on change auf .*

Jetzt möchte ich eine Ausnahme in dem event on update definieren für:

2013-02-06_15:42:02 Tasterschnittstelle_Stiegenhaus Tasterschnittstelle_Stiegenhaus_Btn01
Short (to broadcast)

Wie muss nun der Eintrag im event on update reading aussehen?

Bei battery: ok
wäre das logisch, da nimmt man battery?
aber hier fehlt das attribut also was sollte ich eintragen?
Den Namen des Buttons -> geht nicht. Den Namen des devices geht auch nicht.
Short macht keinen Sinn würde ich ja alle buttons ausnehmen nicht nur den einen?
Any help?

Aja und hier ist erstmals aufgetreten, was andere schon gemeldet haben, das device wird beim event dem Kanal vorangestellt. Jetzt die Frage, wann passiert das? Denn meine anderen Geräte tun das bisher nicht, nur die neue Schnittstelle.Eigenartig.

lG
Martin

[martinp876]

Hallo Martin,

FHEM hat entscheiden das reading 'state' ohne eben diesen zu schicken. Das ist im Gegensatz zu allen anderen (eben zu "batterie")
Das macht ein parsen schwieriger, will man immer 'state' sehen.

Zu den remotes und den notifies: Hier kommt
<device> state:<button_name> Short (to target)
UND
<button_name> state: (to target)

state: wird immer eliminiert.

Aendern werde ich den 2. Teil, den habe ich nicht vollstaendig eingebaut. Nun also
<button_name> state: Short (to target)

Passt es dann so?

Gruss
Martin

[Martin Thomas Schrott]

Danke Martin,

hab nun state ins event-on-update-reading geschrieben und alles funktioniert.

Ja, ich würde state nicht ausblenden, das ist sehr verwirrend, da es aus der Reihe tanzt. Mach es denn irgendeinen Sinn state wegzulassen?

Ich finde die events mit state: xyz viel logischer und stimmiger, da ja alle anderen Werte ebenfalls mit dem attributnamen angezeigt werden.

Kannst du das nicht auch beim 1. Teil so stehen lassen, ohne state wegzuputzen?

btw nochmal die Frage, wann steht jetzt das device vorne und wann nicht? bei der Tasterschnittstelle ist das so, bei z.B. dem remote Schalter den ich habe nicht.
lG
Martin

[martinp876]

Hallo Martin

das bin nicht ich, das ist ein Beschluss aus FHEM bei state eine Sonderbehandlung einzubauen. Aus CUL_HM kann ich dies nicht steuern. Das ist "familienuebergreifend" - muss man bei Rudi einkippen.
Ich stimme mit diener Meinung uederein.

btw nochmal die Frage, wann steht jetzt das device vorne und wann nicht? bei der Tasterschnittstelle ist das so, bei z.B. dem remote Schalter den ich habe nicht.

ist 'gewachsen'. Einst hatten buttons keine Namen, waren keine Kanaele. Da war das event
<remote> state:<BtnNo> [short|long|...] <to dest>

nachdem ich die channels hatte wurde u.a. die BtnNo durch den channel-name ersetzt - falls vorhanden. Also
<remote> state:<BtnName> [short|long|...] <to dest>
plus ein event fuer den Channel
<BtnName> state: <to dest>
letzteres werde ich aendern in
<BtnName> state: [short|long|...] <to dest>

so, da ist der Stand, das sollte immer so sein, fuer Schalter und Taster. Es ist ein Unterschied ob du channels je Button definiert hast oder nicht.
Was kann man verbessern? Evtl sollte "state" des Button-device den Schaltvorgang nicht anzeigen?
Gruss
Martin

[Martin Thomas Schrott]

Hi,

ah, bin ich wieder mal etwas schlauer geworden *freu*

Ja, genau wenn im Kanal der state eventiert wird, nicht zusätzlich im Device ausgeben! Nur events die beim Kanal nichts verloren haben beim Device ausgeben. Also battery etc.

Wenn das state: dort stehen würde wäre ja gar keine Verwirrung aufgetreten. Es ist eben nur in Kombi mit event-on-change-reading problematisch, weil man nicht weiß, was man -freischalten- muss, damit die events auch durchgehen.
Sonst kommen gerade ungeübte user sicherlich an ihre Grenzen, weil nur noc einmal das notify ausgelöst wird solange nicht z.B. einmal short und einmal long getriggert wird. Bin übrigens nur dadurch auf das Problem aufmerksam geworden, weil ich einmal versehentlich zu lange die Kabel zusammengehalten habe, beim Testen. Dann war ein long da und ich hab verstanden, dass ich beim event-change ein Problem habe ;-)

Also falls sich Rudi nicht überzeugen lässt, muss das unbedingt dokumentiert werden, damit user wissen, das state das attribut ist, wenn nichts im log steht. :-)

Danke!
Martin