Schalter/Taster vs (Schalt-)Aktoren, take 2

[fallenguru]

Ich spiel mich gerade wieder mit meiner EnOcean+Fhem-Installation und dachte mir, wenn ich schon alles auf Vordermann bringe, kann ich auch das alte Taster vs. Schaltaktor-Problem wieder aufwärmen (ursprünglicher Thread).

Ich habe Taster (vulgo "Lichtschalter") an den Wänden. Die sind "taub", d. h., sie senden, aber empfangen nichts.
Dazu eine Reihe Schaltaktoren. Die sind "stumm", können Kommandos empfangen, aber keine Rückmeldung geben.
Die Taster sind sowohl an Fhem als auch direkt an den Aktoren angelernt, damit die Grundfunktion gewährleistet bleibt, wenn Fhem außer Gefecht ist (eine der Stärken von EnOcean).

D.h., die Taster schalten die Aktoren "an Fhem vorbei", was es nicht-trivial macht, in Fhem mitzuverfolgen, welchen Status ein Aktor gerade hat. Workaround: Taster ebenfalls in Fhem anlegen, events per notify verfolgen und bei einer Tasterbetätigung den state des zugehörigen Aktors verändern (ohne dabei zu schalten). So weit, so gut.

Nur modellieren lässt sich das Ganze nicht besonders schön. Das EnOcean-Modul kennt nämlich keinen Unterschied zwischen einem Taster (= Sensor) und einem Schaltaktor, beide sind switch.
D.h., Taster werden behandelt, als ob sie eine Anzahl von Kanälen hätten, die sich in jeweils einem von zwei Zuständen befinden. Mag sein, dass es tatsächlich solche echten Kippschalter gibt, ich kenne nur Taster, die nach jeder Betätigung wieder zurückspringen. Bei denen gibt es (angen. 4-fach-Taster) theoretisch 4 Tasten, die unabhängig voneinander entweder gedrückt sein können, oder eben nicht. Sinnvoll wäre m.E. also z.B.: state: AI (A1 wird gerade gedrückt), state: released (Taster im Ruhezustand) oder state: A0, B0 (zwei gleichzeitig gerade gedrückte Tasten) und/oder ein reading pro Taste mit pressed oder released.
Zweitens, Taster haben set-Befehle, was keinen Sinn ergibt.
Auf Aktoren-Seite wiederum gibt es das Problem, dass zumindest meine Aktoren (Opus, Peha), unabhängig davon, ob ein (virtueller Fhem- oder ein physischer) Schalter als Richtungstaster (ein/aus) oder als Universaltaster (toggle) eingelernt ist, ein released nach einem Schaltvorgang bekommen wollen, also davon ausgehen, dass sie jedenfalls von einem Taster (nicht Schalter) bedient werden. Das geht zwar über pushbutton problemlos -- nur verliert man dann den Status des Aktors. (Dabei würde hier das mit den Kanälen in einem von zwei Zuständen ja sogar stimmen, released als Zustand gibt's nicht, das Loslassen des virtuellen Schalters ändert den Zustand des Aktors ja nicht.) 

tl;dr: Ich finde, mittelfristig wäre eine Unterscheidung von Schaltaktoren und Schalt-/Tastsignalgebern eine gute Sache.

[fallenguru]

Gerade habe ich entdeckt, dass es neben switchMode noch sensorMode gibt -- die "Überschrift" in der commandref ist übrigens in beiden Fällen switchMode. Jetzt funktionieren, mit attr dummy 1 und attr sensorMode pushbutton, wenigstens die Wandschalter richtig.
Noch schöner wäre es, wenn man Fhem erklären könnte, dass das reine Sensoren sind, set also keinen Sinn macht; oder, dass es vier unabhängige Taster sind, die jeweils nur "pressed" und "released" kennen -- aber das sind reine Schönheitsfehler.

Für meine Schaltaktoren bräuchte ich wohl einen eigenen Typus "pushbutton switch", der einerseits nach jedem Schaltvorgang "released" sendet, dann aber dieses selbst gesendete "released" ignoriert, was den Status des Aktors betrifft. Niemand hat etwas davon, wenn die gesamte Beleuchtung/-lüftung unabhängig vom tatsächlichen Zustand quasi immer "released" ist. Das scheint ja auch die Idee bei sensorMode zu sein -- leider greift das offensichtlich nicht, wenn Fhem selbst schaltet.
Lustigerweise bräuchten diesen Typus alle unidirektionalen Schaltaktoren, die mir je untergekommen sind (Opus, Peha, Eltako) -- sie alle erwarten, von Tastern bedient zu werden (die beizeiten "released" senden), sind aber selbst natürlich Schalter mit zwei stabilen Zuständen (pro Kanal).
=> Könnte man eventuell sensorMode dahingehend ausbauen, dass es auch selbst gesendete "released" schlucken kann?

[klaus.schauer]

- Der letzte, aktuell gültige Zustand eines Kanals ist in den "channel<x>"-Readings verfügbar.
- Die Stati "pressed"/"released" signalisieren lt. EnOcean-Spezifikation den letzten Zustand des Schalter insgesamt, also unabhängig von den Kanälen.

[fallenguru]

Das Problem ist, dass aus EnOcean-Sicht m.E. zwei Geräte involviert sind, die in Fhem als ein Gerät abgebildet werden:
1) Der virtuelle Schalter/Taster, den Fhem simuliert. Für den ist pressed/released als Status natürlich vollkommen korrekt.
2) Der physische Schaltaktor, der nur den Status ein/aus kennt (ggf. pro Kanal), welcher davon geschaltet wird.
Als User interessiert einen im Grunde nur (2), momentan verwendet Fhem/EnOcean aber (1) als state.

D.h., im Modus switch ist state wie erwartet, aber der Aktor wartet auf ein released, das nie kommt. Solange man nur Fhem darauf eingelernt hat, ist das egal, aber auf andere Sender reagiert er dann nicht mehr normal. (Gilt, wie gesagt, für alle unidirektionalen Schaltaktoren, die ich habe.) Im Modus pushbutton ist der Aktor glücklich, dafür bekommt man in Fhem nur noch released als state, was reichlich sinnlos ist, wenn man bedenkt, was da alles dranhängt.

channel<x> Readings habe ich bei den Aktoren leider keine. Die haben nur ein einziges Reading, nämlich state! Fehlt am Ende was in der (Uralt-)Definition?

Code Auswählen Erweitern


define a_GZ_Decke_1 EnOcean XXXXXXXX
attr a_GZ_Decke_1 IODev rocket
attr a_GZ_Decke_1 alias [GZ] Deckenlicht
attr a_GZ_Decke_1 devStateIcon off:light_generic_off@black on:light_generic_on@orange
attr a_GZ_Decke_1 eventMap AI:on A0:off
attr a_GZ_Decke_1 group Beleuchtung
attr a_GZ_Decke_1 icon light_ceiling_fan
attr a_GZ_Decke_1 manufID 7FF
attr a_GZ_Decke_1 room GrünesZimmer
attr a_GZ_Decke_1 subType switch


[klaus.schauer]

Jetzt werden die Readings channel<x> auch beim Senden gesetzt. Bitte mit Entwicklerversion testen, siehe Anhang.

[fallenguru]

Der Schaltzustand des (einen getesteten) Aktors wird jetzt in channelA gespeichert, sogar die eventMap wirkt gleich schon darauf. attr a_XY stateFormat channelA greift auch. ==> schaut sehr gut aus, danke!

Die Notifiys, die den Status des Aktors bei Schaltungen über Wandschalter togglen, funktionieren nicht mehr,  aber das ist ein anderes Thema und sicher leicht zu beheben. Unterm Strich wird's einfacher, weil das Released jetzt intern gesendet wird. Mach mich gleich ans Umschreiben.

Mehr als einfaches Schalten hab ich noch nicht getestet.

P.S.: Funktioniert update noch regulär oder sollte ich vorher lieber die mitgelieferte Version wiederherstellen?

[fallenguru]

[...] sogar die eventMap wirkt gleich schon darauf.

Hm, nicht ganz. Wenn sich an dem neuen Reading channelA "live" etwas ändert (Anzeige in FHEMWEB in rot), dann werden "on" bzw. "off" als Reading angezeigt, also die eventMap angewandt. Wenn ich den Aktor aber in FHEMWEB neu aufmache oder die Seite refreshe, steht da "AI" bzw. "A0", also die rohen Werte. ReadingsVal() liefert immer AI/A0, es ist also nur die Anzeige inkonsistent.

Davon abgesehen ist das jetzt deutlich sauberer, danke noch einmal! 

[klaus.schauer]

Die Änderungen stehen jetzt per update zur Verfügung.