Behandlung von 4-fach Tastern

[fallenguru]

Hallo!

Wir haben (EnOcean-)Schalter mit vier Schaltern (zwei Wippen, je oben und unten), die wir auch alle vier einzeln belegt haben. D. h., wir haben nicht zwei Kanäle mit on/off sondern quasi 4 mit toggle. Nun hätte ich gerne, dass FHEM, wenn es von den Schaltern Signale mitbekommt, diese auch dementsprechend interpretiert. Geht das?
(Klarerweise werden die FHEM-Sender auf on/off angelernt.)

Wenn das im Anfängerforum besser aufgehoben sein sollte, bitte ich um Entschuldigung und Verschiebung!

Vielen Dank und lg

[mediastudio]

Hallo,im Event monitor den Schalter erfassen und dann für die Doppelfunktion das z.B. so setzen "eventMap B0:on BI:off A0:Aus AI:An"
die erste Wippe ist dann B0:on BI:off
die zweite Wippe ist dann A0:Aus AI:An
nun die Funktion definieren, für meine Garage habe ich das so gelöst, ist auch ein Schalter mit zwei Wippen.
Es darf nur nich zweimal on oder off am Schalter als  "eventMap B0:on BI:off A0:on AI:off" erscheinen, dann gibt es Fehlschaltungen.

 
##############################################
# Garagentor Schaltkontakt AUF AB
#############################################
#Schalter einmal definieren
define GaragentorSchalter EnOcean 001B09AB
attr GaragentorSchalter eventMap B0:on BI:off A0:Aus AI:An

#Actor für den Garagentorimpuls
define GaragentorRelais EnOcean FFF25C8E
attr GaragentorRelais alias Garagentor
attr GaragentorRelais eventMap B0:on BI:off
attr GaragentorRelais manufID 00D
attr GaragentorRelais room Garage
attr GaragentorRelais subType switch

# Zeiteinstellung Kontakt
define Garagentor_toggle notify GaragentorRelais:on {fhem ("define Garagentor_at at +00:00:02 set GaragentorRelais off")}
# Schalterbetätigung erkennen
define GaragentorSchalter_on notify GaragentorSchalter:on set GaragentorRelais %
define GaragentorSchalter_off notify GaragentorSchalter:off set GaragentorRelais %

##############################################
# Garage Licht
#############################################
#Actor für das Licht
define Garagenlicht_Actor EnOcean FFF25C8B
attr Garagenlicht_Actor alias Garage Licht
attr Garagenlicht_Actor eventMap B0:off BI:on
attr Garagenlicht_Actor room Garage
attr Garagenlicht_Actor subType switch

# Schalterbetätigung erkennen
define GaragentorSchalter_An notify GaragentorSchalter:An set Garagenlicht_Actor  on
define GaragentorSchalter_Aus notify GaragentorSchalter:Aus set Garagenlicht_Actor  off

[fallenguru]

Danke! Leider bin ich so weit selbst auch schon gekommen. Nur ist auf meinen Wippen eben nicht 2x ein/aus drauf, sondern bis zu vier verschiede Lichter, die je über einen Taster umgeschaltet werden. FHEM hat also eine "falsche Vorstellung" von dem Schalter so dass die erfasste Zustandsinformation ziemlich sinnlos ist. Am ehesten hätte ich mir vorgestellt, dass es so etwas wie subType=toggle gibt, aber bis jetzt habe ich nichts gefunden ...

[klaus.schauer]

Eine Lösung könnte sein:
- reading buttons wird ersetzt durch buttonA0, buttonAI usw. mit den Stati pressed und released
- readings channelA, channelB usw. mit jeweils den Stati A0, AI oder B0, BI usw. sowie released, falls attr sensorMode = pushbutton
- reading state mit dem Stati A0, AI, B0, BI usw. sowie released, falls attr sensorMode = pushbutton

Das reading sensorMode = pushbutton|switch sollte es sowieso in der nächsten Version von 10_EnOcean geben, da das Tastereingabe-Modul Eltako FTS12EM-UC sonst nicht brauchbar ausgewertet werden kann.

Falls jemand nicht unbedingt das reading buttons benötigt, würde ich die Ausgabe sobald als möglich umbauen.

[fallenguru]

Ah, meine Herangehensweise war wohl die falsche ...

FHEM legt ja automatisch nur jeden Lichtschalter als eigenes Gerät an, und versucht dann, dessen Status zu verfolgen. Das hat mit den Aktoren, die daran gekoppelt sind, a priori ja noch gar nichts zu tun ... Es ist ganz logisch, Aktoren und Schalter getrennt zu definieren und dann FHEM beizubringen, wie sie verknüpft sind -- also eh ähnlich wie in dem Garagentor-Beispiel --, aber wie definiert man am besten den Aktor?

Die Def. als fiktiver zusätzlicher Schalter kommt mir etwas sehr behelfsmässig vor, und ich wüsste auch nicht, welche ID ich vergeben sollte. (Meine einfachen unidirektionalen Aktoren senden keine Bestätigung o. ä.) Wahrscheinlich könnte ich einfach eine ID "erfinden", aber das widerstrebt mir etwas. Und wie geht man dann man mit den neueren, bidirektionalen Aktoren um?

Bonusfrage: Gibt es eine Möglichkeit, irgendeine Form von remote teach-in in FHEM+TCM300 auszulösen? Das können nämlich schon ein paar meiner Aktoren und es wäre definitiv komfortabler, als jedesmal in die Dosen hinein zu müssen.

lg

[klaus.schauer]

Ah, meine Herangehensweise war wohl die falsche ...

FHEM legt ja automatisch nur jeden Lichtschalter als eigenes Gerät an, und versucht dann, dessen Status zu verfolgen. Das hat mit den Aktoren, die daran gekoppelt sind, a priori ja noch gar nichts zu tun ... Es ist ganz logisch, Aktoren und Schalter getrennt zu definieren und dann FHEM beizubringen, wie sie verknüpft sind -- also eh ähnlich wie in dem Garagentor-Beispiel --, aber wie definiert man am besten den Aktor?


Die Def. als fiktiver zusätzlicher Schalter kommt mir etwas sehr behelfsmässig vor, und ich wüsste auch nicht, welche ID ich vergeben sollte. (Meine einfachen unidirektionalen Aktoren senden keine Bestätigung o. ä.) Wahrscheinlich könnte ich einfach eine ID "erfinden", aber das widerstrebt mir etwas. Und wie geht man dann man mit den neueren, bidirektionalen Aktoren um?

Die Aktoren sollten in Fhem aufgenommen werden:
-unidirektionale Aktoren: 1. Aktor Device mit einer Fhem SenderID manuell in Fhem anlegen, 2. Fhem per teach-in am Aktor anlernen.

-bidirektionale Aktoren: 1. Senden von Quittungstelegrammen am Aktor einschalten und Fhem legt das Device mit dem ersten empfangenen Datentelegramm automatisch an 2. Über attr subDef Fhem SenderID eintragen und Fhem per teach-in am Aktor anlernen.

Bonusfrage: Gibt es eine Möglichkeit, irgendeine Form von remote teach-in in FHEM+TCM300 auszulösen? Das können nämlich schon ein paar meiner Aktoren und es wäre definitiv komfortabler, als jedesmal in die Dosen hinein zu müssen.

- geht nicht, da TCM nur IDs sendet, die aus dem eigenen Adressbereich sind (BaseID ... BaseID + 127)

[fallenguru]

Die Aktoren sollten in Fhem aufgenommen werden:
-unidirektionale Aktoren: 1. Aktor Device mit einer Fhem SenderID manuell in Fhem anlegen, 2. Fhem per teach-in am Aktor anlernen.

Ok. Das habe ich effektiv eh schon so gemacht. Aber damit legt man ja genau genommen nicht den Aktor an, sondern lernt einen der virtuellen Schalter des TCM auf den Aktor ein. Da Problem damit ist, dass die Aktoren ja parallel auch noch von (teils mehreren) Wandsendern (und einem zweiten TCM) geschaltet werden. Diese Schaltvorgänge kann ich zwar per notify in Fhem verfolgen -- aber was tun mit der Information? Angenommen ein Aktor ist als a1 an den TCM/Fhem angelernt. Wenn ich dann für jedes Schaltereignis, das diesen Aktor betrifft, ein notify anlege und damit set a1 neuer_Status auslöse, damit der Zustand stimmt, wird der Aktor überflüssigerweise noch einmal geschaltet. Von daher die Idee, wirklich für den Aktor an sich ein Gerät anzulegen, das quasi nur noch dazu dient, den aktuellen Status zu halten.
Zwischendurch hatte ich überlegt, einfach einen weiteren EnOcean-Schalter mit der ID des Aktors anzulegen, denn auch rein passive EnOcean-Geräte scheinen eine zu haben. Leider steht sie bei meinen UP-Aktoren auf der Hinterseite und bei den Zwischensteckern gar nicht drauf. Bliebe, eine EnOceanID zu "erfinden", aber das ginge nur dann sauber, wenn es eine Art reservierten Bereich für private / Test-ID gäbe und auf die Schnelle habe ich nichts gefunden ... Ein dummy pro Aktor? Hmm ...

[remote teach-in auslösen] geht nicht, da TCM nur IDs sendet, die aus dem eigenen Adressbereich sind (BaseID ... BaseID + 127)

Schade, ich hatte gehofft, dass man über Query ID und Konsorten Geräte pauschal in einen Lernmodus setzen könnte. Das ist das Einzige, was an EnOcean nervt - jedes Mal, wenn's was zum Umprogrammieren gibt, wieder in die Dose ...

[fallenguru]

So, hier meine aktuelle Lösung für die Einbindung von vorhandenen direkt angelernten (Funktion "Eintastfunktion") Doppelwippen- / Vierfachtastern:

* Für jeden (passiven) Aktor in Fhem einen EnOcean-switch definiert, mit einer für das TCM gültigen Sender-ID. Dieses Gerät repräsentiert gleichzeitig den Aktor und den virtuellen Schalter, mit dem ihn Fhem bzw. das TCM steuert.
* 99_myUtils.pm angelegt, mit folgender an UntoggleDirect / UntoggleIndirect angelehnten Funktion:

Code Auswählen Erweitern


sub ToggleState($)
{
 my ($obj) = shift;
 Log 4, "ToggleState($obj)";
 if (Value($obj) eq "on") {fhem ("setstate ".$obj." off")}
 elsif (Value($obj) eq "off"){fhem ("setstate ".$obj." on")}
 else {Log 3, "Do not know how to toggle $obj!"}
}

* Für jede in "Eintastfunktion" belegte Taste ein notify angelegt, z. B.:

Code Auswählen Erweitern

define Notify_s_Schalter_BI notify s_Schalter.BI {ToggleState("a_Aktor")}
Auf die Weise bekommt Fhem auch "fremde" Schaltvorgänge mit. Das wird natürlich hin und wieder out of sync gehen, wenn der Aktor ein Telegramm mitbekommt und Fhem nicht (oder umgekehrt). Da sehe ich ohne bidirektionale Aktoren aber keinen Weg vorbei.

[fallenguru]

Die o. a. Lösung hat in meiner konkreten Installation folgende Nachteile:

1) Nach einem "fremden" Schaltvorgang funktioniert die Umschaltung über Fhem nicht mehr, man muss immer erst einmal hin- und herschalten, bis es wieder greift.
Das ließ sich nach stundenlangem Herumgewurschtel [herausEDITiert] schliesslich mit switchMode=pushbutton für alle Aktoren beheben ... (Aus reinem Interesse: Warum ist "switch" Standard und was hat das für Vorteile?)

2) Damit "fremde" Schaltvorgänge in der Weboberfläche aufscheinen, muss man die Seite händisch refreshen.
3) notifys am Aktor triggern nur, wenn Fhem schaltet.
Dagegen habe ich schließlich ToggleState wie folgt modifiziert:

Code Auswählen Erweitern


sub ToggleState($)
{
 my ($obj) = shift;
 my @a;
 Log 4, "ToggleState($obj)";
 if (Value($obj) eq "on") { @a = (undef, "off") }
 elsif (Value($obj) eq "off") { @a = (undef, "on") }
 else { Log 3, "Do not know how to toggle $obj!"; return }
 @a = ReplaceEventMap($obj, \@a, 0);
 fhem ("setreading ".$obj." state ".@a[1])
}

Wenn jemandem einfällt, wie man das "schöner" machen kann, bitte melden ...