Mehrere HM-CC-VD an einen HM-CC-TC mit einer Fritzbox 7390 und CUL

[Kai Schotzerl]

Aktuell betreibe ich seit einigen Tagen mehr oder weniger erfolgreich eine 7390+CUL + mehrere Pakete mit je einem HM-CC-TC und einem HM-CC-VD.
Alles wurde untereinander erkannt und auch vom CUL entdeckt. Soweit so gut. Die Einstellerei ist eine andere Sache.
Nun habe ich einen zusätzlichen VD bestellt für einen weitere Heizkörper. In FHEM taucht er auch wunderbar auf.
Aber ein Verbinden mit dem zugehörigen TC (Einstellrad auf KON->ADD) bekomme ich nur ein NOK.
Gehen mehrere VDs nur mit einer CCU? Geht das aktuell nicht oder wo ist der Hund begraben?

[fhem-hm-knecht]

1. ist es da erklärt, warum du ein nok erhälst, grundsätzlich geht, an
einem TC mit 4 VD und fhem.
http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat

2.theoretisch sollte nachtäglich ein VD ergänzbar sein, über Peer,
habe es aber noch nicht ausprobiert,
vielleicht sagt der Martin noch etwas dazu.

Hary

[littlebilly]

Also bei mir geht das!

|Aber ein Verbinden mit dem zugehörigen TC (Einstellrad auf KON->ADD) bekomme ich nur ein NOK.

Ich paire immer durch drücken der Knöpfe, nehme den TC zum VD , drücke am VD die Verbindungstaste (Antennensymbol sollte blinken)

dann am TC --> dann ok.

Gehen mehrere VDs nur mit einer CCU? Geht das aktuell nicht oder wo ist der Hund begraben?

Ich habe bis zu 3 VD's am HMLAN, dürfte aber für den CUL auch kein Problem sein!

Gruss Billy 

[Martin]

Am Freitag, 23. November 2012 15:17:01 UTC+1 schrieb fhem-hm-knecht:

1. ist es da erklärt, warum du ein nok erhälst, grundsätzlich geht, an
einem TC mit 4 VD und fhem.
http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat

2.theoretisch sollte nachtäglich ein VD ergänzbar sein, über Peer,
habe es aber noch nicht ausprobiert,
vielleicht sagt der Martin noch etwas dazu.

Das peering durch die Zentrale funktioniert.
Zu beachten ist, das
- TC und VD installiert sind
- der TC_Climat channel existiert
 - das peering vom sender  (TC_Climate ausgeht) also set tc_Climate devicepair 0 vd single set

Pruefen mit getConfig -
TC und VD pruefen
Gruss
Martin

[Franky]

@Kai
Meine Erfahrung ist, dass immer wenn ich eine neue Komponente (Stellantrieb oder Fenstersensor) einem Thermostat hinzufügen möchte, dass bereits mit dem Fhem gepairt ist (richtig gepairt, nicht nur sichtbar), dann muss ich alle bisherigen Komponenten und das Thermostat komplett auf Werkseinstellungen zurück setzen! Zumindest funktioniert es dann auf jeden Fall. D.h. aber auch, dass Du im Thermostat wieder alle Einstellungen neu machen musst. In Fhem behalten wenigstens die bisher bekannten Komponenten ihre Namen und Einstellungen. Ich weiß nicht, ob es auch anders geht, bei mir hatte ich sonst immer ein NOK.

Grüße
Frank

[Martin]

Hallo Frank,

Am Samstag, 24. November 2012 12:47:15 UTC+1 schrieb Franky:

@Kai
Meine Erfahrung ist, dass immer wenn ich eine neue Komponente (Stellantrieb oder Fenstersensor) einem Thermostat hinzufügen möchte, dass bereits mit dem Fhem gepairt ist (richtig gepairt, nicht nur sichtbar), dann muss ich alle bisherigen Komponenten und das Thermostat komplett auf Werkseinstellungen zurück setzen!

das kann ich nicht bestaetigen. Wann auch immer du die letzten Tests gemacht hast - ich kennen keinen Fall mehr, in dem ein devicepair nicht funktioniert. Voraussestzung ist, dass die Komponenten korrekt eingerichtet sind in FHEM und das Kommando korrekt abgesetzt wird.
TC und VD funktionieren garantiert.

Ich denke der Satz Funktionen zum peeren ist komplet:
- setzen und loeschen von peerings
- fuer Actor, Sender oder beide gleichzeitig
- Einzel oder doppel Tasten (TC nur einzeln)
- Lesen der Peerings

Geht mit Sicherheit auch, wenn man mit der Zentrale gepairt ist

Zu beachten ist beim VD, dass der nur mit einem peer 'kann'. Wenn man also den TC tauschen will muss man erst den altenloeschen dann den neuen setzen

VD peer tauschen:
set <TC_alt_Climate> devicepair 0 <vd> single set actor # peer wird nur im actor (VD) geloescht
set <TC_neu_Climate> devicepair 0 <vd> single set actor # peer wird nur im actor (VD) gesetzt
set <vd> getconfig
### jetzt einmal anlernen druecken am VD oder warten - falls der VD noch regelmaessig sendet
### es werden alle 3 Kommandos der Reihe nach abgearbeitet. Das ergebnis ist in readings zu sehen
### Es bleiben alle settings im aktor erhalten
### TC kann mit mehreren VDs gleichzeitig gepairt sein.
 

Zumindest funktioniert es dann auf jeden Fall. D.h. aber auch, dass Du im Thermostat wieder alle Einstellungen neu machen musst. In Fhem behalten wenigstens die bisher bekannten Komponenten ihre Namen und Einstellungen. Ich weiß nicht, ob es auch anders geht, bei mir hatte ich sonst immer ein NOK.

 Wann war das? Mit der Aktuellen SW?

Gruss
Martin

[Kai Schotzerl]

Ich habe es noch einmal probiert und immer wenn ich den TC mit dem zusätzlichen VD verbinden wollte, gab es ein NOK.

Nun habe ich -wie Franky beschrieb- einfach die 3 Dinger resettet. Da meine Heizzeiten ja hinterlegt sind, musste ich neben dem Uhrzeiteinstellen nicht viel machen.
Und schon das erste Verbinden der Geräte untereinander funktionierte sofort.

[HJosefL]

Hallo zusammen,

habe dieses gleiche Problem gelöst, indem ich den CUL kurz außer Betrieb genommen habe und dann das Ventil mit dem TC gepairt habe. Dann habe ich den CUL wieder eingeschaltet und beim VD die Pairingtaste betätigt nachdem natürlich bei fhem die pairforsecxxx eingetellt war.

Freundliche Grüße

Josef

[Martin]

Josef, Kai,

ich denke
- ihr redet von 2 unterschiedlichen Dingen - pairing mir der Zentrale und pairing mit einen 'peer' als TC zu VD
- ich bin ueberzeugt, dass beides mit fhem funktioniert.

Also: Um einen VD mit der Zentrale zu pairen ( das device ist schon in FHEM eingerichtet - nur die Zentrale fehlt noch im VD!) ein set <vd> pair abzuschicken und dann anlernen (3sec ) zu druecken. Das sollte reichen.


Peering eines TC mit mehreren VDs habe ich schon probiert (2 stueck) - hat funktioniert, sollte auch bei euch klappen. Dazu braucht man den Climate channel.Das kommando ist
set <tc_Cliamte> devicepair 0 <vd> single set

Zu beachten:
es wird sowohl ein Kommando an den VD alsauch an den TC gesendet. Beide erhalten ihre kommandos erst wenn
a) sie aufwachen oder
b) man anlernen drueckt.
ein VD kann nur einen peer verwalten! Sollte schon einer eingetragen sein, muss dieser geloescht werden  - mit devicepair unset.

ob das ganze funktioniert hat kann man einsehen indem man getConfig fuer die Devices macht. und dann die peerliste ansieht

Sollte es nicht funktionieren dann bitte message-traces ziehen

Gruss
Martin

[HJosefL]

Hallo Martin,

ich denke, ich habe die Aufgabenstellung von Kai schon verstanden. 

Er hat im ersten Schritt eine Fritzbox 7390 + CUL + HM-TC-CC +  HM-CC-VD erfolgreich ans Laufen gebracht.

Bei der Erweiterung um ein zusätzliches Heizkörperventil mit einem zweiten HM-CC-VD gelingt es ihm im laufenden Betrieb nicht, dieses Ventil an der bestehenden HM-TC-VD anzumelden. FHEM erkennt das neue Ventil sofort, der HM-TC-CC leider jedoch nicht, solange der CUL mitlauscht. Aus diesem Grunde bin ich zu der Lösung des temporären Abschaltens des CUL zu diesem Zweck gestoßen. 

Es handelt sich hier meiner Meinung nach auch nicht um einen Fehler in FHEM, sondern um ein rein physikal/techn.Vorgang, da der CUL ja quasi immer empfangsbereit ist. Ich gehe hier sogar noch einen Schritt weiter und behaupte sogar, dass es nicht gelingt, im Umfeld eines eingeschalteten CUL ein "pairing mit einen 'peer' als TC zu VD oder zu Fensterkontakt" herzustellen. Vielleicht kann das ja mal jemand probieren, mir ist es leider nicht gelungen.

Freundliche Grüße

Josef

[Martin]

Am Donnerstag, 6. Dezember 2012 13:00:50 UTC+1 schrieb HJosefL:

Hallo Martin,

ich denke, ich habe die Aufgabenstellung von Kai schon verstanden. 

Er hat im ersten Schritt eine Fritzbox 7390 + CUL + HM-TC-CC +  HM-CC-VD erfolgreich ans Laufen gebracht.

Bei der Erweiterung um ein zusätzliches Heizkörperventil mit einem zweiten HM-CC-VD gelingt es ihm im laufenden Betrieb nicht, dieses Ventil an der bestehenden HM-TC-VD anzumelden.

seltsam

FHEM erkennt das neue Ventil sofort, der HM-TC-CC leider jedoch nicht, solange der CUL mitlauscht.

mitlauschen beeinflusst das Verhalten nicht. Der TC wird nicht selbstaendig nach dem VD suchen. Die Zentrale muss dem TC sagen, dass der neue VD ihm zugeordnet werden soll. Das Kommando ist "devicepair"

Aus diesem Grunde bin ich zu der Lösung des temporären Abschaltens des CUL zu diesem Zweck gestoßen. 

Es handelt sich hier meiner Meinung nach auch nicht um einen Fehler in FHEM, sondern um ein rein physikal/techn.Vorgang, da der CUL ja quasi immer empfangsbereit ist. Ich gehe hier sogar noch einen Schritt weiter und behaupte sogar, dass es nicht gelingt, im Umfeld eines eingeschalteten CUL ein "pairing mit einen 'peer' als TC zu VD oder zu Fensterkontakt" herzustellen.

das habe ich schon oft gemacht in meinen Tests. Geht ohne Probleme, wie beschrieben. Muss aber von der Zentrale aus gemacht werden, nicht direkt - das betrifft alle Geraete, die eine "Zentrale" eingetragen haben.
Ob die CUL mithoert ist volkommen egal - woher sollte das dein TC wissen? Wenn die CUL etwas sendet ist es etwas anderes - dann kommt es darauf an was und warum sie sendet

 

Gruss
Martin

[Merhan]

Hallo Martin,

funktioniert das auch auf dem Kanal für die Fensterkontakte?

Wenn ja wie lautet der entsprechende Befehl analog zu dem folgenden für die Antriebe?

set <TC_neu_Climate> devicepair 0 <vd> single set actor

Wofür steht eigentlich die 0 nach dem devicepair?

Danke & Grüße,

Merhan

[Martin]

Am Mittwoch, 19. Dezember 2012 15:27:50 UTC+1 schrieb Merhan:

Hallo Martin,

funktioniert das auch auf dem Kanal für die Fensterkontakte?

Wenn ja wie lautet der entsprechende Befehl analog zu dem folgenden für die Antriebe?

set <TC_neu_Climate> devicepair 0 <vd> single set actor

bei einem Fensterkontakt ist dieser auch der Sender - also ds erste Argument. Der empfaenger ist nicht der Climate channel sondern der WinRec channel (daher Window-Receiver)
Somit ergibt sich
set <WIN-Contact> devicepair 0 <TC_WinRec> single set

den letzten Parameter [aktor|remote|both] kannst du im commandref nachlesen - hier ist both angebracht, was der deafult ist. Also kannst du ihn auch weglassten (set uebrigens auch).

Wofür steht eigentlich die 0 nach dem devicepair?

das ist ein Relikt (oder ein feature...). 'geschichtlich' gesehen war dies ein Kommando fuer Fernbedienungen - und das Channel-konzept war nicht "komplett". Man hatte (kann immer noch haben) eine Fernbedienung mit x Buttons. Man definiert nur ein Device, keine Kanale. Um jetzt pairen zu koennen musste man den Kanal angeben - das ist die '0' - also eben nocht '0' sondern eine Nummer zwischen 1 und x.

Die SW jetzt prueft, ob die erste Entity ein Channel oder ein Deivce ist. Wenn es ein Channel ist wird die Kanalnummer (also die 0) ignoriert. Du kannst also schreiben was du willst - hauptsache es steht ein string da.
Wenn die entity ein deivce ist wird die '0' als kanal oder button nummer interpretiert und sollte ein auch im device vorhanden sein.

Gruss
Martin

[Merhan]

Hallo Martin,

die Fensterkontakte kennen kein devicepair. Ist vielleicht pair gemeint?

Muss ich im Anschluss an beiden Geräten den pairmodus über die entsprechenden Tasten starten? Zumindest der Fensterkontakt lauscht ja sonst nie.

Danke & Grüße,

Merhan

[Martin]

Hallo Merhan

die Fenstekontakte kennen kein devicepair. Ist vielleicht pair gemeint?

nein - devicepair.
Welches model und sybtype stellt sich beim Fensterkontakt ein? Dann schalte ich es ggf frei.
Model sollte HM-SEC-RHS sein, dann sollte es funktionieren, devicepair sollte verfuegber sein
SubType 'threeStateSensor'

Muss ich im Anschluss an beiden Geräten den pairmodus über die entsprechenden Tasten starten? Zumindest der Fensterkontakt lauscht ja sonst nie.

beim TC geht es automatisch, beim fensterkontakt ist ein "Anlernen"  notwendig, da hast du recht.

Gruss
Martin

[Merhan]

Hallo Martin,

so wurden die Fensterkontakte bei mir erkannt:

model HM-SEC-SC

subType threeStateSensor

Grüße,

Merhan

[Martin]

ah - der ist noch nicht drin. Werde ich einbauen - alle sensoren sollten devicepair koennen...

Next Update...

Gruss
Martin