Unterputz Aktoren Sw2 lassen sich nicht mit Wandschalter pairen

Begonnen von Rosco, 17 März 2013, 13:12:49

Vorheriges Thema - Nächstes Thema

Rosco

Hallo ins Forum,

aktuell habe ich neben einer kleinen FS20-Konfiguration mit CUL zusätzlich einen HMLAN Adapter in Betrieb genommen.

Einbindung HMLAN funktioniert und autocreate erkennt das Pairing der Aktoren und legt die Devises sowie deren log-Files an. So weit so gut...

An dem eingesetzten Wandschalter HM_PB_4DIS_WM möchte ich zunächst zwei Unterputzaktoren 2-fach HM-LC-SW2-FM betreiben.

Jeweils des erste Kanal (sw01) eines Aktors lässt sich mit dem Wandschalter pairen.
Der zweite Kanal (sw02) jedes der beiden eingesetzten Aktoren lässt sich nicht pairen (die Anzeige am Schalter wird nicht grün).

Nun weiß ich nicht, liegt das am Schalter oder an den Aktoren.

In FHEM können alle Kanäle (sw01 und sw02) an BEIDEN Aktoren geschaltet werden.

Ich freue mich über jeden Ratschlag, denn dies sind meine ersten Schritte in der Homematic-Welt.

Schönen Sonntag noch und beste Grüße ins Forum
Rosco
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

Hallo Rosco,

was machst du den? Also welche Kommandos?

Du kanst jeden channel des schalters mit jedem der 20 Buttons peeren, also 40 peer-links wenn du willst.

Sind der SW2 und der 4DIS schon an die Zentrale gepairt?

Also
Kommandos (vielleicht reicht das ja schon)
sonst:
Configuration der betreffenden channels und der Devices - aus der HW frisch mit getConfig gelesen und mit list angezeigt.

Gruss
Martin

Rosco

Hallo Martin,

nach gefühlten 20tausend Ab- und Anlernversuchen habe ich es nun:

Es war der eigentlich einfache Versuch den SW2 mit 4Dis zu pairen.
(fhem lauscht mit und autocreate legt die Devices zu den Channels an.)

Das Rätsels Lösung:
Zuerst Sw2 und dann Sw1 anlernen! Bloß nicht anderum, sonst ward dat nix.

Frag´ mich warum das so ist, ich weiß es nicht - auch nicht wie ich den Einfall des Vertauschens in der Reihenfolge hatte.


In fhem läuft der eine Sw 2 nun perfekt. der andere will jetzt nicht mehr (tat es aber schon mal). Leider kann ich nach der ganzen probiererei nun nicht mehr nachvollziehen, was dies verursacht haben könnte. Daher poste ich hier mal die Infos des mäkeligen Sw2´s:

ZitatDEF 1CA4F6
EVENTS 22
HMLAN1_MSGCNT 33
HMLAN1_RAWMSG E1CA4F6,0000,13FD68A2,FF,FFB5,A080021CA4F61ADDE70101C80020
HMLAN1_RSSI -75
HMLAN1_TIME 2013-03-17 19:20:44
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 33
NAME gwc_Switch_A
NR 184
STATE MISSING ACK
TYPE CUL_HM
channel_01 gwc_Spiegelleuchte_swA1
channel_02 gwc_LEDStripes_swA2
hmPairSerial JEQ0279xxx
lastMsg No:A0 - t:02 s:1CA4F6 d:1ADDE7 0101C80020
protCmdDel 104
protLastRcv 2013-03-17 19:20:44
protNack 1 last_at:2013-03-17 18:10:27
protResnd 122 last_at:2013-03-17 20:56:49
protResndFail 31 last_at:2013-03-17 20:56:52
protSnd 31 last_at:2013-03-17 20:56:46
protState CMDs_done_events:38
rssi_CUL_HM_HM_PB_4DIS_WM_1ADDE7 avg:-33.22 min:-39 max:-28 lst:-32 cnt:9
rssi_at_HMLAN1 avg:-74.51 min:-83 max:-70 lst:-75 cnt:33

Readings
CommandAccepted yes 2013-03-17 18:15:53
PairedTo 0x123ABC 2013-03-16 20:18:08
R-intKeyVisib invisib 2013-03-16 20:17:58
R-pairCentral 0x123ABC 2013-03-16 20:17:58
RegL_00:
noReceiver src:1CA4F6 (A001) 0106 2013-03-17 18:15:56
powerOn - 2013-03-17 19:16:30
state MISSING ACK 2013-03-17 20:56:52

expert 2_full
firmware 1.9
model HM-LC-SW2-FM
peerIDs    
room CUL_HM
serialNr JEQ0279xxx
subType switch
webCmd getConfig

Beste Grüße
Rosco
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

Hi Rosco,

sw1 und sw2 sind
a) 2 Kanaele eines devices
b) 2 devices mit 2 kanaelen

welches Kommando hast du zum devicepair abgesetzt?

Gruss
Martin

Rosco

Guten Morgen Martin,

im Herzogtum Lauenburg ist mal wieder das Winterchaos ausgebrochen - und das im März *schüttel*

Entschuldige meine unklare Beschreibung.
Mit sw1 und sw2 meine ich die beiden Kanäle eines Devices HM-LC-SW2-FM (von denen ich zwei in Betrieb nehmen will).
Hier am Schalter 4Dis zunächst den 2. Kanal (sw2) anlernen, dann den 1. Kanal - so hat´s geklappt.

Zur Anbindung an fhem
Das eine Device HM-LC-SW2-FM läuft (hab ich irgendwie geschafft).
fhem hat drei Geräte definiert:
- das Device selbst (siehe vorheriges Posting)
Zitatgwc_Switch_A
- und zwei Kanäle für das Device
Zitatgwc_Spiegelleuchte_swA1 und gwc_LEDStripes_swA2

Für das Device ´gwc_Switch_A` habe ich ein set <device> pair abgesandt.
Muss dies auch für die einzelnen Kanäle ´gwc_Spiegelleuchte_swA1´ und ´gwc_LEDStripes_swA2´ vorgenommen werden?

Für den 4Dis wurden auch die 20 Buttons angelegt. Daran habe ich aber nichts weiter vorgenommen oder verändert.

Verschneite Grüße aus dem Norden
Rosco
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

Hi Rosco

ZitatMuss dies auch für die einzelnen Kanäle ´gwc_Spiegelleuchte_swA1´ und ´gwc_LEDStripes_swA2´ vorgenommen werden?
nein. pairen (mit der Zentrale) kann man jedes 'device' nur einmal (und sollte dies auch tun). Channels kann man nicht pairen, das Kommando gibt es bei channels nicht.
Die Channels sind nun deine Funktions einheiten. Das Device ist die Protokoll-instanz, die von allen Channels gemeinsam genutzt wird.

Auch den 4DIS solltest du pairen (also Zentrale...). Auch hier sind die Channels die Funktionalen Einheiten, das Device macht Protokoll.

Nun willst du 4dis mit SW verbinden. Du kannst ueber die Zentrale gehen oder direkt "peeren" (nicht pairen!)

peeren macht man mit devicepair. Haengt etwas von der gewuenschten Funktion ab.
Jeder schalter (also etwa: gwc_LEDStripes_swA2) kann mit 'vielen' buttons gepairt werden (also channels des 4dis). Und je nach button macht der gwc_LEDStripes_swA2 eine andere Aktion. So kannst du definieren:
- einschalter
- ausschalter
- toggelschalter
- monoflop (treppenhausschalter)
........... sonstige

Ein devicepair "single"  erstellt einen default-toggle im SW
Ein devicepair "dual"  erstellt einen default-ein UND eine default-aus im SW, braucht also 2 Buttons/Channels deines 4Dis.
Commandref beschreibt es.

Natuerlich sind die Buttons im 4dis damit nicht verbraucht! auch die koennen sich mit mehreren Aktoren peeren.
Wichtig: einem Button ist immer egal, was ein aktor mit dem Trigger anstellt. Aktionen werden im Aktor definiert!!!

Die Reihenfolge des Peerens (devicepair) ist unerheblich, also welcher Kanal zu erst.
ggf. mal das peering kommando posten

Und Danke fuer den Schnee, ist jetzt angekommen :-(
Martin


Rosco

Hallo Martin,

ich hab´s geschafft. *jubel*

Vielen Dank für Deine Erläuterungen. Ich habe gelernt, dass eine physikalische Komponente ´Device´ gepairt wird und die jeweiligen ´Channel´ gepeert werden müssen.

Autocreate erkennt die Komponenten, definiert die ´Devices´ und legt die Log-Dateien an.
Ein Peering der Kanäle kann direkt in der Hardware durch Anlernen des Sw an den 4Dis erfolgen (alternativ auch in fhem mit devicepair, wobei die letzte Silbe pair irritiert).
Die Zentrale (in diesem Fall der HMLAN-Adapter) muss nun noch mit dem Sw2 bzw. dem 4Dis gepeert (oder doch gepairt?) werden. Dazu habe ich mit
<set HMLAN1 hmPairforSec 300> (für 300 Sek. Aktivität) die Zentrale auf "Empfang" gesetzt und die Anlernprozedure an der Hardware durchgeführt.

Im Ergebnis kann ich die Kanäle 1 und 2 am Sw2 durch Betätigen des Schalters 4Dis und in fhem die definierten "Devices" für die jeweiligen Kanäle (hier gwc_Spiegelleuchte_swA1 und gwc_LEDStripes_swA2) triggern.

Liege ich so in etwa mit dieser Beschreibung richtig?

Dann habe ich nur noch das (kleine) Problem, dass in fhem der jeweils erreichte Schaltzustand mit einem Ausrufezeichen im Lampensymbol angezeigt wird. Nach einem Refresh des Browsers ist das Ausrufezeichen dann futsch. *rätsel*


Nach viermal Schnee schippen ist jetzt erst einmal Entwarnung. Bin mal gespannt auf die Wettervorhersage...
Beste Grüße
Rosco
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

Hi Rosco,

prima.

ZitatAutocreate .... und legt die Log-Dateien an.
Beachte,dass man dies abschalten kann (auto-log dateien). Aus meiner sicht sollte man nicht zu viele log-dateien legen lassen. Zum einen kann man die schlecht handlen und zum anderen kosten sie Performance. Bei kleinen Konfigurationen sollte es kein Problem sein.

ZitatEin Peering der Kanäle kann direkt in der Hardware....
wenn die devices gepairt sind geht dies nicht mehr!


ZitatDie Zentrale (in diesem Fall der HMLAN-Adapter)
eigentlich FHEM
Zitatmuss nun noch mit dem Sw2 bzw. dem 4Dis gepeert (oder doch gepairt?)
gepairt ... ja, unschöne wortwahl, hatten wir schon haeufig


ZitatDazu habe ich mit <set HMLAN1 hmPairforSec 300>
oder hmpairserial, oder pair am device...

Zitatdie definierten "Devices" für die jeweiligen
ich wuerde von channels oder entities reden - in diesem Zusammenhang

Zitatder jeweils erreichte Schaltzustand mit einem Ausrufezeichen

nach dem Schalten wird die entity auf 'set_on' gesetzt. Das zeigt, dass ein set kommando 'on' abgesetzt wurde. Bei HM wollen wir aber eine Bestaetigung (in Gegensatz zu z.B. FS20). Mit der Bestaetigung wird der Zustand von 'set_on' auf 'on' gesetzt ( genau genommen auf was immer das device meldet, koennte auch etwas anderes sein...)

Da wir aber mit dem refresh nicht warten koennen, bis die bestaetigung da ist wird set_on gesetzt und weiter gearbeitet

Gruss
Martin

Rosco

Hallo Martin,

spannend, wenn auch etwas aufwendiger als bei FS20. Ich schätze (und kratze dabei sicher nur an der Oberfläche), dass mit HM einige Möglichkeiten mehr realisierbar sind.

Bei meinem Aufbau hier kam ich in die "Verlegenheit" HM-Komponenten einzusetzen, da es keinen FS20-Wandschalter gab, der mehr als 2x4 Schaltungen erlaubt. Beim 4Dis habe ich ja sogar noch ein bisschen Reserve. ;-)

Wenn jetzt aus meinen beiden Sw2 eine Gruppenschaltung umgesetzt und auf ein weiteres Tastenpaar gelegt werden soll, muss dann in fhem ein ´structure´ für die jeweiligen Entities gebildet werden? Wie kann ich es dann einem Tastenpaar zuweisen?

Oder ist es doch einfacher, wie es in der Bedienungsanleitung des 4Dis steht, dass jeder der bis zu 10 Positionen auch bis zu 10 Geräte durch Anlernen zugewiesen werden können können, dass diese dann wieder durch ´hmPair...´ in fhem eingelesen werden?

Wenn man erst auf den Geschmack gekommen ist...

Beste Grüße
Rosco
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

Hi Rosco,

FS20 habe ich nie genauer angesehen - denke aber dass der Funktionsumpfang deutlich kleiner ist.
Um HM auf FS20 'Niveau' zu betreiben braucht es nicht viel. Wenn man alles ueber die Zentrale steuern will gibt es warscheinlich auch nicht viele Vorteile.
HM bietet aber viele Moeglichkeiten die Aktoren/Schalter untereinander zu verknuepfen und einige steuerungen zu realisieren - ohne Zentrale. Die Zentrale ist zur konfiguration notwendig.

Also wie immer die erste Entscheidung: dezentrale vernetzung oder zentral. Ich mache moeglichst viel dezentral. Ausnahme sind schon einmal alle Zeitsteuerungen, die kommen immer von der Zentrale.

Das HM Prinzip ist
- der Button/Sensor schickt "trigger" der Aktor empfaengt trigger
- der Aktor legt die Reaktion auf trigger fest, nicht der Sensor!
- Ein Aktor, Sensor oder Button sind immer "channels"
- ein trigger kann an mehrere Aktoren gehen (gruppenschaltung)
- ein Aktor kann auf mehrere Sensoren hoeren.
  => die Reaktion eines Aktors auf den trigger eines Sensors ist einstellbar und unabhaengig von allen anderen Triggern.

Das Highlight unter den Moeglichkeiten sind die dimmer (fast alle) bei denen das Licht durch 3 virtuelle channels, jeder mit der Moeglichkeit zum peeren, errechnet wird. Diese Maechtigkeit werden wohl nicht viele nutzen....

Zu deiner Frage - kann man so ode so machen. Wenn ich klare Verknuepfungen zu den Schaltern habe wuerde ich IMMER peeren. Hier benutze ich nicht "anlernen" sondern devicepair. Hat das selbe Ergebnis, wird aber von der Zentrale aus gesteuert.
Noch einmal zur sicherheit: peeren (anlernen von channels) funktioniert nicht mehr direkt, wenn das device an eine Zentrale gepairt ist. Mit einer Zentrale pairen heisst die Hoheit ueber das Programmieren (auch peeren) an die Zentrale abgeben.

hmPair.. ist eine Funktion zum PAIREN: ein DEVICE an die Zentrale anlernen
devicepair ist DIE Funktion zum PEERED: CHANNELs direkt zu verknuepfen.
getConfig ist die Funktion, daten aus dem HM-device zu lesen. Besonderheit: wenn du getConfig auf ein Device ausloest werden auch alle channels gelesen.

Verknuepfungen deines channels werden im reading peerList angegeben (muessen vorher mit getConfig oder getdevicepair gelesen werden)

gleich dazu: nach dem Lesen eines devices (getConfig) kann an ein get saveConfig machen um die Daten zu sichern und ggf in ein device zurueckzuschreiben.

Und dann noch eins: Wenn die Anleitung von 10 positionen redet ist das nur die halbe Wahrheit. Es sollten 20 channels sein. Die gaengige Konfig ist, ein Button 'on' ein button 'off'. Daher beschreibt HM nur 10 'peers', weil immer gleich 2 verheizt werden. Musst du aber nicht machen. Du kannst auch nur einen nehmen und den Toggeln lassen. devicepair unterstuetzt dies mit der Option 'single/dual'.

Und nicht vergessen, dass (fast) jeder Schalter long und short kann. Das kannst du auch nutzen um weitere Funktionen unf peerings zu realisieren. Somit hast du zu den 20 tasten eigentlich 20 short udn 20 long. Du musst nur deiner Familie die Ergonomie beibringen

Die Entscheidung liegt bei dir ;-)
Fragen? gerne

Gruss
Martin

Rosco

Hallo Martin,

ich war zwei Tage offsite, musste nach Fischland-Darss - ein Traum, bei diesem Wetter...

Vielen Dank für Deine Erläuterungen. Du bestätigst damit meine Gedanken zur Homematic-Welt, nachdem ich dort erstmals eintauchte und das eine oder andere dazu gelesen hatte.

Mit den Zeitsteuerungen hast Du absolut Recht, das geht nur über eine Zentrale, genauso wie Wetter- oder auch PV-gesteuerte Anwendungen. Hier könnte fhem beitragen, wenn auch gerade diese logischen Verknüpfungen durch Programmierung sehr universell, jedoch für Programmier-Dummies wie mich starkter Tobak sind.
Hast Du schon von QIVICON gehört? Da ist EQ-3 auch mit Homematic beteiligt. Ende des Jahres soll eine HomeBase auf den Markt kommen...

Mit dem 4Dis und den zwei Sw2 habe ich nun eine Lösung für das Gäste-WC geschaffen, eine Anforderung, die eigentlich völlig dezentral gelöst wird. fhem dient aber als (Fernbedienungs-)Zentrale und mit andfhem werden alle Smartphones und Brett-Pc´s zu Remotes (falls mal der Schalter außerhalb der 2Meter-Komfortzone liegt).
Ich befürchte, dass ich die beiden sw2 mit hmpair... nun direkt an die Zentrale gepairt habe. Peeren wären offensichtlich sinniger gewesen. Nun, das gehe ich dann bei der nächsten Anwendung an; im G-WC ist das ja alles überschaubar.

Ja, da kommen dann auch tageslichtabhängige Schaltungen mit einfachen/kostengünstigeren FS20- oder sogar IT-Aktoren auf den Wunschzettel und die Krönung wird einmal das Schalten von Verbrauchern, wenn denn die PV-Module gerade so richtig in Schwung sind. Aber eins nach dem anderen...
Da werden wir bestimmt noch einmal schnacken, ich freu´ mich drauf.

Beste Grüße
Lutz
fhem 5.8 (Community Ware), CUL CC1101-USB-Lite 868MHz (3.4), HMLAN, Loxone Miniserver, Loxberry, HA Bridge
RSL 2-Draht Schalter
FS20 ST, DI
FHT80b, 8v, FHTTK
HM_PB_4DIS_WM, HM-LC-SW2-FM

martinp876

ZitatIch befürchte, dass ich die beiden sw2 mit hmpair... nun direkt an die Zentrale gepairt habe. Peeren wären offensichtlich sinniger gewesen

das hört sich nach einem Missverständnis an. Pairen mit der Zentrale empfehle ich IMMER.
Peeren kann man dann immer noch alles. Es geht nur nicht mehr durch 'anlernen'.
Wenn ein Device an der Zentrale angelernt ist (gepaired) dann funktioniert der Mechanismus mit "anlernen an beiden deivices drücken) nicht mehr.
Aber dafür funktioniert das devicepair (das ist peeren von der Zentrale aus gesteuert).

Das muss ich irgendwo groß hinschreiben, glaube ich.

Du kannst jederzeit eine Schaltung von der Zentrale mischen mit dem peeren von channels, kein Problem.

Gruss
Martin

snoop

Hallo Martin,

ZitatDas muss ich irgendwo groß hinschreiben, glaube ich.

Ich befürchte das hilft nicht - es ist wirklich immer wieder ein Thema (bereits diskutiert) - aber auch ein zentrales bei den HM Komponenten.
Es muss ein anderes wording her das nicht gleich klingt.. bisher ist keinen (in den bisherigen Diskussionen) nichts schlaueres/eindeutigeres eingefallen.

Ich lege noch einen drauf: SW2 kenn ich eigentlich als Channel sw_01 sw_02 etc.(müsste eigentlich laut FHEM ein Channel sein).
Channel kann ich per devicepair peeren?! ohhje(per pair peer)... macht es nicht einfacher
Devices kann ich pairen?!
;o)
Aber Channel pairen (nicht devicepair und nicht peeren) mit der Zentrale - geht das? - ach ja für den handshake oder?

*sorry, wieder das Thema... nicht böse gemeint...
Viele Grüße
Arthur

martinp876

Hi Artur,

hast ja recht.
Ich werden erst einmal ein neues Kommando zum "peeren" machen - parallel zum anderen.
a) pairen wuerde ich lassen. Da gibt es zu viele Kommandos (pair, hmPairFor... serial..)
b) devirepair werde ich noch fuer eine uebergangszeit belassen. Gut ist, dass es wohl kaum in Notifies benutzt wird. Das macht es einfacher, denn die Systeme der User werden nicht 'beschaedigt'. Es ist ja 'nur' ein Konfigurationskommando, also manueler Betrieb.
c) will man den bereits vergebenen Namen treu bleiben sollte es "peeren" heissen - und ein Hinweis zu Channels sollte noch mit rein => "peerChannel" oder kurz "peerChan" oder gedreht "chanPeer"
Ich bin fuer
peerChan <peer> <dual|single> <set|unset> <both|actor|remote>

"quelle" ist immer ein Button/Sensor, nie ein Aktor.

Verbesserungen?

Gruss
Martin

snoop

Hallo Martin,

a) ja
b) Gute Idee - ja
c) peerChan (8-Stellig) finde ich ganz gut ausgeschrieben "peerChannel" wäre besser, da es aber ein kommando ist, ist es ok (meine Meinung).

Vielleicht noch eine Anregung - war/ist ein peer nicht eigentlich (technisch gesehen) nur ein link? Idee "linkChan" - ist aber eher technisch.
Ich denke der Begriff "peer" wurde auch schon so oft hier im Forum genutzt, daher würde ich es lassen - also "peerChan".

Grüße
Arthur