FHEM Forum

Hallo,

ich habe einen HM-CC-TC namens DG.hinten.Heizung
mit seinen 3 Channels
01 - DG.hinten.Heizung_Weather
02 - DG.hinten.Heizung_Climate
03 - DG.hinten.Heizung_WindowsRec

dazu einen HM-CC-VD namens DG.hinten.Thermostat

und einen HM-Sec-SC namens DG.hinten.FensterOffen

Gestern habe ich meine Konfiguration überprüft und bemerkt, dass der SC nicht mit dem TC gepeert ist und somit keine Absenkung der Temperatur erfolgt, wenn das Fenster offen ist. Das Peering wollte ich diesmal per peerChan-Befehl bewerkstelligen und habe den Befehl

set DG.hinten.FensterOffen peerChan set DG.hinten.Heizung_WindowRec single

abgesetzt. Leider kam mir dann etwas dazwischen, so dass ich die Aktion nicht mehr überprüfen konnte. Heute wurde ich von einem Familienmitglied darauf hingewiesen, dass der TC ab und zu piept. Am TC blinkte das Antennensymbol zusammen mit einem kleinen "s". Das Peering war also "in die Hose gegangen".

Nun habe ich einiges versucht und irgendwie nur "verschlimmbessert". Die commandref enthält zu dem Thema peerChan einige Infos und auch Beispiele, aber überwiegend nur für "Buttons" und alles nur englisch, was nicht meine Muttersprache ist.

Bevor ich jetzt wieder - nach alter Gewohnheit - alles auf Werkszustand setze (habe ich schon) und per Anlernknöpfe peere (habe ich noch nicht, aber schon alles wieder mit Fhem gepairt), wollte ich fragen, ob mir jemand bitte die notwendigen peerChan-Befehle erläutern/nennen/sagen kann, aber bitte für Dummies?

Danke und Gruß
Thomas

Ich antworte mir erst einmal selbst aber nicht im Sinne einer Lösung, sondern als Hinweis, warum ich auf diese Art und Weise frage (irgendwie habe ich nämlich das Gefühl, als wenn meine Intention ansonsten nicht so richtig rüberkommt):

Lt. commandref ist die Syntax von peerChan folgende:

peerChan <btn_no> <hmDevice> [single|dual] [set|unset] [actor|remote]

Nun ist es ja nicht, so, als ob ich hier nicht auch (gerade) die HomeMatic-Threads verfolge. Da fragt dann z.B. jemand, ob folgendes richtig sei:

Zitatset thermostat_kinderzimmer_lilith_climate peerChan set hm_cc_vd_lilith

und bekommt als Antwort:

Zitatset thermostat_kinderzimmer_lilith_climate peerChan set hm_cc_vd_lilith single

das single ist für nur einen channel und kein Paar von channels.

Nach der Syntax-Beschreibung in der commandref müsste z.B. das "single" vor dem 2. "set" stehen (oder die Reihenfolge ist frei). Aber auf jeden Fall *nach* dem 2. HM-Device. Und ein "Paar von Channels" bezieht sich evtl. auf Buttons (?), aber so ein HM-CC-TC hat 3 Channels. Ist dort also alles single in Sinne der commandref?

Weiter im Text... etwas weiter oben in dem Thread, auf den ich mich beziehe steht:

ZitatBein Peeren steht der Sensor immer 'vorne' und der Aktor hinten.
set <TC_Climate> peerChan..... <vd>...
set <TC_WindowRec> peerChan..... <RHS>...

set und unset sollte klar sein.

Hmmm... Sensor vorne, Aktor hinten... Ein HM-Sec-SC ist jetzt was? Für mich ein Sensor, also hatte ich mir daraus dann meinen Peer-Befehl

set DG.hinten.FensterOffen peerChan set DG.hinten.Heizung_WindowRec single

gebildet und genau damit wohl Schiffbruch erlitten.

Und nochmal auf die commandref... da steht auch als Option etwas von "[actor|remote]". Und "actor" dürfte doch dem deutschen "Aktor" entsprechen. Irgendwie sehe ich immer unklarer.

So...
Ich möchte es verstehen, damit ich es erstens nicht nur umsetzen kann, sondern ich möchte auch versuchen, dieses dann ins Wiki zu übertragen, denn ich weiß aus mittlerweile doch nicht wenigen Postings hier im Forum, dass ich mit meinen Verständnisproblemen nicht alleine dastehe und nicht wenige davon vorher ins Wiki geschaut haben. Dort ist (nicht von mir) noch die Sache mit dem Peeren per Anlernknopf vor dem Pairen mit Fhem drin (was bei mir ja auch funktionierte), aber ich weiß, dass die Empfehlung des/der HomeMatic-Fhem-Modul-Programmierer anders lautet. Diese Methode möchte ich als Alternative ins Wiki einarbeiten (nicht als allein seelig machende).

Das mit dem Peer und Pai habe ich mittlerweile großteils gerafft. Ich gebe die Hoffnung nicht aus, dass sich der Nebel um "peerChan" auch noch lichtet.

Und bitte: Nicht "in den falschen Hals kriegen" oder auf die Goldwaage legen. Ich hoffe und glaube, hier konstruktiv zu sein.

Danke fürs Mitlesen
Thomas

der TC piept wohl immer zur vollen Stunde wenn ein peer nicht erreichbar ist

zum peerChan,
a) ich werden die Syntax Beschreibung geradeziehen

set <channel> peerChan <btn_no> <actorChannel> [single|dual] [set|unset] [both|actor|remote]

Die unterstrichenen sind die defaults.

<channel>: ist immer der sender.
<actorChannel>: ist immer der aktor/empfaenger.
<btn_no>: ist historisch. Wenn <channel> ein channel ist kannst du es vergessen, also '0' schicken
[single|dual]: ein oder 2 Kanaele peeren.
[set|unset] : peeren oder peer aufloesen
[both|actor|remote]: Da das kommando (als einziges ueberhaupt) gleichzeitig 2 entities bearbeitet halte ich es fuer notwendig, dies steuern zu koennen. Also "actor"  fuehrt nur den Teil aus, der fuer actorChannel bestimmt ist, remote nur den teil der fuer channel bestimmt ist und both eben beide


Beim TC ist der climate ein sender (an den VD) und der winrec ein empfaenger
Ausserdem wird immer nur einer gepeert, also single.

set tc_Climate peerChan 0 vd single # normalfall
set tc_Climate peerChan 0 vd single set both# gleich wie vor
set tc_Climate peerChan 0 vd single set remote# vd ist schon ok, der TC hat aber den VD peer verloren
set tc_Climate peerChan 0 vd single set actor# vd wird gepeert, der TC nicht (ist hoffentlich schon

set tc_Climate peerChan 0 vd single unset actor# peer aus VD loeschen. VD kann nur einen peer. Du kannst nur einen setzen, wenn keiner 'drin' ist. also ggf erst loeschen, dann setzen.

set sc peerChan 0 tc_winRec single # sc (sender) wird an TC_winRec(empfaengfer) gepeert. andere Optionen wie oben

Spezielfaelle: Probleme gibt es, wenn ein peer eingetrage ist den es nicht mehr gibt. Dann musst du die HMID entfernen.
Fall 1) eine Remote hat einen 11223303 eintrag den du nicht mehr willst. Das ist einfach, da du anstelle des actorChannel die HMId schreiben kannst
set remoteChan peerChan 0 11223303 single unset remote

Fall 2) das gleich im Aktor ist komplizierter, das das Kommando peerChan IMMER mit der remote startet. Also 33221105 (channel 05 also) soll aus ActChn3 entfernt werden. Man muss erst dummies bauen.

define dmy CUL_HM 332211
set dmy virtual 5 # wir brauchen den 5. channel
set dmy_Btn5 peerChan 0 ActChn3 single unset # jetzt aber loeschen
delete dmy # und weg mit den Hilfsmitteln


Zu deinem Beispiel:
set thermostat_kinderzimmer_lilith_climate peerChan set hm_cc_vd_lilith
da fehlt einiges:
<btn_no> fehlt
set hm_cc_vd_lilith falsche reihenfolge
single fehlt
set thermostat_kinderzimmer_lilith_climate peerChan 0  set hm_cc_vd_lilith


Ein HM-Sec-SC ist jetzt was?
sensor. Ein sensor ist etwas das vorgaenge aufspuert und meldet. Er hat einen Fuehler (sense) fuer fenster und kann melden ob offen oder nicht.
eine remote mit buttons hat einen Sensor fuer Human-interaction und kann "fuehlen" ob der Button gedrueckt wird, was dann vermeldet wird.
Alles, was einen Aufnehmer hat und dessen Zustaende Melder ist erst einmal ein Sensor.

set DG.hinten.FensterOffen peerChan set DG.hinten.Heizung_WindowRec single
<btn_no> fehlt
reihenfolge beachten.
set DG.hinten.FensterOffen peerChan 0  DG.hinten.Heizung_WindowRec single set

es ist nicht erlaubt die Reihenfolge der Parameter zu aendern. Demnach duerfen auch keine mittendrin weggelassen werden. Commandref ist an dieser Stelle eigentlich eindeutig.

Also in deinem Fall
set DG.hinten.FensterOffen peerChan 0 DG.hinten.Heizung_WindowRec single
set DG.hinten.Heizung_Climate peerChan 0 hm_cc_vd_lilith single

es werden SC, VD, TC climate und winrec gepeert

Fragen?

Hallo Martin,

ich danke dir sehr für deine Informationen. Ich glaube, damit werde ich es schaffen, meine 3 Geräte und zukünftig auch andere mittels peerChan zu peeren.

Aber (sorry dafür) ...

du schreibst

Zitates ist nicht erlaubt die Reihenfolge der Parameter zu aendern.

und gibst die Syntax / den Befehlsaufbau wie folgt wieder:


set <channel> peerChan <btn_no> <actorChannel> [single|dual] [set|unset] [both|actor|remote]


und gibst mir das Beispiel:


set DG.hinten.FensterOffen peerChan 0 DG.hinten.Heizung_WindowRec set single


(wobei ich mir erlaubt habe, das Zitat insofern abzuändern, dass ein Blank zwischen "set" und "single" kommt.)

Hier eben z.B. mein Problem: Laut commandref-Syntax kommt "single" vor "set", in deinem Beispiel aber nicht.

Vlt. kannst du das noch klarstellen.

Wenn ich jetzt an meinem Fhem arbeiten könnte / sitzen würde, hätte ich es einfach ausgetestet, aber das dauert noch ein paar Stunden, evtl. komme ich auch erst Morgen dazu.

Und nochmals: Vielen Dank!

Gruß
Thomas

Zitatset DG.hinten.FensterOffen peerChan 0 DG.hinten.Heizung_WindowRec set single

war ein test ;-)
Da hast du recht, ich tippe aus dem Kopf hier... ist also Falsch.
Ich hatte es aber 2 min spaeter korrigiert.
in deinen Beuspielen ist es meist verdreht gewesen. Mit Set hat du ein weiteren Kommando assoziiert, glauben ich.

peerChan ist das komplexeste Kommando, schon einmal weil es 2 Channels gleichzeitig behandelt.

Das Prinzip ist eigentlich ganz einfach, die Parameter liegen auf der Hand. Das ist nichts gegen dich, ich habe es nur offensichtlich nicht geschafft, die 2-3 basics in der Doku rueberzubringen.
Evtl kannst du eine Beschreibung ausarbeiten.

Peeren nach HM, ohne FHEM interessiert mich nicht.
a) FHEM hat damit nichts zu tun
b) es funktioniert nach dem peiren nicht mehr
c) peerChan geht immer nach dem pairen
Es ist also nicht verboten, warum auch. Da es aber komplex genug ist, den Leuten peerChan nahezubringen halte ich es fuer unguenstig, auch noch eine 2. Variante anzubieten.

User, die kein FHEM nutzen brauchen es, die interessieren hier aber nicht.

Gruss
Martin

Hi,

Zitat von: martinp876 schrieb am Fr, 19 April 2013 12:11war ein test ;-)

ok ;)

ZitatMit Set hat du ein weiteren Kommando assoziiert, glaube ich.

Ja.

ZitatDas ist nichts gegen dich, ...

Kein Problem, ich habe genug Lebenserfahrung. Solche Situationen (Anwender != Programmierer, Arzt != Patient, User != Administrator, Mann != Frau) kenne ich zur Genüge aber ich habe erstens 1 Mund bzw. 2 Finger, um zu fragen und zudem keine Scheu etwas zum 2., 3. oder auch nochmal zu erläutern. Zum Glück gehörst du auch dazu ;)

ZitatEvtl kannst du eine Beschreibung ausarbeiten.

Ich werde mich nach Kräften bemühen, möchte dich aber bitten, dir diese vorab durchzusehen (als PM?).

ZitatPeeren nach HM, ohne FHEM interessiert mich nicht. .... Da es aber komplex genug ist, den Leuten peerChan nahezubringen halte ich es fuer unguenstig, auch noch eine 2. Variante anzubieten.

Kann ich verstehen, deine Gründe auch und ich werde das Thema "Peeren per peerChan" im Wiki auch klar und deutlich als Empfehlung herausstellen. Aber ich glaube, dass man als Mitautor im Wiki nicht einfach "Möglichkeiten" verschweigen sollte.

ZitatUser, die kein FHEM nutzen brauchen es, die interessieren hier aber nicht.

Ich glaube nicht, dass Anwender/Nutzer der "reinen HomeMatic-Lösung (mit CCU und der eQ-3-Software)" im Fhem-Wiki lesen. Aber es wird (einige?/viele?) Umsteiger geben (von eQ-3 auf Fhem). Und die kennen die Peering-Methode per Anlernkopf.

Aber ich bin da ansonsten offen und wenn es eine Tendenz zum Weglassen geben würde, wäre das auch völlig emotionslos möglich (bis auf die leichten Skrupel, die ja nicht falschen Wiki-Einträge eines anderen Wiki-Autors zu löschen).

Evtl. meldet sich zum letzten Thema noch jemand zu Wort ;)

Danke und Gruß
Thomas

Hallo,

danke euch, dass ihr das peerchan hier mal so ausführlich behandelt. So versteh ich das auch mal. Im ganzen Forum gab es glaube ich ( zumindest im Bezug auf TCs ) bisher kein peerchan-Beispiel, dass der Syntax in der Commandref entsprach.

Eine Frage hätte ich aber noch:
Mir ist noch nicht ganz klar, wie die Kommunikation abläuft. Sagt FHEM dem Sensor, dass er mit dem Aktor sprechen soll, oder dem Aktor, dass er auf den Sensor hören soll, oder beides?
Meine Annahme ist beides.
Muss ich demnach am Sensor die Anlerntaste drücken, damit der das Peer-Kommando schluckt?

Wenn ich Sensor und TC ohne FHEM verheirate, kommt das Peering ja nur zustande, wenn beide beteiligten Geräte sich darauf "einigen".
Was passiert beim Peeren über FHEM, wenn einer von beiden das Kommando nicht mitkriegt, sei es aufgrund von Missing Ack oder weil ich zulange gebraucht habe, die Anlerntaste am Sensor zu drücken. Kann ich das dann einfach nochmal machen, oder hat der TC den Sensor dann doppelt drin?

Gruß

Carsten

Hallo Carsten

Zitat von: Carsten schrieb am Fr, 19 April 2013 13:23...So versteh ich das auch mal.

Ein schönes Gefühl, nicht allein zu sein ;)

Zitat... Muss ich demnach am Sensor die Anlerntaste drücken, damit der das Peer-Kommando schluckt?

Davon gehe ich nicht nur aus, sondern habe mir das schnell so angewöhnt, sonst kannst du z.B. beim HM-Sec-SC ohne "cyclicMessage on" (Edith trägt noch nach: bzw. ohne Zustandsänderung) warten bis du schwarz wirst bzw. beim TC bis er die nächste Meldung an Fhem macht. Ein dann nachgeschobenes getConfig mit Anlerntaste drücken erleichtert / verkürzt die Kontrolle enorm.

Zum Rest kann ich atm nichts beitragen

Hi,

die Beschreibung gegenlesen, gerne. Ich habe mich schon ein paarmal versucht, aber evtl immer die falsche Brille auf. Es ist immer schwer festzustellen, wo man die Leute abholen muss.

Zum peeren:

Peeren mit Zentrale:
- wird mit peerChan gemacht
- geht nur, wenn das DEVICE gepairt ist. Wenn nicht wird es das Device rejecten, mag einfach nicht.
- das pairing gilt einzeln fuer aktor uns sensor - sollte klar sein.
- es wird eigentlich einzeln der Aktorchannel und der sensorchannel 'programmiert'. Diese beiden Teile sind unabhaengig von einander, werden aber im Normalfall in einem Rutsch mit peerChan erledigt.
- peerChan erlaubt auch, nur eine Seite zu peeren (actor,remote,both).

Peeren ohne Zentrale:
- HM beschreibt dies "natuerlich" in seinem Handbuch an erster Stelle. Sie koennen eine Zentrale nicht voraussetzen. FHEM User haben aber eine, brauchen es also nicht
- kann man nur, wenn NICHT gepairt ist. Wenn eine Zentrale eingetragen ist (gepairt) dann funktioniert dies nicht mehr, es muss die Zentrale machen.
- da man komfortables User-interface hat, wenn keine Zentrale hat HM einfach das Anlernen missbraucht (haben ja sonst nichts). Implizit machen sie nichts anderes, aber auf eine leicht andere Weise.
- ohne das Druecken des Anlernen koennte der channel nicht wissen, mit wem er pairen soll

Operation von peers:
wenn gepeert ist, egal wie, funktioniert der Sensor(channel) wie folgt:
- press short: sende eine Message jeden der Peers und warte auf ein ack.
- gesendet wird die Button-nummer, deine sequenznummer  und ggf ein messwert (motion detector)
- press long schickt alle .4sec an Broadcast und am ende eine message an jeden seiner Peers mit bitte um ACK

Aktoren, gepeert:
fuer jeden peer wird im Aktor(channel) ein Ablauf erstellt, was zu tun ist, wenn ein trigger kommt. Man kann alle 3 Wert beruecksichtigen, so
- long/short
- der Messwert (kommt nicht immer)
- die Sequenznummer
um die Aktion festzulegen.
HM stellt beim peeren einen Default Ablauf ein. Der ist unterschiedlich, je nachdem ob man signel oder dual peert. Bei single wird von einem ein-button betrieb ausgegangen (toggle-schalter) bei dual von einem Ein-und einem Ausschalter. Ueber die Register kann man dann alles ueberschreiben.


Anlernen druecken: Wenn wir ueber Zentrale arbeiten.
Annahme: das Pairing ist vollbracht!
Man muss die devices unterscheiden:
- 'normale' schalter/dimmer brauche nie mehr anlernen
- 'normale' remotes brauceh immer anlernen
warum: Batterieverbrauch
Um die Aufmerksamkeit des Device zu erlangen muss das device wach sein. Devices mit stromanschluss sind dies immer. Devices mit Batterie nicht. Um sie wachzukuessen stehen 3 Modi zu Verfuegung: burst, wakeup,config.
burst: kein Problem, FHEM weckt das Device automatisch auf (falls HMLAN genutzt wird. Der User nutzt es wie ein 'dauer-an' device
wakeup: das device wacht regelmaessig auf. FHEM wartet ab, biss es das "gaehnen" hoert und schickt dann alle bis dahin aufgelaufennen Daten an das Device.
config: das Device ist nach anlernen empfangsbereit. FHEM speichert alle kommandos bis anlernen erkannst wird, dann wird alles gesendet.

Ein device kann ggf mehrere Modi. Beispiel TC: der macht wakeup alle 3 min. Wenn mir das bein testen zu lange dauert druecke ich anlernen, dann wird sofort uebertragen. Evtl schaltet der sogar auch burst ein, wenn ein SC angelernt ist.

meine RC12 kann ausschlieslich config. Immer wenn ich die configuration auslesen will oder peeren muss ich anlernen druecken.
eine RC19 hat ein display, daher hat EQ3 auch burst eingebaut - sonst koennte die Zentrale das Display nicht beschreiben.

=> ist anlernen also zu druecken? Ja, bei allen Devices die nur config beherrschen. Und zwar immer, wenn man mit dem Device reden will.

Nebenbei: FHEM speicher die Kommandos nur bis zum naechsten reboot/update.

Fuer eine Uebersicht Protokollstatus empfehle ich HMinfo mit
define hm HMinfo
set hm protoEvents

Gruss
Martin

@Martin

>Peeren mit Zentrale:

ich würde das lieber Peeren via / über Zentrale nennen, sonst denken manche wieder sie peeren das Gerät mit der Zentrale ... sie sollen es ja nur durch Nutzen der _Zentrale mit einem weiteren Gerät peeren.

lG
Martin

@Carsten


Nein es ist nichts doppelt drin wenn du den Befehl wiederholt sendest es wird höchstens überschrieben.
Du kannst aber auch einfach nur den fehlenden Teil nachsenden indem du entweder actor oder remote am Ende des Befehls dazuhängst dann wird nicht both also nicht beide sondern nur der gewählte Teil ausgeführt (siehe oben in Martins Erklärung)

Das sollte auch deine anderen offenen Fragen beantworten so diese noch offen waren nach der Erläuterung.
lG
Martin

Ich habe es an Hand der mir hier gegebenen Hilfen / Erklärungen geschafft, die im Betreff genannten Devices mittels peerChan zu peeren, habe mir entsprechende Notizen machen können und glaube, dass ich es nun verstanden habe.

Großes Danke an dieser Stelle an Martin!

Und: Letztendlich ist es einfacher und problemloser als das "Peeren per Anlerntasten", denn wenn da etwas in die Hose geht (sofern eine Zentrale im Spiel ist), darf man im worst-case wieder bei Null anfangen, also alle Devices auf Werkseinstellung setzen um es erneut zu versuchen.

Notizen sind im Kasten, ich werde mich also dann der Dokumentation (Wiki und dem Anderen!) widmen können, werde dies aber noch an meinen anderen HM-Devices (Schalter/Remotes usw.) vertiefen.

Gruß
Thomas

Edith musste ein "mein" gegen "man" tauschen

Danke für die ausführliche Darstellung. Bei mir liefert der Aufruf

"set OG.BAD.FENSTER_HM peerChan 0 OG.BAD.THERMOSTAT_HM_WindowRec single set"

den Fehler "0 is not a button number". Dies liegt scheinbar an "$bNo < 1". Gemäß Anleitung
im Aufruf auf 0 gesetzt.

Siehe Ausschnitt aus "...CUL_HM.pm"
>>>
 elsif($cmd eq "peerChan") { ############################################# reg
    #peerChan <btnN> <device> ... [single|dual] [set|unset] [actor|remote|both]
   my ($bNo,$peerN,$single,$set,$target) = ($a[2],$a[3],$a[4],$a[5],$a[6]);
   $state = "";
   return "$bNo is not a button number"                          if(($bNo < 1) && $roleD);  
<<<

Hat jemand eine Idee?
Vielen Dank!

hm - wieder ein Sonderfall.

die '0' gibt die Channelnummer an, wenn keine channels definiert oder eben das Kommando auf ein Device anwendet.
Und dann soll hier die channel-nummer stehen, also eine Zahl >=1.

Dein sonderfall ist, dass du einen 1-channel-device hast und somit channel und Device in einer Entity dargestellt werden - korrekt?

Also ersetze die '0' mit de Channel-nummer, in deinem Fall '1'
"set OG.BAD.FENSTER_HM peerChan 1 OG.BAD.THERMOSTAT_HM_WindowRec single set"

Ich werden diesen Fall wohl noch einarbeiten...

Gruss Martin

Danke für die schnelle Rückmeldung. Funktioniert.
Vielen Dank.