Langen Tastendruck bei HM-PBI-4-FM (Tasterschnittstelle 4fach) auswerten

[martinp876]

HAllo Arthur

kann es sein, dass der PBI und die HM-RC-4 von Readings noch nicht soweit implementiert sind wie z.B. der HM-SEC-MDIR?
Kann man das in Angriff nehmen - kann da gerne unterstützen.

kann sein - aber was fehlt dir? Dann koennen wir es einbauen

Gruss
Martin

[snoop]

Hallo Martin,

mir fehlt zwar die intuitive Hanhabung - ist ein anderes Thema - aber die Möglichkeit Einstellungen vorzunhemen wie bei HM-SEC-MDIR wär schon mal ein Anfang.
Vorschlag:
Folgende Readings wären interessant:

- longPress
- LedColor (longPress/shortPress) - sofern möglich
- was sonst noch möglich ist... meintetwegen kann ich auch das eine oder andere Geräte zur Verfügung stellen (zusenden kann den PBI für ein paar Tage/Wochen entbähren)
- etc.

Viele Grüße
Arthur

[snoop]

Hallo Martin,

kleine Spezifikation: "zur Verfügung stellen!" allerdings nur beschränkt (an dich) :o).

Sorry - also noch einmal zu den Readings konkret:

- longPress -> klar nur bei HM-RC-4 (macht bei PBI keinen Sinn? - vielleicht sogar möglich, da beide Farben vorhanden - interessanter eher bei HM-RC-4)(Nur am rande laut Doku: "Montageart/ausserdem": http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen) besagt die Namenskonvention
B = schwarz
SW = weiss
ich habe beide -> bei B alles ok - das Gerät heißt "HM-RC-4-B" funktioniert soweit bei SW müsste es aber "HM-RC-4-SW" heißen - dem ist aber nicht so es heiß einfach nur HM-RC-4. Nur so am Rande... kannst du das fixen/bzw. soll man das fixen oder ist das so richtig? So weiter...
- LedColor (longPress/shortPress) - sofern möglich
- KeyPressInterval?
- was sonst noch möglich ist... kann das nicht abschätzen , muss du(einer) mir vielleciht sagen was ich machen muss , um heruaszufinden was geht - ich kann auch das eine oder andere Geräte zur Verfügung stellen (kann z.B. den PBI und HM-RC-4 für ein paar Tage/eher Wochen für die Implementierung entbähren)
- etc.

Viele Grüße
Arthur

[martinp876]

Hallo Arthur

- longPress -> klar nur bei HM-RC-4 (macht bei PBI keinen Sinn? - vielleicht sogar möglich, da beide Farben vorhanden - interessanter eher bei HM-RC-4)(Nur am rande laut Doku: "Montageart/ausserdem": http://www.fhemwiki.de/wiki/HomeMatic_Namen_verstehen) besagt die Namenskonvention
B = schwarz
SW = weiss

nach XML hiessr das Device mit code 008 einfach nur RC-4. ein RC-4-B gibt es nicht. Die Konvention ist  nicht von HM sondern nur eine Interpretation. Ich wurde gerne beim eQ3 Namen bleiben

So weiter...
- LedColor (longPress/shortPress) - sofern möglich

redest du von der LED an der Fernbedienung? Diese LED Farben sind nicht zu steuern. Die hat HM festgelegt und zeigen uebertragungsfehler an. Wenn die RC gepeert ist und alle peers korrekt antworten kommt gruen, wenn die taste nicht gepeert ist orange, bei Fehlern rot. Das sollt alles schon funktionieren

- KeyPressInterval?

du kannst longPress einstellen sowie dblPress - oder nicht? welchen subtype hat deine RC?

- was sonst noch möglich ist... kann das nicht abschätzen , muss du(einer) mir vielleciht sagen was ich machen muss , um heruaszufinden was geht - ich kann auch das eine oder andere Geräte zur Verfügung stellen (kann z.B. den PBI und HM-RC-4 für ein paar Tage/eher Wochen für die Implementierung entbähren)
- etc.

ich nehme an du hast schon regList auf device und channel angewendet? Die Register sind eigentlich alle drin.

auch der mdir sollte komplett sein. der sen und der sec (ausser AES - da habe ich aktuell keine Ahnung)

Im allgemeinen haben remotes extrem wenig funktionen - Funktionen sind eigentlich in den Aktoren beheimatet.
Sensoren haben ein paar parameter.

Aktuell sehe ich nicht, was fehlt.

Gruss
Martin

[snoop]

Hallo Martin,

bin ein wenig verwirrt - muss mir das genaze mal in ruhe anschauen - scheinbar verstehe ich das System noch nicht ganz.
Ok, longPress sowie dblPress sehe ich nun, jedoch nicht in den Teadings wie bei dem Bewegungsmelder - aus rgendeinen Grund kann ich aber die werde nicht ändern.

set Fernbedienung_4_1 getConfig
set Fernbedienung_4_1 regSet dblPress 1.5
set Fernbedienung_4_1 longPress 1.8
get Fernbedienung_4_1 regList


#############
list:         register | range              | peer     | description
   0: intKeyVisib      |   0 to 1           |          | visibility of internal channel options:visib,invisib
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   1: dblPress         |   0 to 1.5s        |          | time to detect double press
   1: longPress        |   0 to 1.8s        |          | time to detect key long press
   4: expectAES        |   0 to 1           | required | expect AES options:on,off
   4: peerNeedsBurst   |   0 to 1           | required | peer expects burst options:on,off
##############

Medlung:
Unknown argument longPress, choose one of actiondetect clear devicepair getConfig getRegRaw getdevicepair getpair pair peerBulk raw regBulk regRaw regSet reset sign statusRequest unpair virtual


Sonst habe ich ein Screenshot beigefügt.
Viele Grüße
Arthur

P.S: Ob, ich nun mit den 1.8 Sec auskomme, um mein Vorhaben umszusetzen muss ich dann mal schauen - kann man auch höhere werte als die 1,8 sec einstellen?

[Zorin]

Hallo,

jetzt muß ich mich auch mal wieder "reindrängeln".

Ich denke, ich habe ein ähnliches Anliegen wie snoop:
Ich will dem 4-fach Taster (HM-PBI-4-FM) in meinem Fall, soviele Funktionen wie möglich entlocken.

Im Detail (und in Abweichung zu snoop) geht es mir um folgendes:
1) Die Short(-Tastendrücke) sollen immer direkt mit eienm Aktor gepairt sein, sozusagen die "Basisfunktionalität" auch ohne FHEM.
 -Erledigt

2) Die Long(-Tastendrücke) sind bei mir das "FHEM-Sahnehäubchen" und führen Spezialaktionen aus, z.B. bestimmte Lampen zu bestimmten Zeitpunkten.
 Das Notify habe ich (dank diese Threads) soweit fertig. Nur leider geht immernoch die "Basisfunktionalität" parallel mit an (d.h. bei "Long" wird auch das "Short" mit ausgeführt.
 Kann man das irgendwie vermeiden ?
 Ich habe schon einiges mit getConfig, reg all etc. rumgespielt und bekomme da folgendes für den Kanal:

RegL_01:
   04:10 08:00 09:00 00:00   2013-01-21 11:03:24
RegL_04:va_SchalterBZ1.CH2_Btn1
   01:00 00:00

fhem> get BZ.Schalter1.CH2 regList
list:         register | range                | peer     | description

Danke schonmal für die Hilfe

[martinp876]

Hallo Zusammen

1)
longPress ist ein register, kein Kommando
also
set Fernbedienung_4_1 regSet longPress 1.8
hast du bei dblPress doch auch gemacht.

das ganze wird bei den meisten Remotes erst ausgeführt, wenn einmal anlernen gedrückt wurde.

2)
a) pairen kann man nur channels, nicht deren Funktionen. Also einen Button oder Sensor mit einem Aktor-channel. Nur short oder long gehen nicht
b) remotes senden nur einen trigger. Short /long, evtl noch einen level (nur manche Sensoren). Aktionen werden NIE von einer remote festgelegt sondern IMMER vom empfangenden Aktor channel
c) du kannst im Aktor festlegen was zu tun ist. Wenn er bei 'long' nichts tun soll, sag es ihm. Viele habe ein lgActionType... und shActionType..  der lässt sich meist auch auf "off" setzen. Einfach mal schauen, was dein Aktor können sollte
d) unabhängig was du gepeert hast kannst du IMMER Aktionen zusaetzlich über FHEM definieren

Gruss
Martin

[snoop]

Hallo Martin,

mit 1) bin wohl ich gemeint:
Ja, sorry ist mir auch schon aufgefallen - DANKE.

(falsch) set Fernbedienung_4_1 longPress 1.8
(richtig)set Fernbedienung_4_1 regSet longPress 1.8
Anlerntaste für die Übertragung der CMD queue -> "KLAR".

Bin schon eine Weile am testen - scheint so als wenn es funktionieren würde, zumindest das was ich vor habe.

Folgende Fragen sind bei den Tests aufgekommen:
   Ich bin ein wenig verunsichert, welche Vorteile ich bei einem virtuellen Adapter den ich mit PBI/Remote gepairt habe.
   Für einen Leihen: - Pro: ACK wird grün gemeldet/signalisiert
                     - Kontra: Kaskade über den Virtual Adapter -> Performance?
                     - Mehr coding Aufwand
   Hast du eine Empfehlung: Wie gesagt - mein Anwendungsfall ist ein Einfamilienhaus (Keine wirklich kritischen Anwendungsfälle und      
   Komponenten halten sich in Rahmen (ein/zwei Hände voll)), Komplexität (Includes/Definitions = gering bis mittel)

Der Vollständigkeitshalber bin ich dir auf deine Anmerkung noch ein paar Antworten schuldig (Sorry, habe grade etwas mehr Zeit):

- Die Einschränkungen bei Remotes sind mir nun klar.
- Namenskovnention: ok, verstanden! Gibt es noch weitere Komponenten die eine SW&B Unterscheidung haben: Bei Remote gibt es nur RC-4 (White) RC-4-B (Black) mMn müsste dann die SW Unterschgeidung raus - Bsp: Ein HM-SEC-MDIR ist auch weiss und wird nicht explizit gekennzeichnet. Ich finde das verwirrt - will da nicht drauf rum reiten - ist nur eine Anmerkung - habe im Moment andere Herausforderungen als mich mit den Namen (Schall und Rauch) zu beschäftigen.
- MDIR ist (nachdem ich mich ein wenig damit beschäftigt habe) sehr gut implementiert (obwohl ich auch hier auch ein paar Fragen/Anregungen habe - da komme ich aber in ein paar Tagen/Woche drauf zurück, wenn ich Zeit habe). Meine Frage dazu ist - warum ist(vielleicht lässt sich das technisch nicht) der PBI und Remote mit den Registern (in Readings) nicht implementiert. Zeitmangel? geht nicht? Ich finde, dass es einfacher/schöne/übersichtlicher ist das direkt im Device zu sehen - daher zvor die Frage, ob "PBI und Remote noch nicht vollständig implementiert ist/sind?!!"

Zu 2)
da ich auch ein PBI habe hätte ich auch noch ein paar Fragen - schaffe es aber Zeitlich nicht - vielleicht die Tage.

"Dake" und bis Bald/die Tage.

Viele Grüße
Arthur

[martinp876]

Arthur,

ein virtueller Aktor bietet nur bedingt funktionen, wie du richtig erkannt hast. Der Aufwand zum Implementieren war ueberschaubar und mache wollen es.

Anwendung ist wohl in erster linie
- gruene LED => Bestaetigung  des Kommandos. Komplexe ablaeufe sind machbar ueber die Zentrale und man hat die LED
- simulationen und tests moeglich

Ich wuerde immer ein direktes peering bevorzugen, wenn es die Funktion  der komponenten hergibt.
>weniger traffic in der luft
>Ausfallsicherheit

es gibt nochmehr komponenten mit farben (RC12, RC19,...). Ich verwende die Bezeichnung aus XML, wie gesagt. Funktional ist es kein unterscheid - schade dass HM dies ueberhaupt im code unterscheidet...

Darstellung der Register in readings:
nein, kein Zeitmangle. Ich kann die Darstellung fuer jeden wert sofort aendern - ist nur ein Tabelleneintrag.
Das Problem ist, den User nicht mit werten zu ueberfahren. Ich wollte nur operationell wichtige Werte direkt anzeigen. Mittlerweile gibt es einen expert mode von Rudi, damit koennte man etwas steuern... aber damit bin ich noch nicht glücklich - da muss ich alle Register umbenennen....

zum PBI: gut - so viel Zeit habe ich ja auch nicht ;-)
Aber Frage nur... damit wir es stabil bekommen

Gruss
Martin

[snoop]

Hallo zusammen,

ok, verstanden, direktes peering ist zu bevorzugen - check! - Sieht die Welt für mich zwar nun anders aus als ich urprünglich dachte - ja, macht auch Sinn, die wichtigen Dinge sollen auch "nur mit Strom funktionieren-> sofern welches da ist" Die FritzBox läuft erstaunlich gut - nach eine dekade Erfahrung. Aber mit FHEM habe ich seid ein paar Wochen Kontakt (positiv).
Nun die ultimative Frage: Ich versuche die Frage von Zorin, anders zu formulieren - interessiert mich auch -
"Um:
- weniger traffic und viel wichtiger
- Ausfallsicherheit (Falls FHEM nicht verfügbar ist - Router/andere FHEM fähige Komponetenten "rauchen ab")
zu gewährleisten.
!!! Ist es möglich ein gepeete(n) Aktor(en) so zu konfigurieren, dass es erkennt, dass FHEM nicht da ist nur die peer Aktion ausführen soll! Ist FHEM hingegen verfügbr, sollen zuerst die FHEM notify's geprüft und zuerst ausgeführt werden. Also eine Art Priorisierung. !!!
Ich merke die Fragestellung ist auch nicht ganz korrekt, hoffe jedoch, dass dies verständlich ist - ich befürchte auch, dass ich auch schon die Antwort kenne (Daher auch keine Rückmeldung von Zorin dazu - er hat's verstanden) :o(

Danke und Viele Grüße
Arthur

[Martin Thomas Schrott]

Hallo Arthur,

>- MDIR ist (nachdem ich mich ein wenig damit beschäftigt habe) sehr gut implementiert
>(obwohl ich auch hier auch ein paar Fragen/Anregungen habe - da komme ich aber in
>ein paar Tagen/Woche drauf zurück, wenn ich Zeit habe).

Bitte frag doch gleich jetzt und hier, ich bin gerade noch am Testen der Bewegungsmelder und kann dann deine Anregungen / Wünsche gleich berücksichtigen. (Anmerkung: Die Beschreibungen im command ref für die md sind momentan vermutlich nicht ganz korrekt, aber teilweise schon korregiert für ein update)
Liebe Grüße
Martin

[snoop]

Hallo Martin,

danke für das Anbgebot/den Hinweis - ich habe auch ein paar von den Bewegungsmelder hier stehen und habe einige Anforderungen/Ideen was ich damit machen möchte - mangels Zeit komme ich aber nicht dazu die Komponenten final einzurichten.
Aus diesem Grund kann ich derzeit und kurzfristig keine sinvollen/verwertbaren Input liefern.

Danke und viele Grüße
Arthur

P.S: Nur so am Rande - was mir nur aufgefallen ist, ist das ich mit der Reaktionszeit des MDIRs nicht ganz zufrieden bin (dazu gibt es bereits einige Diskussionen) - kann im Moment aber nicht abschätzen, ob das an der definierten Konfiguration liegt und ob dies bei meinem Anwendungsfall zum Tragen kommt - dazu wollte ich noch ein paar Tests durchführen.

[Martin Thomas Schrott]

Hallo!
>der Reaktionszeit
>des MDIRs nicht ganz zufrieden

Meinst du wirklich die Reaktionszeit oder meinst du das delay bis er wieder reagiert?

Das Delay lässt sich einstellen, die Sekunden Angaben in FHEM stimmen derzeit aber noch nicht. Ich bin noch am austesten, wie lange die Verzögerungen wirklich sind.
Die normale Reaktionszeit ist eigentlich kaum merkbar. Also er reagiert sofort auf Bewegungen, außer du hast die Einstellungen geändert. Hier sind die Werte von evtFltr* zuständig. Wenn du diese auf 1 lässt ist alles flott.

Nähere details zu den Einstellungen gibt es im command ref bzw. bei regList sobald ich meine Tests abgeschlossen habe.

Liebe Grüße
Martin

[snoop]

Hallo Martin,

es ging - meine ich - um das Thema "minInterval" (ist schon ein paar Wochen her).
Aber wie gesagt da möchte ich mir noch ein wenig Zeit nehmen und mich im detail einarbeiten.

Viele Grüße
Arthur

P.S.: ;o) Falls du Zeit hast das zu verifizieren: Die möglichen Werte für "Wahl des Sendeabstandes - dynamisch" soll ja bei 15,20,60,120 Sekunden liegen - wenn ich als Wert 0 eingebe erscheint im Reading (nach Abarbeitung der CMDs) R-minInterval=set_0 - ich weiß nicht ob das so richtig ist? Wie gesagt nur wenn du Zeit hast?! Ferner habe ich noch nicht verstanden (sorry bin noch dran mir die Infos zu erlesen) warum bei dem MDIR die Readings mit R-* anfangen und bei den anderen Komponenten kein R-* davor steht? Idee Vorschlag wäre das einheitlich zu handhaben - wie gesagt es kann ja sein das das erstmal gewollt ist?

[martinp876]

Die möglichen Werte für "Wahl des Sendeabstandes - dynamisch" soll ja bei 15,20,60,120 Sekunden liegen

hat sich geaendert. Martin hat die Werte ausgemessen. Es liegt jetzt bei 15,30...240

- wenn ich als Wert 0 eingebe erscheint im Reading (nach Abarbeitung der CMDs) R-minInterval=set_0 - ich weiß nicht ob das so richtig ist?

das ist korrekt. Ich bin vielleicht ein bisschen paranoid  - aber ich will den Unterschied zwischen abgeschickt und gelesen sehen. also ein "set_" bedeutet immer dass ein kommando in Bearbeitung ist. Kann in der queue haengen oder schon gesendet sein... Wenn eine explizite bestaetigung kommt verschwindet das set_. Also beim Licht einschalten kommt ein set_on und sobald das ack da ist wird auf "on" gesetzt.
Bei Registern kann ich erst mit Sicherheit das 'set_' zurücknehmen wenn der Wert wieder gelesen wurde. Also nach getConfig beispielsweise.