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

[snoop]

Hallo Martin,

ich hatte nun ein wenig Zeit mein Vorhaben mit der Fernbedienung (HM-RC-4) zu implementieren und zu testen.
Das ganze funktioniert so wie ich mir das vorstelle, bin jedoch auf ein Problem gestossen und Zwar:

Meine fhem.cfg beinhaltet diverse includes (Autocreate.cfg, Fernbedienungen.cfg etc.) bzw. die gesamte fhem config basiert auf cfg Dateien. Jetzt habe ich das Problem das meine HM-RC-4, die mit einem virtuellen Adapter gepeert ist, nach einen FHEM restart (vorher werden alle meine cfg inkl. der fhem.cfg hineinkopiert) die peerinformationen verliert und ich die Fernbedieung erneut peeren muss.

Kannst du mir sagen wie ich peering Informationen deklarieren kann sodass diese auch einen FHEM Neustart überleben.

Vielen Dank.
Grüße
Arthur

[martinp876]

Artur,

dein RC verliert das peering hoffentlich nicht, sondern nur die "kopie" die in FHEM gehalten wird.

Ich gehe also davon aus, dass du die Werte in FHEM weiter sehen willst und dir ein getConfig nach einem neustart zu bloed ist (Fernbedienungen kann man ja nicht automatisch Fragen...)

Die Peers stehen im Attribut "peerIDs" - und zwar als 8 stellige IDs (4-stellig hex, also HMID + channelNo)

Die lesbare Form "peerList" in readings wird daraus generiert.

Wo du es so sagst - ich denke peerList wird nach dem restart nicht neu generiert. Das muss ich einmal einbauen - ist nicht ganz straight Forward.

Gruss
Martin

[Martin Thomas Schrott]

@Martin
Danke, jetzt versteh ich auch warum die list bei mir immer auf cleared steht ;-)
lG
Martin

[snoop]

Hallo Martin,
Genau so ist es, die peering Informationen scheinen noch da zu sei.
Der vituelle Aktor/Channel hat nur keine Informationen mehr.

Was mich ein wenig wundert ist - warum funktioniert mein notify noch - bedient sich dieser der Informationen aus dem HMLAN?

Viele Grüße
Arthur

[martinp876]

Hallo Artur

a) ich werde das Reading 'peerList' nach Neustart auf den Stand des Attributes peerIDs angleichen. Das wird mit etwas Verzoegerung datgestellt, da es vom "Feature" autoReadReg mitbedient wird.

b) das Handling attr->peerIDs und readings->peerList habe aus verscheidenen Gruenden so implementiert.
- Attribute werden besser 'gesichert' (bei save beispielsweise) also readings
- programmiertechnisch sind IDs das mass der Dinge, Usertechnisch die Namen
- das Konzept solle 'hardened' gegen renames aller Art sein - so auch renames im config-file

=> die peerList ist eigentlich nur eine "Darstellung" fuer den User. Hier ist alles "human-readable". Programmtechnische Nutzung dieses eintrages ist aufwaendig, umstaendlich und unsicher(er).
=> die eigentliche Info ist in peerIDs, wird bei save mitgespeichert und bleibt somit erhalten
??> wenn punkt a) erledigt ist (heute Abend?) sollte die (hoffentliche) letzte Luecke geschlossen sein - peerIDs und peerList sind dann inhaltlich identisch

c) notifies
- keine Ahnung, wie dein notify aussieht...
- dein virtueller channel aggiert als Aktor oder Button?
- gepeerte virtuelle Channels bekommen immer ihre Peers im Attribut peerIDs eingetragen. Wenn du ohne save restartest ist IMMER alles was du virtuell gemacht hast weg -> und mehr... eben alles was in FHEM ist und nicht in HM-devices
==> ich gehe also davon aus, dass du einen Stand gesaved hattest, und die peerIDs somit nach Neustart immer wieder gesetzt werden (die peerList -noch- nicht)
==> damit sollte alles funktionieren: Nachrichten werden immer aufgrund der ID gesendet/empfangen/geparst/notifiziet und die entsprechenden events repostet.

d) grundsaetzlich zu Namen und HMId in CUL_HM
wie oben erwaehnt funktioniert das System eigentlich nur auf Basis der ID. Namen sind programmtechnisch hinderlich/stoerend/fehleranfaellig und dienen nur dem Zweck dem User das Leben zu erleichtern (mir auch...).
Ein nicht unerheblicher Teil des Codes besteht darin diese zu konvertieren fuer devices, channels, device ohne channel, virtuelle-HM channel, virtuelle-FHEMentities

e) ich empfehle nach dieser Erklaerung nicht, das Attribut "peerIDs" zu editieren. Kann man natuerlich, sollte aber wissen, was man tut.

So viel getippt - hoffentlich etwas Hintergrund verbreitet.
=> wenn du konkrete Fragen hast muss du die notofies und die attribute deiner virtuellen Entity mit der Frage posten

Gruss
Martin

[snoop]

Hallo Martin,

c) notifies
- keine Ahnung, wie dein notify aussieht...
- dein virtueller channel aggiert als Aktor oder Button?
- gepeerte virtuelle Channels bekommen immer ihre Peers im Attribut peerIDs eingetragen. Wenn du ohne save restartest ist IMMER alles was du virtuell gemacht hast weg -> und mehr... eben alles was in FHEM ist und nicht in HM-devices
==> ich gehe also davon aus, dass du einen Stand gesaved hattest, und die peerIDs somit nach Neustart immer wieder gesetzt werden (die peerList -noch- nicht)
==> damit sollte alles funktionieren: Nachrichten werden immer aufgrund der ID gesendet/empfangen/geparst/notifiziet und die entsprechenden events repostet.

=> wenn du konkrete Fragen hast muss du die notofies und die attribute deiner virtuellen Entity mit der Frage posten

Gruss
Martin

1) Meine notifys sehen wie folgt aus:
define Fernbedienung_4_1_Btn_01_on notify .*Fernbedienung_4_1_Btn_01.* {if(ReadingsVal("vaRemote_4_1_Btn_01","virtActTrigType","") eq "short_Release") {fhem "set GA_Tor_Sw_1_01 on"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 on"}}
define Fernbedienung_4_1_Btn_02_off notify .*Fernbedienung_4_1_Btn_02.* {if(ReadingsVal("vaRemote_4_1_Btn_02","virtActTrigType","") eq "short_Release") {fhem "set GA_Tor_Sw_1_01 off"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 off"}}
define Fernbedienung_4_1_Btn_03_on notify .*Fernbedienung_4_1_Btn_03.* {if(ReadingsVal("vaRemote_4_1_Btn_03","virtActTrigType","") eq "short_Release") {fhem "set GA_Beleuchtung_Sw_1_02 on"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 on"}}
define Fernbedienung_4_1_Btn_04_off notify .*Fernbedienung_4_1_Btn_04.* {if(ReadingsVal("vaRemote_4_1_Btn_04","virtActTrigType","") eq "short_Release") {fhem "set GA_Beleuchtung_Sw_1_02 off"} else {fhem "set GA_Beleuchtung_Sw_1_02,GA_Tor_Sw_1_01 off"}}

2) Mein virtueller channel aggiert als Button?
define vaRemote_4_1 CUL_HM 200000
set vaRemote_4_1 virtual 1
set vaRemote_4_1 virtual 2
set vaRemote_4_1 virtual 3
set vaRemote_4_1 virtual 4
rename vaRemote_4_1_Btn1 vaRemote_4_1_Btn_01
rename vaRemote_4_1_Btn2 vaRemote_4_1_Btn_02
rename vaRemote_4_1_Btn3 vaRemote_4_1_Btn_03
rename vaRemote_4_1_Btn4 vaRemote_4_1_Btn_04

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single
set Fernbedienung_4_1_Btn_02 devicepair 1 vaRemote_4_1_Btn_02 single
set Fernbedienung_4_1_Btn_03 devicepair 2 vaRemote_4_1_Btn_03 single
set Fernbedienung_4_1_Btn_04 devicepair 3 vaRemote_4_1_Btn_04 single

Wie der virtuelle Button nach einen FHEM Neustasrt aussieht kannst du aus dem angehängtem Screenshot entnehmen.

Konkrete Frage habe ich nicht, mich hat nur gewundert, dass trotz der fehlenden peerings (bzw. der fehlenden Informationen) der notify funktioniert hat, obwohl das hier "{if(ReadingsVal("vaRemote_4_1_Btn_03","virtActTrigType","") eq "short_Release")..." hätte nicht funktionieren können, da der "vaRemote_4_1_Btn_03" ein virtueller Button ist der den ReadingsVal - virtActTrigType garnicht hat (siehe screenshot).

Ansonsten warte ich auf das was da kommt. ;o)
Viele Grüße
Arthur

[martinp876]

Hallo Artur,

das mit deinen Settings sollte so funktionieren (tut es ja auch nach  habe ich verstanden)

Ich kommentiere einfach einmal deine Einstellungen. Du kannst es auch ignorieren, kein Problem:

Du hast eine FB mit 4 Buttons, ein Tor und ein Licht.
Dein virtual aggiert als Aktor: Die FB sendet an den VirtualAktor und will eine Antwort.
FHEM beobachtet das ganze und triggert (ueber die Notifies) das Tor und das Licht.

Ich nehme an, dass das devicepair nur einmal ausgeführt wird und nicht im config steht. also entweder
- set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single actor
=> damit wird kein Kommando in die command-queue der FB geschrieben - ist unschön
oder
- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.

Das Ganze funktioniert gut für short_Release.

Bei 'Long' passiert folgendes:
so lange du drückst werden trigger von der FB geschickt, alle 0,4sec, alle mit 'long'. Somit wird unnötig zu den Aktoren (tor und Licht) mehrfach 'auf' oder 'zu' gesendet. Das solltest du vermeiden. Du solltest somit nur reagieren wenn ein 'Release' im reading ist - oder das notify umstrukturieren.


---------------------------------
Mein Ansatz waere ein direktes peeren (ok - nicht jedermanns Sache, aber eigentlich HM Philosophy, so meine ich). Das spart alle virtuellen Aktoren. koennte so aussehen (tipfehler vorbehalten):

#---peer 4 buttons zum tor, je 2 auf und 2 zu---
set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Tor_Sw_1_01
set Fernbedienung_4_1_Btn_03 devicepair 0 GA_Tor_Sw_1_01
#---peer 4 buttons zum Licht, je 2 auf und 2 zu---
set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Beleuchtung_Sw_1_02
set Fernbedienung_4_1_Btn_03 devicepair 0 GA_Beleuchtung_Sw_1_02
#---keine reaktion beim Tor fuer short Buttons 3 oder 4---
set GA_Tor_Sw_1_01 regSet shActionType off Fernbedienung_4_1_Btn_03
set GA_Tor_Sw_1_01 regSet shActionType off Fernbedienung_4_1_Btn_04
#---keine reaktion beim Tor fuer short Buttons 1 oder 2---
set GA_Beleuchtung_Sw_1_02 regSet shActionType off Fernbedienung_4_1_Btn_01
set GA_Beleuchtung_Sw_1_02 regSet shActionType off Fernbedienung_4_1_Btn_02

# nur eine reaktion auf einen longPress (kann man evtl auch weglassen
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_01
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_02
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_03
set GA_Tor_Sw_1_01 regSet lgMultiExec off Fernbedienung_4_1_Btn_04
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_01
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_02
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_03
set GA_Beleuchtung_Sw_1_02 regSet lgMultiExec off Fernbedienung_4_1_Btn_04

# Und nicht vergessen die FM zu entpaaren, aufraeumen
set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote
set Fernbedienung_4_1_Btn_03 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote
delete vaRemote_4_1

==> jetzt anlernen an der remote drücken - dann werden alle peers gesetzt und gelöscht - an der FB

dann noch (je nachdem ob es eines oder 2 devices sind)
attr <devicetor> autoReadReg 1
attr <devicelicht> autoReadReg 1

wenn du das durch hast funktioniert alles ohne die Zentrale, aber alles sichtbar sein

Gruss
Martin

[snoop]

Hallo Martin,

ja, das Thema direktes peeren zu FHEM Variante hatten wir schon diskutiert.
Die Variante mir dem virtuellen Aktor gefällt mir wenn ich erhlich bin nicht so. Ich habe 4 Fernbedienungen da kommen so einige virtuelle Komponenten ins Spiel (4 Aktoren mit je 4 Channels) was einiges an komplexität mit sich bringt :o( und ich muss bei jedem FHEM Update bangen, dass etwas davon plötzlich nicht mehr funktioniert - von daher ist der HM Ansatz grundsätlich ok.

Danke für die ausführliche Erklärung - die Variante wie du die Komponenten konfigurierst, insbesondere "segSet lgMultiExec" und "regSet shActionType" ist mir neu - eröffnet aber auch neue Möglichkeiten - ich teste das ganze.

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote

Habe ich auch schon gesucht und nicht gefunden - also was dazugelernt.

Ich nehme an, dass das devicepair nur einmal ausgeführt wird und nicht im config steht. also entweder
- set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 single actor
=> damit wird kein Kommando in die command-queue der FB geschrieben - ist unschön
oder

Ja, richtig nur einmal.

- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.

Kann ich ein save aus einer Konfig heraus triggern? Wie? Einfach nur save?

Bei 'Long' passiert folgendes:
so lange du drückst werden trigger von der FB geschickt, alle 0,4sec, alle mit 'long'. Somit wird unnötig zu den Aktoren (tor und Licht) mehrfach 'auf' oder 'zu' gesendet. Das solltest du vermeiden. Du solltest somit nur reagieren wenn ein 'Release' im reading ist - oder das notify umstrukturieren.

Ja, richtig ist mir auch schon aufgefallen.

Abschließend ist noch zu sagen - dass die bisherige Implementierung nur die 1/2 Miete ist, da die Idee ja wie folgt aussieht:

- 3 Aktoren (Switch) je 2 Kanal
- 4 Remotes

1)
Remote#1/2/3/4 Taste1 (short)-> Aktor #1 Kanal 1 on
Remote#1/2/3/4 Taste2 (short)-> Aktor #1 Kanal 2 on
Remote#1/2/3/4 Taste3 (short)-> Aktor #2 Kanal 1 on
Remote#1/2/3/4 Taste4 (short)-> Aktor #2 Kanal 2 on
2)
Remote#1/2/3/4 Taste1 (long): Aktor #1/2 jeweils Kanal 1 und 2 on
Remote#1/2/3/4 Taste2 (long): Aktor #1/2 jeweils Kanal 1 und 2 off
3)
Remote#1/2/3/4 Taste3 (long)-> Aktor #3 Kanal 1 on und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 on
Remote#1/2/3/4 Taste4 (long)-> Aktor #3 Kanal 1 off und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 off

Ich denke/hoffe dass ich mit den Boardmitteln (sprich devicepair) 1) und 2) realisieren kann?!?
Mit FHEM werde ich wohl 3) realisieren?!

Ach ja, longPress habe ich übrigens auf 1.2 sek. gestellt.

So jetzt aber mal testen angesagt.
Danke und Viele Grüße
Arthur

[martinp876]

Hallo Arthur,

insbesondere "segSet lgMultiExec"

das ist kosmetik - bei einem Schalter dessen link nicht auf "toggel" programmiert ist sollte es eigentlich egal sein

set Fernbedienung_4_1_Btn_01 devicepair 0 vaRemote_4_1_Btn_01 dual unset remote

Habe ich auch schon gesucht und nicht gefunden - also was dazugelernt.

oh - sollte im commandref stehen - schlecht erklärt?

- nach den devicepair ein "save". Die vaRemote_4_1_Btn_0x erhalten dann ein Attribut über das peering und gut ist es.
Kann ich ein save aus einer Konfig heraus triggern? Wie? Einfach nur save?

aus der config heraus nicht - macht auch keinen Sinn. Aber aus dem terminalfenster. also wenn du alles eingestellt hast im FHEM dann ein save. Der speichert die aktuellen defines und attribute.
Beachte: natürlich nicht die Einstellungen IN HM, aber quasi alles aus FHEM (auch keine readings, sind ja keine Einstellungen).
HM speichern kannst du mit "get... configSave" - siehe commandref. Somit lassen sich die Einstellungen den HM-devices sichern. ist auch beschrieben, wie du sie wieder einspielen kannst.

- 3 Aktoren (Switch) je 2 Kanal
- 4 Remotes

=> also 6 schalterKanaele
=> also 16 tasten

1)
Remote#1/2/3/4 Taste1 (short)-> Aktor1Kanal1 on
Remote#1/2/3/4 Taste2 (short)-> Aktor1Kanal2 on
Remote#1/2/3/4 Taste3 (short)-> Aktor2Kanal1 on
Remote#1/2/3/4 Taste4 (short)-> Aktor2Kanal2 on
2)
Remote#1/2/3/4 Taste1 (long): Aktor1 Aktor2 jeweils Kanal 1 und 2 on
Remote#1/2/3/4 Taste2 (long): Aktor1 Aktor2 jeweils Kanal 1 und 2 off
3)
Remote#1/2/3/4 Taste3 (long)-> Aktor #3 Kanal 1 on und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 on
Remote#1/2/3/4 Taste4 (long)-> Aktor #3 Kanal 1 off und ggf. abhängig von der Uhrzeit: Aktor #1 Kanal 1, Aktor #3 Kanal 2 off

dann noch ein Versuch:
Beachte die HM defaults im AKTOR:
bei devicepair dual wird ein ein button fuer 'on' und einer für 'off' programmiert
bei devicepair single wird ein ein button fuer 'toggle' programmiert
=> also in deinem Fall immer dual nehmen, das macht weniger Arbeit. Sonst musst du die register im Aktor alle selbst umsetzen.

default ist dual/set/both, es wird immer short und long gesetzt
also erst die Basics fuer Akt1_1:

set rm1_1 devicepair 0 Akt1_1
set rm2_1 devicepair 0 Akt1_1
set rm3_1 devicepair 0 Akt1_1
set rm4_1 devicepair 0 Akt1_1
### jetzt reagiert Akt1_1 auf alle 4 remotes Button 1 UND 2 long UND short
### also short ausschalten fuer Taste 2
set Akt1_1 regSet shActionType off rm1_2
set Akt1_1 regSet shActionType off rm2_2
set Akt1_1 regSet shActionType off rm3_2
set Akt1_1 regSet shActionType off rm4_2
###--- da mit sind erledigt:
### Remote#1/2/3/4 Taste1 (long): Aktor1 Kanal 1 on
### Remote#1/2/3/4 Taste2 (long): Aktor1 Kanal 1 off

Wenn Akt1_2 fertig ist würde ich den kompletten Aktor 1 einmal sichern. Also
set Akt1 getConfig  # liest auch die channels 1 und 2 in einem!
get Akt1 configSave <filname>

Den Punkt3 - speziell das Uhrzeitabhängige schalten - geht nicht direkt aus HM.

Ich denke/hoffe dass ich mit den Boardmitteln (sprich devicepair) 1) und 2) realisieren kann?!?
Mit FHEM werde ich wohl 3) realisieren?!

richtig, jedenfalls den Uhrzeitabhängigen Teil
Gruss
Martin

[snoop]

Hallo Martin,

so, jetzt bin ich an den Punkt angelangt wo ich das ganze aufgebe - drehe mich im Kreis.

Entegen deinen Vorschlag habe ich die Komponenten wie folgt gepairt (!wow! schon erstaunlich welche Verzögerung über FHEM einhergeht - direktpairing ist da schon das was mir zusagen würde):

Ist nur ein Beispiel zum testen:

set Fernbedienung_4_1_Btn_01 devicepair 0 GA_Tor_Sw_1_01 single set
set Fernbedienung_4_1_Btn_02 devicepair 0 GA_Beleuchtung_Sw_1_02 single set

Also als single um zu toggeln (Also je Remote pro Taste ein Channel in Toggel modus das ganze "short").
Funktioniert soweit alles mit "short".
Da ich den Remotes für "long" eine andere Funktion geben möchte, laufe ich in das Problem, dass bei einem "long" zuerst ein short ausgeführt wird. Somit benötige ich wie bei dem virtual Aktor ein "short_Release" und ein "long_Release"

Ich denke dass ich ohne den va mein Vorhaben nicht realisieren kann :o( schade.
Hat sich zum Thema peerList und peerIDs was getan? Wäre super dann  könnte ich das mal doch noch ausprobieren und es ankommen lassen dass ohne FHEM nichts geht - sind keine kritischen Komponenten die ich schalten möchte. Direktpairen kann ich ja immer noch falls ich unzufrieden bin.

Viele Grüße
Arthur

[martinp876]

Hallo Artur

Entegen deinen Vorschlag

es gibt unendlich viele wege - und darunter einige Gute...;-)

Da ich den Remotes für "long" eine andere Funktion geben möchte, laufe ich in das Problem, dass bei einem "long" zuerst ein short ausgeführt wird.

sollte eigentlich nicht sein. Der Aktor kann es von Beginn an unterscheiden.

Du musst dir vorstellen, dass in einem Aktor (ich wiederhole mich - hoffentlich nicht langweilig...)
- je gepeerten Button (besser channel) ein peer eingetragen wird. HM spricht von einem "link"
- je link die Aktionen und Reaktionen einstellbar sind.
- im Aktor ein default erstellt wird, wenn gepeert wird. Im allgemeinen gibt es 3 defaults
  + beim pairen 'single' wird ein Link erstellt der toggelt
  + beim pairen 'dual' werden 2 Links erstellt, einer mit 'on', einer mit 'off' funktion
- alle Links reagiere erst einmal auf "long" und "short"


so das war der default, den macht HM nach peeren. Jetzt kannst du ueber die Register alles steuern, aus allem ein 'toggle' machen, ein 'on' einen treppenhausschalter und mehr.

Auf der 'link' ebene - also alle Register eines peers hast du eigentilch 2 datensaetze, einen fuer "long" und einen fuer "short". Diese sind vom registerumfang nahezu identisch (long hat immer noch den multiexec...) - vom Inhalt nicht.

Du musst jetzt also entscheiden, welcher Link auf short oder long reagieren soll und welcher nicht.

Wenn ich mich recht erinnere sollen alle auf "long" reagieren, nicht alle auf short.
also
set <licht> regSet shActionType off <button-name>
=> auf short wird nicht mehr reagiert.

Programiere doch einmal dein Licht und schicke die Register - im expert mode, dass ich alle habe.
Dann logge einmal die messages von dem, was nicht geht.

Und letztlich noch die Frage: welchen remote hast du? Die kann hoffentlich long und short. Meine taster koennen dies alle - aber ich habe keine mit 4 Button

Gruss
Martin

[snoop]

Hallo Martin,

zunächst danke für deine Geduld.

Also ich sehe nun mit
get GA_Tor_Sw_1_01 (ein Channel eines Aktors) reg all alle möglichen Einstellungsmöglichkeiten:

    3:Fernbedienung_4_1_Btn_03   lgActionType     :jmpToTarget
   3:Fernbedienung_4_1_Btn_03   lgCtDlyOff       :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtDlyOn        :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtOff          :geLo
   3:Fernbedienung_4_1_Btn_03   lgCtOn           :geLo
   3:Fernbedienung_4_1_Btn_03   lgMultiExec      :off
   3:Fernbedienung_4_1_Btn_03   lgOffDly         :0 s
   3:Fernbedienung_4_1_Btn_03   lgOffTime        :111600 s
   3:Fernbedienung_4_1_Btn_03   lgOffTimeMode    :absolut
   3:Fernbedienung_4_1_Btn_03   lgOnDly          :0 s
   3:Fernbedienung_4_1_Btn_03   lgOnTime         :111600 s
   3:Fernbedienung_4_1_Btn_03   lgOnTimeMode     :absolut
   3:Fernbedienung_4_1_Btn_03   lgSwJtDlyOff     :off
   3:Fernbedienung_4_1_Btn_03   lgSwJtDlyOn      :on
   3:Fernbedienung_4_1_Btn_03   lgSwJtOff        :onDly
   3:Fernbedienung_4_1_Btn_03   lgSwJtOn         :dlyOff

   3:Fernbedienung_4_1_Btn_03   shActionType     :jmpToTarget
   3:Fernbedienung_4_1_Btn_03   shCtDlyOff       :geLo
   3:Fernbedienung_4_1_Btn_03   shCtDlyOn        :geLo
   3:Fernbedienung_4_1_Btn_03   shCtOff          :geLo
   3:Fernbedienung_4_1_Btn_03   shCtOn           :geLo
   3:Fernbedienung_4_1_Btn_03   shOffDly         :0 s
   3:Fernbedienung_4_1_Btn_03   shOffTime        :111600 s
   3:Fernbedienung_4_1_Btn_03   shOffTimeMode    :absolut
   3:Fernbedienung_4_1_Btn_03   shOnDly          :0 s
   3:Fernbedienung_4_1_Btn_03   shOnTime         :111600 s
   3:Fernbedienung_4_1_Btn_03   shOnTimeMode     :absolut
   3:Fernbedienung_4_1_Btn_03   shSwJtDlyOff     :off
   3:Fernbedienung_4_1_Btn_03   shSwJtDlyOn      :on
   3:Fernbedienung_4_1_Btn_03   shSwJtOff        :onDly
   3:Fernbedienung_4_1_Btn_03   shSwJtOn         :dlyOff
Meine Frage: was bedeuten die ganzen Register/Values - gibt es von HM eine Beschreibung dazu? Ich denke nicht.

Ist Register 3 nun ein Link auf die Fernbedienung Btn 3? Den Link kann ich nun konfigurieren wie ich möchte richtig? Was heißt den sh und was ist lg. Du siehst schon irgendwie Fragen über Fragen.

Programiere doch einmal dein Licht und schicke die Register - im expert mode, dass ich alle habe.
Dann logge einmal die messages von dem, was nicht geht.

Ok, einen Schritt zurück - "im expert mode" ? Bin ich überfragt - was genau muss ich da tun.

Ich habe einen PBI-4 und einen HM-RC-4 testen tue ich derzeit mit dem RC.

Ach so, reagieren soll der Aktor schon auf "short" bzw. "short_Release" aber nicht auf "long" bzw. wenn ein "long" dann tue bei "short" (das vor long kommt) nichts. Also ist die default Einstellung erstmal ok = ein "devicepair single" reagiert auf short.

Viele Grüße
Arthur

[snoop]

Hallo Martin,

kleiner Nachtrag:

Wenn ich mich recht erinnere sollen alle auf "long" reagieren, nicht alle auf short.
also
set <licht> regSet shActionType off <button-name>
=> auf short wird nicht mehr reagiert.

Das habe ich ausprobiert - genau das ist es allerdings andersrum - also wie im vorherigen Beitrag beschrieben.

Womit ich mir noch schwer tue ist, was hat "shActionType off" damit zu tun, dass der Button nur noch auf long reagiert? Sorry das habe ich noch nicht verstanden. Muss ich dann für mein Fall ein "shActionType on" konfigurieren? Irgendiwe macht das für mich keinen Sinn?!

Viele Grüße
Arthur

[Martin Thomas Schrott]

Hi Arthur,

zwar der andere Martin, aber etwas Abwechslung bringt doch meh Schwung in die Sache? *smile*
du hast z.B.
3:Fernbedienung_4_1_Btn_03   lgActionType :jmpToTarget

Die 3er register sind die von den gepairten Geräten, also die, die dich interessieren. 3 hat nichts mit den Namen zu tun.

Die Fernbedienung hier ist:
Fernbedienung_4_1
und der Button z.B. 3 = Btn_03

Soweit zu dem was verbunden ist.

Du scheinst auch noch nicht ganz versanden zu haben, was du hier wo und wie einstellen kannst.

ein devicepair single hat nichts mit sort oder long zu tun! short und long sind immer aktiviert, wenn du neu gepaired hast.

sh steht für sort.
lg für long!

Was du nun machen kannst ist, dass du für bestimmte Geräte short oder long deaktivierst.

Ich nehme ein abstraktes kurzes beispiel!

Du hast einen button auf deiner Fernbedienung nr. 1 dieser soll zwei lampen einschalten, innen und außen.
Aber du willst innen mit short schalten und außen mit long.

Jetzt musst du alles mal pairen.
also devicepair mit innen und fb. Und devicepair außen und fb.

wenn du außen nicht mit short schalten willst musst du nun im kanal der außen lampe den register für deine fb für den btn_03 suchen der sh deaktiviert.
also sowas wie
3: fb1_Btn_03 shActionType
und den auf off stellen.
Bei der innen Lampe den lgActionType ausschalten.

Sonst schalten beide bei short und long.

Macht das so Sinn für dich?

lG
Martin

[Martin Thomas Schrott]

Hi nochmal,

nein kein shActionType on
das lässt du dann auf jumpToTarget!
Aber dafür setzt du lgActionType auf off.

Aber nur bei dem Kanal, der wirklich auf long nicht reagieren soll, nicht bei allen! Sonst schalten alle nur noch bei short!
logisch ? ?