Brauche mal Hilfe.
Ich stelle gerade Teile meiner Heizungsregelung von FHT auf HM um. Bisher im Einsatz:
VCCU
1x HM-CC-TC mit HM-CC-VD (hatte ich noch rumliegen, geht)
1x HM-CC-RT-DN (geht)
Jetzt will ich aber einen Raum mittels
1x HM-TC-IT-WM-W-EU und 2x HM-CC-RT-DN steuern. Uns da komme ich mit dem peeren nicht so recht klar.
Meine Zielvorstellung wäre, dass ich eigentlich nur den HM-TC-IT-WM-W-EU mit FHEM paire und dann die HM-CC-RT-DN mit dem Wandthermostaten peeren (aber nicht mit FHEM paire) und nur über den steuere.
a) geht das? Wenn ja, wie?
b) Oder muss ich alle drei Geräte mit FHEM pairen und dann die passenden Kanäle peeren? Wenn ja wie? Klar, alle drei Geräte pairen, aber wie dann weiter?
Bonusfragen:
c) Ist meine Zielvorstellung vielleicht machbar aber aus Gründen die ich gerade nicht sehe blöd?
d) wie ist die Reihenfolge von peeren und pairen genau? Die Wikiartikel scheinen sich zu wiedersprechen. Einerseits wird behauptet, man müsse zuerst den HM-TC-IT-WM-W-EU mit FHEM pairen und dann die HM-CC-RT-DN peeren, andere artikel behaupten, es könne nur gepeert werden, wenn vorher nicht gepairt wurde.
Überhaupt werde ich aus den Wikiartikeln recht wenig schlau. Wenn ich das begriffen habe, werde ich gerne versuchen die Artikel zu ergänzen.
Kann mir jemand ein wenig auf die Sprünge helfen?
ZitatMeine Zielvorstellung wäre, dass ich eigentlich nur den HM-TC-IT-WM-W-EU mit FHEM paire und dann die HM-CC-RT-DN mit dem Wandthermostaten peeren (aber nicht mit FHEM paire) und nur über den steuere.
Macht keinen Sinn, da die Regelung im HM-CC-RT-DN liegt , und du Zugriff auf die Register dort brauchst.
deine b: ist richtig
dann peeren wie im Wiki mindestens Channel (Kanal) 01 _Weather und Channel (Kanal) 02 _Climate
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP (https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP)
generell gilt für HM
wenn gepairt, kann nur noch über Zentrale (Fhem,CCu usw) gepeert werden!
Hi,
also ich kenne keine Artikel wo das falsch oder widersprüchlich steht, aber scheinbar wird es immer wieder falsch verstanden. Es steht auch in jeder Bedienungsanleitung von den Geräten - Abschnitt anlernen ...
Ohne Zentrale - Geräte sind nicht an einer Zentrale angelernt
Bei beiden den Anlernknopf drücken (Siehe Bedienungsanleitung) und die Geräte werden mit der Standardfunktion angelernt.
Danach kann man beide oder ein Gerät an der Zentrale anlernen, das peering bleibt erhalten.
Mit Zentrale - beide Geräte sind fertig an der Zentrale angelernt (gepairt)!
Am "Sensor/FB" das Peering mit den Befehl peerChan (https://fhem.de/commandref_DE.html#CUL_HMpeerChan)mit entsprechenden Parametern starten.
Peering geht nur über die Zentrale, funktioniert danach aber völlig eigenständig wie im Fall "Ohne Zentrale"
Es gibt mehr Möglichkeiten.
Ein Gerät pairen und das andere nicht macht für mich keinen Sinn.
Sind deine Fragen damit beantwortet? Außer das ich keine Detailbefehle liefern kann?
Gruß Otto
P.S. Hary war schneller ;)
Zitat von: fhem-hm-knecht am 21 Januar 2018, 14:46:18
Macht keinen Sinn, da die Regelung im HM-CC-RT-DN liegt , und du Zugriff auf die Register dort brauchst.
Vielleicht habe ich dann die Architektur von HM an der stelle noch nicht erfasst. Kann man den Wandtermostat nicht so nutzen, das man dem sagt, welche Zieltemp man haben will und der übermittelt die weiter?
Also in etwa so, also ob man lokal am Rad dreht?
D.H. das funktioniert im Prinzip anders als FHT und HM-CC-TC / HM-CC-VD
Der Wandtermostat HM-TC-IT-WM-W-EU ist also nur eine Raumtemperaturmesstellte und sonst eigentlich nichts?
Zitat
deine b: ist richtig
dann peeren wie im Wiki mindestens Channel (Kanal) 01 _Weather und Channel (Kanal) 02 _Climate
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP (https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP)
Den Artikel hab ich gelesen.
Der hat mich eben genau nicht so richtig schlau gemacht. Aber mit euren Einlassungen bin ich jetzt etwas weiter.
Zitatalso ich kenne keine Artikel wo das falsch oder widersprüchlich steht, aber scheinbar wird es immer wieder falsch verstanden. Es steht auch in jeder Bedienungsanleitung von den Geräten - Abschnitt anlernen
Seufz. Warum sagen Leute sowas? Wie hilft mir das? Aber ich will versuchen mich zu erklären:
Ganz zu Anfang: In den Bedienungsanleitungen steht was von FHEM? Oder nur von der CCU, wo man deutlich weniger sieht als in FHEM und die meisten Dinge wie Channels etc dem Nutzer weitesgehend verborgen sind? Also ich finde das die Anleitungen Detailfragen im Umfeld zum Einsatz im FHEM nicht beantworten. Erwarte ich natürlich auch nicht.
Wikiartikel:
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP:
Zitat"Betrieb mit FHEM
Zuerst muss das Wandthermostat mit FHEM gepairt werden.
Das Pairing sollte wie in HomeMatic Devices pairen beschrieben durchgeführt werden.
Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden"
https://wiki.fhem.de/wiki/Peering_(HomeMatic):
Zitat"Ein direktes Peering zweier HomeMatic-Geräte ist nur möglich, wenn keines zuvor gepairt wurde."
Zu deutsch: Wer zuerst den oberen Artikel liest und dann den unteren wundert sich.
Zitatgenerell gilt für HM wenn gepairt, kann nur noch über Zentrale (Fhem,CCu usw) gepeert werden!
Aha. Im Artikel https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP: ist also nur peeren mit FHEM gemeint und keinesfalls peeren mit dem Thermostaten.
Und wer schonmal mit einem HM-CC-TC mit HM-CC-VD gearbeitet hat wird da auch nicht sofort drauf kommen, da geht das nämlich. Ventil <-> Wandthermstat <-> FHEM
Daraus ergibt sich, das jemand der meint, die Funktion der Kombination HM-TC-IT-WM-W-EU und HM-CC-RT-DN sei analog HM-CC-TC mit HM-CC-VD diese beiden Aussagen als widersprüchlich aufassen kann.
D.H. die Artikel sind nicht widersprüchlich, wenn man bestimmtes Vorwiesen hat. Gerade wenn man von HM-CC-TC mit HM-CC-VD und/oder FHT kommt, ist man aber gewohnt, dass das Peeren der Ventile mit dem Wandthermostat sehr wohl geht, auch wenn der Wandthermostat bereits mit FHEM gepairt (oder im Falle von FHT gepeert) ist. Man hat dann quais das falsche Vorwissen.
Versuch mal in dem Lichte mit den Anleitungen weiterzukommen. Schon nicht mehr so leicht.
ZitatOhne Zentrale - Geräte sind nicht an einer Zentrale angelernt
Bei beiden den Anlernknopf drücken (Siehe Bedienungsanleitung) und die Geräte werden mit der Standardfunktion angelernt.
Danach kann man beide oder ein Gerät an der Zentrale anlernen, das peering bleibt erhalten.
Ah. Okay. Und warum steht das nicht so in dem Artikel:
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP
? Da heissts ja nur: (so gut wie das Gegenteil der obigen Aussage:)
Zitat"Betrieb mit FHEM
Zuerst muss das Wandthermostat mit FHEM gepairt werden.
Das Pairing sollte wie in HomeMatic Devices pairen beschrieben durchgeführt werden.
Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden"
Also Danke für eure Einlassungen, mal sehen wie weit ich damit kommen.
Aber die Wikidoku ist in meinem Augen widersprüchlich oder mindestens suboptimal.
Wenn man weiss wie's geht vielleicht nicht.
Können wir uns zumindest darauf einigen, dass das suboptimal geschrieben ist? ;D
Warum nennst Du mich jetzt Leute? :'(
Mein einleitender Satz war nur die traurige Erkenntnis - und ich kenne nicht alle Artikel. ;)
Der erste Anlaufpunkt soll immer die Doku sein, der muss man vertrauen können. Im Wiki kann die Sicht eines bestimmten Users stehen.
Und in der Bedienungsanleitung steht
ZitatSie können den Homematic Heizkörperthermostat an andere Homematic Geräte oder an die Homematic Zentrale anlernen:
Und FHEM ist an der Stelle einfach die Homematic Zentrale.
Ich habe es versucht zu erklären, in der Bedienungsanleitung steht das Prinzip richtig erklärt. Wenn es beides nicht hilft, bin ich mit meinem Latein am Ende..
Gruß Otto
man muss doch nur 2 unterschiedliche vorgänge auseinander halten und verstanden haben. peeren und pairen. ist das wirklich so schwer und missverständlich?
wenn das klar ist, sollte ebenfalls klar sein, dass die durchführung des peerens ohne dabei die zentrale zu benutzen (direktes peeren), nur möglich ist, wenn beide zu peerende devices noch nicht gepaired sind.
ich finde alle zitate konsistent.
Hi!
Zitat von: frank am 22 Januar 2018, 09:55:11
ich finde alle zitate kosistent.
Das ist ja Mal kosequent!
Gruß Franz
Nur ein detail.... Der tc uebermittelt nicht weiter wenn die zentrale sendet. Ich bin mir sicher es schon beschrieben zu haben::::::
Hm decives in teams oder peerings senden an ihre freunde., wenn man bei ihnen manuell etwas einstellt. Alle anderen müssen hören.
Wenn du am tc die temp änderst (lokal) sendet er es seinen Freunden. Wen du an der zentrale aenderst sendet die an ihre freunde ( das musste ich natürlich implementieren). Die zentrale erkennt die Gruppe am peering. Also muss gepeert sein (richtig!!), getconfig muss komplett sein und es darf kein fehler im code sein. Natürlich muss man warten bis der rt aufwacht. 2 mal. Bei ersten mal wird gesetzt. Bei 2. mal meldet er es zurück. Also setzzeit und meldezeit beachte .
Sollte alles im wiki stehen.
Hallo all,
vielen dank für Eure Antworten, die mich überwiegend in Form von Puzzleteilen weiterbringen.
Wenn ich aber mal prinzipiell anmerken darf - auf eine Frage der Art (verkürzt):
"Ich habe mir allerlei Artikel und Anleitungen durchgelesen und leider trotzdem nicht verstanden wie das genau geht"
die Antwort (verkürzt) zu geben:
"Da musst du dir nur alles genau durchlesen, das steht da ja drin"
ist deutlich weniger hilfreich als viele zu denken scheinen. Das ist eben keine Hilfe, sondern vielmehr ein verkapptes: "Bist leider zu blöd/faul/weniger-schlau-als-ich, da kann ich dir auch nicht helfen".
Wenn z.B. jemand sagt: "Der Wikiartikel ist nicht verständlich, dann hilft es genau NICHT zu sagen: "ICH verstehe den aber!".
Das zwar zweifelsohne eine wahre Aussage, wird aber überhaupt nichts daran ändert, dass andere ihn eben nicht verstehen. Die Frage ist hier: WARUM verstehen ihn andere nicht.
Und hier wird eben als allererstes so gut wie immer so geantwortet, dass implizit zu erkennen ist, dass die Person die den Artikel/Doku nicht verstanden hat, leider irgendwie selber Schuld ist. Und gleichwohl das sicher im Einzelfall auch sein kann, so kann es genauso gut sein, dass die Artikel z.b. nur mit Wissen zu verstehen ist, das nicht jeder hat oder der Artikel schlicht nicht gut geschrieben ist. Oder die Person gerade mal auf dem falschen Dampfer ist.
Warum diese Möglichkeit grundsätzlich als wenig wahrscheinlich angesehen wird kapiere ich einfach nicht.
Was bewegt überhaupt IRGENDJEMAND einen Post mit einem (mehr oder weniger): "Ist doch klar, wieso kapierst du das nicht, aber okay du musst den Flunzdüsen einschalten, dass muss ja wohl als Antwort reichen!" zu beantworteten? Soll das eine Hilfe sein?
Das ist in Foren allgemein ein sehr sehr gängige Methode Fragen zu beantworten und ich WUSSTE, dass ich diese Sorte von Antworten hier auch bekommen werden. Ich beobachte bei mir und auch anderen, dass Sie sich zum Teil schon nicht mehr trauen, Fragen zu stellen, weil klar ist, dass solche Kommentare kommen.
Das finde ich schade.
Es ist ja okay, wenn Einzelne zwar wissen wie es geht aber gerade keine Lust haben zu helfen! Wirklich! Aber wie wäre es denn dann, einfach nix zu sagen?
So, ich werde jetzt aus den diversen Antworten hier mir ein Bild zusammenbauen, wie das vermutlich geht, ausprobieren und dann habe ich es irgendwann richtig kapiert und dann werde ich die Wikiartikel ein wenig ergänzen.
So war schon bei der VCCU, die übrigens auch wirklich ganz einfach ist ... sobald man mal verstanden hat wie's geht und warum.
Falls du mich meinst... Ich habe versucht zu erklären. Was ich im Wiki schon gemacht habe.
Ich habe mit dem einsteigerdoc angefangen, weil dies eine Sequenz hat ( glaube ich). In Wiki sehe ich einige Probleme. Gut, dass einige sich einbringen und ihre Zeit investieren. Schade aber, dass es keine Struktur gibt. Ich habe versucht, auch in Wiki ein paar Grundsatzthemen zu beschreiben. Enttäuschend dann immer wieder, dass generelle Themen noch einmal beschrieben werden. So bspw das Protokoll was auch im rt beschrieben wird. Hoffentlich keine Wiedersprüche, hoffentlich besser. Aber leider kein Konzept. Da verstehe ich dich.
Ich nehme auch nicht für mich in Anspruch, gut zu erklären. Wenn es einer verstanden hat sollte er dieses Detail in Wiki doch bitte korrigieren. Und nicht neu an anderer Stelle eine Konkurrenz Erklärung eintragen.
Was hast du nun nicht verstanden, was nicht gefunden und was ist dein Plan? Dann könnte man eine einfach einmal durchgehen.
Nein Martin, ich meine nicht dich.
Was ich machen will steht eigentlich in meinem ersten Post.
Ich versuche es nochmal anders:
Am liebsten würde ich die beiden Ventilantriebe mit dem Thermostat peeren und den Thermostat dann mit FHEM (VCCU) pairen. Warum? Weil ich es so vom älteren HM Thermostat mit den älteren HM-Antrieben sowie FHT so gewohnt bin und weil ich damit weniger Geräte in FHEM hätte, weniger Load, weniger Clutter und Regelung am Thermostat ginge auch noch, wenn FHEM mal tot wäre.
Mein Frage war nun: Geht das und wenn nein, (Warum nicht), dann muss ich ja alternativ alle Geräte mit FHEM pairen und dann bestimmte Channels peeren. Wie man *letzeres* (Channels in FHEM peeren) machen müsste hab ich auch nicht direkt kapiert. Wie ginge das genau?
Die erste Antwort von fhem-hm-knecht war noch okay, obwohl ich gewisse Zweifel habe, dass sie richtig ist:
Zitat"Macht keinen Sinn, da die Regelung im HM-CC-RT-DN liegt , und du Zugriff auf die Register dort brauchst."
Wieso brauch ich den Zugriff? Wenn die Antriebe mit dem Thermostat gepeert sind, sag ich dem: "Mach mal Zieltemp 22Grad" (set xy_Clima desiredTemp 22), der übermittelt das an die gepeerten Ventieltriebe, ausserdem ebenso die vom Thermostat ermittelte Raumtemperatur (die die am Ventiltrieb lokal gemessene ersetzt), die Ventieltriebe stellen dementsprechend Öffnungswinkel ein ... fertig.
Wieso soll das nicht gehen?
Deine letzte Antwort liest sich ein wenig so, also ginge das tatsächlich nicht, ich bin mir aber nicht sicher, ob sich deine Einlassung nicht doch auf die Situation: Alles mit FHEM pepairt und dann gepeert bezieht.
Alle nachfolgende Antworten waren dann wenig zielführend bis nachgerade sinnlos (frank - der nicht mal die Frage verstanden zu haben scheint, mich aber als regelrecht blöd darstellt).
Und das nerft. Ich bin jetzt soweit, das einfach alles der Reihe nach auszuprobieren. Dauert lang bringt aber mehr als manche Antwort hier.
Wenn du mir aber helfen willst wäre ich froh. Vermutlich reichen 4-5 Sätze um mir 2 Stunden rumspielen zu ersparen.
Also direkt peeren sollte gehen. Das beschreibt eq3.
Grundsätzlich wird es hier anders gelöst. Grundsatz 1: erst alle Device pairen. Ich hoffe das ist klar beschrieben.
Dann peeren. Siehe
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_02_Climate
Du musst warten bis die Kommandos übertragen sind.
Grundsatz2: hminfo protoevents zeigt ob alles übertragen ist. Clear msgEvents löscht alle Events und erhöht somit die Übersicht.
Nach dem peeren überträgt der TC die Einstellungen an den rt.
Nun muss der TC noch mit dem weatherchannel gepeert werden. Dadurch überträgt der TC die Raumtemperatur an den rt. Also 2 peerings.
Grundsatz3: Device leiten keine settings weiter. Was heißt das? Das Gerät, an dem die Einstellung vorgenommen werden sendet an die Peers. Verstellst du also die Solltemperatur am TC sendet dieser an alle Peers, also die rt.
Verstellst du die Temperatur an der Zentrale muss diese es an den TC und den rt senden. Fhem macht das, wenn die Peers gelesen sind. Also getconfig, dann speichern.
Nun ist fast alles fertig.
Jetzt würde ich Templisten anlegen. Macht Sinn. Hier ist meine Empfehlung hminfo zu nutzen. Als Startpunkt die Templisten auslesen ( nach getconfig schon erledigt) und mit hminfo speichern.
Nun editieren. Immer erst die Temperatur dann die Zeit bis zu der die Temperatur gelten soll. Am Ende jeden Tages zwingend 24:00 eintragen. Das muss der letzte Eintrag sein.
Die Templisten im TC und rt programmieren.
Als attr webcmd sehe ich desired-temp:controlMode:tempTmplSet. Das ist alles was ich brauche.
Klar soweit?
Im Prinzip kapiert.
Temperaturlisten würde ich ungerne machen. Das ist für uns zu unflexibel. Wann geheizt werden muss, ist hier jeden Tag anders und das meint: Jeden Tag nicht nur jeden Wochentag. Bei mir steht daher grundsätzlich immer alles auf manuel und die Temperaturen werden nur durch FHEM selbst per set desiredtemp gesteuert. FHEM erschliesst aus relativ komplexen Scenarien ob und wer wann im welchen Zimmer sein könnte, und heizt dann oder nicht. (vereinfacht in etwa: Bewegungsmelder im Schlafzimmer1 nachts mehrmals ausgelöst? Jemand ist drin, also morgens Schlafzimmer, Flur und Bad anheizen, Anheizuhrzeit ja nach wem ob WE ist oder nicht. Bewegungsmelder nur 2x ausgelöst? Es hat nur jemand was rausgeholt, es wir am Folgemorgen nicht geheizt.)
Kurzum: Unser Leben ist für Templisten zu unregelmässig.
Deswegen meine ich ja, das es für mich reichen würde, wenn ich dem TC sage: set desiredtemp xy und der gibt das dann weiter. Der Zustand der RT interessiert mich eigentlich gar nicht.
Mir scheint, das dein Grundstatz3 dem entgegen steht. Aber womöglich eben nur dann, wenn man die RTs alle mit FHEM paired und nicht "nur" mit dem TC peert und das dann mit FHEM paired?
Oder anders: Ist Grundsatz1 so weil "wir es überwiegend so machen, es ginge aber wohl auch so wie du meinst" oder weil "Geht mit FHEM nur so"?
Ich glaube dass ist die entscheidenden Frage.
Bin mal gespannt, wann du aus dem Theoriemodus, in den Praxismodus übergehst.
nun, alles ok. Man kann ohne templisten leben, kein Problem.
ZitatDeswegen meine ich ja, das es für mich reichen würde, wenn ich dem TC sage: set desiredtemp xy und der gibt das dann weiter.
im Prinzip ja, im Detail nicht.
Nur damit du verstehts, wie es funktioneirt.Wenn du am TC änderst gibt er es an den RT weiter. Wenn du am Tablet die temp des TC änderst gibt nicht er es an den RT sondern FHEM macht das. Ist eben so, liegt an eq3. FHEM muss das peering kennen!.
Der Grundsatz steht dem nicht entgegen. Von aussen sieht es aus, wie du meinst. Intern ist es etwas anders. Macht aber am Ende keinen Unterschied. Du stellst die Temp um, TC und RT reagieren. Fertig.
Ein Problem sehe ich also nicht.
So und inzwischen sind wir weiter.
Um es kurz zu machen: Das von mir Gewünschte geht (Entgegen dem was man viele zu meinen scheinen)
Was hab ich gemacht?
1. CT mit RT "Angelernt" (gepeert)
2. den CT dann mit FHEM (VCCU) gepairt.
Fertig.
Im RT wird jetzt nur noch die am CT eingestellt ZIELtemperatur angezeigt.
Wenn ich per FHEM nun mittels "set FC desiredTemp 8" am FC die Zieltemp ändere, dann steht ca. eine Minute später die auch am gepeerten RT im Display und das Ventil wird zugefahren.
Ich ich kann auch am CT oder RT die Zieltemperatur ändern, die neue wird an allen Geräten angezeigt und auch an FHEM übertragen.
Alle Werte/Readings des RT sind in FHEM natürlich nichts zu sehen. Ist mir im Grunde aber egal.
Next step: CT wieder mit fhem unpairen und ein weiteres RT peeren,
Dann sehen ob noch immer alles geht.
Würde mich wundern wenn nicht.
@fhem-hm-knecht: Meine Idee war, das jemand WEISS, dass das so geht und einfach sagt: Ja, kann man so machen.
Das hat hier aber keiner, sondern alle haben mir gesagt: "Das macht man so nicht." Du übrigens auch.
Die Wikiartikel erwähnen diese recht simple Möglichkeit ebenso mit keinem Wort.
@martinp876
Ich denke,ich verstehe das schon. Wenn alles mit FHEM gepaired ist, dann muss auch die Kommunkation über FHEM laufen, das ist klar. Un dann muss auch in FHEM passende Channels gepeert werden. Meine Frage war eigentlich von Anfang an: Aber wenn man nur den FC paired und die RTs wiederum nur mit dem FC peert, dann geht die Kommunikation auch FHEM <-> FC <-> RT, oder?
Und die Antwort ist, wie ich jetzt durch AUSPROBIEREN rausfinden konnte: Genau so ist es.
Aktuell glaube ich offen gestanden: Die meisten hier haben das immer anders gemacht und und haben es daher schlicht nicht gewusst.
ZitatIst mir im Grunde aber egal.
;) Wenn du irgendwann einen Beitrag schreibst mit einem Problem vom TC oder RT , dann ziehe ich dich auf!
dann gilt der Spruch von oben.
ZitatAktuell glaube ich offen gestanden: Die meisten hier haben das immer anders gemacht und und haben es daher schlicht nicht gewusst.
schau mal was der Otto123 geschrieben hat!
Zitat
Ohne Zentrale - Geräte sind nicht an einer Zentrale angelernt
Bei beiden den Anlernknopf drücken (Siehe Bedienungsanleitung) und die Geräte werden mit der Standardfunktion angelernt.
Danach kann man beide oder ein Gerät an der Zentrale anlernen, das peering bleibt erhalten.
Du hast jetzt 6 Tage gebraucht um diesen Satz von Otto123 zu bestätigen, Topp Leistung.
;)
Zitatschau mal was der Otto123 geschrieben hat!
ZitatOhne Zentrale - Geräte sind nicht an einer Zentrale angelernt
Bei beiden den Anlernknopf drücken (Siehe Bedienungsanleitung) und die Geräte werden mit der Standardfunktion angelernt.
Danach kann man beide oder ein Gerät an der Zentrale anlernen, das peering bleibt erhalten.
Du hast jetzt 6 Tage gebraucht um diesen Satz von Otto123 zu bestätigen, Topp Leistung.
;)
Ja. Richtig, das war in der Tat die sinnvollste Antwort, wenn gleich doch recht knapp und im möglichen Wiederspruch zu deiner und verborgen in eine Menge Zeug des Tenors: "Bist zu blöd das Handbuch zu lesen oder?"
Ferne blieb die Frage, ob das dannach so funktioniert wie ich es als Wunschvorstellung formuliert hatte. "Peering bleibt erhalten" deutet darauf hin, aber expliziet gesagt ist das nicht. Warum nicht? Otto gerade zu faul die dazu nötigen 4 Wörter mehr hinzuschreiben? Angesichts der Länge seines Posts unwahrscheinlich. Mit anderen Worten: Er war sich nicht sicher oder hat meine Frage (wie vermutlich viele) doch nicht so genau gelesen oder ich frage halt richtig scheisse.
Alles keine Thema, aber immer muss ein agressiver Unterton hier in die Antworten.
Auch du jetzt wieder: DU hast mir eine defintiv irreführende und teilweise falsche Antwort gegeben, obwohl zugegeben trotzdem indirket hilfreich und zunächst sachlich, aber jetzt hackst hier trotzdem auf mir rum. Warum?
ZitatZitatMeine Zielvorstellung wäre, dass ich eigentlich nur den HM-TC-IT-WM-W-EU mit FHEM paire und dann die HM-CC-RT-DN mit dem Wandthermostaten peeren (aber nicht mit FHEM paire) und nur über den steuere.
Macht keinen Sinn, da die Regelung im HM-CC-RT-DN liegt , und du Zugriff auf die Register dort brauchst.
Diese Antwort war schlicht falsch, trotzdem wird hier
meine "Leistung" ironisch kommentiert.
Keine Selbstkritik? Kein "Ja, sorry, ich hab deine Anforderung falsch verstanden" oder sowas?
Nö.
Und nebenher: Ich habe nicht 6 Tage gebraucht um das dann auch so zu machen, sondern nur 20 Minuten. Das ist nämlich die Zeit die ich seit Ottos Post für diese Sache insgesamt nebenher aufbringen konnte.
Ausdrücklich danken möchte ich Martin. Seine Post sind nicht immer leicht zu verstehen, wenn man nicht im Thema steht, aber er macht sich nicht über Fragende lustig und wegen ihm funktioniert die ganze Chose überhaupt.
Pairing ist kein reset. Peerings und Register bleiben erhalten.
Wenn man den rt nicht pairt kann man keine Kommandos aus fhem schicken. Wenn man die temp am TC von fhem ändert schickt er das nicht an den rt. Mein rt hat nicht reagiert.
Welchen Sinn es haben sollte, einen rt nicht zu pairen erschließt sich mir nicht.
ZitatWenn man die temp am TC von fhem ändert schickt er das nicht an den rt.
Macht er bei mir. Jede Änderung der Zieltemperatur sei es in FHEM oder an einem der beiden Heizkörperthermostate oder am Wandthermostat wird auf alle anderen "Instanzen" verteilt.
ZitatWelchen Sinn es haben sollte, einen rt nicht zu pairen erschließt sich mir nicht.
Also zunächst mal: Es geht nur um Räume, in denen es MEHRERE Heizkörper und eine Wandtermosthaten gibt. Ich habe Zimmer mit bis zu 4 Heizkörpern, der Raum um des es hier geht hat immerhin noch 2.
Da sehe ich folgenden Sinn:
Anstatt drei Geräte die mit FHEM gepairt sind - nur eines. 66% weniger Funkkontingentverbrauch an der FHEM Funkschnittstelle. Verstellen der Temperatur lokal "am Geräte" wird zwar am FHEM gemeldet (kann also drauf reagieren, wenn man das denn will), aber nicht
durch FHEM an die Heizkörperthermostate verteilt. Also auch hier weniger Load, geht auch wenn FHEM tot ist. Wenn man Wochenprogramme nutzen
würde, kann und muss man es nur an den Wandthermostaten senden. config File kürzer, da weniger defs. Schneller einzurichten, da keine Channels einzeln mit mehreren Geräten gepeert werden müssen.
Das sind aus meiner Sicht alles Vorteile. Manche wiegen schwerer, andere sind ggf. nur theoretischer Natur.
Zugegeben, es gibt auch Nachteile, man weiss insbesondere nichts über die Heizkörperthermostate, also z.b. nicht wie die Stellung des Ventieltriebs ist oder wie es der Batterie geht oder so. Man könnte auch nicht abweichende Wochenprogramme in diverse Heizkörper eines Raumes einspeisen... gleichwohl ich mir dafür im Moment nichtmal einen Anwendungsfall denken kann. Auch die am Heizkörper gemessene Temp kennt man nicht, nur ist da ja sowieso systembedingt nicht sehr zuverlässig, das ist ja mit einer der Gründe, warum man einen abgesetzten Raumthermostat haben will.
Kurzum: beim Pairen aller Geräte hat man mehr Kontrolle. Aber ich brauche die nicht. Ich will einfach nur einer Instanz sagen: Pass mal auf: Zieltemp ist 23 Grad, nu mach Ventile auf bis wir da sind.
Die Idee, dasa so zu machen ist ja nicht neu, FHT arbeitet so und HM zu Zeiten von HM-CC-TC mit HM-CC-VD ebenso.
ZitatWenn man den rt nicht pairt kann man keine Kommandos aus fhem schicken.
Genau, will ich auch nicht. Ich sende die Kommandos an den TC und
der spricht dann mit den RTs, indem er Zieltemp und gemessene Temp übermittelt und dann machen die RTs ihr Ding. Wozu soll ich direkt mit allen Heizkörpern reden? Funkload am HMLAN hochtreiben?
In Zimmern mit nur einem Heizkörper versuche ich es aktuell mit nur einem RT (mal sehen, wir gut die Idee ist die Raumtemp direkt am Heizkörper zu messen in der Praxis ist) und den hab ich dann natürlich mit FHEM gepairt.
Ich sage ja nicht, dass mein Wunsch für alle die optimale Methode ist. Nur wenn ich meine Hütte hier komplett auf HM umgestellt habe, dann wären mal eben 20 RTs und mindestens 5 TC gepairt.
Da erscheint mir wenig erstrebenswert. Mit meiner Methode wären es ca. 5-6 TCs und dann noch mal vielleicht 5 RTs.
Bei identischer Grundfuntkionalität.
Vielleicht reden wir aber auch irgendwie grandios aneinander vorbei oder so. Der Hase liegt ggf hier im Pfeffer:
ZitatWenn man die temp am TC von fhem ändert schickt er das nicht an den rt.
Ja, wenn das bei mir auch so wäre, dann wäre die ganze Diskussion sofort zuende. :o
ZitatMacht er bei mir. Jede Änderung der Zieltemperatur sei es in FHEM oder an einem der beiden Heizkörperthermostate oder am Wandthermostat wird auf alle anderen "Instanzen" verteilt.
von wem? FHEM oder dem TC?
Wie gesagt in FHEM eingebaut, dass die temp im RT geändert wird. Hast du das zum Testen abgeschaltet?
Zitatnur eines. 66% weniger Funkkontingentverbrauch an der FHEM Funkschnittstelle
warum? ist der knapp bei dir? Empfangen muss es FHEM sowieso. Im übrigen will ich bspw Batterie sehen und Ventilöffnung loggen.
FHEM sendet nicht einfach so.
ZitatAlso auch hier weniger Load, geht auch wenn FHEM tot ist
hattest du das schon? Ich nicht. Was sagt deine Loadauswertung? Bist du an der Grenze? Kann ich mir kaum vorstellen, da ist typisch jede Menge Luft. Im Normalbetrieb kostet es nicht
fast nichts sondern
nichtsZitatDas sind aus meiner Sicht alles Vorteile. Manche wiegen schwerer, andere sind ggf. nur theoretischer Natur.
sorry, da sehe ich keinen. noch nicht einmal theoretisch, wenn man keinen groben Unfug treibt.
ZitatFHT arbeitet so und HM zu Zeiten von HM-CC-TC mit HM-CC-VD ebenso.
das Konzept von FHT kenne ich nicht. Den VD habe ich sehrwohl auch mit FHEM gepairt. Warum auch nicht.
Du kannst es gerne so machen. Allerdings halte ich alle Agrumente für Blödsinn - auch wenn dein TC die Temp überträgt. Vielelicht muss ich das noch einmal testen. Das mit dem Messageufkommen ist definitiv getestet und neutral.
Ich hoffe es gibt keine Nachahmer. Ich habe definitv keine Lust, solch seltsame Konfigurationen zu kommentieren.
Ich beispielsweise kontrolliere
- Button lock
- boost-time
- remote Kanal zur Abschaltung
- Regelparameter
- temp-offset
- maximale Ventilöffnung
Also viel Spass dir - und Nachahmer bitte vorsicht.
ZitatZitatMacht er bei mir. Jede Änderung der Zieltemperatur sei es in FHEM oder an einem der beiden Heizkörperthermostate oder am Wandthermostat wird auf alle anderen "Instanzen" verteilt.
Von wem? FHEM oder dem TC?
Wie gesagt in FHEM eingebaut, dass die temp im RT geändert wird. Hast du das zum Testen abgeschaltet?
Da die RTs nicht mit FHEM gepairt sind, kennt FHEM die doch gar nicht. Wie soll also FHEM das verteilen?
Die RTs waren auch NIE mit FHEM gepairt, wie ich schon schrieb: ich habe die ausgepackt und mit dem TC gepeert und dann das TC mit FHEM gepairt. Geht. Ich wüsste nicht, wie FHEM da irgendwas an den RTs verstellen sollte. Oder?
Zitat
Zitat66% weniger Funkkontingentverbrauch an der FHEM Funkschnittstelle
warum? ist der knapp bei dir? Empfangen muss es FHEM sowieso.
Aktuell nicht. Aber wenn ich erstmal 25 oder mehr RT und TCs gepairt habe mag das anders aussehen. Und Empfangen belastet das Funkkontingent von FHEMs Schnittstelle nicht und ausserdem würde ich meinen, dass der Funkverkehr eines nicht gepairten RTs bei FHEM auch weiter nix auslöst. Oder?
ZitatIm übrigen will ich bspw Batterie sehen und Ventilöffnung loggen.
Ja, ich sagte ja schon, dass wenn man das will bei meinem Setup Trauer hat, das ist einer der Nachteile. Ist für mich nur nicht wichtig.
ZitatFHEM sendet nicht einfach so.
Eben! Aber wenn ich 20 RTs und 5-6 TCs mit FHEM pairen muss und die Temperatur nicht über Wochenprogramme steuern kann, dann gibts potentiell eine MENGE Funktraffik, im Wohnzimmer mit 4 Heizkörpern müsste jede Tempänderunge an immerhin 5 Geräte verteilt werden, wenn ich im Raum selbst am TC was ändere muss FHEM 4 RTs Bescheid geben.
Zitat
ZitatAlso auch hier weniger Load, geht auch wenn FHEM tot ist
hattest du das schon? Ich nicht.
Nein, zugegeben nicht. ;D Und ich nutze FHEM seit 2007. Das ist nur eines der Argumente die ich hier immer wieder höre und ich wollte nur alle theoretischen Vorteile aufzählen.
ZitatZitatDas sind aus meiner Sicht alles Vorteile. Manche wiegen schwerer, andere sind ggf. nur theoretischer Natur.
sorry, da sehe ich keinen. noch nicht einmal theoretisch, wenn man keinen groben Unfug treibt.
Das ist schade, dass du das sagst. Wie man die Vorteile
bewertet ist sicher andere Frage. Für mich zählt vor allem, dass mich die Aussicht 25- 28 Thermostete unterschiedlichster Art zu paireen und dann nochmal zu diverse channels zu peeren irgendwie abgeschreckt hat. Aber ich will nicht nicht mal sagen, ob ich das am Ende nicht doch mache, oder mal so und mal so, ja nach Anfroderung. Ich behaupte auch nicht, dass mein Methode
BESSER ist, erste recht nicht besser für alle. Die Frage am Anfang des Threads war ja, ob man das so machen
kann wie ich das machen wollte.
Und die Antwortet lautet: Offenbar ja. Und zwar offensichtlich zur grossen Überraschung der meisten (oder gar aller) Poster in diesem Thread.
ZitatDu kannst es gerne so machen. Allerdings halte ich alle Agrumente für Blödsinn - auch wenn dein TC die Temp überträgt.
Hm. "Blödsinn" ist auch eine abwertende Formulierung. Wozu ist die nötig? Hier in diesem Forum gibt es in diversen andern Threads z.B. immer wieder das Argument man solle dies und jenes so und so machen, weil damit sichergestellt sei, dass das auch noch geht, wenn FHEM ausfällt. Ich halte das Argument auch für eher unwichtig, aber ist das Argument deswegen "Blödsinn"? Aber geschenkt, ich halte das aus. ;)
ZitatVielleicht muss ich das noch einmal testen. Das mit dem Messageufkommen ist definitiv getestet und neutral.
Naja, bei 4-5 RTs und 1-2 TCs glaub ich das auch. Oder sagen wir mal: Spielt keine Rolle. "Neutral" im eigentlichen Sinne des Wortes kann es nicht sein. Es sei den FHEM sendet Tempänderungen auch dann an RTs, wenn diese NICHT gepairt sind. Vielleicht ist das ja so, ich hatte das nur anders verstanden bisher.
ZitatIch beispielsweise kontrolliere
- Button lock
- boost-time
- remote Kanal zur Abschaltung
- Regelparameter
- temp-offset
- maximale Ventilöffnung
Also viel Spass dir - und Nachahmer bitte vorsicht.
Es ist absolut klar, dass "meine Lösung" nicht geeignet ist, wenn man das machen will. Das habe ich wirklich verstanden und auch schon geschrieben, dass ich das nicht brauche, sondern
nur die Temperatur steuern will und dies mit minimalen Konfigurationsaufwand. Ich bin erfreut, dass deine Implementation das erlaubt, auch wenn es von dir so nicht intendiert ware.
Irgendwie zeihe ich aber den Hass aller auf mich. Und das irritiert mich am meisten. Keiner sagt: "Ist ja spannend, wusste ich noch gar nicht" oder " Hm. Wir machen das eigentlich nicht so, könnte man aber mal testen". Nein, die Methode alles zu mit FHEM zu pairen und dann Channels zu peeren ist irgendwie ein Dogma und ich bin jetzt hier sowas wie ein Störefried.. 8)
Ich sag mal: Stand jetzt funktionieren Dank
deiner Arbeit beide Methoden und beide haben Vor- und Nachteile, kann jeder selbst entscheiden.
Zitat... und Nachahmer bitte Vorsicht.
Hm. Okay: Ich sags den Nachahmern dann hier gerne auch noch mal: In meiner Methode bekommt man keine Informationen von den RTs, nichtmal Valve% oder so. Wer das monitoren will kann es
nicht so machen wie ich es gemacht habe.
Ansonstnen fällt mir gerade nicht ein, was einem da echt um die Ohren fliegen könnte... Aber ich hab das erst 2 Tage am laufen und irgendwie scheine ich der erste zu sein, der das so macht. Also kann ich mich da Martins Ausführungen nur anschliessen: Ist nicht so gedacht und Communitysupport gibts dafür aktuelle eher nicht.
Und ehe ich es vergesse: Ich habe ne Menge gelernt, selbst aus den weniger nett formulierten Antworten. Daher: Vielen Dank!
15 rts plus einige andere devices. Es werden (deutlich) kleiner 100 msgs/h gesendet. Ein iodevice schafft 1600msgs/h vor den overload.
TCs bedienen ist allerdings teuer. Da reichen 100 msgs/h. Burst! Das ist 16fach teurer! Allerdings nur wenn man sendet. Nicht wenn man lauscht.
Rts sinnvoll eingebunden kosten nicht.
Aber sicher kann es bei 20 explodieren.
Schon mal die statistiken angesehen? Hminfo? Hmlan auslastung?
Vorsicht mit tips wenn man die fakten nicht geprüft hat.
Ich habe noch keine Zahlen. Denn noch sind nur 2 TCs und nur 5 Ventilantriebe im Haus, da ich noch fast überall FHT insalliert habe. Ich habe aber aktuell bereits einigen anderen HM Kram (diverse Schaltaktoren, Fernbedienung, Retroanzeige (die mit Burst), diverse Fenster/Tür Sensoren, Bewegungsmelder etc).Macht mir bisher kaum Sorgen, kommt aber eben noch dazu.
Wo ich das so aufzähle: Eigentlich unfassbar, was in meiner Hütte inzwischen alles verbaut ist. Dazu kommt ja noch jede Menge FS20 und reichlich IT. LOL.
Wird ein gepairtes TC automatisch im Burstmode betrieben? Schliessend aus der Verzögerung die die Übertragung einer neuen Temperatur braucht (mit ist so, als wenn das auch mal ne Minute und mehr dauert) hatte ich nicht den Eindruck.
Und wenn ich Temperaturen an eine RT übertrage dann gehts ohne Burst? Ich kann keinen Unterschied in der Übertragungsdauer feststellen. Na gut: Mit einer Stoppuhr hab ich es nicht gemessen.
Tips habe ich hier übrigens kein gegeben. Zu HM gebe ich bestimmt keine "Tips", dazu verstehe ich das System nun wahrlich nicht gut genug. Ich habe allerdings einen Fakt überprüft, nämlich das meine Idee geht.
Und das hat anscheinend vorher keiner, trotzdem habt ihr mir alle Tips ... okay, ich halt ja schon den Mund.
Den nächsten Raum mit 2 Heizkörpern werde ich dann mal nach der von dir favorisierten Methode anlegen, dann hab ich den direkten Vergleich. Hm. Da nehm ich am besten das Bad, denn da ist ein "Heizkörper" die Fussbodenheizung und da könnte mehr Kontrolle und Zugriff je RT sicher von Vorteil sein.
ZitatIch habe noch keine Zahlen.
dann Augen auf und du hast Zahlen.
get hm msgStatZitatWird ein gepairtes TC automatisch im Burstmode betrieben?
wie sonst? er bietet nichts andere an
Du kannst es machen, wie du willst, ist mir egal. Allerdings stört es mich, wenn hier Gerüchte hochkommen und andere deinem Beispiel folgen. Wäre dann zwar auch egal - nur dann bitte keine Fragen zu Problemen solcher Konfigurationen.
Man so eine Abschätzung. Du hast ein Schloss mit 200 RTs. Alles konfuguriert. Du hast nur ein IO (hoffentlcih ist die funkreichweite groß genug)
a) voyeur mode
FHEM lauscht, die RTs sind operationell. Message Belastung IO-Send: 0%
b)Goolge-Kalender:
Du sendest JEDEM RT alle 30 min eine neue Temperatur. IO-Send: 25%
Nun addierst du 50 TC
c) voyeur mode
FHEM lauscht, die devices sind operationell. Message Belastung IO-Send: 0%
d) Goolge-Kalender:
Du sendest JEDEM TC alle 60 min eine neue Temperatur. IO-Send: 50%. Durch Kollisionen kann dies deutlich steigen
e) der Wochenplan der RTs wird regelmäsig "überschrieben"
du hast ein templist file mit Wochenplänen. geelgentlich wird ein Wert geändert. Du führst alle 30min ein
set hm tempListG restore aus. Wenn sich das File nicht geändert hat passiert nichts. FHEM prüft dies.
Hat sich erwas geändert und alle RTs müssen einen kleinen Update bekommen (etwa 5 Werte sind geändert) wird IOsend: 50% sein
Alles unter dem Vorbehalt, dass du für die RTs auf Burst verzichtest.
@Martin, danke für deine vielen Erklärungen hier.
Der Thread hat mir als hauptsächlicher Zwave Nutzer geholfen HM (besondes was Heizen angeht) etwas besser zu verstehen. :)
Da ich gerade am überlegen bin die Fußbodenheizung + Raumthermostate per HM zu realisieren kommt mir das sehr geleben. ;)
Hallo Zusammen,
ich muss Zrrronggg! hier auch Recht geben.....Fhem ist ein so komplexes und wirklich schwieriges Thema udn ich habe mir den Thread hier durchgelesen udn kann mich hier auch wieder sehen und finden. Für viele hier im Board ist das alles Selbstverständlich...aber für uns halt nicht und mit "nur lese mal richtig" ist es mit fhem auch nicht getan.!!
Ich habe eben auch einen Thread eröffnet hier:
https://forum.fhem.de/index.php/topic,83715.0.html
und "Otto" hat mir auch gleich geantwortet....vielen vielen Dank Dir!! aber wenn ich ehrlich bin kann/konnte ich mit dem ersten Post von Otto nicht viel anfangen!!
Wie "PAIRE" ich den mit der zentrale..in meinem Fall ein CUL868????
Gruss
Markus
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
Mensch vor lauter pairing und perren...
Falsche Frage von mir..
Richtig wäre:
Wie peere ich den richtig das Device von der zentrale so das es auch ich hinbekomme
2. wie kann ich dann zb 2 heizkörperthermos untereinanddr von der zentrale peerren?
Gesendet von iPhone mit Tapatalk
Das kommando zum peeren ist immer peerChan. Das kommando wird immer von sensor aus aktiviert!!!!
Im wiki sollte es beschrieben sein-unter rt und tc.
Du kannst einen tc mit mehreren rts peeren. Hier musst du die weatherchan peeren. Der tc ist der sensor. Ein rt mit gepeerten weatherchan nutzt die interne tempmessung nicht mehr.
Man könnte auch einen anderen thermostat peeren
Dannn noch die geber kanaele. Also die clima ( lese es im wiki nach)
Rts kann man ueber die teamkanaele peere . dann tauschen sie die solltemp aus. Ist empfehlensweet fuer zimmer mit mehreren rt und ohne tc. Geht aber sicher auch mit tc!