Wandschalter Pairing Probleme

[DC]

Hallo zusammen,

Versuche gerade, einen Funk-Wnadtaster 2fach HM-PB-2-WM55 mit einem Hutschienen-Schaltaktor HM-LC-Sw4-DR zu pairen.
Beide sind bereits an meinem HMLAN gepairt, sollen aber jetzt direkt miteinander sprechen können.

Lauf Anleitung vom Wandtaster muss man den Taster resetten, was ich auch getan hab. Alle LED Blinksignale kommen so, wie es beschrieben steht. Trotzdem ist das Pairen erfolglos: der Aktor Kanal blinkt langsam rot, der Wandtaster blinkt grün, laut Anleitung sind also beide im Anlernmodus. Aber sie sehen sich nicht.

Was kann ich tun ?

[snoop]

Hallo,
versuch es mal mit (je nach dem wie du pairen willst - im Detail musst du dich duchkämpfen?)
(Siehe WIKI "Heimautomatisierung mit fhem" (http://fhem.de/Heimautomatisierung-mit-fhem.pdf) ab Seite 25/26 und Seite 51)
set 2fach HM-PB-2-WM55 devicepair 0 HM-LC-Sw4-DR single set
optional
set 2fach HM-PB-2-WM55 devicepair 0 HM-LC-Sw4-DR dual set

Grüße
Arthur

[DC]

Hallo Arthur,

Danke ! Das wars...

[brmpfl]

Moin,

ich hatte am WE das selbe Problem:
Ein Schalter "HM-PB-2-WM55" und ein Dimmer "HM-LC-Dim1T-Pl", beide bereits mit FHEM gepairt, sollten direkt miteinander gepairt werden.
Das ist mir leider nicht gelungen. Selbst ein "set <xxx> unpair" beider Geräte und Zurücksetzen in den Ausliefrungszustand brachte keinen Erfolg.

Der stellte sich erst nach einem "set <HM-PB-2-WM55> devicepair 0 <HM-LC-Dim1T-Pl> dual set" ein.

Jetzt habe ich ggf. ein Problem gelöst, aber dafür 2 Verständnisprobleme:

Leider verstehe ich nach wie vor nicht, weshalb ich die beiden Geräte nicht direkt pairen konnte.
Der Schalter "HM-PB-2-WM55" kann lt. Bedienungsanleitung an keinen weiteren Aktor angelernt werden, wenn er bereits an eine Zentrale angelernt wurde.
Das sollte ich doch aber mit unpair und Zurücksetzen in den Auslieferungszustand gelöst haben - oder?

Was genau bewirkt (Erklärung auf Bitebene nicht notwendig) "set <HM-PB-2-WM55> devicepair 0 <HM-LC-Dim1T-Pl> dual set"?
Die Doku bringt hier leider nicht viel Licht in meine Dunkelheit.
Kommunizieren die beiden Geräte jetzt direkt miteinander oder über FHEM?

Ratlose Grüße

[martinp876]

Hi,

ich antworte mal auf das letzte statement:

du willst channels peeren, das geht mit devicepair
wenn du eine Zentrale eintragen willst ist das pair

Die Wortwahl ist ungluecklich und wenn es immer wieder Probleme gibt werde ich die Nerven verieren und es aendern, incl aller kommandos ;-) (werde ich wohl doch eher nicht)

pairen kann man nur ein DEVICE mit der Zentrale, und mit genau einer.

peeren kann man nur CHANNELS mit andren CHANNELS Immer Aktor und button/sender

Die Doku ist hier nichteindeutig?
Pair/unpair will establish a connection between a sender-channel and an actuator-channel called link in HM nomenclatur. Trigger from sender-channel, e.g. button press, will be processed by the actuator-channel without CCU interaction. Sender-channel waits for an acknowledge of each actuator paired to it. Positive indication will be given once all actuator responded.

werden Pair/unpair nach devicepair ersetzen, das ist falsch.

Pair the device again with its known serialNumber (e.g. after a device reset) to the CUL. If paired, devices will report status information to the CUL. If not paired, the device wont respond to requests, and certain status information is also not reported. Paring is on device level and is common for all channels.

Dies werde ich ueberarbeiten. CUL ist falsch, da es FHEM sein muss.

Vorschlaege fuer die Doku? Was habt ihr nicht verstanden? Wo fehlt etwas? Bitte jeweils den ganzen commandref eintrag lesen, das ist nur der erste Teil

Gruss, Danke
Martin

[DC]

du willst channels peeren, das geht mit devicepair
wenn du eine Zentrale eintragen willst ist das pair

Die Wortwahl ist ungluecklich und wenn es immer wieder Probleme gibt werde ich die Nerven verieren und es aendern, incl aller kommandos ;-) (werde ich wohl doch eher nicht)

Ja, darüber bin ich auch gestolpert. Warum nicht

devicePair: paaren von Geräten mit der Zentrale
chanelPair: paaren von Kanälen untereinander

Das wäre jedenfalls klarer als pair und peer.

[martinp876]

nun - wir koennen eine Runde aufmachen - und wenn die User keine Probleme damit haben, koennen wir es aendern.

Ich waere allerdings fuer

assign -> an die Zentrale anlernen
peer -> channels peeren.

Ein peer ist ein gleichgestellter, pair geht evtl auch, ist aber schon abgegriffen. Peer kommt auch in der Doku haeufiger vor.
Die Namen sind dann auch richtig unterscheidlich.

Zu aendern waeren dann auch pairserial und pairforsec... die IO-befehle.

Wenn eine Aenderung nicht konsensfaehig ist werden ich nicht aendern!! Das ist es mir nicht wert....
Meinungen

Gruss
Martin

[snoop]

Ich glaube einfacher/eindeutiger wäre es devicepair in chanelpair umzubennen?

DCs Vorschlag (finde ich gut) ist aufwändiger oder?
Aus devicePair muss channelPair und pair muss devicePair werden.

Edit: Ach, hat sich mit Martins Antwort überschnitten.
Wie ich Martin verstanden habe wollte/will er das aber nicht umprogrammieren?

[martinp876]

dass
pair nach devicepair
mutiert und
devicepair nach channelpair
lehne ich ab. Wenn dann muessen es neue Begriffe sein. Kommandonamen tauschen erzeugt nur Chaos.

Gruss
Martin

[DC]

Hmmm,

Unterschiedlicher Name für gleichen Vorgang auf unterschiedliche Objekte -> nicht selbsterklärend

assign -> an die Zentrale anlernen
peer -> channels peeren.

Besser, aber immer noch zwei Bezeichnungen für selben Vorgang

assignDevice -> an die Zentrale anlernen
peerChanel -> channels peeren.

Gleicher Name für Vorgang, Objekte eindeutig spezifiziert und selbsterklärend

devicePair: paaren von Geräten mit der Zentrale
chanelPair: paaren von Kanälen untereinander

oder als aktives Verb

pairDevice: paaren von Geräten mit der Zentrale
pairChanel: paaren von Kanälen untereinander

Soweit die Theorie. Und nun ?

[martinp876]

Unterschiedlicher Name für gleichen Vorgang

wieso gleicher Vorgang? Das ist etwas grundverschiedenes. daher sollten die Namen auch unterschiedlich sein. Das ist doch der Sinn der Übung.
Das eine ist einen peer finden, eine Arbeitskollegen
das andere ist sich beim chef anmelden, das ist unterordnen.

[DC]

Weil es für den normalen User einfach das Verbinden von zwei Partnern ist, die zusammen arbeiten sollen.
Wie genau ist eigentlich egal. Wichtig ist nur, die Verbindung herzustellen.

[snoop]

Hallo DC, Hallo Martin,

Weil es für den normalen User einfach das Verbinden von zwei Partnern ist, die zusammen arbeiten sollen.
Wie genau ist eigentlich egal. Wichtig ist nur, die Verbindung herzustellen.

Was ist schon ein normaler User?
- Jemand der in der Lage ist ein Rechner zu kaufen und in betrieb zu nehmen?
- Jemand der in der Lage ist Homematic/FS20 (HMALAN/CULs(CUNOs und wie sie alle heißen) Koponenten zu bestellen und in Betrieb zu nehmen?
- Jemand der in der Lage ist FHEM zu installieren?

Ich kann da Martin nur zustimmen, wo ist die Grenze/was kann ich tun, um es einfacher eher sprechender zu gestalten (Unabhängig davon wie es programmtechnisch umgesetzt ist bzw. werden kann.)?
ich denke daher die Ansage von Martin:

nun - wir koennen eine Runde aufmachen - und wenn die User keine Probleme damit haben, koennen wir es aendern.

Ich kann nur sagen, dass FHEM generel - muss gestehen, dass ich mich erst seit 2 Monaten mit FHEM beschäftige - nichts für die Otto Normalverbraucher ist, eher für einen der sich mit der Materie auseinander setzten möchte (sorry, ich möchte FHEM nicht abwerten - ist lediglich meine Wahrnehumng), dazu gehört:
- Informieren = lesen, lesen, lesen
- Bereit sein zu experimentieren / auszuprobieren
- Sich mit der technik zu beschäftigen (siehe Punkt zuvor.)

Aber, zurück zum Thema, am Ende muss(sollte) Martin entscheiden (zum Wohle der anderen und - aus meiner Sicht viel wichtiger - zum Wohle der Stabilität), was wirklich Sinn macht. Wir sollten nur Anregungen/Ideen und Vorschläge einbringen, mehr wollte er auch nicht - und nicht auf die bisherige Implementierung rumhacken.

Meine pers. Empfehlung: Martin hat durchaus den besten Überblick welche Auswirkung (und auch Abhängigkeiten) solch eine Änderung hat - wenn das aus seiner Sicht keinen Sinn macht, dann würde ich das so akzeptieren. Ich würde erstmal nichts ändern.

Wenn man sich mit der Materie beschäftigt, dann bekommt man den bisherigen Unterschied zwischen pairen/devicepairen heraus - und wir haben es hiermit ausgiebig dokumentiert und! es gibt auch noch genug aktive Forum-User "wie Martin" der solche Unstimmigkeiten (auf)klärt und bei der Implementierung der Komponenten unterstützt.

Viele Grüße
Arthur

[Martin Thomas Schrott]

Hi zusammen,

bin zufällig über das Thma gestoßen, denke wenn ihr wirklich eine allgemeine Meinung zu diesem Thema (device pairen und peeren) haben wollt solltet ihr nicht in einem ganz anderen topic darüber schreiben ;-)

Und wenn ich schon da bin, gleich meine 2ct dazu...

Ich finde es schwierig den Leuten den Unterschied zwischen pair und peer zu erklären, denke also man sollte versuchen, diesen Unterschied so unnötig wie möglich zu gestalten.

Unnötig soll meinen, dass es egal sein sollte, ob jemand peer versteht oder nicht.

Wie wäre es also einfach zum Beispiel mit:
set xyz central abc

dann gibt es kein pair mehr, die Anzeige könnte so aussehen:
central: no central paired
oder
central: name <hmid>

Dann könnte devicepair bleiben wie es ist oder angepasst werden ohne notwendige Rücksichtnahme auf Verwechslungsgefahr.
Meinungen? :-)
cheers
Martin

[Rohan]

Hmmm...

mein Senf dazu:

1. Ja, Martin Thomas Schrott (MTS) hat Recht. Das gehört in einen eigenen Thread

2. Ja, die Vorschläge von MTS wären - zumindest für mich - um einiges besser zu unterscheiden als das bisherige "naming". Mangels konstruktiver Alternativen: ++

3. Sch**** ... ;) da gibt es viel im Wiki zu ändern :) ... Sag bitte Bescheid, MartinP876, wenn es soweit ist.

Gruß
Thomas