HM Lan und Cuno und Pairen

[mcfly71]

Guten Tag Gemeinde,

ich habe mal eine Rage zum Verständniss:

Man muss ein Homematic Gerät ja immer mit dem HMLan pairen. In Fhem in der cfg werden die benötigten Einträge per autocreate (z.B) gemacht. Wenn man das Gerät nicht mehr haben will, muss man unpairen.
Soweit so gut.
Was ich nicht verstehe ist: Ich hatte früher einen Cuno, habe ein paar Geräte angelernt und alles war gut. Ich stellte fest, dass der cuno keinen Burst Modus unterstützt, sodass ich mir einen HMLan zugelegt habe. In dem Wiki stand, dass man einfach den HMLan einbinden könne, indem man die ID des cunos (xxxx) einfach mit einem F1 vorher versieht, und dann ist man auch schon fertig.

attr STEUERUNG_HM hmId F1xxxx

Das funktionierte auch, und ich habe dann neue Geräte wiederum am HMLan angelernt. Aber wieso fkt. das ?
Ich dachte, dass das pairen irgendwas im cuno bzw. HMLan auslöst (also sowas wie abspeicherung gewisser Gerätedaten) und das das CUNO bzw HMLan nur mit den "abgespeicherten" Geräten kommuniziert.
Das ist aber anscheinend nicht so, das die alten angelernten Geräte vom Cuno nie nochmals gepairt worden sind mit dem HMLan.
Folglich meine zusatzfrage: Ist ein pairen mit dem HMLan dann überhaupt zwingend nötig ??
Vlcht. kann mich irgendjemand mal aufklären...

mcfly

[mcfly71]

Ich habe natürlich eine Frage keine Rage....

[betateilchen]

Vereinfacht gesagt: Wenn Du zwei Sendegeräte in Betrieb hast, die beide für Homematic konfiguriert sind, und ein HM-Device ist mit einem der beiden Sender gepairt, reicht das erstmal für eine korrekte Funktion, solange Du keine anderen Änderungen in den Gerätekonfigurationen vornimmst (z.B. zwingend ein IODev vorgibst)

Bestimmt kommt noch irgendjemand, der Dir das genauer erklärt - ich habe die gleiche Erfahrung gemacht wie Du, als ich neulich den HMLan und den HMUSB gleichzeitig in Betrieb hatte.

[marc2]

Hi !

Der CUNO merkt sich gar nichts, das mach FHEM, und daher reicht bei der Migration einfach die HM-ID
mitzunehmen.

Anmerkung am Rande: Der CUNO unterstützt mit der aktuelle Firmware sehr wohl die Burstfunktion.
Hier Michael super Arbeit geleistet ! Ich hatte hierfür früher einen Repeater zwischen dem
CUNO und den Devices, die einen Burst brauchen (z.B. einem HM-LC-SW1-BA-PCB). Mit der aktuellen
Firmware ist dies nicht mehr notwendig.

Gruß, Marc

[mcfly71]

Ich habe bislang meine VD's (Heizungs Stellantriebe) an die TC's angelernt (Thermostate) und
dann als letzten Schritt das TC an HMLan angelernt. Diesen letzten Schritt TC an HMLan anlernen
brauche ich also demnach nicht zu machen, solange FHEM den TC angelernt hat ?????

Es geht nämlich darum, dass ich eigentlich 4 VD's an einem TC anlernen müsste, laut Anleitung kann ein VD auch 4 angelernte Einheiten haben, nur ist das 4. bislang der HMLan Adapter und nicht der 4. VD...

[martinp876]

Ich habe bislang meine VD's (Heizungs Stellantriebe) an die TC's angelernt (Thermostate)

kann man direkt aus FHEM machen

als letzten Schritt das TC an HMLan angelernt. Diesen letzten Schritt TC an HMLan anlernen
brauche ich also demnach nicht zu machen, solange FHEM den TC angelernt hat ?????

verstehe ich nicht. Man lernt nicht an HMLAN an, sondern an FHEM. Wir bezeichnen das als pairen. Alle TCs sollten an FHEM gepairt werden.
Ich würde auch die VDs an FHEM pairen, weil ich immer alles an FHEM pairen wurde.

Wenn man an FHEM gepairt hat muss man auch das peeren (vd an TC) über FHEM machen.

Dann ein VD mehr als einen Peer haben kann, kenne ich nicht. Meiner verweigert das.
Ein TC hingegen kann mehrere VDs bedienen.

Unterscheide GENAU zwischen pairen und peeren - auch wenn beides mit dem Anlernknopf zu tun hat.

Gruss Martin

[mcfly71]

Hallo Martin,

ok, dann versuche ich es mal korrekt auszudrücken:

1) Ich habe 3 VD's gepeered mit einem TC ( 4 sec. VD Anlernknopt dürcken, 4 sec. Anlernknopf TC drücken auf OK warten)
2) Ich habe den TC gepeered mit dem HMLan ( set CUL hmPairForSec 600, 4 sec. Anlernknopf TC drücken auf OK warten ).

Danach ist der TC mit 3 VD's gepepered und! mit dem HMLan.

Da autocreate bei fhem eingestellt ist, sind nach der Aktion auch die VD's und TC's eingetragen (gepaired) mit fhem.

Ich steuere nämlich die Heizung nur mit templisten im TC.

Wenn das oben nun richtig beschrieben ist, würde ich sagen dass ich 2) wegfallen lassen kann und somit noch ein 4. VD mit dem TC peeren kann.... ????

Ich hoffe ich habe es jetzt besser verstanden..... ansonsten mea culpa

VG
mcfly

[mcfly71]

Beim nochmaligem Lesen:

Oder ist 2) eigentlich ein pairen an FHEM ????

Fakt ist halt nur: Wenn ich 2) nicht durchführe kann ich ein 4. VD anlernen, wenn ich 2) durchführe geht das nicht mehr (NOK).

mcfly

[betateilchen]

Wenn das oben nun richtig beschrieben ist, würde ich sagen dass ich 2) wegfallen lassen kann und somit noch ein 4. VD mit dem TC peeren kann.... ????

Du kannst keinen 4. VD mehr direkt mit dem TC peeren, solange der TC an eine Zentrale (in diesem Fall fhem) gepairt ist. Du kannst aber den 4.VD an fhem pairen und dann per fhem an den TC peeren. Oder Du musst alle Komponenten ablernen, zurücksetzen und von vorne anfangen. Also erst alle VD an TC anlernen und dann TC mit fhem pairen.

Ich steuere nämlich die Heizung nur mit templisten im TC.

Wie willst Du die templist im TC komfortabel setzen, wenn der TC nicht mit fhem gepaired ist?

Oder ist 2) eigentlich ein pairen an FHEM ?

Natürlich ist das ein pairen, denn wie Du richtig schreibst

Code Auswählen Erweitern

set CUL hmPairForSec 600

heißt es ja hmPairForSec und nicht hmPeerForSec ;)

[mcfly71]

Hmmm,

> Du kannst aber den 4.VD an fhem pairen und dann per fhem an den TC peeren

Das geht mit hmpairforcsec, und dann : attr TC_CLIMATE peerIDs einfach eintragen richtig ?

Wenn das oben richtig ist könnte ich also auch jedes VD und jedes TC nur mit fhem pairen und dann
die jeweiligen peerIds im Climate eintragen.

Wie aber werden dann die VD's gesteuert, wer entscheidet, ob ein VD aufgedreht werden soll?
Entscheidet dies fhem selbst oder "fragt" er den TC ab, ob der aufdrehen würde, und gibt dann den Befehl zum aufdrehen ?

Weil bisher verstand ich es so: Der TC sendet seinen gepeereten VD die Kommandos für auf und zu, damit seine gespeicherten templisten erfüllt werden. Und das tut es natürlich nur dann, wenn er auch mit den VD's gepeered ist.

Ich hoffe ich habe mich verständlich ausgedrückt.... schwierige Sache dies...


mcfly

[betateilchen]

Das geht mit hmpairforcsec,

Richtig.

und dann : attr TC_CLIMATE peerIDs einfach eintragen richtig ?

Falsch. Das geht mit set <actor> peerChan <sensor> ...

Der Eintrag im Attribut erscheint bei korrektem Peering dann automtatisch.

Wenn das oben richtig ist könnte ich also auch jedes VD und jedes TC nur mit fhem pairen und dann
die jeweiligen peerIds im Climate eintragen.

Genau so ist es. Und das ist auch genau die Vorgehensweise, die Martin Dir oben schon vorgeschlagen hat.

Wie aber werden dann die VD's gesteuert, wer entscheidet, ob ein VD aufgedreht werden soll?
Entscheidet dies fhem selbst oder "fragt" er den TC ab, ob der aufdrehen würde, und gibt dann den Befehl zum aufdrehen ?

Kommt drauf an. Wenn der TC im Modus "auto" steht, macht er das selbst. Wenn er im Modus "Cent" steht, steuert FHEM die ganze Regelung. Genau deshalb gibt es diese beiden unterschiedlichen Modi.

Weil bisher verstand ich es so: Der TC sendet seinen gepeereten VD die Kommandos für auf und zu, damit seine gespeicherten templisten erfüllt werden.

Richtig. Aber NUR im Modus "Auto"

Und das tut es natürlich nur dann, wenn er auch mit den VD's gepeered ist.

Er ist auch dann mit den VDs gepeert, wenn Du das Peering per FHEM vornimmst. Die Peering-Partner werden immer in den Geräten (also sowohl im TC ala auch im VD) gespeichert.

Mach Dir nix draus - so schwierig ist das Ganze gar nicht. Man muss nur anfangen, so simpel und logisch an die Sache ranzugehen, wie es das Konzept von Pair und Peer eigentlich vorsieht. Darin liegt meistens die Ursache für viele Probleme bei der Konfiguration von HomeMatic-Komponenten: Man denkt einfach viel zu kompliziert. Ich spreche da aus eigener Erfahrung der letzten paar Wochen.

[mcfly71]

Ok, dann habe ich es so langsam gerafft (endlich)

Nur noch ein letztes:

> Falsch. Das geht mit set <actor> peerChan <sensor> ...

actor ist der VD und sensor der TC ..... richtig ?
Heisst also wenn man 3 VD's hätte muss man
set VD1 peerChan TC1
danach
set VD2 peerChan TC1
.... usw.

und wenn ich nun alles einzeln paire und dann das peering wie oben gemacht habe, müssen alle TC's
auf CENT

[betateilchen]

actor ist der VD und sensor der TC ..... richtig ?

Richtig.

Heisst also wenn man 3 VD's hätte muss man
set VD1 peerChan TC1
danach
set VD2 peerChan TC1
.... usw.

Fast richtig - und jetzt wirds kompliziert: der VD wird nicht mit dem TC gepeert, sondern mit dem Channel TC-Climate und die Syntax ist wichtig.

Code Auswählen Erweitern

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

Irgendwo gab es eine fast perfekte Konfigurationsanleitung, ich weiss spontan nur nicht mehr, ob das hier im Forum oder im Wiki war.
edit: schau mal in diesen Thread, da hat Martin das gut erklärt: http://forum.fhem.de/index.php?t=msg&goto=74169&rid=1592&srch=hm-cc-tc_climate#msg_74169

und wenn ich nun alles einzeln paire und dann das peering wie oben gemacht habe, müssen alle TC's
auf CENT

Fast richtig.

Den Betriebsmodus (Manuell/Auto/Zentrale) Deines TC kannst Du natürlich immer noch frei wählen. Das gibt Dir die Möglichkeit, eine TempList an den TC zu schicken und ihn im Modus "Auto" laufen zu lassen.

Im Modus "Auto" ist er völlig autark und regelt Deine Heizung auch dann, wenn FHEM mal nicht verfügbar sein sollte.
Im Modus "Cent" reagiert er nur auf Steuerbefehle von FHEM (und natürlich direkt am Gerät) und ignoriert die TempList.
Im Modus "Manu" sollte der TC auf FHEM gar nicht reagieren (aber irgendwie hab ich den Eindruck, dass er das trotzdem manchmal tut, bin der Sache aber noch nicht weiter nachgegangen)

[martinp876]

mcfly71 schrieb am Do, 18 Juli 2013 10:30

    Heisst also wenn man 3 VD's hätte muss man
    set VD1 peerChan TC1
    danach
    set VD2 peerChan TC1
    .... usw.

Richtig - aber auf korrekte Syntax bei peerChan achten (commandref beachten!)

falsch. Immer der Sensor an den Anfang

Code Auswählen Erweitern


set TC1_climate peerChan 0 VD1 single
set TC1_climate peerChan 0 VD2 single
set TC1_climate peerChan 0 VD3 single


Beachten: FHEM darf schreiben, wenn das Device gepairt ist. Also erst einmal ALLE devices pairen (auch die VDs!!!)

Am ende immer prüfen:

Code Auswählen Erweitern

set TC1 getConfig
liest alle 3 Channels des TC, alle peers, alles was ich bisher gefunden habe

Beachte TC mode. Der TC unterstützt 2 modi um mit der Zentrale zu reden
Wakeup: Du setzt kommandos ab und wartest, bis der TC seine Temp-messung schickt. Dann ist er wach und FHEM überträgt alles (lesen und schreiben) Kann bis zu 3 min dauern.
Config: Du drückst Anlernen kurz, der TC ist empfangsbereit und FHEM überträgt alle bisher gespeicherten Kommandos (wie bei wakeup).

Nebenbei: der Knopf "Anlernen" ist m.E. missverständlich. Eigentlich ist es bei kurz drücken ein readyToConfig signal. Anlernen (besser peeren/pairen) ist nur eine der Funktionen.

Gruss Martin

[betateilchen]

falsch. Immer der Sensor an den Anfang

ups, ja. Sorry. Aber ich hatte ja im Edit oben schon auf Deine Konfigurationsbeschreibung verwiesen, und da stehts auf jeden Fall auch richtigrum drin.